A decision request template is a short ask you can send to a named leader in another function. It asks them to choose between options by a set date, so a blocked dependency can move. It states the dependency and the milestone it holds up, a one-line ask, a few options with tradeoffs, your recommendation, one decision owner, a decided-by date, what happens by default if no one decides, and the escalation path.
Copy the template below into a Doc, Confluence or Notion page. Fill it in from your plan and RAID log, then send it to the decision owner or the steering committee.
What goes in a decision request template?
A decision request template needs these fields: the dependency, the milestone at risk, the ask, the options, your recommendation, the decision owner, the decided-by date, and the default and escalation rule. Together they tell a busy leader what is stuck, what you want, who decides, by when, and what happens if nobody answers.
Most published formats cover part of this. Atlassian's Confluence decision template and its DACI play focus on who approves and which options are on the table. RAID log templates such as Kiolo's and Simpliaxis's track escalation. The request below puts everything you need to send on one page.
| Field | What to write | Check before sending |
|---|---|---|
| Dependency | What your team needs from the other function | Could someone outside the project understand it? |
| Milestone held up | The milestone and the date it blocks | Is the date current in the plan? |
| The ask | One sentence ending in a question | Can it be answered with an option name? |
| Options | A few real choices, each with its cost, its risk and its effect on the date | Is "do nothing" shown honestly? |
| Recommendation | The option you would pick and why, in a sentence or two | Is it separate from the options list? |
| Decision owner | One named person with authority to choose | Have you confirmed they hold that authority? |
| Decided-by date | The last date a decision still protects the milestone | Is it earlier than the milestone date? |
| Default and escalation | What you will do if there is no answer, and who hears next | Has the escalation owner agreed to this? |
What does a decision request template look like?
A decision request template looks like a one-screen email. The subject line names the decision, owner and date. Below it come the dependency, the milestone held up, the ask, lettered options, a recommendation, named roles, a decided-by date, a default and an escalation path. Plain text pastes cleanly into a Doc, Confluence, Notion or email.
Use the subject line as the summary. Replace every bracketed placeholder. If you can't fill a line, delete it rather than leave it vague.
Subject: Decision needed: [decision in a few words], [owner name], by [date]
Dependency: [What we need from your team]
Milestone held up: [Milestone], due [date]
The ask: Which option should we take for [topic]?
Options
A. [Option] : cost [amount or effort], risk [risk], milestone [kept / moves to date]
B. [Option] : cost [amount or effort], risk [risk], milestone [kept / moves to date]
C. Do nothing for now : risk [risk], milestone [moves to date]
Recommendation: [Option letter], because [reason].
Decision owner: [Name, role]
Consulted: [Names]
Informed: [Names or group]
Decided by: [date]
If no decision by then: we will [default action] and record it as decided by default.
Escalation: if the default is not acceptable, [escalation owner] will take it to [forum] on [date].
Evidence: [link to plan, ticket, test result or RAID entry]
To answer: reply with A, B or C, or name a time to talk before [date].
How do you write the options and the recommendation?
In a decision request, write each option as a choice the owner could actually make. Give its cost, its main risk and its effect on the milestone date. Then put your recommendation on its own line. Keeping the options and the recommendation apart lets the owner see the tradeoffs before they see your preference.
- Start from the milestone. For each option, say whether the date holds or moves, and to when.
- Include doing nothing. Owners often end up there by default, so show what it costs.
- Use the same measures for every option, so the owner can compare them side by side.
- Keep the recommendation short: the option, the reason, and what you need from the owner to act on it.
- Scale the detail to the stakes. A low-cost choice you can reverse needs only a few lines. If a choice is expensive to undo, link supporting evidence from the request.
Who should own the decision?
The decision owner should be one named person with the authority to commit their function's people, budget or systems. Before sending, confirm that authority with them or their chief of staff. List who must be consulted and who only needs to be told. A request addressed to a group usually waits for someone to volunteer.
DACI makes this split explicit. Atlassian's DACI play names a single Approver, and its DACI article explains how to use the method for project decisions. If authority is split between functions, name the steering committee chair as the owner and list the functional leads as consulted. Ask in advance: "Is [name] the right person to decide [topic], or does this need [forum]?"
What happens if nobody decides by the date?
If nobody decides by the decided-by date, the default you wrote into the decision request takes effect and the escalation owner is told. Pick a default that is safe and easy to reverse, often your recommendation or a holding position. Agree it with the escalation owner before you send, so the default has their backing.
Use wording the owner can read in seconds:
If we have no decision by [date], we will proceed with [option] and record it as decided by default. If you would rather we stop, reply before then and we will hold.
Then set the escalation path:
- Name the escalation owner and the forum, for example [sponsor] at [steering committee] on [date].
- Write the trigger: no decision by [date], or a decision that moves [milestone].
- Record both in your RAID log. Kiolo's RAID log template includes escalation-owner and trigger fields, and Simpliaxis describes escalation rules.
- Send one reminder before the date, saying what the default will be.
What does a filled-in cross-functional example look like?
A filled-in cross-functional decision request names one dependency on another function and the milestone it holds up. It gives lettered options with their effect on the date, one decision owner, a default if no one answers, and an escalation everyone knows about. In this illustrative example, a transformation programme needs test access from IT Operations. Every specific is a placeholder.
Replace each name, date and amount with your own.
Subject: Decision needed: [system] test access for [programme], [Head of IT Operations], by [date]
Dependency: [Programme] needs test access to [system] from [IT Operations].
Milestone held up: [User acceptance testing start], due [date]
The ask: Which access route should we use for testing?
Options
A. Full test copy of [system] : cost [effort], risk [risk], milestone kept
B. Read-only access to existing test environment : cost [effort], risk [risk], milestone moves to [date]
C. Wait for [next release window] : risk [risk], milestone moves to [date]
Recommendation: A, because [reason].
Decision owner: [Name], [Head of IT Operations]
Consulted: [Security lead], [Data owner]
Informed: [Programme team], [Sponsor]
Decided by: [date]
If no decision by then: we will plan for B and record it as decided by default.
Escalation: [Sponsor] will raise it at [steering committee] on [date].
Evidence: [link to test plan and RAID entry]
To answer: reply A, B or C, or book time with [lead] before [date].
How do you send a short version in email or chat?
A short decision request for email, Slack or Teams keeps only the ask, the options in one line each, your recommendation, the date and the default, with a link to the full page. Use the short version when the owner already knows the context. Send the full template when they don't.
[Name], we need a decision on [topic] by [date] to keep [milestone]. Options: A [option], B [option], C wait. We recommend A because [reason]. If we hear nothing by [date], we will go with [default]. Full detail: [link].
Where does a decision request sit next to a decision log, a RAID log and DACI?
A decision request is the ask. The decision log records the answer, the RAID log tracks the open dependency and its escalation, and DACI sets who plays which role. Send the request, log the outcome, and close the RAID entry. That way each document does one job.
- Decision log: record what was chosen, by whom and when. ProjectManager's decision log template is one format. For decisions you may revisit, a decision record like this GitHub template tracks status all the way to superseded.
- RAID log: keep the dependency open until the decision lands. See The Digital Project Manager, Asana or Smartsheet for formats.
- DACI: use it to fill in the owner, consulted and informed lines before the request goes out.
- Dependency map: if many requests point at the same function, a map shows the pattern for a steering discussion. Mural and Businessmap describe how to build one.
What do you do after the decision comes back?
After the decision comes back, confirm it in writing to the owner and record it in the decision log. Update the RAID entry and the milestone date, and tell the informed list what changes for them. Add a review date if the choice might need revisiting, and assign the first follow-up task to a named person.
Use this confirmation:
Thanks, [name]. Recorded: [option] for [topic], decided [date]. Next step: [task] by [owner] on [date]. We will review this on [date] if [condition].
If you run sponsor decisions through Unblockd, it sends asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.
Your next step: pick the oldest open dependency in your RAID log and fill in the template for it. Agree the default with the escalation owner before the next steering meeting.