Guides

decision briefs

Assemble a weekly decision brief from open work

Turn the queue, the exceptions, and the client updates into a one-page brief that asks for specific decisions with dates.

Assemble a weekly decision brief from open work
Table of contents

Start from the decisions, not the activity

A weekly decision brief is not a status report. It should ask for the choices that are waiting and explain what happens if they wait. Start with a short list of decisions, each with an owner and a deadline. Activity belongs in a second section or an appendix.

Ask the queue owner which items cannot move without a decision. A decision may be a price approval, a scope change, a priority call, or a permission grant. Write the decision as a question with two or three options. A vague request for direction is not a decision.

Limit the brief to the decisions that matter this week. A brief with twenty items is a queue dump, and the reader will choose the easiest one. Three to five decisions is usually enough. Put the rest in a watch list with a date rather than a request.

Show the evidence in a usable form

Each decision needs the facts that would change the answer. Include the cost, the deadline, the client impact, and the risk of waiting. Add a source link for each number. The reader should be able to check the evidence without opening a second document.

Separate what is known from what is estimated. A forecast is useful, but it should not look like a measurement. Label the assumption and the date it was made. If the decision depends on a client response, say so and give the date the response is expected.

Use one small table rather than several long paragraphs. A table with the options, the cost, the risk, and the recommendation is easier to scan. Keep the prose for the reasoning and the caveats. The table should make the choice visible at a glance.

Make a recommendation

The brief should recommend an option rather than only describe the choices. State the recommendation in one sentence and give the strongest reason. Add the condition that would change the recommendation. A clear recommendation saves the reader time and makes disagreement easier.

Do not hide a weak option to make the recommendation look stronger. Include the best argument against the preferred choice. The reader may know something the writer does not. A brief that presents only one side is advocacy, not decision support.

Name the person who should decide and the date the answer is needed. A recommendation without a decision owner is a suggestion. A decision without a date is a topic for next week. Put both at the top of the item.

Record the outcome and the next step

After the decision, record what was chosen, who approved it, and what changes as a result. Add the next action and the owner. A decision that is not recorded will be relitigated in the next meeting. The brief should become the record, not a discarded draft.

Send the outcome to the people who need to act on it. Include the client contact, the queue owner, and anyone whose work changes. Keep the language short and specific. A decision note is not a meeting transcript.

Review the previous week's decisions at the start of the next brief. Mark each one as done, in progress, or blocked. A decision that never moved should be raised again with the reason. The review closes the loop and shows whether the brief is useful.

Keep the format short and stable

Use the same five parts each week: decisions needed, evidence, recommendation, owner and date, and previous outcomes. A stable format lets the reader find the important part quickly. It also makes the brief easier for an assistant to assemble from the queue. The reader should not have to relearn the layout each week.

Write in plain language and define any internal term. Avoid acronyms that only one team understands. A brief that requires a decoder is not a decision tool. The reader may be a client or an executive who does not see the work every day.

Keep the main page to one screen if possible. Put the detailed evidence and the watch list in an appendix. A brief that is too long will be skimmed, and the decision at the bottom will be missed. Length is a design choice, not a measure of effort.

Set the boundary for the assistant

The assistant can gather the evidence, draft the options, and track the outcome. The decision owner should choose and approve. The assistant should not present a recommendation as a decision or commit the client to a change. Write that boundary in the role brief.

Define what the assistant does when the evidence is incomplete. The default should be to state the gap and ask for a decision on whether to wait or proceed. Do not let the assistant fill a gap with a confident estimate. A visible gap is safer than a hidden assumption.

Review the brief format each month and change one part at a time. If readers ignore the evidence section, shorten it. If decisions are not made, check whether the owner and date are clear. Measure the brief by the decisions it produces, not by the number of pages.

Sources

Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.

  1. NIST Baldrige Excellence Framework
  2. Plain Language Guidelines, plainlanguage.gov
  3. National Archives, Records Management

Turn the reading into a role brief

Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.

Plan a Philippines-based role