Ivara Labs
A client portal is easy to specify badly. Someone says "clients need somewhere to get their files," a tool gets bought, logins go out, and six months later the files are still going by email while the portal sits there holding an outdated copy of everything.
The project was not underfunded. It was aimed at the wrong target. A portal that only stores documents solves a filing problem, and filing was never what was costing anybody a day a week.
What a portal is actually for
The expensive thing in client work running on email is not storage. It is the same question arriving repeatedly, from different people, at unpredictable times, each one interrupting somebody who has to go and look something up before answering.
The job is deflection, not storage. A portal earns its keep by making the answer already visible.
That reframing changes the spec. Four jobs, and every one of them removes an inbound message.
If a portal does not do all four, the email channel survives, and a surviving email channel eventually wins.
The failure nobody scopes for
A portal your clients do not use is worse than no portal at all.
Not neutral. Worse. You now maintain two channels: the portal you paid for, and the email thread where the work actually happens. Your team updates both, or updates one and lets the other go stale, and clients learn that the portal is not authoritative.
Nearly every portal post-mortem lands here, and almost no portal proposal mentions it.
Adoption is not a launch communications problem to be solved with a nicer onboarding email. It is a design constraint, and it has to shape the build.
What actually drives adoption
- Make it the only path for at least one thing clients need. Approvals and invoices work well. If the sole route to approve work or pay you is the portal, people log in. Optional portals do not get used.
- Answer before they ask. The portal has to be faster than emailing you. If checking status takes three clicks and a password reset, email wins every time and deserves to.
- Do not require training for occasional use. A client who logs in twice a quarter will not remember anything. If it needs explaining, it needs simplifying.
- Send notifications outward, not invitations inward. Push the update to where they already are, with a deep link into the exact item. Do not ask people to remember to check.
- Kill the fallback channel deliberately. Gently and with warning, but genuinely. Answering the same question by email keeps the old path alive indefinitely.
Off-the-shelf against custom
Both are legitimate. The decision turns on the same two properties that decide any build, covered in build vs buy: is this differentiated, and is it stable?
| Off-the-shelf | Custom | |
|---|---|---|
| Time to live | Days | Weeks |
| Fits your process | You fit theirs | Built to yours |
| Branding | Logo and colours | Your domain, your product |
| Cost shape | Per-seat, per client, growing | Upfront, then flat |
| Connects to your systems | If they built the connector | By design |
| Who owns the client data | Held in their tenancy | Your accounts |
The row that decides it for most service businesses is the second one. Off-the-shelf portals encode a generic idea of how client work moves — intake, then a linear pipeline, then delivery. If your operation matches that, buy it today and stop reading. If your approvals loop, or your work has states a generic tool cannot express, you will spend the next two years describing your process in someone else's vocabulary and explaining the gaps to clients.
Buy off-the-shelf when
- Your process is standard. If a generic pipeline genuinely describes your work, a bought portal is faster, cheaper and perfectly good.
- You have few clients. Under a couple of dozen, the manual overhead is not yet worth a build.
- The portal is not client-facing brand. If clients do not judge you on it, the branding argument carries less weight.
- You are still working out the process. Encoding an unsettled workflow produces something you immediately need to rebuild.
Access, and the part that is not optional
Whichever route you take, a portal holds client data, which raises the floor on a few things that are not features.
Per-client isolation. Client A must not be able to reach client B's records under any URL, ever. On a custom build this is enforced at the database level with row-level security, rather than by hiding links in the interface.
Roles inside each client. Their finance contact and their day-to-day contact rarely need the same view, and someone who leaves needs access removed.
An audit log. Who uploaded, who approved, when. This is what makes the portal authoritative when a disagreement arises about what was agreed — which is a large part of why approvals belong in it.
How we build these
Portals we build sit on your domain and in your brand, so clients log into something that looks like you rather than a vendor tool. Upload, status, approve and pay in one place, each request routed with a deadline attached, with per-client permissions, audit logs and secure file handling underneath.
Ours carries the client side of an agency running eighty-plus accounts, so the adoption problems above are ones we have had to solve on ourselves first. You can see how that works on the platform we run our own company on.
If status emails are currently a meaningful share of your team's week, that is the number worth measuring before anything gets built. What we build starts from the map.
Frequently asked questions
- What should a client portal do?
- Four things: let clients upload without files vanishing into threads, show the current status of work without anyone being asked, collect approvals with deadlines and a record, and let clients pay where the work lives. Missing any one keeps the email channel alive.
- Is a custom client portal worth it over off-the-shelf?
- It depends on whether your process is standard and settled. If a generic pipeline describes how your work moves, buy. If your workflow has states or loops a generic tool cannot express, or client experience is part of how you differentiate, custom pays back.
- Why do clients not use our portal?
- Usually because it is optional. If email still gets an answer, email wins. Adoption comes from making the portal the only route to something clients need — typically approvals or payment — and from it being genuinely faster than asking you.
- What security does a client portal need?
- Strict per-client data isolation enforced at the database level rather than by hiding interface links, roles within each client organisation, removable access, and an audit log of uploads and approvals.
- How long does a custom client portal take to build?
- Weeks rather than days, and the scope sets the pace. The variable is rarely the interface — it is how many of your existing systems the portal has to read from and write back to.