AI Prompts for Operational KPI Reviews

A KPI review is only useful if it changes what someone does next week. The common failures are reviewing too many metrics, explaining every variance in hindsight, and never connecting the leading indicators to the lagging results the business cares about. A KPI tree fixes the structure; a variance triage rule fixes the attention; a disciplined narrative fixes the meeting.

These prompts produce the review narrative from your numbers, build or repair the KPI tree so metrics connect to outcomes, and set the triage rule for which variances deserve investigation. They rely on your data and definitions — the model should not invent causes for a variance it cannot see the driver for.

Before you use these

Have these ready to replace the highlighted [variables]:

• KPI actuals versus target and prior period, with the driver metrics behind each
• Metric definitions and data sources
• Known events in the period
• The decisions the review is meant to inform

The prompts

• 1. Write the weekly KPI review narrative
• 2. Build the KPI tree and metric definitions
• 3. Triage variances for investigation

1. Write the weekly KPI review narrative

Act as an operations manager writing the weekly KPI review for [site / function] for week [n].

KPI table: [metric, target, actual, prior week, 4-week trend]
Driver metrics: [the operational measures behind each KPI, e.g. OTIF ← schedule adherence, supplier OTIF, order accuracy]
Events this week: [known incidents, changes, absences, volume swings]
Decisions the review informs: [e.g. overtime approval, escalation to leadership]

Write:
1. Headline: overall performance in two sentences — what met target, what did not, and the single most important thing.
2. Significant variances only (define significance as beyond [threshold] or a sustained trend): for each, the size, the driver metric or event it is attributed to, and the evidence. If no driver explains it, state 'cause unknown' and the investigation action.
3. Positive variances that need understanding too (so they can be repeated or so they are not masking a problem).
4. Actions: owner, due date, and the KPI it should move. No more than five.
5. Leading indicators for next week: which driver metrics suggest the KPIs will improve or worsen.
6. Decisions requested.

Keep to one page. Do not explain every metric. Do not invent causes.

2. Build the KPI tree and metric definitions

You are building a KPI tree for [site / function].

Outcomes we are accountable for: [e.g. on-time delivery, cost per unit, quality, safety, inventory]
Current metrics: [name, definition as understood, frequency, owner, data source]
Known problems: [metrics that conflict, metrics nobody acts on, outcomes with no driver visibility]

1. Build the tree: each outcome KPI decomposed into 2–4 driver metrics, and each driver into the operational measures that move it, down to the level a team can act on daily. Show the logical relationship (arithmetic where it exists, causal otherwise).
2. For every metric: precise definition, formula, data source, frequency, owner, target basis, and the behavior it might encourage if optimized in isolation.
3. Map current metrics to the tree. Identify duplicates (same thing measured twice), orphans (metrics with no outcome), and gaps (outcomes with no leading driver).
4. Recommend the review structure: which metrics at which meeting tier and frequency.
5. Flag metrics that conflict (e.g. utilization vs lead time) and the rule for resolving the conflict.

Present the tree as an indented list plus a definitions table. Keep the outcome level to no more than six KPIs.

3. Triage variances for investigation

Act as a performance analyst designing a variance triage rule for [site / function].

Variance history: [metric, target, actual by week for the last [n] weeks]
Investigation capacity: [how many root-cause investigations per week the team can do properly]
Business impact per metric: [cost or consequence of a sustained miss]

1. For each metric, characterize normal variation (range or standard deviation over the history) and separate noise from signal. Propose a threshold rule: single-period magnitude, consecutive periods in one direction, or trend — whichever fits the metric's behavior.
2. Weight by impact: a small sustained variance on a high-impact metric outranks a large one-off on a low-impact metric.
3. Classify this week's variances: investigate now / monitor / ignore, with the rule that placed each.
4. Build the investigation queue within capacity, in priority order, with the question each investigation must answer and the method (5 Whys, data cut, floor observation).
5. Repeat-variance rule: metrics that keep appearing get a structural review rather than another investigation.
6. What to show on the review board so the triage is visible and challengeable.

Do not set thresholds so tight that everything is investigated or so loose that nothing is. State the trade-off made.

What a KPI tree looks like

One branch of a distribution site's tree, at the depth the second prompt produces. Each level is something the level below can move.

Related prompts

• Root Cause Analysis
• Process Improvement
• Forecast Accuracy Review
• Supplier Scorecards and SLAs
• Bottleneck Analysis
• Operations Strategy Review
• KPI tree builder — Consulting

Logical next step

After this, most operations teams move on to Root Cause Analysis.

All Operations & Supply Chain prompts · Search the full library