Most Client Deliverables Don't Stall on Disagreement

They stall on ambiguity about who has to say yes.

TL;DR

Client deliverables rarely stall because someone objected. They stall because the approval chain was never explicitly defined, so nobody knows whose yes is the one that counts. A shared Drive link models access and nothing else: it cannot distinguish an approver from a reviewer from a spectator. That distinction ends up living in the practitioner's head and gets re-explained in every thread. Separating access from accountability is a structural fix, not a discipline fix.

The week nobody was arguing

A strategy deck goes out on a Tuesday. It goes to four people on the client side.

Two reply with comments, both minor. One writes back the same afternoon: "Looks good to me." The fourth does not open it.

By the following Tuesday nothing has moved. The work is finished. It has been finished for eight days. Nobody has raised an objection, requested a revision, or expressed a concern of any kind. The deliverable is simply sitting there, waiting on a decision that nobody has been formally asked to make.

This is the most common way client work stalls, and it is worth being precise about what happened. There was no disagreement. There was no dropped ball in the ordinary sense. Everyone involved behaved reasonably given what they knew.

What was missing was a single piece of information: which of those four people was the approver.

Ambiguity stalls more work than disagreement

Practitioners tend to file this under communication problems. Better follow-up. Clearer emails. A firmer nudge on day three.

That diagnosis is comfortable because it implies a fix within your control. It is also wrong often enough to be expensive.

Consider what the follow-up actually has to accomplish. You are not reminding someone of a task they agreed to and forgot. You are, in the same message, doing three separate things:

1. Establishing that a decision is required
2. Identifying who is meant to make it
3. Asking them to make it

Only the third is a reminder. The first two are structural work you are performing manually, over email, every single time a deliverable goes out. And because that work happens in prose rather than in a system, it does not persist. The next deliverable requires you to do it all over again, often with the same people. This is one of several reasons reply-all is not a document management strategy: the thread carries the instruction once, then buries it.

Disagreement is loud and resolvable. Somebody says the positioning is wrong, you have a conversation, you revise. Ambiguity is silent and self-sustaining. Nobody says anything, so nothing signals that intervention is needed, so the deliverable ages quietly until you chase it.

The missing approver

Here is the mechanism underneath all of this. It is worth naming, because it recurs across every engagement and every client: the missing approver.

A file in Google Drive or OneDrive has essentially one state relevant to your client: it exists, and this person can open it. Permissions add a little detail. Viewer, commenter, editor. Those are capability grants. They describe what a person is technically able to do.

They do not describe what a person is expected to do.

The gap between those two things is where the approval chain lives. In a typical engagement, four people with access to the same deck occupy four genuinely different positions:

• The approver. One person whose yes closes the loop. Their silence blocks everything.
• The reviewer. Someone whose input is wanted and factored in, but whose sign-off is not required. Their silence is mildly unfortunate.
• The contributor. Someone who will produce or supply part of the work. They are not evaluating it, they are feeding it.
• The observer. Copied for visibility, courtesy, or political reasons. Their silence means nothing at all.

Drive assigns all four the same thing: a link. The distinction between them exists only in your head and in whatever you managed to type into the covering email. Three weeks later, when you are trying to work out why the deck has not moved, you have to reconstruct that map from memory.

This is why the problem does not respond to discipline. You can be extremely organized and still be carrying four role assignments per deliverable, across every active client, entirely in working memory. That is not a character flaw. It is an unreasonable thing to ask of a person, and it is exactly the kind of thing a system should hold instead.

Access and accountability are different properties

Worth stating plainly, because most tooling conflates them.

Access is a binary technical fact. Can this person retrieve this file.

Accountability is a relational fact. Is this person responsible for a decision, an input, or nothing.

Cloud storage models access very well. It was built to. It does not model accountability at all, because accountability is not a property of files. It is a property of engagements.

That is the reframe that matters. The approval chain is not attached to a document. It is attached to a piece of work that happens to be expressed as a document. Same deck, different engagements, different approvers. Same client, different deliverable, different approver again. Any system that anchors roles to files rather than to the work will lose the mapping the moment the file changes or a second deliverable enters the picture.

What this costs, concretely

The costs compound in ways that are easy to underweight because each individual instance is small.

Chasing the wrong person. You follow up with whoever has been most responsive, because responsiveness is the only signal you have. They are frequently not the blocker. The actual approver is unaware they are holding anything up.

