“Any update on this?” is the most expensive four words in client work. Not because answering takes long — it takes a few minutes — but because it lands mid-task, it lands often, and every one of those few minutes is unbilled. The fix is not answering faster. It is making the question unnecessary.
Most of us handle this with a status email. It works, in the sense that the client is informed on the day you send it. By Wednesday it is stale, so they ask anyway, so you write another one. The email is a snapshot of something that keeps moving, and you have quietly taken on a recurring job: manually mirroring your own workspace into someone else’s inbox, forever.
You are not paid to describe the work. You are paid to do it.
What the update actually costs
The individual interruption looks trivial, which is exactly why nobody prices it. Take a modest case — five active clients, each asking twice a week, fifteen minutes to context-switch, look it up, and write a decent reply. That is two and a half hours a week that never reaches an invoice, and the real cost is worse than the arithmetic, because those minutes come out of the middle of focused work rather than the edges.
Eighteen hours is most of a working week, spent restating things that were already true and already recorded somewhere in your own tools. It is the same leak we walked through in the effective-hourly-rate post — work the client receives, that never appears on an invoice — but with a specific and unusually fixable cause.
Push versus pull
There are only two ways a client can learn the state of their project. You push it to them, or they pull it themselves. Almost everyone defaults to push, and push has a structural problem: it is only accurate at the instant you hit send.
The right-hand column is not a better email. It is the removal of a job. Once the client can see the current state themselves, nobody has to produce a status update, because the status is not a document — it is just what the workspace already says.
What a client should actually be able to do
A portal that only displays a progress bar solves nothing; the client still emails you to approve the thing, pay the thing, or report the broken thing. To retire the recurring question, the portal has to cover the whole loop.
- See the work. Active projects, milestones, budget, a threaded discussion, and a files tab they can upload to and download from — so “can you resend that?” stops being a message.
- Approve without a meeting. Proposals they can approve, reject, or send back for revisions, and change requests that move through a real workflow instead of a thread where the decision is buried nine replies down.
- Pay without being chased. Invoices with line items and status, a downloadable PDF, and either card payment through Stripe or a recorded manual payment with a reference.
- Report problems in the right place. Incidents raised, tracked, commented on, and confirmed resolved — not reported at 22:40 to your personal phone because that was the fastest channel to hand.
The residual four hours are the point, not a rounding error. A portal does not end client communication and should not try to — the conversations worth having are the ones about the actual work. What it ends is the clerical half: restating status, resending files, and chasing signatures.
The objection worth taking seriously
“I do not want clients poking around in my systems” is a fair instinct, and it is the reason to be precise about what a portal is. It is not a guest login to your workspace. It is a separate surface showing a published subset, with your internal costs, staff notes and other clients structurally absent — not hidden behind a checkbox you might forget to tick.
Per-client permissions matter for the same reason. Not every contact at a client should be able to approve a proposal or pay an invoice, and the finance contact who can pay does not necessarily need the project discussion. Access that is granted per module, per person, is what makes the whole thing safe enough to actually use.
How TimerOS does it
The client portal is part of the same workspace rather than a separate product to keep in sync — which is the only version of this that does not create a second job.
- On every plan, Freelancer included. Each client signs in at your own portal address and sees your trading name, logo and tagline. Connecting your own custom domain is a Startup-and-up capability; the branded subdomain works on every tier.
- It updates in real time. Edits your team makes in the desktop app show up for the client without a refresh, so the portal is never a stale copy that needs reconciling.
- Isolated by construction. Each tenant’s portal shows only the synced subset you publish. Internal costs, staff notes and the rest of your org data never cross into it.
- Permissions per contact. You grant each contact none, view, or edit across projects, incidents, changes, invoices, contacts and company profile, plus explicit approve-projects and approve-changes flags. Paying an invoice needs edit on invoices — a view-only contact can read and download it but not pay it.
- Invites, not shared passwords. Granting access emails the contact a branded one-time link to set their own password, and portal users can enrol their own two-factor. The full setup is in the client-portal documentation.
Clients do not ask for updates because they enjoy interrupting you. They ask because they cannot see, and asking is the only tool they have. Give them a window into their own work and the question mostly stops — not because you got better at answering it, but because they no longer need to.