What Should a Weekly Business Review Template Include?
Green numbers won't tell you what's stuck.
A weekly business review template should include the review period, current priorities, metric definitions and sources, material changes, cross-team dependencies, missing decisions, and previous commitments. Give each important exception an evidence source, an authorized decision maker, and a latest useful decision date. Keep the review document separate from the meeting agenda.

Keep a consistent metric summary, then look underneath it. What changed? Which commitment now depends on an unmade decision? Who can settle it? Revenue can be progressing while the next onboarding promise rests on scope nobody has approved.
The customer plan is waiting on scope
Delivery cannot confirm proposed implementation support until its terms are settled.
- Known condition
- Proposed support exceeds standard scope
- Decision requested
- Include, scope separately, or narrow the promise?
- Owner of the call
- Authorized commercial owner
This is work context alongside financial reporting, not a replacement for it.
The review is not the meeting.
The operating review is a recurring view of the business: results, current conditions, risks, and decisions. The leadership agenda determines how people use meeting time. A written review lets leaders read routine facts before the discussion.
Use the document to compare functional inputs and prepare the exception queue. The COO should be able to see the dependency without reconstructing every handoff personally.
What goes in a weekly business review template?
Start with a short cover block so readers know which version they are reading.
Review period and timezone:
Prepared by:
Data cutoff:
Current company priorities and effective dates:
Changes since the previous review:
Decisions required this week:
Links to supporting records:
Keep the metric summary small enough to interpret. Choose measures the company already uses to make decisions; this article does not prescribe a universal SaaS scorecard.
| Metric | Definition and source | Period and cutoff | Target or reference | Actual and trend | Owner | Explanation or uncertainty |
|---|---|---|---|---|---|---|
| [Measure] | [Definition; source link] | [Comparable period] | [Approved reference] | [Observed result] | [Named owner] | [What changed; what is unconfirmed] |
Distinguish weekly activity from longer-term outcomes. If a measure has too little weekly volume to interpret, label the limitation or use a more appropriate period. Don't turn normal variation into an escalation merely because the meeting happens every week.
How do you connect business review exceptions to decisions?
Use the next table for business changes that need attention. A material exception is a change that could alter an agreed priority, customer obligation, resource choice, or forecast assumption. Leadership should define materiality for its own business.
| Priority | What changed | Evidence and date | Business consequence | Decision needed | Decision maker | Latest useful date |
|---|---|---|---|---|---|---|
| [Current priority] | [Observable change] | [Source] | [Work or obligation affected] | [Answerable question] | [Authority] | [Date and reason] |
Include healthy metrics when the underlying work reveals a risk. Equally, do not escalate every red number without understanding its definition and context. The table is a way to connect evidence to a choice, not a second set of status colors.
Revenue looks fine — onboarding is waiting.
Suppose new contracts are progressing as expected, but Customer Success finds an assisted-onboarding dependency: Sales is describing implementation help that delivery teams have not scoped.
The review needs a scope decision before the next customer discussion.
| Field | Review entry |
|---|---|
| Priority | Repeatable mid-market onboarding |
| Change | Proposed implementation support exceeds the standard onboarding scope |
| Evidence | CS scope review and the proposed customer plan |
| Consequence | Delivery cannot confirm the plan until support terms are settled |
| Decision | Include limited assistance, price it separately, or narrow the promise? |
| Decision maker | Authorized commercial owner, with delivery and Finance input |
| Date | Before the customer scope review |
“Onboarding: amber” leaves the room guessing. This entry names the choice. It lets the leadership team decide whether the commercial promise or delivery plan should change.
How should a weekly business review track previous commitments?
Keep last week's follow-through visible beside the new exception queue.
| Previous commitment | Owner | Due date | Evidence now available | Next step |
|---|---|---|---|---|
| [Agreed action] | [Person] | [Date] | [Completed artifact or confirmed gap] | [Close, revise, or escalate] |
If an action rolls forward, preserve the earlier date and the reason. Replacing the due date makes a recurring dependency look like a new item. Ask whether the owner lacks authority, capacity, or a required decision before simply setting another deadline.
The organizer should distinguish source facts from interpretation. “Sales has sent the revised scope” is different from “the customer accepts the revised scope.” Record which one is supported.
Start with a review someone can keep current.
For the first review, choose one cross-functional priority, a small set of decision-relevant measures, and the commitments already due. Assign a keeper for definitions and a functional owner for each input.
After the discussion, update the decision record and communicate any changed priorities. In the next review, check whether the affected teams changed their work. Add fields only when they help someone make or implement a decision.
What is Decided?
Decided is an AI operating alignment layer for fast-moving SaaS companies. Clara runs recurring private 1:1 AI voice check-ins about priorities, blockers, decisions, and commitments. Decided compares the answers and prepares an alignment map, a weekly leadership brief, and context for follow-up.
This is work context alongside financial reporting, not a replacement for it.
People review the context and make the decisions. Before rollout, explain what is captured, who sees the output, how it is used, and whether participants can review notes. Private 1:1 describes the format, not anonymity. Decided is not hidden monitoring, employee scoring, or an automated employment decision system.
Explore Decided for SaaS companies. Try a live voice check-in to see how it works.
Sources.
Atlassian's weekly team updates play describes a written update practice. WorkBoard's strategy execution discussion connects strategy with an ongoing operating cadence.
