Operating Review System

Executive summary

An operating review system is the set of meetings, documents, owners and records that a company uses to look at its results, decide what to do, and check later whether the decision worked. The meetings are the visible part. The part that decides whether the system produces anything is the record: what was decided, who owns it, what result was expected, and what actually happened.

Most reviews fail in the same way. The numbers are presented, people discuss them, a few actions are mentioned, and the next month the meeting starts again from the dashboard. Nobody can say which decisions from the last six reviews worked, because nobody wrote down what "worked" would have looked like. The review becomes a reporting ritual.

The core claim of this playbook is simple: a review only helps if decisions and outcomes are recorded. Everything else in the system (agenda, layers, KPIs, templates) exists to make recording cheap and checking routine.

What you will build:

1. A small number of review layers with fixed purpose, attendees and inputs.
2. A single decision log and action log that every layer writes to.
3. A rule that every decision names an owner, an expected result, a measure and a check date.
4. A closing step in each review that looks back at decisions that have come due.
5. A 90-day rollout that a mid-market management team can run without new software.

This playbook assumes a company or a portfolio company with a management team of roughly five to fifteen people. For the calendar of meetings, see operating cadence: weekly, monthly, quarterly rhythms. For who is allowed to decide what, see the decision rights matrix template. This guide is about what happens inside and after the meetings.

When to use this

Use this playbook when:

• Leadership meetings are held regularly but the same issues come back month after month.
• Actions are agreed in the room and nobody can find them three weeks later.
• A sponsor, board or lender asks "what did management do about that?" and the answer depends on memory.
• A new CEO or CFO has taken over and wants to replace a reporting ritual with a decision process.
• You manage several companies and want comparable review practice across them.
• A turnaround, integration or value creation plan needs a way to track whether initiatives deliver what the plan assumed.

Do not start here if the monthly numbers are not trusted. If the team spends the review arguing about whether the figures are right, fix the close and the reporting first (see the management reporting playbook). A review system on top of unreliable numbers records decisions that cannot be checked.

Diagnostic questions

Answer these honestly before changing anything. Score each as yes, partly or no.

1. Can you list the decisions made in the last three management reviews, without opening anyone's email?
2. For each of those decisions, is there a named owner and a date by which something should change?
3. Did anyone write down, at the time, what result the decision was expected to produce?
4. Can you say which of last quarter's decisions delivered the expected result, which delivered less, and which delivered nothing?
5. Do review meetings have a fixed agenda, a fixed set of inputs circulated in advance, and a fixed duration?
6. Is it clear which questions belong to the weekly meeting, the monthly review and the quarterly review?
7. Are open actions reviewed at the start of each meeting, or only raised when someone remembers?
8. When a measure is off plan, does the review assign a cause and an owner, or does it note the variance and move on?
9. Does anyone outside the management team (board, sponsor, lender) see the same decision and action records the team sees?
10. When a decision turns out wrong, is the discussion about learning, or about blame, so that people avoid recording expectations at all?
11. Is there one place where decisions are kept, or are they split across slide decks, emails, chat threads and personal notebooks?
12. How many decisions per review are genuinely decisions (a choice between options, with a cost), and how many are updates?

Reading the answers: if questions 1 to 4 are mostly no, the problem is the record. Fix that first, because it makes everything else measurable. If 5 to 8 are mostly no, the meeting design is weak. If 9 to 12 are mostly no, the culture and tooling around the record need work before you add rigor.

The framework: layers, inputs, decisions, outcomes

The system has four parts that connect in a loop.

The loop is: inputs lead to a decision, the decision is recorded with an expectation, the outcome is measured at the check date, and the comparison becomes an input to a later review. Many companies run the first two steps well and stop. The third and fourth are where the system earns its time.

Review layers

Keep the number of layers small. Each layer has one question it answers.

Your company may need a different shape. A plant-heavy business may add a daily huddle below the weekly layer. A portfolio owner may add a portfolio review above the company layer. The principle holds: each layer has one purpose, and a decision is made at the layer whose horizon it fits. A question about next week's shipments does not belong in the quarterly review, and a question about whether to exit a product line does not belong in the weekly meeting.

The rule that makes it a system

Every decision made in any layer is written to the same decision log with these fields:

• Decision: one sentence, written so a stranger could understand it.
• Owner: one named person, not a team.
• Expected result: what should change, stated in the unit of the measure.
• Measure and source: which number will show it, and which system the number comes from.
• Check date: when the owner reports back, and which review it will appear in.
• Review layer: where it was made and where it will be checked.

