Solution
Stop emailing status updates. Build a client portal.
Every "any update on this?" email is a question your customer should have been able to answer themselves, and answering it costs you more than you think.
Start with the workflow that costs you the most
Tell us what the process is and what it currently runs on. A senior engineer reads it and replies with either questions or a straight answer that we are not the right fit.
What is actually going wrong
Client portals get built for the wrong reason and then disappoint. The wrong reason is that it seems modern and a competitor has one. The right reason is arithmetic: count the emails and calls your team answers each week that are purely "where are we with this", multiply by the time each one takes including the context switch, and you have the actual business case. It is usually larger than people expect and it is measurable before you spend anything.
The second thing a portal does is less obvious and often worth more. It creates a single, timestamped record of what the client was told and when. Status updates scattered across individual inboxes are not a record, and their absence is felt precisely on the day a client insists nobody informed them of something.
The failure mode is building a portal nobody logs into. That happens when it shows less than an email would, when logging in is harder than sending a message, or when it is not kept current so the information inside it cannot be trusted. All three are avoidable and all three are decisions made at scoping.
You will recognise some of these
- Your team spends hours each week answering "any update?" by email
- Documents sent as attachments, then re-sent because the client cannot find them
- No record of what a client was told, or when, once a dispute starts
- Clients calling individual staff directly because it is the only way to get an answer
- The same status typed into an email over and over in slightly different words
- Onboarding a new client means a long sequence of emails chasing documents
What is included
- Secure client login with access scoped strictly to their own records
- Live status on whatever they are waiting for, drawn from your operational data rather than typed twice
- Documents and files in one place, with a history of what was shared and when
- Messaging attached to the record it concerns, so context is never lost
- Notifications when something they care about changes, so they do not have to check
- Multiple users per client with different permissions, since organisations are not single people
- An internal view for your team showing exactly what each client can see
What is not included
Stated as plainly as the inclusions. A fixed price only means something if the boundary around it does.
- A portal sitting on top of nothing. If your current status lives in a spreadsheet or a chat group, the portal will show stale information and lose your clients’ trust in a fortnight. The internal system comes first.
- Public marketing pages. This is the authenticated area behind the login, not a website rebuild.
- Billing and payment collection, unless it is scoped in deliberately. Showing an invoice status is straightforward; taking money is a regulated surface with its own requirements.
- Native mobile apps. The portal is responsive and works in a phone browser, which is what clients checking a status actually want.
- Unlimited document storage. Sensible limits are set at scoping, because storage cost scales with use and a surprise bill helps nobody.
Tell us which workflow it is
A short description of the process and what it runs on now is enough to get a straight answer on whether this fits.
Why most portals fail
They fail for three reasons and all of them are predictable. The first is that logging in is more effort than sending an email, so nobody does. If your client needs a password reset to check a status, they will email your team instead, and the portal has added a cost without removing one.
The second is stale information. A portal showing data somebody has to update by hand will drift, and the first time a client finds it wrong they stop believing any of it. The status has to come from your operational system automatically, which is why a portal built on top of a real internal system works and one bolted onto nothing does not.
The third is showing less than an email did. If the portal answers "in progress" when your client wanted to know which stage, when it will be finished, and what is blocking it, it has failed at the only job it had.
What clients actually want to see
Almost always the same four things: where it is now, what happens next, when it is expected, and what if anything is needed from them. Everything else is secondary, and portals that lead with dashboards and charts instead of those four answers are designed for the supplier rather than the client.
Documents come next, because attachment archaeology in an email thread is genuinely unpleasant. One place, current versions, with a record of what was shared.
What they generally do not want is your internal process exposed. Which of your staff is assigned, your internal notes and your workflow stages are usually noise to the client and occasionally embarrassing. Deciding precisely what is visible is one of the more important conversations at scoping.
Common questions
How do we know clients will use it?
Count the "any update?" messages you get now, because that demand already exists and is currently being served by your team. Portals get used when they are faster than emailing, which means straightforward login, information that is actually current, and the answers to the four questions clients really have. They go unused when they are slower or when the data inside them cannot be trusted.
Is client data properly separated?
Yes, and it is the part we treat most carefully. Access is scoped at the data layer so a client can only ever retrieve their own records, not merely hidden in the interface. This is where portal implementations most commonly go wrong, and the failure is serious: one client seeing another client's information is the kind of incident that ends relationships and triggers reporting obligations.
Can clients have multiple users?
Yes, and you generally want it. A client organisation is not one person: an operations contact, a finance contact and a director may all need access to different things. Multiple users per client with distinct permissions is part of the standard build rather than an upgrade.
Can we build the portal without rebuilding our internal system?
Sometimes, if there is already a reliable system holding current status that we can read from. If the status actually lives in a spreadsheet or a chat group, a portal on top of it will show stale information and lose trust quickly. In that case the internal system comes first and the portal follows, which is a sequencing question worth settling honestly at scoping.
How long does a portal take?
A focused portal fits the 30-day shape when there is a dependable internal source of truth to read from. Where the internal system has to be built first, that is the larger piece of work and the portal is a phase after it. Discovery establishes which of the two you are actually looking at, which is the single biggest factor in the price.
Related
The capability pages behind this work, and the other offers in this set.
Which spreadsheet would you kill first?
Describe the workflow and what it runs on today. If it is not a fit for a fixed-scope build, we will tell you that rather than sell you one.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.