Create a weekly GTM operations brief from source evidence
A one-page operating brief that answers three questions, shows exception evidence, and assigns actions without turning into a report factory.
Choose three questions the brief must answer
A weekly operations brief should answer a small number of questions that the team will act on this week. Good candidates include what changed in pipeline coverage, where the handoff queue is aging, and which launch dependency is at risk. Write the questions at the top of the brief and keep them stable for at least a quarter. A stable brief is easier to read and easier to compare week to week.
Do not add a section just because a report exists. Every section should support one of the three questions or be removed. If a leader needs a different question answered, replace a section rather than growing the brief. The brief is a decision tool, not a complete archive of everything the operations team knows. Each section should have a named reader and a decision it supports.
Pull each number from one named source
Name the system, report, and date behind every number in the brief. If two systems disagree, show both values and explain which one the team treats as authoritative. Do not average conflicting numbers to make the brief look tidy. A named source lets a reader verify the figure and understand why it changed. If the source cannot be named, the number should not appear in the brief.
State the time window and the population for each measure. A pipeline number for the current quarter is not the same as a rolling four-week average, even if both are labeled pipeline. Include the comparison period and note any change in definitions. A number without a source and a window is an opinion with a decimal point.
Write the exception section first
Start with the items that did not follow the normal process, because those are the ones that need a decision. Examples include a stalled handoff, a launch dependency without an owner, or a campaign that missed its approved audience. Describe the exception, the consequence, and the decision required. Keep the description short enough to read in one pass.
Do not list every routine task in the exception section. If everything is an exception, the team cannot tell what needs attention. Use a threshold or a rule to decide what qualifies, and record the rule in the brief template. The exception section should shrink when the process is working, not grow because the team is capturing more detail.
Keep the brief to one screen
A one-screen brief forces the writer to choose the most important information. Put the three answers at the top, the exception list in the middle, and the actions at the bottom. Use short sentences and link to the detailed evidence rather than pasting it into the brief. A reader should be able to understand the week in less than five minutes.
Use tables only when they make a comparison easier, and keep the columns few. Long narrative paragraphs hide the decision inside the story. If a section needs more than a few lines, move the detail to an appendix or a linked document. The brief should point to the evidence, not reproduce it. If a table needs a legend longer than the table, replace it with a short paragraph.
Assign actions with dates
Every action in the brief needs one owner and one date. Write the action as an observable result, such as confirm the launch owner for the offer page, rather than a general request to follow up. If the action depends on another team, name the dependency and the date it is needed. An action without a date tends to become a permanent item on next week's list.
Review the prior week's actions before writing the new brief. Mark each one as done, dropped, or carried forward with a reason. Do not silently carry an action for several weeks without noting why it is stuck. The action review is often more useful than the new numbers because it shows where the team is actually blocked.
Audit the brief after four weeks
After four weeks, ask the readers which sections they used and which ones they skipped. Compare the brief with the decisions that were actually made in the operating meeting. If a section never influenced a decision, remove it or replace it with a better question. A brief that is read but never acted on is a writing exercise.
Check the sources and definitions as well. A number may be accurate but no longer relevant, or a report may have changed its logic. Update the brief template with the smallest useful change and keep a note of what changed. The goal is a brief that stays short, sourced, and connected to the work the team is doing.
Automate the pull, not the judgment
Automate the repeated data pull so the writer spends time on exceptions and actions. Keep a documented query or saved report for each number, and check it against the source on a fixed schedule. Automation should reduce transcription errors, not hide the definition. If the query changes, version it and note the change in the brief.
Leave the interpretation and the action assignment with a person. A dashboard can show that a queue is aging, but it cannot decide whether to reassign the work or change the rule. The brief should make that decision visible and assign an owner. Automation handles the collection, and the team handles the judgment. A person should be able to explain any change in the number.