A Portfolio of Customers

How to read this chapter

This chapter explains how to group customers for planning, decide which need individual attention, and assign someone to do that work.

1. A process for the largest consumers and the long tail — where the method comes from, then seven steps: establish the planning boundary; measure the concentration; assign a planning treatment; gather intelligence at the appropriate level; reconcile and stress the plan; promote, investigate, and release; close the loop.
2. When the plans do not agree — multiple forecasts and explicit decision authority.

The lesson to carry: decide who needs an individual forecast, who can share a group forecast, and what would make that arrangement change.

A process for the largest consumers and the long tail

We need enough structure to explain why one project receives an individual model and another is managed in a cohort, while allowing either arrangement to change as the work changes. Inventory planners have run this kind of triage for decades. ABC analysis ranks items by their share of demand value or volume so that the few carrying most of it get the closest control. It applies Pareto’s observation about concentration and is usually traced to a 1951 article by H. Ford Dickie of General Electric. XYZ analysis adds a second axis, usually the variability of each item’s demand, as a proxy for how predictable it is.¹ SAP’s current planning software uses the combined segments to choose forecast models and direct planners’ attention.² I’m adapting that practice to computing, where the thing being classified is a consumer within a particular resource pool, and where service consequences, shared constraints, and the time needed to obtain or move resources also affect the treatment.

I’d be cautious about combining all those dimensions into a single importance score. Inventory planners hit the same problem: Flores and Whybark proposed a matrix of criteria in place of one ranking, and later noted how little guidance existed on how to actually pay the “special attention” that important items were supposed to receive.³ A small, critical workload may need a strong service commitment, while an interruptible workload may be a useful source of temporary supply. Each deserves attention for a different reason, and a single ranking can hide an arrangement that helps both while we congratulate ourselves on having prioritized the portfolio.

1. Establish the planning boundary

I’d begin with the constraint we’re trying to manage: the resource pool, the interval that matters, the service target, and how far ahead the decision has to be made. A monthly cost ranking may be useful to Finance while telling us little about who contributes to a regional peak or occupies a scarce GPU pool. Shared dependencies need their own boundary too, so that allocating their costs to customers doesn’t make us count the underlying demand several times.

The constructed portfolio shows why the underlying models need to remain different. The web service is described in requests per second under a quality target and failure condition. The AI support assistant needs an outcome definition, token-and-cost accounting, and rate constraints. The database specialists have to explain service, maintenance, growth, and recovery together. What I need from every team is the same short list: what’s required, where and when, which evidence supports it, and who can change it. A database recovery deadline belongs on that list in its own terms; forcing it into the central team’s preferred compute forecast would make the report more uniform and the obligation harder to understand.

2. Measure the concentration

The cumulative share curve from Chapter 15 identifies the consumers responsible for most of each material constraint, and it has to be drawn pool by pool. By spend, the batch workers are the smallest line in Volume I, Chapter 1’s portfolio: $9,600 of $448,000, about 2 percent. By what the web rollout needs, they’re the only compatible workers that can be reassigned within two days. A spending classification would give the batch owner the least attention just when we most need to know whether batch can tolerate a delay.

How far down the curve to go depends on the decisions at stake and on what the planning team can maintain. The monthly meetings I describe in the Introduction covered the ten largest consumers of capacity. Looking back, I would recommit to them with a larger group: the top 10 plus the five or six projects I had identified as having the potential to become top 10.

Whatever the group, it has to fit the time available. Suppose, for illustration, that keeping an individual model useful takes a planner about a day a month (an owner conversation, a reconciliation, revised events), a cohort about two days, and a temporary investigation about two days a week while it lasts. Three planners with half their time for this have 3 × 20 × 0.5 = 30 planner-days a month. Twenty individual models and three cohorts use 20 + 3 × 2 = 26, leaving enough for two weeks of one investigation. Whatever the real figures, forty individual models would call for more planners or a lighter individual treatment, and a maintained cohort with a capable owner is worth more than an individual model nobody has touched since the customer’s plans changed.

3. Assign a planning treatment

For computing, I’d give that “special attention” a concrete meaning: work somebody maintains.

The XYZ axis needs adapting too. Its usual measure, the coefficient of variation, is the standard deviation of demand divided by its mean, and a regular daily or weekly cycle makes it large even when next Monday is easy to predict. SAP’s documentation warns about this and offers to remove trend and seasonality first, or to segment on forecast error instead.⁴ I’d use the error of Chapter 14’s seasonal-naive benchmark, relative to the consumer’s demand, at the horizon and busy interval the decision needs. That separates a regular pattern from unexplained volatility and marks a new project honestly as having too little history for either. Somebody still has to maintain that understanding for a cohort; otherwise “Other” remains a reporting category rather than a way of planning for the work.

