How to build a client portal for your company

Three questions carry all the volume

In the vast majority of companies, three questions carry most inbound requests: where is my order, can you resend that document, and how much do I have left to pay or to use.

A portal that answers those three perfectly is used from the first week. A portal offering fifteen features and answering those three imperfectly is not, however good it is otherwise.

That is the only design rule that really counts here: the real frequency of requests, not functional richness. And it can be verified in half a day, by reading back a mailbox and a call log.

That review has a second merit. It separates what your customers ask from what you imagine they ask, and the gap between the two is often considerable.

Web portal, client portal, customer area: what the words cover

These four terms describe the same mechanism seen from four angles. A web portal is a single front door that brings together, behind one sign-in, information and services drawn from several systems. What changes from one word to the next is the audience that door opens to.

• Client portal: the audience is your customers. Each one finds their own orders, documents and deadlines.
• Enterprise portal, or intranet: the audience is your team. They find internal tools and information.
• Extranet: the audience covers your partners, resellers or subcontractors. Many tenders still use this term.
• Customer area: this is the commercial name of the client portal, the one your customers read in the top right corner of your site.

The word you settle on has an immediate practical consequence: it sets the scope of permissions. A client portal shows each person their own data, which assumes that every piece of information displayed knows who it belongs to. That is the first subject to handle, before the design and before the features.

The term also commits the project. Saying web portal leaves the question of audience open, and some decisions then wait for development to be settled. Naming the audience in the first sentence, a portal for customers, for teams or for partners, saves a good week of scoping.

The rest of this article says client portal, since that is the most frequent case. The mechanism described holds for all three audiences: what differs is the permissions granted and the vocabulary shown on screen.

A window, not a source

A portal holds no information. It displays what other systems know: the sales system for orders, accounting for invoices, the production tool for lead times.

That obvious point has a consequence almost always underestimated at quotation time. The visible part, the one you design and show in meetings, is about a third of the work. The other two thirds consist of fetching the information where it lives and translating it into language the customer understands.

A second consequence is harsher. An order status refreshed once a day is enough in most businesses. An inaccurate order status, however beautifully displayed, destroys trust in a single occurrence and sends the customer back to the phone for good.

The rule that follows is counter-intuitive but holds: when a piece of information is not reliable, it is better not to display it at all. A portal that shows less and is never wrong gets used far more than a complete but approximate one.

So for each piece of information, two simple questions belong in the framing phase: which system holds it, and how fresh is it really. The answers define the scope more surely than any feature list.

What a portal that gets used contains

Portals used daily almost always share the same base, shorter than people expect.

• Progress status, in the customer's words rather than the internal system's: "shipped, delivery expected Thursday" rather than a status code.
• Documents available without asking: quotes, delivery notes, invoices, certificates, manuals.
• The full history, so the customer never has to find an email from last year.
• One useful action: report a problem, request an intervention, reorder.
• The right people, with a way to reach them directly.

What can wait for a second version: statistics, dashboards, display personalisation. Those are appreciated by a minority of advanced users and often cost more than the entire base.

The first sign-in decides adoption

A well-designed portal can stay empty if the first sign-in is painful. Four decisions avoid that waste, and they cost little.

• A named invitation sent by your teams, rather than open sign-up.
• A sign-in link that works without a password to remember, or immediate reset.
• Several accounts per client company, with distinct rights: the buyer, the accountant and the technician do not have the same needs.
• Genuine mobile access, because a large share of consultations happens from a phone, often in the field.

Choosing the first invitees matters as much as the technology. Start with the customers who call most: they have the most to gain, and they become the best advocates with the others.

Consultation first, actions second

The build order has a direct economic justification: consultation delivers about four fifths of the benefit for a fraction of the cost.

So deliver sign-in, progress status, documents and history. Go live with a small group. Watch for a month. Then add the actions, knowing which ones are genuinely asked for.

One scheduling detail saves weeks: access requests to existing systems are launched on day one of the project, not the last. Getting read rights on a production system often involves people outside the project, and regularly takes longer than the connection itself.

Timelines, budget and monitoring

A portal centred on the three main questions, connected to an existing system, goes into production in one to two weeks and sits on average between 3,000 and 15,000 euros. As with any custom tool, that average has no limit at either end: a transactional portal, with payment, signature and several connected systems, sits several steps above.

Three things move that figure: the number of systems to query, the freshness required, and whether transactional features are included.

One line is regularly missing from quotes and deserves to be there: monitoring the connections. A portal whose data source stops overnight keeps displaying stale information without saying so, and it is the customer who finds out. Knowing that an exchange did not happen is well worth its cost.

Connection methods and their reliability: what custom software costs

One indicator of success

The right indicator is not the number of sign-ins: it is the drop in inbound requests on the subjects the portal covers. That is what translates into a gain for your teams, and it is measured by repeating the same review three months later.

Three effects then appear, all following from the first. Perceived lead times improve without anything changing in production, simply because the customer can see where their order stands. Document disputes fall, since everyone has the same paperwork. Sales teams recover time for higher-value conversations.

If you are considering a portal, do not start with a mock-up. Start with the review of last month's requests, and with an inventory of the systems holding the answers. That pair defines the scope, and it fits on one page.