Operational Decision Systems: Recording Decisions and Outcomes

Executive summary

An operational decision system, as this guide uses the phrase, is a plain method: write down each operating decision when it is made, state what you expect it to do, name who owns it, set a date to check it, and later record what actually happened. It is a habit and a record, not a product or a piece of software.

Companies make dozens of operating decisions a month: raise a price, hold inventory, hire a collector, drop a customer, change a supplier. The decision is usually discussed well. What happens next is usually lost. A year later, nobody can say which decisions delivered what they promised, so the same optimistic estimates are made again, by the same people, in the same way.

Recording decisions and outcomes fixes three things:

1. Accountability becomes specific. One owner, one expected result, one date.
2. Estimates improve. Comparing expected and actual results shows where your estimates run high or low, by type of decision and by owner.
3. Context survives. When someone asks why a choice was made, the answer is on file, including the alternatives that were rejected.

This guide covers what to log, how to run the review-to-outcome loop, how to read the results without turning the log into a blame list, and a worked example. It is the method behind the closing step of any review meeting. For the meetings themselves, see the operating review system playbook.

When to use this

Use this method when:

• Meetings end with agreement but nobody can say, a quarter later, what was decided.
• Initiatives are approved on projected savings or gains and nobody checks the realized amount.
• Managers disagree about whether a past decision worked, because there was no stated expectation.
• A new owner, CFO or board member asks how decisions have been made historically.
• You are running an improvement plan with many initiatives and want to learn which kinds deliver.
• Estimates keep coming in high, and you suspect a pattern.

The method is not a replacement for authority. It records decisions, it does not say who may make them. For that, see the decision rights matrix template.

Diagnostic questions

1. Can you name the five most consequential operating decisions made in the last quarter?
2. For each one, is there a written statement of what it was expected to achieve?
3. Is there a named individual accountable for the result, not only for the task?
4. Was a date set for checking the result, and did the check happen?
5. Do you know which of those decisions delivered what was expected?
6. Where do decisions live today: slides, email, chat, minutes, personal notes?
7. When someone leaves, does their decision history leave with them?
8. Do managers write expected outcomes honestly, or do they inflate them to get approval?
9. Does the board or sponsor see decisions and results together, or only results?
10. What happens when a decision misses: a learning discussion, or a search for who to blame?

If questions 2, 4 and 5 are answered no, you have discussion without learning, and a basic log will help immediately. If question 8 or 11 shows a trust problem, address the culture first, since a log filled with inflated expectations or cautious silence is no better than no log.

What counts as a decision worth logging

Not everything belongs in the log. A log with every action in it is unreadable. Use a simple test: log it if it meets at least one of these.

• It commits money, headcount or management time above a threshold you set.
• It changes a policy, a price, a term or a process that other people have to follow.
• It chooses between real alternatives, where one was rejected.
• It is expected to change a measure that appears in the monthly review.
• Someone could reasonably ask later "why did we do that?"

Status updates, task assignments and opinions are not decisions. They go in the action log or the minutes, not the decision log. A healthy log for a mid-market company holds a handful of entries per month, not dozens.

The framework: the review-to-outcome loop

The method is a loop with five steps.

The loop turns decisions into evidence. A decision log is a record of choices. A decision log with outcomes is a record of how well your company estimates.

The five questions every entry answers

1. What did we decide? One sentence that a stranger could understand.
2. Who owns the result? One person.
3. What do we expect to happen, by how much, by when? In the unit of an existing measure.
4. How will we know? The measure and the system or report it comes from.
5. When do we check? A calendar date and the meeting where it will appear.

If an entry cannot answer these, it is too vague to be tested. Return it to the owner before the meeting closes.

Keep decisions, actions and outcomes separate. Finishing the actions is not the same as achieving the outcome: an action can be done on time and the outcome still miss.

Step-by-step process

