“Waiting on client” is not “in progress”

A project sits in “In progress” for three weeks. At the end of those three weeks, roughly four days of work has happened. Nobody lied. The status was accurate the entire time. It was just answering the wrong question.

Status tells you the stage of the work. It does not tell you who currently owns the next move. And in client services, the answer to that second question is very often “not us.”

The two axes people collapse into one

There are really two independent things going on in any piece of client work:

• Stage. Where the work is in its lifecycle. Planning, approved, in progress, review, completed.
• Custody. Who has the ball. Us, the client, a designer, a lead who owes an approval.

Most tools give you one column and force you to encode both. So teams invent conventions: a label, a tag, a comment, a person’s name in brackets after the task title. Every one of those conventions decays within a month, because they depend on someone remembering to maintain a fiction.

If your team writes “(waiting on Dave)” in task titles, your tool is missing a field and your people are covering for it by hand.

Why custody is the expensive one

Stage is interesting for planning. Custody is what actually drives cost and schedule, for three reasons.

It makes idle time countable

When “waiting on client” is a real state with a timestamp, you can answer a question you previously could only complain about: how many days of this project were spent waiting on someone outside the team? That number is a negotiating position at renewal time. It is also, in most agencies, shockingly large.

It changes the standup

A standup where every item is “in progress” is a status recital. A standup where items are grouped by who holds them turns into a short list of chases and a short list of actual work. The meeting gets shorter and more useful at the same time, which almost nothing else in operations manages.

It stops silent blocking

Blocked work rarely announces itself. Someone hits a wall on Tuesday, mentions it in a thread, and moves to another task. Three days later nobody has chased it because it never left “in progress.” Making blocked and waiting distinct states means the board itself does the chasing.

What this looks like in Beacon

Projects in Beacon carry a status lifecycle — draft, planning, pending approval, approved, in progress, on hold, review, completed, cancelled — and separately a delivery phase. The phase list includes the honest ones: waiting on client, waiting on developer, waiting on designer, waiting on PM, waiting on lead, alongside design, development, testing, deployment, maintenance and post-go-live support.

Two fields instead of one. It sounds like a small thing. In practice it means a project can be “approved and in progress” while also being visibly parked on the client for feedback, and both of those facts are true and readable at a glance without anyone editing a title.

Tasks get the same treatment at a smaller scale, with blocked as a first-class status rather than a convention.

How to introduce it without a process rebellion

1. Do not add ten states at once. Start with one: waiting on client. It is the highest-volume and least controversial.
2. Agree what leaving the state requires. “Waiting on client” ends when a named person replies with a decision, not when someone says “I think they mentioned it on the call.”
3. Set a chase interval. Anything waiting on an external party for more than three working days gets a nudge. Write the interval down so it is the process chasing, not a person nagging.
4. Report it back. At the end of a project, tell the client how many days sat waiting. Do it neutrally. It reframes the next project’s timeline conversation entirely.

The objection: this is just more admin

It would be, if it were extra. The trick is that it replaces admin rather than adding it. The convention it kills — labels, bracketed names, the weekly “where is this actually at” message — costs more per week than moving a dropdown costs per task.

If you want a rule of thumb: a field earns its place when maintaining it is cheaper than the message you send because it is missing.

Common questions

Isn’t “on hold” enough?

On hold usually means paused by decision. Waiting means active but blocked. They need different responses: one is a scheduling fact, the other is a chase.

Should clients see these states?

Sometimes, and it is worth being deliberate about it. Projects in Beacon can be public or private. Showing a client that their own review is the current bottleneck is often the single most effective thing you can do for a timeline.

Doesn’t this make the board noisier?

It makes it more honest, which can feel like noise for a week. Most teams find the opposite after that: fewer items look active, and the ones that do actually are.

Status answers “how far along.” Custody answers “why has nothing moved.” Track both, and start with the second.