Pārskatīt ikmēneša uzņēmuma izaugsmes plānu

Kad izmantot

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.

Pirms sāc

• 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.

Ko izpilde pieprasa2

Ceļš7 soļi

1. S1

   Collect last month's actualsaģents

   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.

   Izdarīts, kad every metric named in the plan has a number with a source and a date next to it.

2. S2

   Compare against the planaģents

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

   Izdarīts, kad a table exists with no empty cells and no metric left unmarked.

3. S3

   Explain each variance with evidenceaģents

   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.

   Izdarīts, kad 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 actionsīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S4 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   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.

   Izdarīts, kad the owner has named the actions and said what "done" looks like for each.

5. S5

   Turn each action into a goalaģents

   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.

   Izdarīts, kad 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 itaģentsvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

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

   Izdarīts, kad 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 reviewaģents

   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).

   Izdarīts, kad the owner confirms receipt and the cash forecast is updated or explicitly marked unaffected.

Pārbaudes — kā zinām, ka izdevās

• 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.

Ja noiet greizi

Ko atstāj katrs solis

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.

Ko saglabāt

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.

Kā šī procedūra uzlabojas

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.