Network Design & Orchestration
Why Customer Operations Needs Supply-Chain Thinking
Customer operations has become a network of providers, technologies, workforce models and geographies. We should start managing it like one.

I came to customer operations by way of supply chain.
Earlier in my career, I spent years working in logistics, global operations and supply-chain environments. Later, when my responsibilities expanded into customer experience and customer operations, I began to notice something that has shaped how I think about the field ever since:
The two disciplines often use different language to solve remarkably similar problems.
Both are trying to match uncertain demand with finite capacity. Both depend on outside partners whose capabilities, economics and performance vary. Both must balance cost, quality, responsiveness and resilience. Both suffer when an operating model is designed around the average day rather than the difficult one. And both become increasingly fragile when too much depends on a single point in the system.
Supply-chain leaders have spent decades developing ways to deal with these realities. Customer-operations leaders can borrow a great deal from that playbook. I don't mean that every company needs more BPOs. It doesn't. I mean that customer operations should increasingly be designed as a system rather than as a vendor relationship.

Design for variability, not the average
One of the first lessons in supply chain is that averages can be dangerous. Average demand does not tell you what happens during a product launch, holiday season, outage, tax season, enrollment period, weather event or unexpected surge. The network has to work when demand moves away from the mean.
Customer operations has the same problem. A support organization may need 500 people most of the year and substantially more for a few critical weeks. Another may experience unpredictable spikes driven by outages, product issues or external events. A third may need new capacity in a geography it has never used before.
Yet many operating models are still designed around something close to steady-state demand. That creates a familiar choice: carry excess capacity all year, or scramble when demand rises.
Supply-chain disciplines such as demand planning, scenario modeling and Sales & Operations Planning were created in part to manage that mismatch. They force an organization to think explicitly about demand scenarios, capacity constraints and what actions should occur when reality differs from plan.
Customer operations needs the same mindset. The question shouldn't only be, “How many agents do we need?” It should also be, “What range of demand should this system be able to absorb, where will the capacity come from, how quickly can it be activated, and what changes when the forecast is wrong?”
In customer operations, capacity is also unusually perishable. You cannot warehouse yesterday's unused customer-service hour and deploy it tomorrow. When demand arrives, capacity either exists or it doesn't. That makes preparedness especially valuable.
Source for fit, not for the broadest promise
Good supply chains rarely assume that every supplier should do everything. Different suppliers have different strengths: geography, scale, economics, speed, technical capability, flexibility, quality systems or specialized expertise.
Customer operations is no different. One BPO may be exceptional at a large, stable offshore program. Another may be better for a specialized U.S. requirement. Another may excel at rapid deployment or seasonal work. A technology provider may eliminate work that previously required labor. A specialist may solve one narrow problem far better than a broad provider ever could.
The mistake is not choosing one provider. Sometimes one provider is exactly the right answer. The mistake is allowing the capabilities of the incumbent provider to define the universe of possible solutions.
Supply-chain thinking starts with the requirement and works outward. What does the business need? What are the constraints? Which capabilities matter most? What tradeoffs are acceptable? Then: which combination of suppliers, technologies, geographies and operating approaches best fits that requirement? That is a very different question from, “What else can our existing provider sell us?”
I increasingly believe customer operations should preserve that kind of optionality. Not because every company needs a complicated vendor portfolio, but because markets move too quickly to assume that one provider's geography, labor model, technology choices and economics will remain optimal for every requirement over time.
A vendor list is not an operating model
Supply-chain leaders learned long ago that adding suppliers does not automatically create resilience. Sometimes it simply creates more suppliers. The same is true in customer operations.
A company can have three BPOs and still have a poorly designed operating model. Contracts may differ. Data may be inconsistent. Governance may be fragmented. Nobody may clearly own capacity allocation, quality normalization, escalation or the way work moves between providers. The complexity has merely migrated from the vendor to the customer.
That is why I think the most important work often happens between provider selection and steady-state delivery:
- Someone has to design the requirement.
- Someone has to source and evaluate the alternatives.
- Someone has to assemble the pieces.
- Someone has to structure the commercial relationships.
- Someone has to launch the work.
- And someone has to orchestrate the system after go-live.
I think of that lifecycle as:
“DESIGN → SOURCE → EVALUATE → ASSEMBLE → CONTRACT → LAUNCH → ORCHESTRATE”
Traditional sourcing tends to place enormous emphasis on the middle of that sequence: selecting the vendor. But the vendor decision is only one decision. The real operating question is whether the pieces can function together as a coherent solution.
Supply chains have concepts such as lead logistics providers, integrators and control towers because sophisticated networks eventually require coordination above the individual supplier level. Customer operations is reaching a similar point.
Visibility matters because decisions have to be made
Another supply-chain lesson: visibility has little value unless it changes decisions. For years, “control tower” became a popular supply-chain phrase. The best versions were never merely dashboards. Their purpose was to create enough visibility across the network to decide what should happen next.
- Where is capacity tightening?
- Which supplier is underperforming?
- Where is demand deviating from forecast?
- Should inventory, volume or transportation be reallocated?
Customer operations needs the same discipline. If several providers are involved, performance data has to become comparable. Quality needs common definitions. Forecasts need to translate into capacity. Allocation decisions need rules. Escalations need clear ownership.
The purpose is not to build a prettier dashboard. It is to make the network governable. This was one of the more important lessons for me when customer operations became a larger part of my career. The interesting problem wasn’t simply whether an external team could handle the work. It was how to create enough measurement, allocation discipline and operating visibility that several resources could behave like components of one system.
That shift—from managing vendors individually to managing the network—is fundamental.
A backup vendor is not the same thing as readiness
Supply chains also teach us to be skeptical of nominal redundancy. A second supplier on a spreadsheet may provide almost no resilience if it cannot actually deliver when the primary supplier fails.
Customer operations has the same problem. Companies often say they have a backup BPO. But ask a few additional questions:
- Are people already identified?
- Are contracts in place?
- Have they been trained?
- Do they have system access?
- Has capacity been validated?
- Has the operating process been tested?
- Can work actually move?
If the answer to most of those questions is no, the organization does not really have response capacity. It has a phone number. That distinction matters because readiness has to be created before the incident.
A disruption is the worst possible time to negotiate commercial terms, qualify providers, develop training, provision systems and invent governance. Supply-chain resilience increasingly moved upstream for exactly this reason. The time to create alternatives is before they are required. Customer operations should do the same.
Diversification should reduce risk—not manufacture complexity
This is where the analogy can be misunderstood. “Supply-chain thinking” does not mean maximizing the number of providers. A supply chain with unnecessary nodes is not sophisticated. It is inefficient.
A customer-operations model with unnecessary vendors has the same problem. Diversification is useful when it removes a meaningful dependency, introduces a valuable capability, improves economics, adds geographic reach, creates surge capacity or increases resilience. If a second provider does none of those things, there may be no reason to add one.
The goal is not vendor proliferation. The goal is optionality. That distinction is especially important because sophisticated operations should become simpler for the customer, not harder. The customer may need access to several capabilities without wanting to manage several separate sourcing processes, contracts, invoices, operating cadences and escalation paths.
That is another lesson from mature supply chains: complexity can exist underneath the system without every participant having to manage all of it directly.
Well-designed orchestration absorbs complexity rather than merely exposing it.

