How to Track a Task That Depends on the Client

A PM pings you on a Thursday: "Why hasn't the homepage copy task moved in nine days?" You open the task. It's been sitting at In Progress since the Tuesday before last. Your writer finished a draft on day one. It's been waiting on the client to approve the tone ever since.

Nothing is wrong with your writer. Nothing is wrong with your process. The task looks exactly like a task nobody is working on, because your status field only has one word for two very different situations.

The status field can't tell the difference

To Do, In Progress, Done — this vocabulary assumes the obstacle, if there is one, is internal. Someone's behind, someone's blocked by another team member, someone needs to prioritize. It has no word for "we did our part and now we're waiting on a person who doesn't report to either of us."

That gap matters because the two situations get different treatment. Internal inactivity is something you can fix by reassigning, reprioritizing, or asking someone to focus. External dependency is something you can only chase, and chasing has its own mechanics — who's asking, what exactly was asked, and when you follow up if nobody answers. If your board can't show the difference, every client-dependent task looks like a dropped ball, and every PM conversation about it starts from the wrong assumption.

Three shapes this takes

Not all client dependency looks the same, and the shape changes what you should track.

The first is missing input. You can't start the logo redesign because the client hasn't sent brand assets. Nothing exists yet for your team to act on. The task is genuinely empty of agency work until the file arrives.

The second is pending approval. The homepage copy is written. It's sitting with the client for sign-off. Your side of the work is finished; the task can't close until someone else says yes.

The third is the one that actually costs money: downstream blockage. The client's sign-off on the copy isn't just holding up that task — it's holding up the developer who's waiting to build the page, and the designer who's waiting to finalize the hero image around the final headline. One slow approval becomes three stalled people, and if nobody wrote that connection down anywhere, the first anyone hears about it is when the developer says they're idle and nobody knows why.

A state model, not a status word

What a client-dependent task actually needs to carry is four pieces of information, and none of them are a mood word like "blocked."

• Who on your team owns chasing it — the person who gets the awkward job of following up, distinct from whoever will eventually do the work
• Exactly what was asked, written plainly enough that anyone covering for that person could pick it up cold
• A date you'll check again if nothing's come back, so the task doesn't quietly age past the point where someone should have escalated
• What else is waiting on this — named, not implied, so a late answer registers as a cost to more than one task

Notice the owner and the recipient are not the same role. The client owes the approval. Your account manager owns making sure the client doesn't forget they owe it. If you only track one of those, you lose either accountability or action — either nobody's chasing it, or you can't tell your own team apart from the client in the assignee field.

Where this actually lives on the board

In Team and Tricks, that split maps onto parts that already exist rather than a new field you have to invent and maintain. The ask itself — the brand assets, the sign-off, the five-minute decision — is a Request, sent to the client as a guest if they have access, with a thread attached to it instead of a reply buried in an email chain. The request has a recipient. The task keeps its own assignee: the person on your team responsible for getting that request answered and moving the work forward once it is.

If the client-dependent piece is one row inside a larger checklist task — "confirm final headline" sitting inside a dozen other launch items — you can mark that row Blocked, so it stands out from the rows your team is actively working without needing a separate conversation to explain why. A Reminder on the task gives you the chase date: the point at which, if nothing's come back, someone follows up again instead of the task just aging silently at the bottom of the board.

The downstream part is the one honest limitation worth naming. There's no dependency graph here that will automatically flag the developer's task when the copy approval slips — nothing draws the line for you. You write it: in the blocked task's description, in a progress report, in whatever note tells a future reader that this isn't just a late client reply, it's a late client reply with three other tasks sitting behind it. That's manual. It's also honest — a dependency line on a chart can make a delay look tracked when nobody's actually watching it, and a one-sentence note that a human wrote tends to get read.

What changes when you make the wait visible

The real payoff isn't a tidier board. It's the conversation that happens when a client asks why launch slipped. "We were waiting on your approval from the 14th to the 23rd, and the dev work and the hero image were both sitting behind it" is a different sentence than "we got a bit behind." One is defensible and specific. The other sounds like your problem, even when it wasn't.

The distinction costs you almost nothing to track — an assignee who isn't the client, a request that says what you actually need, a reminder date, and one written sentence about what else is waiting. What it buys you is the ability to say, truthfully and specifically, that the work didn't stop. It was handed to someone else, and you were watching for it to come back.