Bain & Company has sized a $100-billion software opportunity in what it calls cross-system labor — the human work of moving information, decisions and handoffs between applications that were never designed to talk to each other.

The figure, published under the headline "The $100-Billion SaaS Opportunity Hiding in Cross-System Labor," reframes where the next wave of SaaS growth comes from. The argument, as the title states it, is straightforward: the money is not in another system of record. It is in the seams between the systems most companies already run.

For product managers, that is a positioning claim with direct roadmap consequences, and it deserves scrutiny before it earns a place in a strategy deck.

What does the claim actually say?

Bain's headline identifies two components. First, a dollar amount: $100 billion. Second, a location for that spend: cross-system labor, meaning work performed by people who reconcile, re-enter, route or verify data as it crosses boundaries between tools.

That framing treats integration friction not as a cost of doing business but as an addressable market. Software that removes the human glue between, say, a CRM, an ERP and a ticketing system would, in this view, compete for budget currently booked as payroll rather than as software spend.

The practical implication for pricing teams is significant: if your product replaces labor rather than another tool, the budget conversation changes from a comparison of license fees to a comparison against fully loaded headcount.

Where does the opportunity work — and where does it fail?

The claim is most credible in functions where handoffs are high-volume, rule-based and repetitive. Order-to-cash, procurement approvals, employee onboarding and support escalation routing are typical candidates. The pattern generalizes: any workflow where two systems of record meet and a person bridges the gap by copy, paste and judgment.

The failure modes are equally concrete, and a senior team should name them before committing.

• Judgment-heavy seams resist automation. Where the cross-system step requires negotiation, exception handling or customer-specific discretion, software can assist but rarely replaces the person, and adoption stalls.
• The buyer is not always the one feeling the pain. The people doing cross-system labor are often individual contributors; the budget sits with function heads who may not measure the friction at all. Without a quantified baseline of hours lost, deals stall in procurement.
• Incumbents can absorb the feature. Platform vendors have a structural incentive to make their own ecosystem the integration layer. A standalone cross-system product needs a defensible reason why the platforms themselves cannot close the gap.
• Integration surface is a maintenance liability. Every connector your product ships is a commitment to track someone else's API changes. Unit economics can deteriorate as the surface area grows.

None of these invalidate the opportunity. They define the conditions under which a roadmap built on it survives contact with an enterprise buyer.

What should product teams do with a $100-billion claim?

Consultancy market sizing is directional, not Gospel. The number's value is as a forcing function: it obliges teams to ask whether their own telemetry shows cross-system friction as a top driver of churn, support load or time-to-value.

Three checks are cheap to run. Instrument where users export and re-import data. Count support tickets whose root cause is a mismatch between two systems. Interview churned accounts about which handoffs they still staff manually. If those signals are weak, the $100 billion belongs to someone else's roadmap.

If they are strong, the positioning shift is real: sell against labor, not against competing software, and build the measurement story procurement will require.

The direction of travel

Bain's framing lands as the industry debate shifts from systems of record to systems of work that span records, and the vendors that win the seams will define the next procurement cycle.