The treatment also decides who acts on cost information. The shared platform’s owner maintains the cohort’s attribution and a showback view for the business, and changes the common defaults; members need a way to report a material change, not an optimization assignment for decisions the platform makes for them. An experiment gets a funding boundary and an end date, like Volume I, Chapter 3’s innovation program, but the label “innovation” doesn’t excuse it from explaining its demand for scarce resources once it becomes a proposed customer commitment.

Applied to the constructed portfolio, each row names a consumer within a pool, because one customer can warrant different treatments in different constraints:

The assistant row is the instructive one. Its cost ranking says it’s expensive, which we knew. It doesn’t say that the proposed rollout would exceed a token limit at the busy interval, or that $88,000 of the assistant’s $100,000 sits in a committed floor that won’t fall if the rollout shrinks, as Volume I, Chapter 1 showed.

4. Gather intelligence at the appropriate level

For an individually managed customer, the demand conversation follows its adoption plans, launches, migrations, retirements, and deadlines. With a cohort owner, I’d concentrate on what could move many members together: a platform migration, a retention default, a common software rollout, or a commercial policy. A rotating sample of members can reveal behavior the aggregate hides, but it won’t establish the safety of an unobserved critical workload, which is one reason to preserve exceptions to the group treatment.

The conversations differ, but the intelligence can share one event register. Chapter 17 examines the relationship work behind obtaining it; here I want a record that’s useful both to the planner and to the person who supplied it. This is the web rollout as the companion holds it:

The record doesn’t make either increment a good estimate. It separates the statistical baseline from the proposed plan and tells us whom to call when a condition changes, which makes the next discussion more specific than asking why the forecast was wrong.

A changed plan needs a changed version

When the product lead revises the event on July 8, revision 2 informs the next decision but can’t be used to judge the June 28 forecast, which was made with revision 1; Chapter 14 shows the perfect score that results if it is. The companion keeps both and gives each forecast the revision known on its date.

Overlap needs the same care. Suppose, in a separate variant, a rollout is expected to add 4,000 requests per second in total, and its first customers already contribute 1,000 to the statistical baseline. The remaining increment is:

$$4{,}000-1{,}000=3{,}000\ \text{requests/second}.$$

Adding the full 4,000 would count those early customers twice, and the overlap keeps changing as adoption proceeds until the ordinary model represents the recurring demand well enough to retire the event adjustment. Someone needs to own that handoff, or the forecast keeps adding a launch increment to history that already contains the launch.

The duplication can be organizational as well. Sales, Product, and a regional team might each describe the same customer expansion: three sources about one cause. The companion gives each record a cause identifier and rejects two current records with the same cause for the same workload and target, but it can’t tell that departments have named the same change differently; a person has to recognize that before the reports are added as separate demand.

Timing deserves the same scrutiny. A rollout the business still wants but can’t date remains useful for planning, but letting the previous date drive a purchase would claim more confidence than we have. The companion refuses an expired record, so somebody has to confirm the date or revise it.

5. Reconcile and stress the plan

Much of reconciliation is a search for double counting, and this process creates three ways to commit it. An event increment can already be in the baseline; the overlap field handles that. A shared service can be counted in its own pool and again in its customers’ totals; the boundary from Step 1 handles that. And a consumer promoted out of a cohort remains in the cohort’s history until someone restates it, so both models forecast its demand. With those removed, and individual and cohort demand at compatible time resolutions, we can compare the combined requirement with usable supply and set investigation triggers against the remaining headroom, as Chapter 15 does, not against spend.

Chapter 15’s warning applies to the stress case: adding every customer’s maximum overstates it unless the peaks would coincide, and assuming they always offset is the opposite mistake. I’d want the people who know those conditions to challenge both the reassuring and the alarming version before we rely on either.

The supply side remains just as specific. Our web service has 12,000 requests per second of degraded capacity; the qualified transfer would provide 13,500; full rollout asks for 14,000. The future independent group would support 16,000, but its estimated readiness comes after the launch. Looking across the portfolio may reveal another option or someone able to change a commitment, but it doesn’t remove the timing and service conditions attached to the resources already identified.

6. Promote, investigate, and release

If the question turns out to be architectural, we may need to fund a separate investigation with a technical owner, a bounded question, and someone able to act on what is learned. Chapter 17 takes up that work, including the friction that can arise when a capacity team questions another team’s deployment choices.

How we explain the closer engagement matters. If every invitation feels like an audit, customers will try to avoid qualifying for one, and a trigger measured per project or subscription is easy to avoid by splitting the work across several. I’d measure contribution by owner and purpose, but the better defense is making the attention worth having: help obtaining scarce supply, a more reliable workload model, an investigation the customer couldn’t otherwise staff, or a route to resolving a conflict outside its authority.

