A customer portal is not a website with a login button. That is where it starts, but it is far from where it ends.
A good customer portal is the place where customers (or partners, suppliers, distributors) find exactly the information and actions that would otherwise go by phone, by email or through a member of staff. Checking an order status. Downloading an invoice. Registering a return. Approving a document. Seeing open actions. Submitting a new request. Exchanging documents with your team.
The impact works both ways. On the customer's side: less dependence on your office hours, less repeating of information, more transparency about what is going on. On your side: less routine customer contact keeping people from work that really adds value.
In practice there are three types of portal we build regularly.
Each of the three calls for a different architecture, a different permissions model and different integrations. What they have in common is the question that always has to be answered first: what does a customer now do by hand that they could do themselves, and what do they need for that?
For end customers who want information about their file, order, contract or ticket. Think of a wholesaler whose customers can see their order history and outstanding invoices, or a service provider whose customers follow the progress of their project.
For third parties who supply or look up information in a structured way. A supplier keeping track of their invoice status, a distributor placing their orders, a partner managing customer files.
For employees who want to handle HR matters, IT requests or facilities requests themselves. These also count as a "portal" but are built internally.
A portal is not a standalone system but a combination of components. We go through them, including the Zoho applications that play a role in each part.
When the standard portal functionality of the Zoho apps is not enough (your own screen design, your own logic, integrations with external systems, specific workflows) we build the portal on Zoho Catalyst. That is Zoho's pro-code development platform for building your own applications and portals, within the same ecosystem as the rest of your Zoho environment.
The advantage is that the portal shares the user management, permissions and data of your Zoho environment, but is designed entirely to your requirements, including your branding, your screen layout and your process logic.
Customers now find their invoices, order status and documents themselves in the portal. Our sales support team gets noticeably fewer calls with the same questions.
The question asked most often when people start exploring is about cost. The most honest answer: it depends on what you put into it.
A portal that only shows invoices through Zoho Books can be delivered in weeks. A portal with full file access, document exchange, forms, ticket handling, an Exact Online integration and an ERP integration for order status is a project of months.
The payback period can almost always be demonstrated. Count the hours your back office, finance or customer service team spend on routine questions a portal answers on its own: sending invoice copies, passing on order statuses, emailing documents, phoning through updates. In most organisations we analyse, that is ten to thirty per cent of the volume of incoming customer contact. Work that out in person-hours per month and the business case writes itself.
That is the analysis we always do before the build request: what will the portal take on, what does that deliver, and what makes sense to build first?
Thinking about having a customer portal built? Request a trial environment first and see for yourself how the portal functionality of Zoho CRM, Zoho Desk and Zoho Books works. We are happy to help you get started.
A partner portal for distributors, agents or resellers calls for different choices than a customer portal for end customers.
We build portals as part of wider Zoho projects and as standalone projects. Our role always starts with the question of what the portal needs to do, not with choosing a template.
Our breadth makes our advice different from that of a web developer who builds portals in WordPress, or a Zoho reseller who only knows the standard portal functionality. We know the integration layer, the CRM logic, the financial integrations and the process questions that determine how a portal really works for customers.
And when it calls for custom work (your own screens, your own logic, integrations outside the standard) we have our own development team that builds on Zoho Catalyst. That is a combination you will not find together anywhere else: Zoho expertise plus pro-code development capacity, in one team.
A portal for customers in the Netherlands, Belgium and Germany speaks three languages, and each market has its own users, its own documents and sometimes its own pricing agreements.
Invoices for the Belgian entity look different from those for the Dutch one, with different VAT numbers, different legal notices and possibly a different accounting package as the source.
Which customer data do you store in the portal, where, and for how long? For customers in several EU countries the question is the same everywhere; for customers outside the EU, additional data transfer considerations come into play.
One country as a pilot, learn the lessons, then roll out to the next. Not everything at once, because then the feedback loop is too slow. We work in Dutch and English and tailor our support to the countries where you operate.
We always run a portal project in phases.
What does a customer do now that the portal needs to take over? We count the volume and calculate the business case.
Where is the standard Zoho portal functionality enough, and where is Zoho Catalyst needed for your own logic or screens?
Which customer can see which data, based on which field in which system?
Exact Online, ERP, WMS, telephony: which data does the portal need to fetch, and which system is the source?
Including the edge cases: what does a customer with no orders see, a customer with a blocked account, a customer logging in for the first time?
A select group of customers goes live first, with a feedback round.
Including documentation and agreements on who manages the portal and develops it further.
A website is public and informative. A customer portal is closed and transactional: customers log in with their own account and only see their own information (their orders, their invoices, their file, their tickets). They can also take action there: submit a request, upload a document, download an invoice. That requires integrations with your back-end systems that a regular website does not have.
That depends on the functionality you want to offer. Zoho CRM for customer files and account information, Zoho Desk for ticketing and support history, Zoho Books for invoices and payments, Zoho WorkDrive for document exchange, Zoho Forms for requests and reports, Zoho Sign for digital signatures, Zoho Learn for training and certification, and Zoho Catalyst for the screens and logic that fall outside the standard.
Yes. Exact Online has a REST API we use to fetch invoice data, payment status and customer information and show it in the portal. The customer sees the current position from Exact, without a separate administration being kept. We build the integration so the data is filtered per customer and only their own information is visible.
Security consists of three layers. The access layer determines who can log in, through which mechanism and whether multi-factor authentication is required. The permissions layer determines for each user which data they may see, and enforces that filtering technically, so it is not just a display restriction but a limit on the data itself. The transport layer encrypts the connection over HTTPS and governs how data is transferred between the portal and the back-end systems. When Zoho platforms are used, Zoho's security certifications and data processing agreements apply to the data stored there.
A simple portal that shows invoices and order status through the standard Zoho Books and Desk portal functionality can be live in a few weeks. A portal with a multilingual interface, your own screen design on Zoho Catalyst, document exchange, an ERP integration and a partner permissions model runs to months. We always work in phases, so you have something working early on that you can give feedback on.
Both are possible. Purely informative portals (downloading invoices, checking status) are the simplest version. Transactional portals also let customers act: place an order, register a return, submit a form, upload a document, give an approval. Those actions trigger an action in your back-end systems straight away.
Yes, and it then becomes a supplier or partner portal. The build is similar but the permissions logic is different: a partner may manage their own customers but not those of other partners, and the information they see (orders, commissions, leads) differs from what an end customer sees. We regularly build partner portals for distribution networks and agencies.
That is a design question, not a technical one. A good portal requires no technical knowledge: the interface is intuitive, the language is easy to understand and the actions are kept to a minimum. We always test with real users before a wide rollout. The less a customer needs to understand about the system behind the portal, the better the design.
Mobile XL builds customer and partner portals on Zoho, including integrations with Exact Online and other back-end systems.
