Client Portals in Practice: What Actually Changes in How You Work With Customers

Most of the custom software I build for clients is unglamorous. The single most reliably useful thing, across very different businesses, has turned out to be the most boring one: giving their customers a login.

Not a platform. A login, and four screens behind it.

This is what I have learned about what actually changes when you do that — including the parts that surprised me and the parts I got wrong.

What changes is not the workload

I used to pitch these on time saved. That framing is wrong, and clients who buy on it are often disappointed.

The queries a portal absorbs are individually tiny. "Where is my order." "Can you resend the invoice." "What did we agree on the delivery date." Each is ninety seconds. If you tally them and multiply, you get a number that looks unimpressive next to the build cost.

What actually changes is when the work happens.

Before: twelve interruptions scattered through a day, each one landing in the middle of something else, each one costing the re-entry cost on either side. After: the same information gets consumed by the customer at 22:40 on a Sunday, and nobody's Tuesday morning is broken.

That is a real productivity gain and it does not show up in a spreadsheet of minutes saved. It shows up as the person who used to be reactive all day being able to plan a morning.

The second-order effect nobody predicts

Here is the one I did not see coming: the portal changes what the client's own team knows.

To show a customer an accurate status, someone has to define what the statuses are. That sounds trivial. It is not. In most small companies, "where is this order" is answered by a person who reconstructs it from memory, three systems and a hunch. There is no canonical status because nobody ever had to write one down.

Building the portal forces that definition. And once the statuses exist and are updated, the company has, almost as a side effect, the operational visibility it had been talking about wanting for years. More than one client has got more value out of their own internal view of the status data than out of the customer-facing part.

If you are considering one of these: that is the argument I would lead with now. Not "your customers will self-serve" but "you will finally know where everything is."

The four screens

Every portal I have built that worked contains these, and the ones that struggled contained more:

1. Status. Where the thing is, in language a customer understands. Not "WIP" — what happened, when, and what happens next.
2. Documents. Invoices, contracts, delivery notes, reports. Pure retrieval, zero judgement, and it silently kills a whole category of email.
3. History. What was ordered, agreed or delivered before. This one is used less often than the others but it is the one that removes the worst task — someone digging through a year of email to answer a question.
4. One action. Reorder, approve, upload a file. Exactly one, chosen because it is the thing the customer most often wants to do next.

Anything past this in version one is a bet, and it is a bet you cannot evaluate because you do not have usage data yet. Ship four screens, watch for a month, then add what people actually reach for.

Three things I got wrong

Passwords. My first portal had a normal email-and-password login with a reset flow. Usage was terrible. B2B customers log in every few weeks at most, so the password is never in muscle memory and never in the browser's memory either — which means every single visit begins with a reset email. Magic links fixed this more than any other change I made. If the customer logs in rarely, do not make them remember anything.

Statuses that were honest but useless. I once mapped the portal statuses directly to the internal production states, because that was the accurate thing to do. Customers saw "Stage 3" and phoned to ask what Stage 3 meant. Accurate and useless. The customer-facing status needs its own vocabulary written for someone who does not work there — and it needs to say what happens next, because that is the actual question behind "where is my order."

Assuming announcement equals adoption. We launched one with an email. Two weeks later almost nobody had logged in, and the conclusion in the room was that customers did not want it. They did want it — they had forgotten it existed. What worked was mundane: the link went into every transactional email and every signature, and for two months the team answered routine questions with "I have just updated it in the portal, here is the link." Adoption is a habit you train, not a feature you ship.

When I tell people not to build one

Three situations where I have said no, or should have:

• The data does not exist yet. If order status lives in someone's head, the portal cannot show it. That is a systems project first, and pretending otherwise produces a portal that shows stale information and destroys trust in a month.
• Customers buy once a year. Portals compound through repetition. A once-a-year customer will always email you, because that is genuinely easier for them, and they are right.
• Nobody will own accuracy. The failure mode eighteen months in is not that the portal breaks. It is that it quietly drifts out of date, customers act on wrong information, and it becomes worse than nothing.

What I would tell a business owner

Do the counting exercise before anything else. For one week, tally every incoming question that you could have answered by pointing at a screen. If it is under ten a week, do not build a portal — write better email templates and move on. If it is thirty, you have a case, and the case is stronger than the minutes suggest, because the cost you are removing is fragmentation rather than time.

And scope it to four screens. Every portal I have seen fail, mine included, failed by being ambitious early instead of useful early.