AI will make this more important, not less
The next wave of customer operations makes supply-chain thinking even more relevant.
AI is not simply another tool inside the existing BPO model. It is creating new combinations of labor, automation, specialist technology and workflow design.
Some work will disappear. Some work will become more complex. Some programs will use AI heavily. Others will remain human-intensive. Many will blend the two.
New providers will emerge faster than traditional procurement cycles can comfortably evaluate them. Existing providers will make different technology bets. Geography, labor economics and specialized capability will continue to change.
In that environment, hard-wiring an entire customer-operations strategy to a single provider's view of the future becomes a more consequential decision. I suspect the strongest operating models will increasingly behave like modular networks. They will be able to:
- adopt a better technology without redesigning everything else;
- add a specialist capability without replacing the core program;
- move capacity when economics, performance or risk change;
- scale up for an event and scale down afterward;
and they will know which parts of the system genuinely benefit from consolidation.
That is very much a supply-chain mindset.
Start with the problem
Over the years, my work has taken me from global supply chains into customer operations, outsourcing, technology and eventually ArenaCX. The more of the customer-operations market I have seen, the more convinced I have become that the most useful question is usually not, “Which provider should we use?” It is, “What system should we design to solve this problem?”
- Sometimes the answer is one excellent provider.
- Sometimes it is one core provider plus a specialist.
- Sometimes it is several coordinated providers across geographies.
- Sometimes the right answer is technology rather than additional labor.
- Sometimes the requirement is not more capacity today, but readiness for capacity tomorrow.
The architecture should follow the problem. Supply-chain professionals have been thinking this way for a long time: segment the requirement, preserve options where they matter, understand dependencies, design for variability, create visibility, and establish clear orchestration across the network.
Customer operations is ready for more of that thinking. Not because customer service is a supply chain. But because both disciplines are ultimately trying to do the same thing:
“Put the right capability in the right place, at the right time, at the right economics—and keep the system working when conditions change.”