If a discussion ends without a decision that fits this shape, it was an update, not a decision. That is fine. Updates do not go in the log. Keeping the log to genuine decisions is what keeps it readable.

Step-by-step process

The steps below set up the system. The next section gives the 90-day sequence. Each step lists an owner and an output.

1. Define the layers. Write one paragraph per layer: purpose, frequency, attendees, chair, inputs, and the kinds of decisions made there. Owner: CEO with CFO. Output: a one-page review architecture.
2. Fix the review pack. Decide what goes in the monthly pack and hold the format constant for at least three cycles. Include the plan, actual, variance and a cause field for each measure. Owner: CFO or head of FP&A. Output: a pack template and a circulation deadline.
3. Create the decision log. One shared file with the fields above. A spreadsheet is enough. Owner: chief of staff, CFO or the person who runs the meeting. Output: the log, with a single named keeper.
4. Create the action log. Actions are smaller than decisions: tasks with an owner and a due date that carry out a decision or answer a question. Link each action to the decision it supports where there is one. Owner: meeting keeper. Output: the action log.
5. Set the agenda and clock. Allocate time per section. The look-back at due decisions and open actions comes before new business. Owner: meeting chair. Output: a standing agenda.
6. Run the first review with the new structure. Capture decisions live, in the room, on screen. Read each one back before moving on: owner, expected result, check date. Owner: chair. Output: the first populated log entries.
7. Send the record within 24 hours. One page: decisions, actions, owners, dates. Owner: keeper. Output: a circulated summary that doubles as the next meeting's starting point.
8. Check decisions at their check dates. The owner reports the outcome using the measure named in the log. Record the result next to the expectation. Owner: decision owner. Output: a closed log entry with expected versus actual.
9. Hold a quarterly look-back. Review all decisions closed in the quarter. Which delivered, which did not, and what pattern appears in the misses. Owner: CEO. Output: adjustments to how expectations are set, and to the review system itself.
10. Change the system, not only the decisions. If the same kind of decision keeps missing, change how it is analysed, who owns it or how the expected result is estimated. Owner: CEO with CFO. Output: a documented change to the process.

Meeting design

The monthly operating review

The monthly review is the center of the system. It happens after the monthly close, so the numbers are final enough to discuss. A workable shape for 90 to 120 minutes:

Rules that keep it working:

• Pre-read is mandatory. The pack goes out at least a day before. Meeting time is for questions and decisions, not for presenting slides the room can read.
• Exceptions only. Do not walk every line of the scorecard. Discuss the measures that missed plan or moved unexpectedly.
• Cause before remedy. For any measure off plan, name the cause with evidence before proposing an action. A decision to fix the wrong cause is expensive and hard to see afterwards.
• Two deep dives, not six. More topics means shallow decisions. Choose the two where a decision is needed this month.
• The chair does not present. The person running the meeting guards time, forces decisions and reads back the record.

The weekly operating meeting

The weekly meeting is short, 30 to 45 minutes, and about execution. It uses a stable set of leading measures (orders, shipments, cash receipts, open positions, service levels, whatever matters in your business), the open action list and any decisions that cannot wait for the month. It writes to the same action log. Decisions of consequence go to the decision log with an expectation, even in the weekly meeting.

The quarterly business review

The quarterly review asks a different question: not "did we hit the number" but "are we working on the right things." Inputs include the quarter's closed decisions with expected versus actual results, the progress of strategic initiatives, the outlook for the next four quarters, and the risks that have moved. Decisions here include stopping initiatives, reallocating resources and changing the plan. For companies with a sponsor or board, this is often the review where they join.

Inputs: the review pack

A pack has a fixed order. Change the contents when the business changes, but not the order.

1. One-page summary: three to five sentences on what happened and what needs decisions.
2. Scorecard: the chosen measures with plan, actual, prior period and a status. For how to choose them see KPI design: choosing 12 metrics.
3. Variance causes: for each exceptional measure, the cause with evidence.
4. Decision log extract: decisions due for check this month, with the owner's draft result.
5. Action log extract: open and overdue actions.
6. Forecast: updated outlook with changes since last month and why.
7. Deep-dive papers: no more than two, each one page of facts plus options and a recommendation.

Templates

These are designed to be copied into a spreadsheet.

Decision log

Notes on fields:

• Alternatives considered can be one line. It records that a choice was made, which helps later when someone asks why the other option was not taken.
• Expected result must be measurable. "Improve customer service" is not a result. "Reduce late deliveries from 12 per week to under 6 per week by the end of next quarter, from the shipping system" is a result.
• Check date is set when the decision is made, not later.
• Lesson is filled when the entry closes. One sentence. Whether the estimate was too optimistic, the cause was misread, execution slipped, or something outside the company changed.

