“Any update on this?” are the four most expensive words in client work. The answer only takes a few minutes. The problem is that the question arrives in the middle of a task, it arrives often, and none of those minutes are billed. Answering faster will not fix it. Making the question unnecessary will.
The usual fix is a status email. On the day you send it, the client is up to date. By Wednesday it is stale, so they ask anyway and you write another one. A status email is a snapshot of something that keeps moving: send one and you have quietly signed up to retake it every few days, copying your own workspace into someone else’s inbox by hand.
You are not paid to describe the work. You are paid to do it.
What the update actually costs
A single interruption looks trivial, which is why nobody puts a price on it. Take a modest case: five active clients, each asking twice a week, and fifteen minutes to switch tasks, look things up and write a decent reply. That alone is two and a half hours a week that never reach an invoice. Add the status emails, the resent files and the approvals you chase, and a month looks like this.
Twenty-one hours is more than two and a half working days, spent telling clients what your own tools already record. It is the same leak we described in our post on effective hourly rate (work the client receives but never sees on an invoice). This one, though, has a clear cause and is unusually easy to fix.
Push versus pull
A client can learn the state of their project in only two ways. You send it to them (push), or they look it up themselves (pull). Most teams default to push, and push has a built-in problem: it is only accurate at the moment you hit send.
Pull removes the job altogether. Once the client can check the project themselves, nobody has to write a status update: the status is whatever the workspace already shows.
What a client should actually be able to do
A portal that only shows a progress bar solves half the problem. The client still emails you to approve something, pay for something or report something broken. To keep the client out of your inbox, the portal has to cover everything they would otherwise email you about.
- See the work. Active projects, milestones, budget, a threaded discussion, and a files tab they can upload to and download from, so nobody has to ask “can you resend that?”
- Approve without a meeting. Proposals they can approve, reject, or send back for revisions, and change requests that go through a proper approval process, so no decision ends up buried nine replies down an email thread.
- 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 they can raise, follow, comment on and confirm as resolved, so your personal phone at 22:40 is no longer the quickest way to reach you.
The four hours that remain are the conversations worth having, the ones about the work itself, and a portal should not try to end them. What it removes is the admin around them: repeating the status, resending files and chasing signatures.
The objection worth taking seriously
“I don’t want clients poking around in my systems” is a fair concern, so it helps to be precise about what a portal is. A portal does not let clients into your workspace as guests; it is a separate site that shows only what you publish. Your internal costs, staff notes and other clients are not in it at all, so nothing depends on a checkbox you might forget to tick.
Per-contact 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 pays does not necessarily need to see the project discussion. Granting access per section and per person is what makes a portal safe enough to actually use.
How TimerOS does it
The client portal reads from your workspace, so there is no second copy to update by hand.
- 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 needs the Startup plan or higher; the branded subdomain works on every plan.
- 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.
- Separate by design. Your portal shows only the data you choose to publish. Internal costs, staff notes and the rest of your company data never reach it.
- Permissions per contact. For each contact you choose no access, view or edit for projects, incidents, changes, invoices, contacts and company profile. Separate switches control who can approve projects and changes. Paying an invoice needs edit access to invoices; a view-only contact can read and download it but not pay it.
- Every contact has their own login. When you grant access, TimerOS can email the contact a branded one-time link to set their own password, and portal users can turn on two-factor sign-in themselves. 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 the work, and asking is the only way they have. Let them see their own project and the question mostly stops. You did not get better at answering it; they simply no longer need to ask.