You wrote four careful paragraphs, ended with "thoughts?", and got silence. Then a clarifying question. Then a meeting invite. What you did not get was a decision.
Decision requests rarely fail on the merits. They fail structurally: the reader can't find the decision, can't hold the options in one glance, and can't tell which parts of the message are facts and which are hopes. Six moves fix that.
Name the decision in one sentence — options included
Open with the whole request: "I need a decision between renewing the lease (A) and taking the smaller space on 5th (B), by Friday." One sentence, options enumerated, list closed.
If you can't close the list, you aren't asking for a decision yet — you're asking for ideas, which is a different request with a different shape, and it's fair to just say so. A closed list turns your message into a multiple-choice question. Multiple-choice questions get answered; essays get archived.
Give a cold reader 150–400 words of context — not your history
Write the background for someone who knows nothing, even if the reader knows plenty — the cost of over-explaining is seconds, the cost of under-explaining is a week of back-and-forth.
The trap is chronology. How the situation unfolded is your story; what is true right now is their input. State the current position, the hard constraints, and the stakes, and cut everything whose real purpose is justifying yourself. Under about 150 words you force the reader to guess; past 400 you bury the question you opened with. The cut hurts, and the hurt is diagnostic — if you can't compress the situation, you may not understand it yet.
State your recommendation — and what would change your mind
"I recommend B. I'd flip to A if the landlord commits to a two-year cap." A request without a recommendation outsources your homework: the reader has to reconstruct your analysis before they can start theirs.
The second half — the disconfirmer — is the part people skip and the part that does the most work. It proves the recommendation is falsifiable, and it tells the reader exactly where their knowledge is most useful. If you have no recommendation, you're asking for an opinion, not a decision. That's a legitimate ask; make it explicitly.
Label facts and guesses
"The renewal is 8% above market" is a fact. "The landlord will negotiate" is a guess. Decisions go wrong when guesses arrive dressed as facts, because the reader can't tell which claims will hold weight.
The fix costs a word or two: prefix "confirmed:" or "my read:". Cheap to write, expensive to omit — an unlabelled guess that turns out wrong doesn't just sink this decision, it taxes every message you send afterward.
Set the response shape and an honest deadline
Say what a sufficient answer looks like: "Reply A or B — one line is enough. If you'd rather talk it through, say so and I'll find fifteen minutes." Most people over-answer because nobody told them they were allowed to be brief.
Then a real deadline with a named default: "If I don't hear by Thursday noon, I'll proceed with B." An honest deadline includes what happens when it passes. A decorative one trains people to ignore the next ten.
Make replying nearly free
One decision per message — bundle three questions and you'll get the answer to the easiest one. Nothing load-bearing in an attachment. The test is whether a busy reader could answer well from a phone, in under two minutes, without opening anything. If not, the request gets deferred, and deferred is where decisions die.
This structure already has a name
Read the six moves back as a list: an ask with a response shape and honest urgency; a context brief written for a cold reader; options enumerated; a recommendation with its disconfirmer; assumptions labelled fact or guess. Field for field, that is a briefing — the format exists because good decision requests keep converging on this shape independently.
None of it requires software. The checklist works in any email you write by hand, and if you take one thing from this page, take the checklist. The reason to formalize it is cost: composition, not delivery, is the expensive half of email, and if you've already worked the problem through with an AI assistant, the raw material — current state, options, constraints, your actual lean — already exists in the session. On RelayLink, your assistant assembles the briefing from that private session, you review the exact package before anything sends, and provenance handles the fact-versus-guess bookkeeping: every assumption is labelled stated by sender or inferred by sender's AI, so your reader never wonders which is which.
One honest limit: a briefing can't rescue a decision you haven't thought through. If your recommendation is missing, the format shows the gap rather than papering over it. That's a feature — better to find out before you send than after.
To see the structure applied to five concrete situations, read AI briefing examples. For particular cases worked through at length, there are guides on asking for a technical design review, asking an advisor or board member, getting a decision out of an open source thread, running a vendor selection, and writing an investor update with an ask. To have your assistant do the assembly, connect it.