Exception-based planning means planners review only the plan lines that break a rule, instead of checking every SKU, location and order. The system plans everything, flags the lines that cross a threshold, and sends them to a queue with the reason, the impact and a proposed fix. Planner time goes to the few decisions where judgment changes the outcome.
From Every Line to a Queue
A replenishment planner at a retailer with 300 stores and 8,000 active SKUs is responsible for well over two million SKU-store combinations. Nobody reviews that many lines. Without exception rules, planners sample: they scan the categories they know, react to the stock-outs someone reports and adjust whatever looks odd. Problems in the lines nobody opened go unnoticed until they show up on the shelf.
Exception-based planning reverses the order of work. The system produces a complete plan first. Rules then decide which lines a person should see, and everything else goes to execution as recommended. The idea is older than planning software. Management by exception, a general management practice, asks managers to act only on significant deviations from plan and to leave the rest to routine (Wikipedia). In planning, the deviations are measured line by line, every planning cycle.
This only works if the plan underneath is sound. If the system ignores pack sizes or truck capacity, every line is an exception, and the queue becomes a second way of reviewing everything.
How to Set Exception Thresholds and Alerts
A threshold says how far a line can move from its expected value before a person should look. Good thresholds share a few properties.
- Value-weighted. A 30% forecast deviation on an item that sells two units a week is noise. A 5% deviation on a top-selling item can cost more than the whole slow-moving range. Express thresholds in units or money at risk, not only percentages.
- Set per segment. Stable items can carry tight tolerances because a deviation is unusual. Erratic items need wider bands, or they flag every week. Our post on ABC XYZ inventory segmentation covers how those segments are built.
- Inside the action window. An exception matters only while something can still be done. A projected stock-out in week ten may be fixed by next week’s plan, while one in week two needs an expedite today. Flag by the lead time of the possible responses.
- Persistent. One odd day of sales should not raise an alert. Require the deviation to hold for a set number of periods, or to exceed a larger limit once.
- Predictive where possible. An alert on a projected stock-out leaves time to act. An alert on yesterday’s stock-out can only explain a loss.
Start with a few well-scoped rules and add more as the team learns what each alert is worth.
What Makes an Exception Actionable
An exception is actionable when a planner can decide what to do from the exception itself, without opening three other screens. That requires seven pieces of information:
- What: the measure that broke and by how much, for example projected cover at a DC falling to two days against a five-day target.
- Where: the SKU, location and channel, with the related lines grouped together.
- When: the date the problem hits and the last date a response still works.
- Why: the root cause, such as a delayed purchase order, a promotion not in the forecast or a supplier shipping short.
- Impact: units and value at risk, in lost sales, excess stock, waste or penalty cost.
- Options: one or more proposed actions, such as a transfer from another DC, an expedite or a reallocation, each with its cost.
- Owner: who decides, and by when.
Compare two alerts. “Forecast error above 25% on SKU 40118” leaves the planner to do the analysis. “Projected stock-out at the North DC on 14 November for SKU 40118: inbound PO delayed six days, 3,200 units of demand at risk, transfer 1,800 units from the South DC at a cost of one extra truck” can be approved or rejected in a minute.
Group related lines as well. If one delayed purchase order affects 140 store lines, the planner should see one exception with 140 lines attached, not 140 alerts.
Measuring Exception-Based Planning Workload
The queue is a workload, and it can be measured like one. These measures show whether the rules are set well:
| Measure | What it tells you | Warning sign |
|---|---|---|
| Exception rate | Share of plan lines flagged per cycle | Rising while service and stock are stable |
| Exceptions per planner per day | Whether the queue fits the team | Queue not cleared before the next run |
| Action rate | Share of exceptions that lead to a change | One rule type is approved unchanged nearly every time |
| Time to resolve | Hours from flag to decision | Exceptions resolved after the response window closed |
| Backlog age | How long open exceptions wait | Old exceptions auto-closing unread |
| Repeat rate | Same exception on the same line, cycle after cycle | A missing constraint or parameter in the model |
| Missed problems | Stock-outs or excess that no rule flagged | A gap in the rule set |
Read the measures together. A low action rate on one rule means its threshold is too tight, and planners are only confirming what the system proposed. A high repeat rate means a cause should be fixed in the model rather than handled again every week, which is the feedback described in our post on closed-loop supply chain planning. Missed problems matter most, because a quiet queue can also mean the rules are blind.
Check edits outside the queue too. If planners edit lines that were never flagged, the rules are missing something. User acceptance rate, the share of executed decisions that go live with no planner edits, shows how much of the plan already runs without review. Solvoyo explains how it is calculated on its user acceptance rate page.
Common Pitfalls
- Alert floods after go-live. Default thresholds from a template need tuning to your business. Plan a tuning period with the planners who work the queue.
- Exceptions with no reason. Planners who cannot see why a line was flagged rebuild it in a spreadsheet. Our post on explainable AI in supply chain planning covers how reasons on the screen change that.
- One queue for every role. Buyers, replenishment planners and transport planners need different exceptions. Route by owner.
- Rules nobody reviews. Demand patterns, suppliers and assortments change. Review thresholds on a fixed cadence, starting with the rules that have the lowest action rate.
How Solvoyo Handles Exceptions
Solvoyo’s supply chain analytics and visibility layer shows inventory, demand, supply and service in one control tower. Predictive alerts flag demand shifts, supply risks and service threats before they happen. Solvi, the AI planning agent in Solvoyo’s supply chain decision automation platform, quantifies the business impact of inaction for each exception and lists prioritized actions that planners review and execute inside the platform. Where the client has cleared it, Solvi handles routine exceptions automatically.
Tolerances are measured against a plan that already respects capacity, pack sizes and lead times, so a flag points to a real change in demand or supply. Lines without a flag run as issued: over 95% of Solvoyo’s plans execute untouched. To see the exception queue on your own data, request a demo.
Frequently Asked Questions
Exception-based planning is a way of working in which the planning system produces the full plan, flags only the lines that break a set rule, and sends them to planners with the cause, the impact and a proposed action. Lines inside their tolerances go to execution as recommended, so planners spend their time on the decisions that need judgment.
Weight thresholds by units or value at risk rather than percentages alone, set them per product segment, flag only problems that fall inside the window where a response still works, require a deviation to persist before alerting, and prefer projected problems to past ones. Then review each rule’s action rate and loosen rules that planners approve unchanged.
Track the exception rate, exceptions per planner per day, the share of exceptions that lead to a change, time to resolve, backlog age, repeat exceptions on the same line and problems that no rule flagged. Together they show whether the queue fits the team and whether the rules catch the problems that matter.
