Weekly operations agenda
Objective. Turn dashboards into a repeatable weekly decision routine for the customer's managers - one that always ends in actions, owners and a data-health check.
A fixed weekly meeting agenda the customer runs themselves, built so every session converts numbers into decisions rather than admiring charts. It carries forward the review loop managers learned (KIT-06), adds a standing data-health check, and keeps an action log with owners. This is the tool version of C06 - copy the agenda, set the cadence, and make it the heartbeat of adoption.
See it in the demo
What it is and when to use it
The weekly operations agenda is the recurring routine that makes the product part of how the customer runs their week. Install it right after manager enablement (KIT-06), and keep it running - it is the single strongest predictor of adoption and therefore of renewal. It matters because entitlement and configuration mean nothing if nobody looks at the numbers and acts; a dashboard with no routine is shelfware. The agenda is deliberately short and fixed so it survives busy weeks, and every item is designed to end in a decision, not a discussion.
The agenda - copy this
TEAM / SCOPE: ____ FACILITATOR: ____ CADENCE: weekly, ____ (day/time)
- DATA HEALTH (5 min) - is coverage complete, are sources fresh, any gap since last week? If a number is not trustworthy, say so and do not act on it.
- LAST WEEK'S ACTIONS (5 min) - review the log: done / in progress / blocked. Carry forward or escalate the blocked ones.
- THE EXCEPTIONS (15 min) - the agreed view's exceptions only, read with context (denominator, scope, period). For each: what does it mean, what does it NOT mean, is it worth an action?
- DECISIONS (10 min) - for each exception worth acting on: the action, the owner, the date. Nothing leaves this block without an owner.
- ONE IMPROVEMENT (5 min, optional) - one process or coaching change to test, with a before/after measure.
- ESCALATIONS (5 min) - anything for the admin, the CSM or a specialist.
ACTION LOG (standing): exception | action | owner | due | status.
How to fill and run it
Keep it fixed and short so it runs even in a bad week - a 30-minute routine that happens beats a 90-minute one that gets cancelled. Start with data health every time: if coverage dropped or a source is stale, the numbers are not trustworthy and the meeting says so rather than acting on bad data. Review last week's log before looking at anything new, so actions do not evaporate. In the exceptions block, read each number with context and explicitly state what it does not prove, carrying forward the discipline from the manager workshop (KIT-06). Every exception worth acting on leaves block 3 with an action, an owner and a date in the log - that is the entire point. Escalate what belongs to the admin, CSM or specialist rather than letting it stall. Tie the routine's focus to the success plan (KIT-08).
The honest caveat
A running agenda is a leading indicator of adoption, not proof of outcome - the business result still depends on the actions in the log actually getting done and being the right ones, which is what the QBR tests (KIT-12). Guard against the routine decaying into a status read-out where numbers are admired and nothing is owned; if a session produces no action with an owner, the routine has failed that week regardless of attendance. Do not let an untrustworthy number drive an action - the data-health block exists precisely so a coverage gap or stale source stops the meeting from acting on a figure it cannot defend. And keep every reading honest: a weekly cadence repeats a misread fifty times a year if the context discipline slips.
Interpretation check
A running weekly routine is the strongest leading indicator of adoption, but it is not the outcome - the result depends on the logged actions getting done. Every session starts with a data-health check so no decision is made on a number that is not trustworthy.
Practical task
Stand up a weekly operations agenda for a real or seeded team: set a fixed day and time, run one full session (data health, last week's log, exceptions read with context, decisions with owners, escalations), and produce a populated action log where every acted-on exception has an owner and a due date. Tie the focus to the account's success plan.
Self-check
Why does every session start with a data-health check?
If coverage dropped or a source is stale the numbers are not trustworthy; the check stops the meeting acting on a figure it cannot defend, and a weekly cadence would otherwise repeat the mistake every week.
What must block 3 (decisions) always produce?
An action, an owner and a date for every exception worth acting on - nothing leaves the block without an owner, logged. A session with no owned action has failed that week.
Why keep the agenda fixed and short?
A 30-minute routine that actually happens every week beats a long one that gets cancelled; durability is what makes it a reliable adoption signal.
Is a well-attended weekly meeting evidence of value?
No - it is a leading indicator. Value depends on the logged actions being done and being right, which the QBR tests; attendance without owned action is shelfware with a calendar invite.
Verified vs demo. The agenda is reusable; the exceptions and numbers are the customer's own validated data, read with context. The data-health block depends on real coverage and freshness for the account, and app-specific context (denominators, what a label does not prove) comes from each application's guardrails.