Approval that does not survive. "Looks good to me" in an email thread is not a record. Three months later, when the question is whether the messaging framework was signed off before implementation began, you are searching an inbox.

Client-side confusion you get blamed for. The client's team is not organized either. When your process does not impose clarity, theirs will not supply it, and the resulting mess reads to them as your delivery being disorganized.

Meetings that exist to answer status questions. The recurring check-in call is often a workaround for the absence of a status surface. If the client could see where a deliverable sits without asking, half the agenda would evaporate.

That last one is the clearest tell. Any standing meeting whose main function is answering "where are we on X" is a meeting your system should have made unnecessary.

Fixing it without adding a tool

The structural fix does not require software. It requires making four decisions explicit before the deliverable ships, and keeping them somewhere durable.

1. Name one approver per deliverable, not per client

The instinct is to designate a client-side owner once and apply it everywhere. That breaks quickly. The person who approves a brand positioning document is often not the person who approves a media plan. Assign the approver at the level of the individual deliverable, and assign exactly one. Two approvers is zero approvers.

2. Distinguish reviewers from approvers out loud

When you send work out, say which is which. Not implicitly through the ordering of names in a To field. Explicitly: this person signs off, these two are invited to comment, this person is copied for visibility. It takes one sentence and removes the ambiguity that causes the stall.

3. Define what happens when the approver is silent

Decide the rule in advance and state it. Silence after five working days means approved by default, or it means escalate to the sponsor, or it means the timeline moves. Any of these is better than the current default, which is that silence means you chase indefinitely while the engagement clock runs.

4. Record the approval where the work lives

Not in email. The approval should attach to the deliverable itself, so that six months later the record is discoverable by anyone looking at the work rather than by whoever still has the thread.

These four habits, applied consistently, remove most of the stall. They are also the first four things that get dropped when you are running five engagements at once, which is precisely the point: a habit that survives at two clients and fails at five was never a system. It was you, remembering.

Why this gets worse with scale, not just bigger

At two clients, holding the approval map in your head is manageable. You know who approves what because there are perhaps six live deliverables total and you touched all of them this week.

At six clients the arithmetic changes. It is not three times the load. Each client contributes deliverables, each deliverable contributes a role map, and switching between clients means reloading a different map from memory. The cost sits in the context switching as much as the volume.

This is the point at which practitioners typically conclude they need to hire, or cap their client count, or accept that delivery quality will degrade. Sometimes that is correct. Often what has actually been reached is the ceiling of an ad hoc system, not the ceiling of the practitioner.

The underlying principle

Client work has states. Drafted, in review, approved, delivered, closed. It has roles. Approver, reviewer, contributor, observer. It has a lifecycle with a beginning and an end.

File storage models none of these things, because it was not built to. It models existence and access, and it does both well.

The mistake is not using Drive. Drive is the right place for files to live, and moving them somewhere else creates a migration problem in exchange for solving a structure problem. The mistake is expecting storage to carry structure it was never designed to hold, and then treating the resulting friction as a personal organizational failing.

The work is the unit. Not the file. Once you organize around the engagement rather than the folder, roles and states have somewhere to attach, and the question "who approves this" stops being something you answer from memory every time.

Frequently asked questions

Who should approve a client deliverable?

One named person per deliverable, assigned before the work ships. Assign the approver at the level of the individual deliverable rather than once per client, because the person who approves a positioning document is often not the person who approves a media plan.

What is the difference between a reviewer and an approver?

An approver's yes closes the loop, and their silence blocks the work. A reviewer's input is wanted and factored in, but their sign-off is not required and their silence does not block anything.

How long should you wait for client approval before following up?

Set the rule before you send rather than deciding case by case. A common approach is that silence after five working days triggers escalation to the engagement sponsor or moves the timeline, stated explicitly when the deliverable goes out.

Why do client deliverables stall when nobody has objected?

Because the approval chain was never defined, so no single person knows the decision is theirs to make. Disagreement is loud and resolvable; ambiguity is silent and self-sustaining, so nothing signals that intervention is needed.

Related reading

• Why 'Reply-All' Is Not a Document Management Strategy: Building Email-Free Client Workflows
• The Fractional Executive's Guide to a Clean Digital Desk
• Async Video Reviews: The Operational Efficiency Play Marketing Leaders Are Missing

---

firmä turns the Google Drive or OneDrive you already use into a structured client portal. Files stay in your Drive, non-custodial by design.