1. Set the threshold. Decide what size and type of decision gets logged. Owner: CEO with CFO. Output: a one-paragraph logging rule.
2. Create the log. One shared spreadsheet or table, with the fields in the template below. Name one keeper. Owner: CFO or chief of staff. Output: the log.
3. Capture in the room. The keeper types the decision live while the meeting runs, and reads it back: owner, expected result, check date. Owner: meeting keeper. Output: complete entries before the meeting closes.
4. State the evidence behind the estimate. For each expected result, note whether it rests on a contract, ledger data, a prior result, or an assumption. Owner: decision owner. Output: an evidence field.
5. Set the check date by the decision, not the calendar. A pricing change might be checked at 90 days, a supplier change after the first full order cycle. Owner: decision owner. Output: a check date that fits how fast the result can appear.
6. Place check dates in the review calendar. Each check date maps to a review where it will be the first agenda item. Owner: keeper. Output: a due list for each meeting.
7. Report back with the measured result. Owner reports in one or two lines: expected, actual, variance, cause of the gap. Owner: decision owner. Output: the closed entry.
8. Classify the gap. Was it estimation (we expected the wrong amount), cause (we misread the problem), execution (we delayed or did it poorly), or external (something outside the company changed)? Owner: CFO with the decision owner. Output: a gap type in the log.
9. Review patterns each quarter. Group closed entries by decision type, owner and gap type. Owner: CEO. Output: a short note on where estimates run high or low and one change to make.
10. Adjust how estimates are made. Apply the pattern: more evidence for assumption-based estimates, a standard haircut where history supports one, a required check for a known blind spot. Owner: CFO. Output: an updated estimating practice.

Templates

These are designed to be copied into a spreadsheet.

Decision log

Expected-outcome statement (one sentence form)

"By [check date], [measure] will change from [baseline] to [expected level], measured from [source], because [reason]."

Example form: "By the end of the next quarter, on-time shipments will move from the current rate to the target rate, measured from the shipping system, because the carrier change removes the two slowest lanes." Fill the brackets with your own figures.

Check-in note (what the owner brings at the check date)

1. Decision and original expected result.
2. Measured result and how it was measured.
3. Gap, and the classified type (estimation, cause, execution, external).
4. What would you do differently, in one sentence?
5. Should the decision be kept, adjusted or reversed?

Quarterly pattern review

Reading the results

Realization ratio

Realization ratio = Sum of actual results ÷ Sum of expected results

Compute it only across decisions measured in the same unit. A ratio below 1.0 means estimates ran high. A ratio above 1.0 means they ran low. Both are useful. Neither is a verdict on any individual decision, since a single decision can miss for reasons that tell you nothing about the owner.

Use history to adjust, not to punish

If an owner's or a function's ratio sits consistently below 1.0 across several decisions, the practical response is to ask for more evidence behind their estimates, or to apply their trailing ratio when sizing future ones. If you reverse that and punish the miss, people write smaller, safer or vaguer expectations, and the log loses its value.

Separate two kinds of accountability:

• Accountability for results, which is what the log records. Misses lead to better estimates and adjusted plans.
• Accountability for execution, which is what the action log records. Late or poor execution is a management matter in its own right.

Gap types

Metrics and KPIs

Do not set an absolute realization target such as "95%." A ratio near 1.0 across many entries means estimates are calibrated, but if you push people to hit a target ratio, they will pad or shrink expectations. Use the ratio as a diagnostic.

Common mistakes

1. Logging tasks as decisions. The log fills with items nobody needs to check. Keep it to choices that commit resources or change course.
2. Writing the expectation after the fact. If the expected result is written when the result is known, the log is fiction. Capture it in the room.
3. No check date. Without a date, the follow-up depends on someone remembering. Set it when the decision is made.
4. Vague results. "Improve margin" cannot be tested. Use a measure in a system you already have.
5. Treating the log as an archive. The log must be opened at the start of each review. If it is not on the agenda, it will go stale.
6. Using the log to assign blame. The fastest way to destroy honest expectations. Use gap types and patterns to adjust estimates.
7. Mixing units. Dollars of one-time cash release and annualized EBITDA are different results. Total and compare them separately.
8. Ignoring the cause. A decision that misses because the problem was misdiagnosed will be repeated unless the cause is recorded.
9. Too many owners. If three people own a result, nobody does. Name one, and list contributors in the action log.
10. Checking too early. A result that takes two quarters to appear cannot be judged after one month. Set the check date to fit the decision.
11. Keeping the log private. A log one analyst holds does not change how the team decides. Share it with the management team and the board or sponsor.

Worked example

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

A distributor logs its operating decisions over two quarters. At the quarterly pattern review, eight decisions have closed, all measured as annualized EBITDA effect in thousands of dollars. The CFO groups them by owning function.

Verification: 100 + 60 + 40 = 200, and 80 + 70 + 10 = 160. For Sales, 150 + 80 + 120 = 350 and 90 + 40 + 60 = 190. For Finance, 50 + 70 = 120 and 55 + 65 = 120. Totals: 200 + 350 + 120 = 670, and 160 + 190 + 120 = 470, so 470 ÷ 670 = 70.1%.

What the pattern says:

