Building a Customer Portal: What to Include and Skip

A customer portal is usually commissioned to stop phone calls. That is a good reason, and it is also the test: if the portal does not answer the questions that generate the calls, it will not reduce them, however much else it does.

Start with the calls, not the features

Before designing anything, categorize a month of inbound contacts. Most businesses find a short list dominates: where is my order, what do I owe, can I have a copy of that document, I need to change something.

That list is your specification. Everything else is a candidate for phase two, no matter how enthusiastically it gets proposed in a workshop.

What earns its place in version one

• Status. Where the thing is, in plain language, updated from the system of record rather than typed in by staff.
• Documents. Invoices, contracts, reports — downloadable without asking. Usually the single highest-volume call category.
• History. What has happened on this account, in order, with dates.
• A way to ask. A structured request form that lands somewhere accountable, not a mailto link.
• Sensible access. Users see their own records and nothing else, enforced at the data layer.

What can wait

• Self-service editing. Letting customers change their own records sounds efficient and creates a validation and audit problem. Start with requests that staff approve.
• Payments. Genuinely useful, genuinely a separate project with its own compliance scope. Phase two.
• Messaging threads. You already have email. A second inbox nobody watches is worse than none.
• Dashboards and analytics for customers. Almost always requested, almost never used.
• Mobile apps. A responsive web page covers this. Revisit if usage proves otherwise.

The two things that decide adoption

Login has to be effortless. Portals die at the password. Use email magic links or single sign-on rather than yet another credential. If customers have to call to get into the portal that was meant to stop calls, the project has inverted.

The data has to be live. A portal showing yesterday's status trains people to phone and check. That means real integration with your system of record, which is usually the bulk of the build — and the part most likely to be underestimated when the visible deliverable is screens.

Launching it so people use it

A portal nobody logs into is the most common failure, and it is almost always a launch problem rather than a build problem.

• Seed the accounts. Do not wait for customers to register. Create accounts and send an invitation that lands them somewhere useful on first click.
• Point the existing channels at it. Put the link in invoice emails, order confirmations, and signatures. The portal has to appear where the question is already being asked.
• Let staff answer with it. When someone calls, the answer becomes "I can see that — and you can too, here is the link." That converts calls into adoption instead of just deflecting them.
• Watch the first month. Which pages get used, where people abandon, what they still phone about. That data is your phase-two list, and it beats any workshop.

Do you actually need one?

Sometimes not. If most calls come from a handful of large accounts, a scheduled report by email may solve it for a fraction of the cost. If the questions are genuinely varied and judgment-based, a portal will not deflect them.

The build is worth it when volume is high, the questions are consistent, and the answers already exist in a system — just not anywhere the customer can reach.

We scope these as web application development engagements, starting with the call analysis. If the underlying data is spread across systems, that is integration work first — see why the API question matters.

Send us your top five call reasons and we will tell you whether a portal fixes them.