Write approval messages people can answer correctly

The four parts of a request people can answer

A reviewer can only answer well if the request carries its own context. Four parts do that work: the action (what the agent will do), the target (who or what it affects), the reason (why it was proposed), and the consequence (what becomes true the moment you say yes). Miss one and the reviewer has to leave the message to find it — or, more often, approve without it.

Watch the same request lose and regain its meaning:

Before: “Approve task #3172?”
After: “Send the renewal reminder to 18 members whose plans end this month? Uses the approved template, no discount. Sends immediately on approve.”

How to judge it: a good request can be answered correctly from a phone, on the first read, without opening anything else. If you would need to check another screen to be sure, a fact is missing.

The trade-off is length, and it is smaller than it looks: the four facts are shorter than the back-and-forth a vague request creates, and far shorter than undoing a mistaken yes.

Lead with a verb and an object

Open with what will happen, not with a label. “Send refund confirmation,” “Publish pricing update,” and “Archive 42 inactive records” each say the whole action in the first three words. “Confirm action?” and “Approve request?” hide the verb and force the reviewer to reconstruct it from the details below — and the moment they stop reading, they are approving a blank.

Match the verb to what actually happens, not to what feels gentle. “Delete” is not “Clean up”; “Charge” is not “Process.” A soft verb that undersells the consequence is worse than a blunt one, because it invites a yes the reviewer would not give if they read it plainly.

How to judge it: cover everything except the first line. If a stranger can still say what they would be approving, the verb and object are doing their job.

The trade-off: precise verbs make a message feel abrupt. At a gate that is a feature — the abruptness is the reviewer noticing the stakes.

Carry the facts the decision turns on

Between the action and the choice sit the facts a person weighs: who or what is affected, the amount or date or destination that matters, why the agent proposed it now, and what happens after approval. The test for including a fact is one question — could it ever change a yes into a no? If not, it is noise.

The failure here is usually too much context, not too little. When the agent dumps everything it knows, the one number that decides the answer — the recipient count, the refund amount, the deletion scope — sits buried mid-paragraph, and a rushing reviewer skims past it. Three sharp facts beat a tidy wall of ten.

How to judge it: read the request and ask what would have to be different for you to say no. If that fact is not on the screen, add it; if a fact would not move the decision either way, cut it.

The trade-off is real: trimming context risks hiding an edge case. Resolve it by keeping the facts that bound the blast radius — scope, money, and reversibility — and linking the rest behind a “review draft” for the times a reviewer wants to dig in.

Offer real choices, matched to the stakes

“Yes” and “No” make the reviewer translate a direction into an outcome. Label the choices with the outcomes instead: Send now and Keep as draft, Publish and Save changes only, Issue refund and Hold for review. For anything destructive, offer the reversible choice first, so a thumb moving on muscle memory lands on the safe option, not the permanent one.

Then spotlight the fact that carries the risk for that kind of action:

• Customer contact — name the recipients and that the message sends under your name.
• Publishing — say where it appears and who can see it afterwards.
• Payments — show the amount and the direction, in or out.
• Destructive actions — show the scope and whether it can be undone, and for how long.

How to judge it: if a reviewer tapping fast, without reading, would still land somewhere safe, the choices are ordered right. A symmetric “Yes / No” on a deletion fails this test.

The trade-off: putting the reversible option first adds a half-second to the common, safe path. That is a fair price for making the rare, irreversible mistake hard to reach by accident.

Measure the approvals people got wrong

A request you cannot see fail is one you cannot fix. Four signals separate a message that was misunderstood from one that was understood and approved:

• Undo right after approval — the reviewer said yes, then reversed it. They approved something other than what they meant.
• Repeated edits before approval — the draft keeps getting rewritten because the request did not surface what needed changing.
• Questions the reviewer asks — every “wait, who is this going to?” is a fact that belonged in the message.
• A rejection rate near zero — nobody ever says no. Usually that means the gate is being rubber-stamped, not that every proposal was perfect.

How to judge it: read the reasons behind rejections and undos, not just the counts. Three cancellations that all name the same missing fact tell you exactly which line to rewrite.

The trade-off: speed alone lies. A message approved in two seconds can mean it was perfectly clear or that nobody read it — only the undo-and-question trail separates the two.