Action log

Variance cause card (one per exceptional measure)

Meeting record (one page, sent within 24 hours)

1. Decisions made (ID, one line, owner, expected result, check date).
2. Actions assigned (owner, due date).
3. Decisions closed this month (expected versus actual, in one line each).
4. Items carried over and why.
5. Next meeting date and its two deep dives.

Look-back agenda for the quarterly review

1. List every decision closed in the quarter, with expected and actual.
2. Group by type (pricing, hiring, capital, cost, process) and by owner.
3. Identify the largest misses, and for each one: was it estimation, cause, execution or external change?
4. Identify patterns: owners, functions or types of decision that miss in the same direction.
5. Agree one change to how expectations are set or decisions are made, and log it.

Metrics and KPIs

These measure the health of the review system itself. They are not business KPIs. Targets are set by method, not by a published number.

Keep realization ratio separate for different units. A cash release in dollars and an EBITDA improvement in dollars are not the same thing, and mixing them hides which type of estimate you misjudge. Do not mix one-time and recurring effects either.

Common mistakes

1. Recording actions but not decisions. Actions say what people will do. Decisions say what the company chose and why, and what it expects. Without the decision record you cannot test whether the choice was right.
2. No expected result. If you did not write down what you expected, you will remember the outcome as what you expected. Hindsight is not a measurement.
3. Expected results that cannot be measured. "Better alignment" cannot be checked. Pick a number that exists in a system today.
4. A log nobody opens. If the first agenda item is not the look-back, the log becomes an archive. Make the look-back the first block.
5. Too many decisions in the log. Updates, status reports and opinions bury the entries that matter. Keep only choices that cost something or commit resources.
6. Reviewing everything on the scorecard. Walking every line wastes the room. Pre-read, and discuss exceptions.
7. Presentation instead of decision. If most of the meeting is one person presenting, the meeting is a briefing. Move it to the pre-read.
8. Blame in the look-back. If people are penalized for decisions that missed, they stop writing realistic expectations. The look-back is for learning how to estimate better. Accountability for execution is separate and happens through the action log.
9. Different formats for each function. When every function brings its own slides and definitions, the review becomes a translation exercise. Use one pack and one set of definitions.
10. Treating the review as the owner's meeting. The system is the management team's tool. If it only exists to satisfy a sponsor or lender, it will be done minimally. Share the same records with the board, but design them for the people who use them every week.
11. Never changing the system. If the same type of decision keeps missing, change how it is made. Otherwise the log only documents repeated failure.

Worked example

Illustrative. The numbers below are made up to show the method. They are not benchmarks.

A $60M manufacturer runs a monthly operating review. At the quarterly look-back, the CEO opens the decision log for the five decisions that came due in the quarter. Two were cash decisions, and three were EBITDA decisions. Amounts are annualized run-rate effects for EBITDA decisions, and one-time releases for cash decisions, in thousands of dollars.

EBITDA decisions (annualized):

Realization ratio for EBITDA decisions: 210 ÷ 390 = 53.8%.

Cash decisions (one-time):

Realization ratio for cash decisions: 720 ÷ 850 = 84.7%.

What the look-back found, using the lesson field:

• D4 missed because the cause was misread. The product line was bundled with a higher-margin line, and some customers stopped buying both. The estimate treated the line as standalone. The change to the process: any decision to cut a product line requires a bundle and attach-rate check before it reaches the review.
• D3 missed on timing. The collector started six weeks later than planned and the first month was training. Estimate was not wrong, execution slipped. The log shows this by comparing the original check date with the actual date.
• D2 beat expectation because the SKU list was longer than the first estimate assumed. This is also a miss in estimation, in the other direction, and worth recording.
• D5 delivered exactly. The owner had a signed contract amount to anchor on, which is the type of estimate worth copying.

The CEO notes that decisions anchored on contract amounts or ledger data landed near expectation, and decisions that depended on customer behavior did not. For the next quarter, the log adds a field: "evidence behind the estimate (contract, ledger, assumption)." In future reviews, decisions resting on assumptions about customer behavior carry a smaller expected result, based on the trailing ratio for that type.

None of this required new software. It required the log, the check dates and a look-back that happened.

AI prompt assistance

AI can help draft packs, clean logs and spot patterns. It cannot know what you decided. Provide the data yourself and check the output before circulating.

1. Convert meeting notes into a decision log.