• Sales estimates ran well below expectation across all three decisions. Each of the three Sales entries has an evidence field marked "assumption about customer response." The Finance entries rest on contract or ledger data. The CFO does not conclude that Sales performs poorly. She concludes that estimates built on assumed customer response need more evidence.
• Operations missed on one decision, with a gap type of "execution." The third operations decision, expected 40 and actual 10, slipped because a system change was delayed by two months. The check date was too early to see the full effect, so the gap is recorded as "partial or too early" and rechecked.
• The Finance estimates were calibrated. The entries were based on signed contract amounts.

The changes the CEO approves:

1. Any decision whose estimate rests on customer behavior must include a prior result, a test or a pilot before it is logged at full value.
2. For planning, Sales-owned estimates without such evidence are sized using the trailing Sales ratio (54.3%) as a cross-check next to the owner's figure, so the review sees both numbers. If the owner's figure is expected at 150, the cross-check shows about 81.
3. The operations decision is rechecked in the next quarter.

Nobody was penalized. The sales leader gained a clearer path to getting an initiative approved: bring evidence. The log produced the pattern, and the pattern changed how the next decisions were made.

AI prompt assistance

AI can structure notes and surface patterns in the log. It should not invent owners, expected results or outcomes. Provide your own data and check the output.

1. Turn meeting notes into log entries.

From these meeting notes, list each decision as: one-sentence decision, owner, alternatives mentioned, expected result, measure, and check date. If any field is not in the notes, write "not stated". Separate decisions from updates and tasks. Do not infer missing fields.

Check: take the "not stated" fields back to the room and fill them in before the entry counts as complete.

2. Tighten expected-outcome statements.

Here are five expected results from our decision log. For each one, tell me whether it is measurable, which existing measure it maps to, and rewrite it in this form: "By [date], [measure] will change from [baseline] to [level], measured from [source], because [reason]." Leave the figures as placeholders where I have not supplied them.

Check: the owner supplies the figures. Reject any rewrite that adds numbers you did not provide.

3. Summarize closed decisions by type.

Here is a table of closed decisions with type, owner, unit, expected, actual and gap type. For each type and unit, compute the total expected, total actual and ratio. Show the arithmetic. Then list gap types by frequency. Do not rank owners.

Check: recompute one ratio by hand and confirm that units are not mixed.

Implementation guide

Start small. Log the three or four most consequential decisions each month, not everything. Expand the threshold once the habit holds. The first quarter produces few closed entries and little pattern, which is normal. The value compounds as entries accumulate.

Where a lender document, shareholder agreement or governance policy defines which decisions require approval or disclosure, follow those documents and involve counsel or advisers. This guide is a management method, not legal or governance advice.

Downloadable assets

The decision log, expected-outcome statement, rejected-options record, check-in note and pattern review table 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 review system: the meetings in which decisions are made and checked.
• Decision rights matrix template: who may decide, which sets who owns each entry.
• KPI design: choosing 12 metrics: the measures that expected results map to.
• EBITDA bridge continuous tracking: comparing planned and realized EBITDA effects over time.
• Management reporting playbook: putting decision results in front of leadership and the board.
• AI governance for finance and operations and an AI risk register and review cadence: the same record and review habits, applied to AI.

Frequently asked questions

What is a decision log?

A decision log is a shared record of the operating decisions a management team makes, with each entry stating the decision, one owner, the alternatives considered, the expected result, the measure, a check date, and later the actual result. Its purpose is to compare what was expected with what happened, so that future estimates improve.

What should be logged as a decision?

Log choices that commit money, headcount or management time above a threshold you set, change a policy, price or process, choose between real alternatives, or are expected to move a measure in the monthly review. Status updates, tasks and opinions do not belong in the decision log. They go in the action log or minutes.

How do you track decision outcomes?

Set a check date when the decision is made, tied to how quickly the result can show up. At that date the owner reports the measured result against the expected result, and the gap is classified as estimation, cause, execution or external. The comparison is then reviewed by type and owner each quarter to improve future estimates.

Does a decision log create blame?

It can, if it is used that way, and then people stop writing honest expectations. Use the log to find patterns in how estimates are made, not to punish individual misses. Keep accountability for results (recorded in the decision log) separate from accountability for execution (recorded in the action log).

How is a decision log different from meeting minutes?

Minutes record what was discussed. A decision log records only the choices made and, critically, what each was expected to achieve and what it actually achieved. Minutes are read once. A decision log is reopened at each check date, which is what lets the company learn from its own history.

How this works in a System of Performance

A decision log only helps if the expectation and the later result stay connected to the decision. In most companies, the decision sits in a slide, the owner in an email, and the result in a report that nobody ties 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 how your own decisions are being recorded today, bring it to us as a launch partner.