A customer portal is a place where your customers answer their own questions instead of asking your staff.
That is the entire idea, and holding onto it prevents most of the ways these projects go wrong. Portals get scoped as platforms, with dashboards and messaging and document libraries and notification preferences, when the thing that justified the project was a single question being asked 40 times a week.
This article covers what makes a portal worth building, how to size the first version, and the four reasons portals get built and then not used.
What a portal actually replaces
Look at the interruptions your team handles, and sort them.
Status questions. Where is my order. Has my payment been received. When is the engineer coming. Where is my application in the process. These are the strongest case for a portal, because the answer already exists in a system and the only reason a human is involved is that the customer cannot see it.
Document requests. Send me last month's invoice. I need a copy of the certificate. Can you resend the report. Also strong, and often easier, because the answer is a file rather than a state.
Small transactions. Change my delivery address. Reschedule the appointment. Update who receives the invoice. Worth including when frequent, though these are more work than they look, because each one has rules about when it is allowed.
Questions that need judgement. Is this the right product for my situation. Can you do this by Friday. Why was I charged this. A portal will not remove these, and it should not try. Attempting to automate judgement is where portals become expensive and unsatisfying.
The exercise worth doing before anything else: for one week, have whoever answers the phone tally each contact into those four groups. The result is your business case, and it is usually more lopsided than anyone expects. A portal built for the first two categories can remove a large share of contacts. A portal built for all four removes fewer and costs several times as much.
Four questions that decide whether it is worth it
One: how often does the same question arrive?
Volume is what justifies this. Something asked twice a month is not a portal, it is an email. Something asked forty times a week, occupying a person for a substantial part of each day, is a portal with an obvious return.
Two: does the answer already exist in a system?
This is the question that decides feasibility, and it is the one most often skipped. If order status lives in an accounting package that updates overnight, a portal will confidently show yesterday's answer, which is worse than a phone call. If status lives in a spreadsheet someone maintains by hand, the portal project is really a data project with a screen on the end.
Before designing anything, establish where each answer lives, how current it is, and how it can be read. If the honest answer for a key question is "in the dispatcher's head", that has to be solved first, and it may be the whole project.
Three: do your customers already have an identity with you?
Portals need accounts, and accounts need a way to be created and recovered. For a business with named account customers and existing reference numbers, this is straightforward. For a business selling to occasional consumers who order twice a year, login is a real barrier and the portal may be less useful than a link in an email that opens the relevant record without a password.
Four: is the answer stable enough to publish?
If your delivery dates are estimates that move frequently, showing them creates a new problem: the customer now watches a date change three times and phones to ask why. Sometimes the honest sequence is to fix the underlying reliability first, then expose it.
Start smaller than feels sensible
The most useful advice in this article: the first version should answer one question, read-only.
Not a dashboard. One question, the one your customers ask most, shown accurately, with nothing else. Read-only, because the moment customers can change things, you need rules about what they may change, in which states, with what approval, and who is notified. That is where most of the cost and most of the risk lives.
The reasons this works are practical.
It can be built quickly, which means you learn whether customers will use it at all before committing a large budget. Adoption is the real risk in these projects and it cannot be predicted from a specification.
It fails safely. A read-only portal showing wrong information is embarrassing. A portal that lets customers change orders and gets the rules wrong creates operational and financial problems.
It reveals the second question. Once customers can see order status, what they ask next tells you what version two should be, and that information is far more reliable than a workshop held in advance.
The version-one scope for most businesses is roughly: log in, see your own records, see the current state of each, see the documents attached to them. That is small, it is genuinely useful, and it removes the largest category of interruption.
Why portals cost what they cost
The screens are simple. The cost sits behind them.
| Driver | Why it costs |
|---|---|
| Identity and access | Registration, login, password recovery, invitations, and the question of who at the customer's company can see what. A single-user account is simple; three colleagues with different rights is a different build |
| Permissions | Every screen must ask who is looking and what they may see. The rules are usually more complicated than described, particularly where customers belong to groups, branches or parent companies |
| Data currency | The answer must be current. Live connections to the system of record are more work than nightly copies, and often necessary, because a stale portal generates the calls it was built to remove |
| States | Each record's lifecycle must be shown in terms customers understand, including the awkward ones: cancelled, on hold, disputed, partially delivered |
| The mapping problem | Internal states rarely map cleanly to what a customer should see. Deciding what "awaiting allocation" means to a customer is a business decision, not a technical one, and it takes longer than expected |
| Security | Customer data behind a login raises the standard for access control, logging and data handling |
| Support for the portal itself | People forget passwords and query what they see. Lighter than the load removed, and not zero |
The mapping problem deserves emphasis because it surprises people. Businesses usually have more internal states than customers should see, and collapsing them into three or four honest, understandable ones is a design exercise with real consequences. Show too little and customers phone for detail. Show too much and they phone about states that do not concern them.
The four reasons portals fail
Nobody logs in. The commonest failure. Customers have a working habit, which is to phone the person they know, and a portal must be noticeably better than that habit for them to change. The most effective counter is to reduce friction to near zero: send the link directly in the notification the customer already receives, so the portal is reached in one tap rather than remembered as a destination.
The information is stale. A portal showing yesterday's state is worse than nothing. Customers check, doubt what they see, and phone anyway, so you now carry the cost of both channels.
It answers most of the question. Showing that an order has shipped without showing when it will arrive sends the customer to the phone with the portal open in front of them. Half an answer generates the contact it was meant to remove.
No reason to return. A portal used once at onboarding is a form, not a portal. Something must bring people back: a change they want to see, a document they need periodically, a state that matters to them.
The thread running through all four is the same. A portal competes with a phone call, and a phone call is very good. It is immediate, requires no password, and includes a human who can interpret. To win, self-service has to be faster than that for the question at hand.
Measuring whether it worked
Decide before launch how you will know, because portals produce satisfying-looking numbers that mean little.
Logins are not the measure. Neither are page views. Both rise during onboarding and tell you nothing about the workload.
The measure is the contact count in the categories the portal was built to replace, compared with the same count before launch. That is why the week of tallying at the start matters twice: once for the business case and once as the baseline.
Watch also for displacement, the contacts that changed shape rather than disappearing. If status calls fell but emails asking about what a status means rose, that is a mapping problem and it is fixable.
An illustrative example
A distributor with 40 dealer accounts takes roughly 60 calls a week asking where orders are. Order status lives in their accounting system and is accurate to within an hour.
The first proposal is a dealer portal with order history, invoice downloads, a reordering function, delivery scheduling, a support ticket system and a dashboard. Six months of work, and its value depends on dealers changing how they work.
The version that answers the actual problem is: a dealer logs in, sees their open orders with a state and an expected date, and can open the delivery note. Weeks rather than months. If dealer calls drop substantially, the case for reordering and invoicing is proven with real evidence rather than assumed. If dealers do not log in, the business has learned that for a fraction of the cost, and the reason will be informative.
The example is hypothetical. The pattern of a six-month proposal where a six-week one would settle the question is not.
Common questions
Portal or mobile app? Almost always a web portal first. It works on every device, needs no installation, and updates for everyone at once. An app is worth considering when customers use it often and would benefit from notifications or offline access, which is a genuinely small number of cases.
How do we get customers to use it? Put the link where they already are. In the order confirmation email, in the invoice, in the message they get when something changes. Sending an announcement asking customers to visit a new portal is the least effective available approach.
Can it be bought rather than built? Sometimes. If your operational system already offers a customer-facing module, evaluate it seriously, because the integration is done and it is likely to be the cheaper answer. The reason to build is usually that your customers need to see something specific to your business, or that the answers live across several systems. Build or buy sets out how to weigh that.
What about security? Customer data behind a login raises the standard. At minimum: an access model that has been reasoned through rather than assumed, a log of who saw and changed what, sensible session handling, and clarity about which data is exposed. Worth writing into the scope explicitly rather than leaving as an assumption, and what a scope document should contain covers how.
Will customers still phone? Yes, for the fourth category, the questions needing judgement. That is the right outcome. The aim is not to end contact but to end the contact that a screen could have handled, so the calls that remain are ones a person adds value to.
The short version
- A portal is somewhere customers answer their own questions. Status questions and document requests are the strong cases; anything needing judgement is not.
- Tally one week of contacts into four categories. That tally is the business case and the baseline you will measure against.
- Check where each answer lives and how current it is before designing anything. A portal on stale data generates the calls it was built to remove.
- Build one question, read-only, first. Write access brings the rules, the risk and most of the cost.
- Costs sit in identity, permissions, data currency, states, and the mapping between internal states and what a customer should see.
- Portals fail because nobody logs in, the data is stale, the answer is half an answer, or there is no reason to return. All four are versions of losing to a phone call.
Where to take this next
If you are still deciding whether this is a portal, a website addition, or a bigger system, website, web application or custom software settles the vocabulary and the boundary.
The cost drivers in this article are the same ones that shape any custom build, and what drives the cost of custom software covers why estimates vary so much for what sounds like a simple set of screens.
If you have run the one-week tally and want an opinion on what the smallest useful first version looks like for your situation, that is a conversation worth having early. Discuss your idea, or say hi on WhatsApp.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass. Cornerstone article, so these visuals will be referenced by later articles in the applications cluster and should stand alone.
Hero visual — the four kinds of contact
Concept. A week's contacts drawn as a horizontal band of small marks, sorted into four labelled groups of visibly different sizes: status questions (largest), document requests, small transactions, needs judgement. A brass bracket spans the first two groups with the label what a portal can answer. The remaining group is left plainly marked stays with a person.
Purpose. Sets the article's frame and, more usefully, gives the reader an exercise they can run on Monday.
Composition. Wide, roughly 4:1, marks illustrative rather than counted, captioned as such.
Alt text. A week of customer contacts sorted into status questions, document requests, small transactions and questions needing judgement, with a portal answering the first two groups.
Supporting visual 1 — the smallest useful portal
Concept. Two proposals side by side as screen inventories. Left, proposed: fourteen boxes covering dashboard, orders, invoices, reordering, scheduling, tickets, preferences. Right, first version: three boxes, log in, see your records, open a document. Underneath both, a rule marked at two points labelled months and weeks.
Purpose. Carries the article's strongest recommendation, which readers otherwise agree with and then do not follow.
Placement. In "Start smaller than feels sensible".
Alt text. A proposed portal with fourteen screens taking months, next to a first version with three screens taking weeks: log in, see your records, open a document.
Supporting visual 2 — the mapping problem
Concept. Two columns joined by lines. Left, nine internal states in operational language. Right, four customer-facing states in plain language. Several internal states converge on each customer state, and one internal state has a line ending in a small cross, labelled not shown.
Purpose. Makes visible the design decision that most often delays these projects and is rarely anticipated.
Placement. After the cost table, alongside the mapping paragraph.
Alt text. Nine internal operational states collapsing into four plain-language states shown to customers, with one internal state deliberately not shown.