7. Close the loop

The review checks whether these arrangements produce useful information. I’d compare forecasts with actual demand for individual projects and cohorts separately, including membership changes and whether event adjustments helped, and look at bias and capacity shortfalls alongside spend variance: a service might stay within budget while becoming harder to support, or overspend because the business deliberately expanded its use.

The process needs its own checks, which the register can answer: individual models unrevised across two reviews, cohort owners nobody has spoken to since the last review, temporary exceptions past their deadline, consumers that changed treatment more than once in a year, event adjustments still active after their launch, and planner-days spent against the Step 2 budget. A stale individual model usually means the treatment was heavier than anyone could sustain; I’d lighten it rather than send a reminder.

Those findings should change the next action and, where necessary, the planning treatment. If the review leaves every conversation and decision unchanged, I’d ask what work the classification is doing for us.

When the plans do not agree

Even after all this work, the business may expect full adoption while Operations plans to stage access and Finance budgets for a later launch. Those are different kinds of number: an operating plan, a budget, and a business figure that may be a forecast or a target. They can remain different because they describe different conditions, and I don’t want the capacity team to average them into a curve that nobody intends to follow. I’d keep all three in the review, each with its owner and the supply it relies on, and ask which actions the organization is prepared to commit to and what has to change for those actions to be feasible.

Volume I, Chapter 3 mapped who can change which promise in the web case. When those decisions still leave incompatible obligations, they go to an executive who can weigh the consequences across the teams, and the capacity lead’s job is to make that choice understandable, with the evidence and alternatives the executive needs.

If staging is rejected but the transfer is agreed, full rollout leaves a gap of 14,000 − 13,500 = 500 requests per second after a group failure. If the batch owner also declines the delay, we retain only 12,000 of degraded capacity and the full-rollout gap grows to 2,000 requests per second. An executive can accept that exposure or change the customer promise, but accepting it does not change what the workers can do.

That may be an uncomfortable result to bring to a review, and it’s useful if it lets someone change an obligation while there’s still time. Getting people to tell us early, and to keep telling us after a forecast has gone wrong, is the subject of the next chapter.

Notes and sources

1. Tim J. van Kampen, Renzo Akkerman, and Dirk Pieter van Donk, “SKU classification: a literature review and conceptual framework,” International Journal of Operations & Production Management 32, no. 7 (2012): 850–876, https://doi.org/10.1108/01443571211250112 (open-access version: https://orbit.dtu.dk/en/publications/sku-classification-a-literature-review-and-conceptual-framework), accessed October 3, 2026. Supports ABC as an early inventory classification built on Pareto, XYZ as classification by demand variability, and their implementation in SAP planning software. The usual origin citation is H. Ford Dickie, “ABC Inventory Analysis Shoots for Dollars, Not Pennies,” Factory Management and Maintenance 109 (July 1951): 92–94, describing practice at General Electric; it is not online and was not consulted directly.↩︎

2. SAP, “ABC/XYZ Segmentation,” SAP Integrated Business Planning documentation, version 2608, https://help.sap.com/docs/r/feae3cea3cc549aaa9d9de7d363a83e6/LATEST/en-US/33e40058547f8073e10000000a441470.html, accessed October 3, 2026. Vendor documentation describing segment uses, including forecast-model assignment, accuracy analysis, and identifying items for closer attention. It documents a product feature, not the method’s origin, and doesn’t make this chapter’s process an SAP method.↩︎

3. Benito E. Flores and D. Clay Whybark, “Multiple Criteria ABC Analysis,” International Journal of Operations & Production Management 6, no. 3 (1986): 38–46, https://doi.org/10.1108/eb054765, whose abstract presents ABC as a way to allocate scarce management time and proposes a joint-criteria matrix. The “special attention” observation is from their “Implementing multiple criteria ABC analysis,” Journal of Operations Management 7, no. 1–2 (1987): 79–85, https://doi.org/10.1016/0272-6963(87)90008-8, as summarized by van Kampen, Akkerman, and van Donk (2012), section 4.2. Both concern inventory; the computing treatments here are the author’s.↩︎

4. SAP, “XYZ Segmentation,” SAP Integrated Business Planning documentation, version 2608, https://help.sap.com/docs/SAP_INTEGRATED_BUSINESS_PLANNING/feae3cea3cc549aaa9d9de7d363a83e6/457c0aeb10f245c08fe5d6c7b78825dd.html, accessed October 3, 2026. Vendor documentation: coefficient-of-variation segmentation, an option to remove trend and seasonality because they “indicate volatility despite often being predictable,” and segmentation on a forecast-error measure such as MAPE. Using the seasonal-naive benchmark’s error is the author’s adaptation.↩︎