To see which Linear risks and blockers need a sponsor decision or escalation, and by when, give every issue that is waiting on the client the same label in each client team. Give each one a client owner, a decide-by date worked back from the milestone it puts at risk, and a one-line impact if it slips. Start each issue title with that date, then gather the labelled issues from every team into one table, ordered by date, before each portfolio review.
How do I find which Linear issues are waiting on a sponsor decision?
To find Linear issues waiting on a sponsor decision, create the same label, such as [Awaiting client decision], in every client team, plus an [Escalate] label for items that need raising. Start each issue title with the decide-by date, so each team's labelled list shows the date first and the lead can order the portfolio rollup by hand.
Linear already works with labels: its AI page describes Triage Intelligence suggesting "assignees, teams, projects, labels, and related issues." Using the same label name in each team gives every lead the same thing to look for.
Set it up like this:
- Agree the label names with your delivery leads, for example
[Awaiting client decision]and[Escalate]. Create them with the same names in every client team so every lead tags the same way. - Ask each lead to apply the sponsor decision label only when work cannot move until the client answers. Slow work does not qualify.
- Start the issue title with the decide-by date, then state the decision as a question the client can answer: "[YYYY-MM-DD] [Client]: approve [deliverable] scope option A or B?" Writing the date year first means titles read in date order when listed alphabetically.
- Link or name the work that is waiting on the answer, so anyone reading the issue can see what is stopped.
- Remove the label the moment the client answers, and record the answer in the issue.
How do I tell a sponsor decision apart from an internal blocker?
A sponsor decision is a blocker only the client can clear: an approval, a choice between options, an input the client owns, or access the client controls. An internal blocker is one your own team could clear with time or effort, so it stays with the team and never goes to the client.
Plane's guide defines a blocker as work that "cannot move forward without a specific decision, approval, input, or fix" and treats feedback and approval blockers as their own type.
Ask these questions for each blocked issue:
- Could anyone on our side clear this if they had the time? If yes, it is internal. Assign it and leave the client out.
- Does clearing it need the client's authority, budget, content, or access? If yes, it is a sponsor decision.
- Is the client owner named? If the lead can't name a person, the first step is finding that person, not escalating.
How do I work out the decide-by date?
The decide-by date is the latest date the client can answer without moving a milestone. Start from the earliest milestone the blocked work feeds, find when the dependent work must start, then step back by the time your team needs to act on the answer and the time the client needs to review.
Use this rule:
Decide-by = [start date of the first dependent task] minus [time the team needs to act on the answer] minus [time the client needs to review and confirm]
The ripple matters because one stopped item delays everything after it. Plane gives the example that a blocked design approval pushes development, testing, and release timelines. So tie the date to the earliest milestone affected, not the final launch.
Two checks before you write the date down:
- If the decide-by date has already passed, the item is an escalation today, and the conversation is about a revised milestone or a reduced scope.
- If the client owner is away before that date, bring the date forward or name a delegate.
What should each item record?
Each sponsor decision item in Linear should record what is blocked, what decision is needed, the client owner, the decide-by date, the milestone at risk, the impact if the answer is late, and a fallback. With those fields in the issue description, you can act on the item without opening the rest of the project.
The core is the five-part blocker statement Plane suggests in its guide to project blockers: what is blocked, what is needed, from whom, by when, and what happens otherwise.
Paste this into the issue description:
Blocked: [work that is stopped]
Client decision needed: [the question, with options A / B]
Client owner: [name, role]
Decide by: [date], so [milestone] stays on [milestone date]
If late: [impact: milestone moves to [date] / scope drops [item] / cost of [amount]]
Fallback: [what we do if no answer by decide-by]
Internal owner: [delivery lead]
First asked: [date] via [email / meeting]
The fallback line matters. It turns "we're waiting" into a choice the client can make, including the choice to let your recommendation stand.
How do I roll this up across several client engagements?
To roll up sponsor decisions across several engagements, collect the labelled issues from each client team before each portfolio review and copy them into one table, ordered by hand by decide-by date, earliest first. Each row names the client, the client owner, the milestone at risk, the impact, and a link to the source issue, so every line traces back to evidence.
Rollup template:
| Decide by | Client | Sponsor decision needed | Client owner | Milestone at risk | Impact if late | Status | Issue |
|---|---|---|---|---|---|---|---|
| [date] | [client] | [question] | [name] | [milestone, date] | [impact] | [asked / reminded / escalated] | [issue link] |
To assemble it:
- Ask each delivery lead to check the label and the decide-by dates in their team before the review.
- Open the
[Awaiting client decision]label in each client team and copy each issue into the table. - Order the rows by the date at the start of each title, earliest first.
- Pull out anything also tagged
[Escalate]or past its date, and discuss those first. - For each row, agree one next step and who takes it before the next review.
Linear's AI can help draft the narrative. Its AI page says Linear Agent can "Summarize progress, risks, blockers, and recent changes into an update your team can review and post," and lists a Linear MCP for connecting assistants. Treat any draft as a starting point: the lead checks each line against the source issue before it goes to a partner or client.
When should a sponsor decision be escalated, and to whom?
A sponsor decision should be escalated when there is no answer by the decide-by date minus the client's review time, when the decide-by date has passed, or when the item puts the critical path at risk. Escalation runs from the delivery lead to the portfolio head, then from the portfolio head to the client sponsor above the client owner.
Write the trigger down so every lead applies the same rule. Monday's escalation guide recommends objective triggers over judgment, and its project template escalates on timeline slips of one or two weeks, or any critical-path impact. Those are internal response rules, so tie yours to the decide-by formula instead:
- When you first ask, the lead sends the client owner the question, the decide-by date, and the fallback.
- If there's no answer by [decide-by date minus the client's review time], raise it with the client sponsor.
- If the decide-by date passes with no answer, put the revised milestone or reduced scope in front of the client sponsor for a decision.
Some clients react badly to the word "escalation." Keep the [Escalate] label internal, and in client conversations ask for help with a decision.
Escalation wording you can use:
[Client sponsor name], one decision on [project] is holding up [milestone]. We need [client owner]'s answer on [question] by [date] to keep [milestone date]. If we don't have it, we'll [fallback], which means [impact]. Could you help us get an answer, or confirm the fallback?
How do I get the decision to a client who can't see Linear?
To get a decision from a client who can't see Linear, send the client owner a short written request by email or raise it in your regular meeting, with the question, the options, your recommendation, the decide-by date, and the fallback. Keep the Linear issue as your record and log the request there.
Clients often don't work inside your tracker: one review notes Linear is a weaker fit when teams need client-facing reporting, so the request has to travel outside it.
Request wording:
Subject: Decision needed by [date]: [question]
Hi [client owner], to keep [milestone] on [date], we need your call on [question]. Option A: [summary]. Option B: [summary]. We recommend [option] because [reason]. If we don't hear by [date], we'll go ahead with [fallback].
Unblockd supports asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.
What doesn't this approach solve?
A label-based rollup in Linear is only as accurate as the labels behind it. When leads forget to apply or remove the sponsor decision label, the rollup misses items or shows stale ones. A decide-by date is also an estimate from your plan, not a contract term, so present it as what the team needs to hold the date.
Make label hygiene part of each project's regular review, and check that every title still starts with the current decide-by date.
Watch the vocabulary too. Linear's own Method essay uses "blocker" for gaps or friction that stop a user from using a product, not delivery dependencies. Say "client decision" in your labels and rollup so nobody confuses the two.
What should I do first?
The first step is to agree the sponsor decision label names with your delivery leads, then ask each lead to tag their open sponsor decisions, date-prefix the titles, and fill in the description template before your next portfolio review. Build the first rollup from those issues, ordered by decide-by date, and open the meeting with anything already past its date.