Flag a blocker that is waiting on the customer by recording who must act, what they must decide or provide, the date it started waiting, and what the delay costs the milestone. Then send the sponsor one decision request that names the decision, the options, the deadline, and the default if no answer arrives. If there is no answer at the deadline, escalate to the person with authority to decide.
How do you know a blocker is waiting on the customer?
A blocker is waiting on the customer when the next step needs a named client person to decide, approve, provide data, or grant access, and the team cannot move it alone. Mark it the day the work stops, not when the milestone slips.
Ask these questions in order:
- Could the team finish this step without anyone outside the team?
- If not, which client person must act?
- What exactly must that person do: decide, approve, provide data, or grant access?
Write the answers down the same day the work stops. A note such as “client slow” gives the sponsor nothing to act on.
Supportbench's guide defines an escalation as an issue that moves beyond its current owner for reasons of capability, severity, or relationship. A client-held blocker is a different case, because the work stops while a client person has not acted and the team has no way to move it.
Plane's guide separates escalations by decision type, such as authority, expertise, or coordination. Use the same idea here: the kind of help needed tells you which client person to name.
Keep one record for each blocker:
Blocker: [short name of the stalled work]
Waiting on: [client person's name and role]
Needed: [the exact decision, approval, data, or access]
Waiting since: [date]
Milestone at risk: [milestone name and its current date]
Cost of delay: [what slips, in plain words]
Next step: [action] by [date]
Illustrative example, with placeholders only: Blocker: [import data set]. Waiting on: [client data owner, role]. Needed: sign-off on the field mapping in [document name]. Waiting since: [date]. Milestone at risk: [rehearsal name, date]. Cost of delay: the rehearsal moves to [new date], and training moves with it.
Do not mark your own team's work as waiting on the client. If your team owns the next step, keep it as an internal blocker and give it to a named team member with a date.
How do you make an aged blocker visible to the sponsor?
Put every client-held blocker in a section called Waiting on the client, placed above the risks and sorted by the date it started waiting, oldest first. Age makes the delay visible without anyone arguing for attention. Name the client person who can clear each item and the milestone it touches.
Plane's guide uses an issue statement: because something happened, a named outcome is at risk by a date. Adapt it for the status report:
Because [what happened], [milestone] is at risk by [date] unless [client person] [decides or provides] [item].
- Add the section above the risks.
- Show each item on one line: the blocker, the client owner, the date it has been waiting since, and the milestone it affects.
- Sort by waiting-since date, oldest first.
- Review the list in each internal team meeting. Remove an item only when the project record shows the answer, not when someone says it is handled.
Keep these items in the status report the sponsor reads. An internal risk log that the sponsor never sees leaves the aged item invisible until the milestone is late.
What should a decision request to the sponsor contain?
A decision request names one decision, lays out the options with a recommendation, gives a specific deadline, states the default if there is no answer, and says what waiting costs. Send it as one email the sponsor can answer by choosing an option.
ONES's guide puts a decision-ready summary before an issue reaches the person with authority. Write the request so the sponsor can decide without rebuilding the context. Use this template:
Subject: Decision needed by [deadline date]: [item]
Hi [sponsor name],
[Milestone name] is waiting on one decision: [the decision, in plain words].
Options:
A. [Option A]. Trade-off: [what it costs or risks].
B. [Option B]. Trade-off: [what it costs or risks].
Our recommendation is [A or B] because [one reason tied to the milestone].
If we have your answer by [deadline date], [milestone name] stays on [milestone date].
You can change your answer until [deadline date]. If we have no answer by then, we will go ahead with [default option from the request] from the day after [deadline date], and we will note it in the status report so you can review it.
Reply with A, B, or another option.
[Your name], [role]
Keep each request to a single decision. Keep each trade-off short, and give the deadline as a calendar date, not a phrase such as “end of week.”
What default should apply if the sponsor does not answer?
Set the default in writing before the request goes out: name the option the team will take if there is no answer by the deadline. The default must be one the sponsor has already seen in the request, and it must be easy to reverse.
Check each default against these rules:
- It is one of the options in the decision request, not a new idea.
- It keeps work moving and can be undone, such as [interim option name].
- It does not change price, contract scope, or a committed go-live date. Those need a written decision from the people who sign for each side.
- The contract owner has reviewed the wording before kickoff.
Use this sentence in each request:
If we do not have your decision by [deadline date], we will proceed with [option from the request] from the day after [deadline date] so [milestone name] stays on [milestone date]. You can choose or change an option until the end of [deadline date].
The reply window and the default share one boundary. The window closes at the end of the deadline date, and the default begins the next day.
Some clients will not accept a default, which is a fair position. If so, write into the kickoff notes that the milestone date moves while a client-held item is open. That is a separate agreement, and it is easier to reach at kickoff than in the middle of a delay.
What should the kickoff notes say about a default deadline?
Kickoff notes should record a default-deadline clause for each client-held decision. The clause names the decision, the response deadline, the default option, the milestone date if the default is not used, and who signs off. The contract owner reviews the wording before kickoff.
Client-held decision: [decision item]
Response deadline: [deadline date]. The client may choose or change an option until the end of that day.
Default if there is no response: [default option from the decision request], starting the day after [deadline date].
Milestone effect if the default is not used: [milestone name] moves to [new milestone date].
Not changed by the default: price, contract scope, and committed go-live date. Any change to these needs a written decision signed by [client signatory] and [supplier signatory].
Escalation: if there is no response by [deadline date], the same summary goes to [decision-holder role].
Review: [contract owner name] confirms this wording before kickoff on [kickoff date].
Treat the clause as a starting point, not finished contract language. The contract owner decides whether it fits your agreement.
When should you escalate a client-held blocker, and to whom?
Follow up on a client-held blocker the day before the deadline. If it is still open at the deadline, escalate it to the person with authority to decide, sending the same summary and asking that person to confirm the decision or name who will make it.
ONES's guide describes an escalation path in six steps: trigger, lowest-level attempt, decision-ready summary, correct authority, track decision, and confirm closure. The steps below follow that order.
- The day before the deadline, follow up with the sponsor in one line that points to the original request.
- At the deadline, if the item is still open, send the same summary to the person with decision authority. Say what was asked, when it was asked, and what the default is.
- Write the response deadline and the escalation contact into the kickoff notes, so both are agreed before anyone needs them.
- When the decision arrives, record it on the milestone and in the next status report, with the date and who decided. Confirm with the team that the work has restarted.
Pylon's guide says every escalation needs one point person responsible for progress and account communication. Name that person on the request, usually the project lead, so the client knows who to answer.
Why do sponsors stall, and how do you reword the request?
Sponsors slow down when a request is open-ended, bundles several decisions, or hides what waiting costs. Fix the wording before the request goes out, not after the deadline has passed, by naming the option, the date, and the cost of delay.
Replace the common wording:
- Open-ended: “What do you think about the timeline?” becomes “Do you approve option A, which keeps go-live on [go-live date] with [trade-off]?”
- Bundled: split the thread into one request per decision, each with its own deadline.
- Hidden cost: “We are waiting on access” becomes “Without access by [date], the data migration moves to [new date].”
Before a request goes out, check that the decision really is outside your authority. Plane's guide includes guidance on when not to escalate, which is worth reading first. Some blockers belong with the client's technical lead rather than the sponsor, so confirm who holds decision rights before you write.
Before the next sponsor meeting, choose the client-held blocker that has waited longest, fill in its record, and turn it into one decision request using the template above.