Analysis creates insight, but decision rules create action. Many SKU rationalization efforts stall after the analysis is complete because the organization has not agreed on how decisions will actually be made. Teams can identify low-volume items, weak margins, hidden complexity, and likely substitutes, yet still fail to move because every case is reopened from first principles. Without a clear rule set, the process becomes slow, political, and inconsistent.
This chapter explains how to turn analysis into decision rules that the business can apply reliably. It shows how to define the criteria for retain, rationalize, replace, or exit; how to set thresholds and manage exceptions; how to apply the rules consistently; and how to document the framework so decisions remain clear and repeatable after the first wave of rationalization is complete.
12.1 Establishing Criteria for Retain, Rationalize, Replace, or Exit
Decision rule: a predefined logic for determining what action should be taken on a SKU once the relevant evidence has been assembled. Good rules do not eliminate judgment, but they improve the quality and speed of judgment by making the starting logic explicit.
Most companies need four action categories. Retain: keep the SKU in its current form because it creates sufficient value relative to its burden. Rationalize: simplify the SKU or the surrounding range without fully removing the customer need, for example by reducing duplication or tightening pack ladders. Replace: move demand from the current SKU into a clearly designated alternative through substitution, redesign, or migration. Exit: discontinue the SKU because it does not earn its right to remain in the portfolio and no compelling reason exists to preserve it.
The criteria behind these actions should draw from the full fact base, not just one metric. A retail decision usually rests on healthy demand, acceptable economics, manageable complexity, and a clear role in the portfolio or market. A rational decision is appropriate when the customer need is valid but the current expression of that need is unnecessarily fragmented. Replacement is appropriate when a customer requirement still exists but can be met through a better SKU, a simpler range, or a more efficient configuration. Exit is appropriate when the item contributes little incremental demand, carries weak economics, creates disproportionate burden, and has no strong strategic, contractual, or technical defense.
It helps to think of the criteria as cumulative rather than binary. A SKU rarely deserves to exist because of one weak attribute alone. The case becomes compelling when several signals point in the same direction. Low sales by itself is not enough. Low sales plus weak contribution, high complexity, easy substitution, and no special constraint is much stronger. The same is true on the positive side. A SKU may merit retention not because every metric is attractive, but because its role is commercially important, operationally manageable, and difficult to replace elsewhere.
The action categories should also shape behavior, not merely classify outcomes. If the only choices are kept or cut, the organization will protect too much. The middle actions of rationalization and replacement create room for more intelligent decisions. They allow teams to preserve customer value while still removing complexity. In many successful programs, the biggest gains come not from pure exits, but from consolidating overlapping variants into a smaller, healthier set of survivors.
A good rule states, in effect, that a SKU stays when it earns enough value and serves a valid role, changes when the need is real but the form is inefficient, and leaves when both the economics and the strategic case are weak.
12.2 Defining Thresholds and Exceptions
Once the action categories are clear, the business needs thresholds. Threshold: a quantitative or qualitative boundary that signals whether a SKU should be reviewed for a specific action. Thresholds create focus. They tell the organization which items should automatically enter the discussion and which ones can usually remain outside it. Without thresholds, every SKU becomes a debate. With overly rigid thresholds, important nuances are ignored.
Most companies use a mix of thresholds rather than one universal cutoff. Volume or revenue thresholds help identify the long tail. Margin thresholds expose weak economic performers. Inventory and complexity thresholds highlight items that burden the system disproportionately. Customer concentration thresholds identify items dependent on one account or one narrow segment. A practical rule might say that any SKU falling below minimum contribution, above a defined complexity burden, and lacking a clear strategic role must be reviewed for replacement or exit. Another may say that any item with moderate economics but strong duplication within a family should be reviewed for rationalization.
The business should resist the temptation to make thresholds look more precise than the data can support. A boundary such as “less than $50,000 of annual contribution” may be directionally useful, but it should not pretend to be universally meaningful across all categories and channels. Some portfolios require category-specific thresholds because the economics of a snack flavor, a medical pack size, and an industrial spare part are not comparable. The right design is usually a small number of standardized metrics with calibrated cutoffs by category or business model.
Thresholds are valuable because they shift the burden of proof. If a SKU sits clearly below the expected performance range, the default should become “why should this stay?” rather than “why should we remove it?” That shift is often the turning point in a rationalization program.
But thresholds alone are never enough. Every portfolio has exceptions, and the way exceptions are handled determines whether the rule set remains credible. Exception: a case in which a SKU does not fit the normal thresholds or criteria but may still deserve different treatment because of a legitimate reason.
Good exception logic starts by defining the allowable grounds. These usually include binding contractual commitments, real regulatory constraints, significant technical incompatibility, strong evidence of poor transferability, or a clearly articulated strategic role. Each exception should require a documented rationale, a named owner, and where possible a time limit or review date. A temporary exception is often better than a permanent one.
If exceptions are easy to grant and hard to revisit, the rationalization effort will quietly collapse. The solution is controlled flexibility: structured exceptions, visible to leadership, with evidence behind them and consequences understood.
12.3 Applying Decision Rules Consistently Across the Portfolio
A decision framework only creates value if it is used consistently. Many organizations develop a sensible set of rules, then abandon them in practice because different categories, regions, channels, or leaders apply them differently. That inconsistency weakens the quality of individual decisions and undermines trust in the process.
Consistency: applying the same underlying logic across the portfolio while allowing for legitimate structural differences between categories and business models. Consistency does not mean identical metrics everywhere. An aftermarket fitment portfolio and a fast-moving consumer range may require different thresholds. What must remain constant is the decision logic: value created, burden imposed, transferability, strategic role, and constraint profile should all be considered in a comparable way.
The best way to create consistency is to use a standard review sequence. First, test the SKU against the base criteria and thresholds. Second, determine the likely action category. Third, check for substitute paths and commercial risk. Fourth, test whether any valid exception applies. Fifth, record the decision and owner. When every item passes through the same sequence, the conversation becomes more disciplined and less vulnerable to personalities.
Cross-functional participation is also important. Commercial teams often see customer value more clearly. Operations sees burden more clearly. Finance sees economic performance more clearly. Product or category teams understand portfolio architecture. Consistency improves when these views are brought together under one rule set instead of being applied separately by function.
Calibration sessions help too. Early in the process, leadership should review a sample of clear cases, borderline cases, and expected exceptions to confirm that the rules are being interpreted similarly. These sessions surface hidden disagreements and prevent hundreds of later arguments.
Consistency also depends on resisting case-by-case erosion. The portfolio should not become a place where every manager can defend one special item. Once repeated local exceptions override the rule set, complexity returns through the back door. The rule set should guide the majority of decisions automatically, with only a small minority needing escalation.
12.4 Creating a Documented Decision Framework
The final step is to turn the logic into a document the organization can use. Documented decision framework: a written record of the decision categories, criteria, thresholds, exception rules, review sequence, and approval rights used in the rationalization process. This is more than administrative hygiene. It is what makes the program repeatable.
The framework should be short enough to be usable and detailed enough to prevent ambiguity. At minimum, it should define the action categories, the metrics and qualitative factors considered, the thresholds that trigger review, the accepted grounds for exception, the owners of each decision step, and the evidence required to support a retain, rationalize, replace, or exit recommendation. It should also state how decisions are recorded and when they are revisited.
In practice, the framework usually works best when supported by standard templates. A decision sheet for each SKU or SKU family can capture the key facts: performance, complexity burden, substitute path, customer sensitivity, proposed action, exception status, owner, and implementation notes. This prevents teams from debating from memory or from bringing inconsistent materials into decision meetings. It also creates an audit trail.
Documentation serves another purpose as well: it improves the quality of future SKU additions. Once a company has a clear rule set for exiting or simplifying items, it becomes much easier to ask whether a proposed new SKU deserves to enter the portfolio at all. The same logic that supports rationalization should eventually support launch discipline.
A documented framework should therefore be treated as part of portfolio governance, not as a one-time project artifact. It should live in the operating rhythm of the business, be reviewed periodically, and evolve as the company learns. The long-term goal is not simply to make good decisions during one cleanup effort. It is to create a portfolio management system in which decisions are faster, clearer, and less political because the rules are already known.
