Team Operations
Weekly Business Reviews: Turn KPI Exceptions Into Decisions
Review a small set of operating measures with clear definitions, comparable periods and accepted actions, rather than reading a dashboard aloud.
What you will learn
- Choose operating measures tied to decisions and explicit definitions
- Investigate exceptions without confusing missing data with poor performance
- Record accepted actions and review their outcome in the next period
A weekly business review is a short operating rhythm for examining important changes and deciding what to do next. It should connect trustworthy measures with accountable decisions, not become a meeting where every owner reads a dashboard aloud.
Begin with the decisions the team needs to make. A metric earns a place when it helps reveal a condition that could change an action. More charts do not automatically produce a better review.
Define the scorecard before judging the result
For each measure, write its unit, period, source, owner and coverage. A count of open requests is a snapshot; completed requests over a week are a flow. A signup is not an activated account, and a forecast is not collected revenue.
AWS's operational dashboard guidance discusses clear human-facing system views and designing for the intended reader. The scorecard below is an original small-team exercise, not a reproduction of Amazon's business-review process.
Choose stable definitions before comparing periods. If a data source or eligibility rule changes, flag the break rather than presenting the resulting movement as business performance.
Use an exception-to-decision scorecard
This fictional service team reviews complete Monday-to-Sunday periods. Its thresholds are internal investigation triggers, not external performance benchmarks.
| Measure and definition | Observation | Exception question and decision |
|---|---|---|
| Accepted requests completed during the week | 18 completed versus 20 in the prior complete week | Did request mix or available capacity change? Review the two largest blockers before changing staffing |
| Open requests at Sunday cutoff | 12 open versus 9 at the prior cutoff | Reconcile new arrivals and completions; identify the oldest unresolved dependency |
| First useful customer outcome | Five confirmed; tracking incomplete for two accounts | Resolve the coverage gap before reporting a full-cohort conversion rate |
| Rework requests attributable to completed deliveries | Three reported, but two await classification | Review evidence before calling all three quality failures |
Give every row a source link and a named data owner. Keep unavailable values visible. A blank cell should not silently become zero, green or “on track.”
Reconcile a surprising change
In the fictional example, nine requests were open at the beginning of the week, 21 arrived and 18 completed. If no requests were canceled, merged or otherwise removed, ending open work is 9 + 21 − 18 = 12. That reconciles the scorecard.
If the reported ending count were 15, investigate definitions, missing events and record changes before inventing an explanation about demand. The basic reconciliation can reveal a measurement issue that a percentage chart would conceal.
A two-request reduction from 20 to 18 completions is a 10% decrease, but the percentage does not establish a trend or cause. Inspect the underlying work and the sample size. One unusually complex request may matter more than a small week-to-week fluctuation.
Spend live time on exceptions and choices
Circulate the scorecard and context before the review. Ask owners to identify what changed, what is known and which decision needs help. Do not demand a causal story for every variation; “we do not know yet” can be the correct answer.
For a meaningful exception, decide whether to investigate, change an action or continue observing. Name the output and owner. A decision to wait should include a review trigger so it does not become neglect disguised as patience.
Use the meeting agenda template to make those decisions explicit. Keep routine progress in the working record rather than expanding the meeting to cover every task.
Review the previous action, not just the next number
Begin the following review by checking accepted actions. Did the owner resolve the data gap? Was the blocker removed? Did the intervention create a new problem? Separate whether an action happened from whether it helped.
Retire measures that no longer support decisions, while preserving necessary historical definitions. Add a measure only with a reason and maintenance owner. The task management guide helps translate a review decision into visible work.
Copyable AI prompt
Try this with Aurora AI in Finta, Codex, or Claude. Use authorized aggregate operating data.
Prepare a weekly business review from [metric definitions], [complete comparable periods], [coverage notes] and [previous accepted actions]. Build a small exception-to-decision scorecard. Reconcile stocks and flows where possible, recalculate changes and flag missing data or definition breaks. Separate observations, hypotheses and decisions. Propose bounded investigations with owners for human acceptance. Do not invent causes, benchmarks or commitments, and do not change staffing, priorities or source records.Build a useful operating rhythm
Explore Finta's Executive Assistant for preparing the review. A reliable definition and one clear decision are more valuable than a dashboard nobody can act on.