Owner's weekly review — money, people, customers, risks

When to use

Every week, on the fixed slot. Not for the month-end numbers and VAT filing — that is money.month-close and money.vat-return-lv, which run on their own cadence and feed this review. Not for the monthly growth and metrics deep-dive — that is growth.monthly-growth-review. Decisions that change how the company works are written up separately with management.decision-record; this playbook only records that they were made.

Before you start

• The slot is in the owner's calendar and the agent's schedule; the review happens even in a bad week — especially in a bad week.
• Last week's watch list is available (it is an input, not something to reconstruct from chat).
• The owner has decided which numbers matter: usually bank balance, cash-in/cash-out last 7 days, unpaid invoices, open offers, live goals. The pack does not grow week to week.

What a run requires2

The trail8 steps

1. S1

   Assemble the packagent

   Pull from the money module: balance per account, in/out for the last 7 days, unpaid invoices with days overdue, upcoming outgoings. Pull goal and task status. Keep it to one page of numbers, each with its source and date.

   Done when the pack exists, is dated, and every number names the module it came from.

   ⛔ A number without a source is a guess; the owner will decide on it.

2. S2

   Flag exceptionsagent

   Compare against the watch list and simple thresholds: invoices overdue past the agreed term, weeks with negative cash in the 13-week view (money.cash-forecast-13w output), tasks past their date, contracts or licences near expiry, unanswered customer escalations.

   Done when every exception is one line: what, how big, since when, link.

   ⛔ "Everything looks fine" with no list of what was compared is not a scan.

3. S3

   Walk the pack and decideownerneeds approval · owner

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

   The owner reads the pack, asks, and marks each flag: act (do something this week), watch (check again next week), drop (accepted, with one line why).

   Done when every flag carries exactly one of the three marks in the owner's own words where it matters.

   ⛔ A flag left unmarked is not "no decision" — it is an unrecorded one; force the mark.

4. S4

   Record and route the decisionsagent

   Each act becomes a task or goal update with an owner and a date; each drop keeps its one-line reason; each watch goes to the carry-forward list. Anything big enough to change the company is also noted for management.decision-record.

   Done when the agent reads the decisions back and the owner confirms nothing is missing or wrong.

5. S5

   Draft the messages the decisions needagent

   Chase letters for overdue invoices, replies to customers, requests to suppliers — drafted in the mail module from the company's templates, addressed, not sent.

   Done when every draft names the decision it implements and sits in the outbox as a draft.

6. S6

   Approve outgoing messagesownerneeds approval · owner

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

   The owner reads each draft and approves or edits it. Only then is it sent from the company's mail.

   Done when every sent message matches an approved draft, and nothing left without the owner's approval.

   ⛔ The agent never sends to a third party on its own — a chase sent with the wrong tone costs more than a late invoice.

7. S7

   Carry forwardagent

   Build next week's watch list: every watch item, plus act items not yet closed, each with the question to answer next week.

   Done when the next run's S2 will start from this list, not from memory.

8. S8

   Log the runagent

   Record: date, minutes taken, flags raised, decisions by type, "act" items created, messages sent.

   Done when the run row exists with playbook_id@version and is comparable to previous weeks.

Checks — how we know it worked

• Every flag from S2 has a mark; no blank lines.
• Every act has a named owner and a date — "someone should" is not a decision.
• The balance and invoice numbers in the pack match the money module as read back at S4, not a screenshot from Monday.
• Nothing was sent to a third party without an S6 approval.
• The watch list for next week exists before the meeting ends.

If it goes wrong

What each step leaves behind

1. S1the pack exists, is dated, and every number names the module it came from.
2. S2every exception is one line: what, how big, since when, link.
3. S3every flag carries exactly one of the three marks in the owner's own words where it matters.
4. S4the agent reads the decisions back and the owner confirms nothing is missing or wrong.
5. S5every draft names the decision it implements and sits in the outbox as a draft.
6. S6every sent message matches an approved draft, and nothing left without the owner's approval.
7. S7the next run's S2 will start from this list, not from memory.
8. S8the run row exists with playbook_id@version and is comparable to previous weeks.

Evidence to keep

The dated pack · the decision record with marks and reasons · tasks and goal updates created, with ids · approved drafts and sent messages · the watch list for next week · the run log row with management.weekly-owner-review@version, minutes taken, flag and decision counts.

How this playbook improves

After every 8 runs ask: how long did the review take, and is the trend up (pack too big)? What share of flags was decided in the meeting vs deferred — and did any deferral turn into a miss? How many "act" items passed their date without closing? Which exceptions did S2 find late — should that check move earlier or get its own playbook? A new version changes the step that caused the drift or the miss, and says so in its change note.