A typical service case in a small company: the customer writes an email, someone on the team digs out the documents, replies, the customer asks two days later how things stand, someone checks again. Five messages for a matter that would take one minute of actual work. A customer portal promises to end this ping-pong. It does – but only for certain kinds of inquiries, and only if you set it up right. Let’s look at both.

What the ping-pong is actually made of

Watch your inbox for a week and you will usually find that most customer emails are not real questions. They are status requests (“Where does my order stand?”), document requests (“Could you send me the March invoice again?”), and incomplete inquiries that need two rounds of follow-up questions before anyone can start working.

These three categories share one trait: the answer already exists in your systems. Someone on your team merely acts as a human interface between the customer and a piece of information that has been sitting in the ERP, the CRM, or the file share all along. That interface work is precisely what a portal takes over.

What a portal handles – and what it doesn’t

To be honest: the tricky complaint call, the price negotiation, the annoyed customer – all of that stays on the phone and in email, and that is fine. A portal does not replace communication. It replaces lookups.

What it can absorb is everything routine: checking status, downloading documents, updating contact details, booking appointments, submitting structured requests. That last one is underrated. A form that asks for all required details up front spares the customer the writing and spares your team the two follow-up questions plus the retyping of whatever was said on the phone – mishearings included.

The most common planning mistake: launching with the full catalogue

Many portal projects start with a three-page wish list: requests, documents, payments, approvals, chat, knowledge base. That takes a year to build, costs accordingly, and in the end customers use two of the twelve features.

A better starting question: what do your customers ask most often? Usually two or three types of inquiry account for the bulk of the volume. A portal that does only those two or three things is built in weeks rather than months and takes noticeable traffic off the phone and the inbox right away. Everything else comes later – based on what customers actually use.

Why customers use the portal. Or don’t.

The legitimate worry before any portal project: what if nobody uses it? The worry has a real basis. In a Gartner survey of 5,728 consumers (2024), 73 percent of customers tried self-service at some point in their service journey, but only 14 percent of issues were fully resolved there. The most common reasons: the company did not understand what they were trying to do (45 percent), or there was simply no content matching the issue (43 percent).

Both problems hit generic help pages, not portals built on real order data: in a status view, the content is the order itself. Beyond that, in our experience adoption is decided at three unglamorous points.

The login: anyone forced to remember yet another password will pick up the phone instead. A sign-in link by email solves this – no password, no forgotten password.
The way in: every email your team sends should link straight to the right place in the portal. “You can track the status here” with a link beats any training brochure.
The phone: most customers open a portal on their phone, in the evening, in passing. If it is clumsy there, adoption is over before it started.

The team side: a portal is not a second inbox

One point that portal projects like to overlook: something has to change internally too. If portal requests land in a separate queue that someone manually transfers into the real system, you have moved the retyping, not eliminated it.

The portal should therefore not be its own data silo but a surface on top of your existing systems. The ERP or CRM remains the source of truth; the portal shows its state and writes changes back. That integration is the technically demanding part of the project – and the reason it belongs in the plan from day one, not in phase two.

What it costs and when it pays off

A lean first version – login, status view, documents, one request form, connected to an existing system – lands roughly in the range of €15,000 to €40,000 depending on your starting point. The wide range almost always comes from the integration: a system with a clean API connects quickly, a grown one without any interface needs groundwork first.

Set that against the time that flows into lookup work today. If two people spend an hour each per day on status answers, document hunting, and retyping, that adds up to around €18,000 a year at €35 fully loaded cost per hour. Whether the portal pays for itself after one year or three depends on your numbers – but that calculation belongs before the project, not after. If it doesn’t work out, we say so.