Why clients keep asking "any update?" and how to make status visible
Clients chase because they cannot see status, not because they are impatient. What "any update?" really asks, and how to answer it before it is sent.
· 6 min read · Agency operations
Clients keep asking for status updates because they have no other way to find out. The question "any update?" is not impatience. It is a client doing the only thing your process lets them do, and each time they ask, they are telling you the status of their work is invisible from where they sit.
So the fix is not a better reply, or a faster one. It is making the answer visible before the question forms. That takes less software than most agencies expect and more discipline than most agencies have, so it helps to be precise about what the client is actually asking.
What "any update?" really asks
Pull the last ten chasing emails from your inbox and read them side by side. Almost every one is a version of four questions:
- Is anyone working on it? The client sent a request and heard nothing. They do not know if it was received, let alone picked up.
- When will I have it? They have a meeting, a launch or a boss asking them, and they need a date they can repeat.
- Is it waiting on me? Nobody wants to be the reason work stopped. Often it is waiting on them and they do not know.
- Did something change? They suspect the date has moved, and they want to hear it from you before they find out the hard way.
Notice that none of these is "please send me a paragraph about progress". They are four small facts. If the client could see those four facts at any moment, most chasing would stop, because there would be nothing left to chase.
The request is logged and a named person has it.
The day it should land, set by the person doing the work.
Visible when the work is waiting on the client, by name.
A date change shows the old date, the new one and the reason.
Why status updates do not fix it
The standard response is a weekly status email or a Monday call. Both answer the four questions once, then go stale. A Monday email that says "homepage copy due Thursday" is wrong by Wednesday afternoon if the copy slipped, and the client who relied on it finds out on Thursday. We wrote about that pattern in the status update email is a symptom: scheduled reporting describes work at a moment, and the client needs it at a different moment.
The other common response is to give the client a login to your project tool. That answers more questions, but usually the wrong ones. They see your internal task names, your sprint labels and the twenty subtasks behind their one request, and they still cannot tell which date to believe. A view built for the team is noise to a client.
Make status visible: what it has to show
Visible status has to be built from the same records your team works from, or it drifts. Four rules make it work.
One request, one record. Every client request becomes a single item with an owner, whether it arrived by email, form or a call. Status cannot be visible if the work is spread across three inboxes. How agencies keep one record of every client request covers the mechanics.
A date on everything, from the person doing the work. Not a deadline the client set, and not a guess from an account manager. The person who will do the work commits to a landing date when the request is scoped, and the client sees it. Of everything here, it does the most to stop chasing, and the argument is in landing dates, not deadlines.
Tell them when something changes, not on a timetable. Notifications should fire when the state changes: picked up, sent for review, approved, delivered, date moved. A client who gets one message when their work moves trusts the silence in between. A client who gets a weekly digest learns to skim it.
Show the reason when a date moves. A slipped date with a reason attached ("brand guidelines came back with comments") is an update. A slipped date with no reason is a broken promise. Recording the reason on the request means nobody has to write the apology email from memory. More on handling the slip itself in what to do when a client moves the deadline, which works just as well in reverse.
How to cut the email back-and-forth
Visibility removes the chasing. It does not remove all email, and it should not. What it removes is the email that exists only to ask or report status. A practical way to get there:
- Count first. For two weeks, tag every client email that asks or answers a status question. The number is usually higher than anyone guessed, and it gives you a baseline to beat.
- Answer with a link, not a paragraph. When a client asks, reply with the link to the request and its date rather than retyping the status. It trains the habit of looking without telling anyone off.
- Make "waiting on you" explicit. The fastest way to shorten a project is to show the client, by name, what is waiting on them. They are usually glad to know.
- Keep the weekly call for decisions. Once status is visible, the call can stop being a read-out and start being about the things that genuinely need a conversation.
What to look for in a tool
If you are choosing software to automate client status updates, the test is simple: can your client, with no help from you, answer the four questions for any request in under a minute? Look for:
- A client-facing view built for clients, not a guest seat in your internal tool.
- A projected date on each request that the team sets and the client sees.
- Notifications on state changes, sent from your agency's name.
- A clear list of what is waiting on the client.
- A history that records date changes and their reasons.
Many project tools can be configured to do some of this. The question is how much configuration you will keep up, per client, when the agency is busy. If you are comparing approval tools at the same time, our ranked list of client approval software covers the sign-off half of the same problem.
Questions agencies ask about client status updates
How often should we update clients on project status?
Whenever the status changes, and not on a fixed timetable. A message when work is picked up, sent for review, approved or delivered, plus one when a date moves, is enough for most retainers. Scheduled reports go stale between sends.
What is the best way to communicate project timelines to clients?
Give each request its own landing date, set by the person doing the work, in a place the client can check at any time. Campaign-level timelines help too, as long as they are drawn from the same dates rather than a separate deck that has to be updated by hand.
Can clients see real ETAs on deliverables?
They can if the ETA is a date someone has committed to and updates when it changes. An automatic estimate nobody owns is easy to show and hard to trust. The date matters less than the fact that a person stands behind it.
Where HoopoeHQ fits
HoopoeHQ was built around the four questions. Each client has its own workspace, every request has an owner and a projected landing date the client can see, and when that date moves the request records when, by how much and why. Clients get notifications when work changes state, and My feedback lists what is waiting on each person, the client included. Campaigns draw their requests on a timeline the client sees too. The detail is on the landing dates page and the campaign timeline page.
If "any update?" is the most common email your team receives, start a 14-day trial with the client who sends it most, and count the emails for a fortnight.