Review the monthly company growth plan

When to use

Once a month, for the whole company's growth numbers against its plan. Not for setting the quarter's objectives — that is growth.quarterly-okrs. Not for reviewing one experiment — that is growth.run-experiment, whose results feed into this review as input. Not for a single channel's tactics (SEO, reviews, newsletter) — those have their own playbooks; this one decides *which* of them deserve effort next month.

Before you start

• The plan (or OKRs) for the current quarter exists and names its metrics. If it does not, run
• money.month-close for the reviewed month is done, or its output is marked provisional.
• The agent has access to site analytics, the money module and the goals module.

What a run requires2

The trail7 steps

1. S1

   Collect last month's actualsagent

   Pull from site analytics: sessions, conversions, top sources. From the money module: revenue, new invoices, new customers, paid vs overdue. Note the date of each pull.

   Done when every metric named in the plan has a number with a source and a date next to it.

2. S2

   Compare against the planagent

   For each planned metric write actual, target, and the gap in percent. Mark each as on-track / behind / ahead.

   Done when a table exists with no empty cells and no metric left unmarked.

3. S3

   Explain each variance with evidenceagent

   For every metric behind by more than 10%: find the cause in the data (a channel stopped, a campaign ended, price changed, season) and cite the number that shows it.

   Done when each variance has a cause backed by a figure, or is honestly marked "cause unknown — needs a check".

   ⛔ "We think it was the holidays" without a comparison to the same month last year is a story, not an explanation.

4. S4

   Choose at most three actionsownerneeds approval · owner

   Approval · S4 · owner — the run stops until a named person records the decision

   The agent proposes a shortlist ranked by expected effect and effort, including at least one action that fixes the biggest variance and one that protects what worked. The owner picks ≤ 3 and drops the rest explicitly.

   Done when the owner has named the actions and said what "done" looks like for each.

5. S5

   Turn each action into a goalagent

   Record each chosen action in the goals module with an owner, a metric and a due date within the month; link it to the plan it serves.

   Done when every chosen action exists as a goal and every dropped proposal is recorded as declined, with the reason.

6. S6

   Write the one-page review and file itagentneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   One page: the S2 table, the S3 causes, the decisions, the goals created. The owner reads and approves it.

   Done when the approved review is stored, linked from the plan, and the review log has a row (month, date, decisions, who approved).

7. S7

   Hand the numbers to the owner reviewagent

   Send the owner the same one-pager formatted for management.weekly-owner-review and flag any metric that affects the 13-week cash view (feed to money.cash-forecast-13w if the revenue gap is material).

   Done when the owner confirms receipt and the cash forecast is updated or explicitly marked unaffected.

Checks — how we know it worked

• Every planned metric has an actual number read back from its source (not from memory or last month's file).
• Every variance above 10% has a cause with a figure, or is marked "cause unknown".
• At most three goals exist for the coming month; each has an owner, a metric and a date.
• The review log row exists and names the plan version that was reviewed.

If it goes wrong

What each step leaves behind

1. S1every metric named in the plan has a number with a source and a date next to it.
2. S2a table exists with no empty cells and no metric left unmarked.
3. S3each variance has a cause backed by a figure, or is honestly marked "cause unknown — needs a check".
4. S4the owner has named the actions and said what "done" looks like for each.
5. S5every chosen action exists as a goal and every dropped proposal is recorded as declined, with the reason.
6. S6the approved review is stored, linked from the plan, and the review log has a row (month, date, decisions, who approved).
7. S7the owner confirms receipt and the cash forecast is updated or explicitly marked unaffected.

Evidence to keep

Analytics and money pulls with dates · the S2 comparison table · the S3 causes with their figures · the owner's decision in S4 (who, when, what was declined) · the approved one-pager · the review log row.

How this playbook improves

After every 6 runs ask: how many days from month end to a filed review, and which step delayed it? What share of last month's chosen actions actually shipped? Did any decision in S4 turn out to have no measurable effect — and did the review catch it? A new version changes the step that caused the delay or the miss, and says so in its change note.