Here are the raw notes from our monthly operating review. Extract each genuine decision (a choice between options that commits resources or changes course) and list it with: one-sentence decision, owner, expected result as stated or "not stated", measure, and check date as stated or "not stated". Separate updates and opinions into a different list. Do not invent owners, results or dates.

Check: read the "not stated" entries aloud in the meeting and fill them before closing. Confirm that no decision was dropped by comparing against your own recollection.

2. Draft variance cause cards.

Here is the scorecard with plan, actual and prior period for the measures that missed. For each, propose up to three possible causes that could be tested with data we hold in our ERP, and name the report or extract that would confirm or reject each one. Do not state any cause as fact.

Check: treat the output as hypotheses. The owner confirms the cause with evidence before the card is filled.

3. Review closed decisions for patterns.

Here are the decisions closed this quarter with expected result, actual result, owner and lesson. Group them by type. For each group, compute total expected, total actual and the ratio. Point out any owner or type where the actual is consistently below or above expected. Show all arithmetic.

Check: recompute two ratios by hand. Do not use the output to assign blame. Use it to decide where estimates need more evidence.

4. Draft the one-page meeting record.

From this decision log extract and action log extract, write a one-page record for circulation: decisions made, actions assigned with owners and due dates, decisions closed with expected versus actual, items carried over. Keep each item to one line.

Check: confirm each owner and date against the room before sending.

Implementation guide

30/60/90 days

Roles

• CEO owns the system and chairs the quarterly look-back.
• CFO or head of FP&A owns the pack, the scorecard and the integrity of the numbers.
• Meeting keeper maintains the logs and sends the record. This role is often under-resourced; it is the cheapest way to make the system work.
• Decision owners own results, report back on check dates and fill the lesson field.
• Board or sponsor representative receives the same records, and reads the look-back for patterns rather than line items.

What to expect

The first two cycles feel slower, because capturing expectations takes thought. By the third cycle the format is familiar and meeting time drops, because the pre-read removes presentation. The first useful finding usually appears at the first quarterly look-back, when the team sees where its estimates run high or low. Expect resistance to writing numeric expectations; start with a few decisions per meeting and build the habit. Do not announce targets for the review-health metrics in the first quarter. Establish baselines first.

Where an agreement, lender document or board governance requirement defines what must be reviewed or approved, follow those documents and involve your counsel or advisers. This guide is operating method, not legal or governance advice.

Downloadable assets

The decision log, action log, variance cause card, meeting record and look-back agenda above are designed to be copied into a spreadsheet as they are. No calculator exists for this topic in the current tool set.

Related resources

• Portfolio operations hub: the parent collection for operating system topics.
• Operating cadence: weekly, monthly, quarterly rhythms: the meeting calendar this system runs on.
• KPI design: choosing 12 metrics that run the company: what goes on the scorecard.
• Decision rights matrix template: who may decide what, which determines who owns each log entry.
• Management reporting playbook: building the pack and the numbers behind it.
• VCP governance charter template: a governance structure for value creation work.

Frequently asked questions

What is an operating review system?

An operating review system is the set of recurring meetings, review packs, owners and records a company uses to examine results, make decisions and check later whether those decisions worked. The defining feature is the record. A set of meetings without a decision log and a follow-up step is a reporting routine, not a system.

What should be on a monthly operating review agenda?

Start with the look-back at decisions due and open actions, then a scorecard read by exception, two deep dives where a decision is needed, a forward look at forecast and risks, and a closing read-back of every decision and action. Circulate the pack before the meeting so time is spent deciding, not presenting.

What goes in a decision log?

Each entry needs the decision in one sentence, one named owner, the alternatives considered, the expected result, the measure and where it comes from, a check date, and later the actual result and a lesson. If the expected result and check date are missing, the entry cannot be tested, so it should not be accepted as complete.

How is an operating review different from a board meeting?

An operating review is run by management to make operating decisions and track their results, usually monthly. A board meeting is about governance, oversight and major approvals, usually quarterly. Boards can and should see the operating review's decision records, but the two meetings answer different questions and run on different time horizons.

How long does it take to set up an operating review system?

The structure can be designed in a month: layers, pack, logs and a named keeper. Real value appears at the first quarterly look-back, around 90 days, when decisions begin reaching their check dates and expected results can be compared with actual ones. Expect the first two review cycles to feel slower while the habit forms.

How this works in a System of Performance

The review only helps if what was decided and what happened next stay linked. In most companies the decision lives in a slide, the action in an email, and the outcome in a report nobody connects back. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see where your own review loop breaks, bring it to us as a launch partner.