A Client Portal Starts with What Happens After Submission
· Daniel Șotropa
A client portal usually gets judged by how easy the form is. That is the easy twenty percent.
What decides whether anyone keeps using it is everything after the button is clicked: what state the request is in now, who is moving it to the next one, what the client sees while nothing visible is happening, and what happens when something goes wrong. A portal that only models the path from “submitted” to “approved” will generate the same status-check emails as the mailbox it replaced, because the submission got a form and the exception did not get a home.
This article is about that other eighty percent, and why it belongs in the first version rather than the second.
What the person waiting actually needs
Order tracking is the best-measured version of this problem. In Baymard Institute’s research on it, half of respondents named tracking the single most important feature of their account, and they checked it repeatedly: straight after submitting, and again days later, to plan around the outcome and to avoid a follow-up call they would rather not make.
The same research found that two thirds of the sites tested failed to consistently show the details people were looking for, and a quarter gave no expected date at all. When the status view could not answer the question, people stopped using it and went to find the answer somewhere else.
Strip the e-commerce specifics away and the list of what a status view has to answer is short. What state is this in. Since when. Who is handling it. What happens next, and roughly when. A reference the client can quote. A history of what has already happened. A request portal for a services firm, a claims process, an application for a permit or a grant: the questions are the same, and so is the behaviour when they go unanswered.
Why status pages quietly fail
The failure is rarely dramatic. The portal goes live, the form works, and adoption stalls somewhere well short of everyone.
A 2026 UK survey of workplace self-service found that a quarter of employees still complete almost nothing independently through it, and only about one in five can handle nearly all of their needs that way. Everyone in between falls back to email or a phone call the moment a request stops being the easy, well-trodden case. Research into why people abandon self-service points mostly to one cause: not that they wanted a person, but that they could not find an answer.
That maps directly onto a portal with a thin status model. The request is “in review”. It has been in review for eleven days. Nobody can see why, nobody is named, and the only button is “contact support”. The client emails. The staff member answers the email instead of updating the record. Email has just proven faster than the portal, and it will keep winning.
A status without an owner is a holding pen
Here is the half that usually gets skipped. Naming a state is not enough; every state needs a role attached to it, with a next action that role can take.
“Submitted” is owned by whoever triages. “In review” is owned by a named reviewer, not a team. “Waiting on client” is owned by the client, and the portal should say so, with what is being waited for. “Approved” is owned by whoever delivers the outcome. When a state has a label but no owner, it is not a status. It is a queue that nobody is watching, and the fact that it now lives in a database rather than an inbox changes nothing about who clears it.
Formally, this is a state machine: a request is in exactly one state at a time, only certain moves between states are allowed, and some moves have conditions. You do not need the vocabulary to use the idea. You need a table with three columns, state, owner and next action, and the discipline to fill in every row before the first screen is designed.
Exceptions are states, not errors
This is where the table gets uncomfortable, and where it earns its keep.
Take an illustrative request portal. The straight-through path is submit, review, approve. The states that generate most of the email are the ones that sit beside it: a document is missing, the request was filed under the wrong category, the reviewer needs more information, the request is declined. Teams tend to model these as error messages or dead ends, and that is precisely why clients pick up the phone.
Each of those is a real state with a real owner. “Needs more information” belongs to the client, with a specific ask and a way to respond inside the record. “Declined” belongs to the reviewer, and the state has to carry the reason and whatever the next step is, whether that is an appeal, a resubmission or simply an end. A declined request that says only “declined” has told the client to call.
Modelling these first tends to make the happy path simpler, not more complicated, because the exceptions are no longer hiding inside it.
Where this does not apply
Some submissions genuinely are simple. A two-state process that really is two states needs a paragraph of thought, not a status model, and it would be dishonest to pretend otherwise.
Some people will also always prefer a person, especially for a declined claim or a sensitive application. That is not a design failure. A status view should always show a way to reach a named human, most of all at an exception state, rather than try to replace that route.
And a status model does not fix a staffing gap. If nobody has time to clear “in review”, moving the queue from an inbox to a portal only makes the backlog visible. That is still an improvement, because a visible backlog can be managed, but it is not the same thing as a solved one.
What this means for the first version
A first useful version of a client portal includes its exception states by definition. If it does not, it is not a first version. It is a form with a database behind it.
At Haiori that is where the scoping conversation for a portal starts: not with the fields on the form, but with the list of states a request can be in, who owns each one and what the client sees at each step. The form comes last, and it is usually the quickest part.
If you have a portal in mind, or a request process that currently lives in email and spreadsheets, tell us about it. Defining the status model is a short exercise, and it tends to make the rest of the scope clearer than the feature list did.