A decision memo template that makes the trade-off clear

A reader should know what they are being asked to approve in the first paragraph. Specify the action, scope, cost ceiling, and timing. “Improve support operations” is an ambition. “Approve a four-week ownership rota for routine support tickets, using existing staff and no new software” is a decision. State who has authority to make it and when an answer is needed.

Put your recommendation before the background. Follow it with the strongest reason and the largest unresolved risk. Then explain why the choice is needed now: a recurring operational failure, expiring commitment, capacity constraint, or evidence from a completed experiment. If waiting is acceptable, say what useful information the delay would produce.

NASA’s decision-analysis guidance distinguishes mandatory conditions from criteria used to compare viable options. It recommends measurable criteria and documenting assumptions and uncertainty. For a business memo, this translates into two checks: can an option meet the essential requirements, and how does it compare on the outcomes that matter?^[1]

Define each metric tightly enough that two people could calculate it from the same records. “Faster support” leaves room for selective interpretation. “Share of routine tickets still without an owner after four business hours” names the population, event, and time boundary. Record the baseline period and exclusions before the pilot starts.

Keep the criteria few and distinct. Speed, time to respond, and responsiveness may count the same benefit three times. Put non-negotiable access or operational constraints in a pass/fail gate. Use weights only when you can explain why an extra unit of one outcome should outweigh a loss in another; a precise-looking score is still a judgment.

List options that someone could realistically implement. Include continuing the current approach, a process change, and a tool or staffing change when relevant. For each, explain the mechanism: what would actually improve the outcome? A new dashboard can expose a queue; it cannot make an absent owner available.

Give the current approach the same cost horizon and outcome measures as the proposed change. Existing licenses and staff time are not free simply because they are already budgeted, but sunk expenditure is not a new cash outlay either. Separate additional cash, internal effort, recurring commitments, and exit work so the reader knows what approval changes.

Label every important input as observed, estimated, or unknown. Record the source and date beside observed values. If a vendor quote is missing, use a clearly labeled scenario or leave the field unknown; do not make up a price and call it a quote. Ask which uncertain input could reverse the recommendation, then investigate that input first.

The following organization, measurements, and costs are fictional. A support team reviews 200 routine tickets received over two weeks. Thirty-six remained unassigned after four business hours: 36 ÷ 200 = 18%. Sixteen of those 36 crossed a shift handoff without a named next owner. That pattern makes handoffs worth testing; it does not prove they caused every delay.

The memo recommends a four-week rota with one named queue owner per shift and an explicit handoff. Setup is estimated at two internal hours. A ten-minute daily check over 20 working days adds three hours and 20 minutes, making planned pilot effort five hours and 20 minutes. The estimate excludes ordinary ticket resolution and adds no license expense. Coverage must be confirmed before launch.

The strongest objection to the fictional rota is that naming an owner may move work around without increasing capacity. If staffing is already saturated, it might improve the assignment metric while worsening resolution. The memo therefore pairs ownership delay with reopen rate and old backlog. A single improved number is not enough to declare success.

Set a stop condition before results arrive. In this example, pause expansion and review staffing if old backlog exceeds 12% at two consecutive weekly checks, or a shift cannot maintain its required coverage. Continue only if the pilot meets the ownership target without breaching the quality or backlog limits. Otherwise revise the process or investigate another option.

Compare similar weeks and note changes in ticket volume, complexity, staffing, and incident load. A short before-and-after pilot is operational evidence, not a controlled causal study. If the apparent gain disappears when a major incident week is excluded, describe that sensitivity rather than presenting the most flattering comparison.

AWS’s architectural decision-record guidance preserves the context, choice, and consequences of significant software decisions. Accepted records are retained, and a later decision can supersede them. That practice is useful beyond architecture: a team should be able to recover why an option made sense using the information available at the time.^[2]

Record the approver, decision date, version, owner, and review date. Keep the original assumptions visible when results arrive. Add the outcome or link a replacement memo instead of silently rewriting the original rationale. Distinguish an unsuccessful outcome from a poorly reasoned decision; an explicit uncertain assumption can fail even when the process was sound.

Before the review meeting, ask one colleague to argue for the strongest alternative. Resolve factual disagreements in the evidence table and leave genuine trade-offs visible for the approver. End the meeting with one of four states: accepted, rejected, revise, or defer until named evidence arrives. Assign the next action so the memo produces a decision rather than another meeting.