A customer portal is a logged-in area where your clients can answer their own questions — where their order is, what they owe, what you sent them last March, what stage their project has reached — without asking a person.
That definition is deliberately narrow, and the narrowness matters. Most portal projects fail because someone widened it to "a place where customers do everything" before anyone had established that customers wanted to do anything.
We build these for mid-sized companies. Here is the assessment we run before quoting, including the version where the answer is no.
What a portal actually removes
Not work. Interruptions.
The hidden cost in most client-facing businesses is not the time it takes to answer "where is my order" — that is ninety seconds. It is that the ninety seconds arrives unscheduled, in the middle of something else, twelve times a day, and each one costs the context switch on either side.
So the question is not "how much time do we spend on customer queries." It is:
How many of the questions we answer this week are questions the customer could have answered themselves if they could see what we can see?
Count them for one week. Tally marks on paper are fine. If the answer is under ten a week, stop reading — a portal will not repay itself, and you should fix your email templates instead.
The four questions that decide it
1. Is the information already in a system? A portal is a window, not a filing cabinet. If order status currently lives in someone's head or in a spreadsheet updated on Fridays, the portal will show stale data and your customers will stop trusting it within a month. Fix the source of truth first, or accept that the portal project is really a systems project.
2. Do the same customers come back repeatedly? Portals pay off through repeat use. A customer who buys once a year will never log in — they will email you, because finding the password is harder than typing your address. High-frequency, ongoing relationships are where this works: recurring orders, long projects, ongoing service.
3. Is the question genuinely repetitive? "Where is my delivery" is a portal question. "Can you do this slightly differently" is not, and never will be. Sort a week of inbound messages into those two piles. The ratio tells you the ceiling on what a portal can deliver.
4. Will you keep it accurate? This is the one that kills projects eighteen months in. A portal showing wrong information is worse than no portal, because customers check it, act on it, and then call anyway — angry. If nobody owns data accuracy, do not build it.
What goes in version one
Almost always these four, and nothing else:
| Screen | Answers | Why first | |---|---|---| | Status | "Where is my thing?" | Highest-volume question in nearly every business | | Documents | "Can you resend the invoice/contract/report?" | Zero-judgement, pure retrieval, high frequency | | History | "What did we agree/order last time?" | Removes an archaeology task from your team | | One action | Usually reorder, approve, or upload | Gives a reason to return |
What does not go in version one: messaging (you already have email, and a second inbox nobody watches is a liability), dashboards and analytics (nobody asked), self-service configuration of anything complex, and a mobile app.
The discipline here is the whole project. Every portal we have seen fail was scoped as a platform. Every one that worked started as four screens that answered the four questions the phone was ringing about.
Build or buy?
A reasonable rule:
- Buy if your process is standard for your industry and a vertical product already models it. Do not build a bespoke portal to do what a well-established tool does, however tempting the customisation is.
- Extend if you already run a system — ERP, ticketing, accounting — that ships a customer-facing module. It will be uglier than a custom build and it will already be connected to the data, which matters more.
- Build when the thing customers need to see is specific to how you work, and no off-the-shelf model fits without distorting your process. This is more common in manufacturing, logistics and specialised services than in software, where standard tools cover most needs.
The honest failure mode of building is not cost — it is that you now own a login system, password resets, permissions, an audit trail and a security surface, forever. Budget for the second year, not just the launch.
Why portals fail after launch
Nobody logs in. The single most common outcome. Usually because the portal was announced by email once and never mentioned again. The fix is unglamorous: put the link in every transactional email, in the email signature of everyone client-facing, and — the one that actually works — have your team answer routine questions with "I've just updated it in the portal, here's the link" for the first two months. You are training a habit, not shipping a feature.
The login is harder than the question. If retrieving an invoice takes a password reset, customers will email you. Magic links beat passwords for low-frequency B2B users by a distance. This one decision affects adoption more than the entire UI.
It shows less than the person would tell you. If a customer logs in, sees "In progress", and still has to ring to find out what that means, the portal has added a step rather than removed one. "In progress" is not a status. "Cut and assembled, in painting since Tuesday, expected to ship Friday" is a status.
What it costs
For a scoped four-screen portal on top of a system that already has an API: typically a few weeks of build, and a similar amount again on authentication, permissions and the accuracy work nobody quotes for.
The number that matters more is the payback calculation, and you can do it yourself in five minutes:
- Repetitive queries per week × average handling time (add 50% for the interruption cost — people systematically forget the context switch either side).
- × 52, × loaded hourly cost.
- Compare to build cost plus a realistic annual maintenance figure.
- Then discount it by your honest guess at adoption. Thirty per cent in year one is a normal result, not a bad one.
That fourth step is the one that turns an optimistic business case into a real one, and it is the step almost every vendor leaves out.
Frequently asked questions
What is a customer portal? A secure logged-in area where customers can see their own information — orders, documents, status, history — and perform a small number of routine actions without contacting your team.
What is the difference between a customer portal and a client portal? Nothing meaningful. "Client portal" is more common in professional services, "customer portal" in product and B2B commerce. "Self-service portal" usually emphasises support use cases specifically.
How long does it take to build one? A well-scoped first version on top of existing systems is a matter of weeks, not months. If a proposal says months, ask what is in scope beyond the four screens above — the answer is usually where the budget went.
Will customers actually use it? Only if logging in is easier than emailing you. Assume roughly a third adoption in year one and build the business case on that; anything more is upside.
Do we need one if we already have good email support? If your customers are happy and your team is not interrupted, no. A portal solves interruption volume and out-of-hours access. If neither is a real problem for you, it is a solution looking for one.
What is the biggest mistake companies make? Scoping it as a platform. Four screens that answer the four most common questions beat a comprehensive system nobody logs into — every time, and it is not close.