The People Business Operating System

The thing a people business actually sells

Most companies can point to the thing they sell. A manufacturer sells a unit that comes off a line. A software firm sells a licence that costs almost nothing to copy. A bank sells the use of money. In each case the product is separable from the people who make it, and the whole discipline of management is about making that product more cheaply, or in greater volume, or at a higher price. There is a category of company for which none of this is quite true, and it is larger than it looks: the business process outsourcer answering a bank’s customers, the consultancy staffing a transformation programme, the managed service provider keeping a hospital’s systems alive at three in the morning, the staffing firm placing thousands of workers a month. Their product is not separable from their people. It is their people, doing skilled work on someone else’s behalf.

We will call them, together, people businesses, and the definition worth holding is a narrow one. A people business is one whose output is human judgement organised well. The organising is the value. Anyone can hire an agent, a consultant or a contractor; the difference between a firm that earns a healthy margin and one that does not is almost never the raw quality of the individuals, and almost always the quality of the decisions made around them: which work to take, whom to put on it, how to run it, and what to charge. Those decisions are made continuously, under time pressure, by many people, with incomplete information. They are the production process. And unlike a factory line, that process leaves almost no trace.

This is the structural fact everything else in this report follows from. A software company that improves its product improves every future sale at no marginal cost. A people business that improves has to improve a chain of judgements that is remade from scratch on every engagement. It has no economies of code, only economies of judgement, and judgement is the one thing its systems were never built to capture. We can measure how a decision is stored, in other words, by looking at how little of it survives: a won deal becomes a line in a forecast, a hire becomes a filled requisition, a delivery becomes a timesheet, a price becomes an invoice. The reasoning that connected them, the part that was actually the work, is gone.

When researchers do manage to look directly at decision quality, the findings are sobering. McKinsey’s survey of more than twelve hundred managers found that only 20% of respondents believe their organisations excel at making decisions, and that on average 61% of the time spent making them is used ineffectively. Translated into money for a typical Fortune 500 company, that inefficiency amounts to more than 530,000 days of managers’ time, or around USD 250m, wasted every year.¹ Those numbers describe organisations in general. In a people business, where the chain of decisions is not a support function but the product itself, the same inefficiency is not an overhead line. It is the margin.

And the margin is thin, because the product is billable time and time is finite. SPI Research’s benchmark of professional-services firms found average billable utilisation falling to 66.4% in 2025, down from 68.9% and the lowest the survey has recorded, against a level SPI treats as the minimum healthy threshold of 70%.² A few points of utilisation is not a rounding error; at the scale of a large firm it is the difference between a good year and a bad one. In the contact-centre world the same arithmetic shows up on the income statement: Concentrix, the largest listed operator, reported its non-GAAP operating margin slipping to 12.8% of revenue in fiscal 2025, from 13.7% a year earlier, even as revenue grew.³ Volume rose; the money per unit of work did not.

Put those together and the shape of the problem is clear. The economics of a people business are decided at the level of individual decisions, made fast and forgotten, in a sector where a couple of points of utilisation or one mispriced engagement swings the whole result. A people business does not have a margin so much as a chain of decisions, and the margin is whatever that chain happens to leave behind. The rest of this report is about why that chain is currently impossible to see as a whole, and what it would take to change that. The discipline that names the ambition is decision intelligence: treating a decision not as an event that vanishes but as an object you can hold, question and learn from.

The loop every people business runs on

Strip away the sector labels and every people business runs the same loop. It sells work. To deliver the work it hires or assigns the people. It delivers, against a promise of quality, cost and time. Then it gets paid, and what it is paid, minus what the delivery cost, is the margin that funds the next turn of the loop. Sell, hire, deliver, get paid. Four verbs, endlessly repeated. It is tempting to read them as four departments in sequence, a relay race where each hands off to the next. That reading is the mistake, and most of the industry’s software is built on it.

The loop is not a relay; it is a circulatory system. Each stage sets the conditions the next one has to live with, and the last stage sets the conditions for the first. The price agreed in the sale determines what the delivery can afford to spend, which determines who can be hired, which determines whether the promise made in the sale can actually be kept, which determines whether the client pays on time and buys again. A commitment made in one part of the business is a constraint imposed on another. Sell against work you cannot staff by the date you promised, and you have not won a deal; you have booked a loss that delivery will discover and finance will price, weeks later, when nothing can be changed. This is why the sharpest question in a people business is rarely can we win this, but can we deliver what winning it requires, and the two questions live in different systems that never speak.

Consider an illustrative case, offered only to make the mechanics concrete rather than to describe any real company. A mid-sized outsourcer wins a contract to run a new support queue for a retailer, priced on an assumption of a certain cost per interaction. The assumption depends on a target occupancy the workforce team has not been asked about, and on hiring forty agents in six weeks that the recruiting team has not been warned is coming. Recruiting hits its own target, time-to-fill, and fills the roles in eight weeks with a cohort whose ramp is slower than assumed. Delivery meets its own target, average handle time, by pushing occupancy past the point where attrition accelerates. Every function hits its number. The account still loses money, because the numbers were never the same number. Each team optimised a metric the neighbouring team could not see, against a commitment none of them owned.

That failure is not incompetence. It is the predictable result of running one loop through four scorecards that do not reconcile until finance closes the month. And it is getting more dangerous, because the economic ground under the loop is shifting. The Harvard Business Review has argued that generative AI automates precisely the standardised, monitorable, rules-based work that made offshore labour arbitrage rational in the first place,⁴ which means the parts of the loop that were once cheap and forgiving, the routine interactions, the easily specified tasks, are the parts being competed away fastest. What remains, and what will increasingly decide who wins, is judgement: the harder calls about what to take on, how to staff it, and how to price the risk that the easy work no longer covers.

The parts of the loop that AI automates first are the forgiving ones. What it leaves behind is judgement, the exact thing the tools do not hold.⁴

So the loop matters more, not less, as the routine work erodes. Yet the way it is instrumented assumes the opposite: that each stage can be optimised in isolation and the whole will take care of itself. A people business is a single loop, not four functions, and it is only ever as profitable as its worst handoff between them. To manage the loop as a loop, you would need one place where the commitments made in one stage become visible as constraints in the next, before the money is spent rather than after. That place does not exist in the standard stack. The next section is about why.

Five systems that cannot reason together

Walk into any established people business and you will find the loop, but you will find it dismembered. The selling lives in a CRM. The hiring lives in an applicant tracking or recruiting system. The delivery lives in a workforce or resource management tool. The money lives in finance and ERP. And laid over the top, promising to make sense of it all, is a business intelligence layer of dashboards and reports. Five categories of system, each excellent at the slice of the loop it was built for, and each structurally blind to the others. They were bought at different times, by different owners, to solve different local problems, and none of them was designed to hold a decision that spans two of them.

The blindness is not a data-access problem that a connector fixes. It is a modelling problem. A CRM models the world as accounts, opportunities and a forecast; its concept of success is a closed-won stage, and once a deal reaches that stage the CRM considers its job done. It has no representation of the team that deal now requires, no notion of whether that team exists, and no way to hold the price it agreed as a constraint on anything downstream. An applicant tracking system models the world as requisitions and candidates; it optimises time-to-fill against an open role, and it neither knows nor asks which revenue depends on that fill or what margin the pay rate it accepts implies. Each system is coherent inside its own boundary and incoherent across it, which is exactly the wrong shape for a business whose value lives in the crossings.

Read the right-hand column as one sentence and the problem states itself. No system in the standard stack can see the thing that actually determines the margin, which is the relationship between a commitment made in one stage and the constraint it imposes on the next. The CRM cannot see delivery reality; the recruiting system cannot see revenue; workforce management cannot see the price; finance sees all of it, but only once it is history; and BI, the one layer that touches everything, is a mirror, not an actor. It can tell you, beautifully, that last quarter went wrong. It cannot hold the decision that would have made this quarter go right.

Business intelligence can show you, in high resolution, that the loop leaked. It cannot stand at the leak and hold the decision that would close it.

This is why integration, on its own, disappoints. The instinct, when five systems cannot see each other, is to connect them, and connection helps: it stops the same customer being keyed in twice. But a pipe between two systems moves records; it does not create a shared way to reason. Connect the CRM to the ATS and you can pass a name across; you still have no single object that says this deal requires this team by this date at this cost, and here is whether that is possible. The five systems are not badly integrated so much as differently minded, and no amount of piping makes two systems agree on a decision neither was built to represent. The deeper cost of that arrangement, and it is a measurable one, is the subject of the next section. It is also explored in our note on why a CRM is not enough and on why recruiting systems do not talk to finance.

The price of a loop that does not close

It is easy to treat fragmentation as an aesthetic complaint, the sort of thing that annoys architects and no one else. It is not. Fragmentation has a price, and the price is paid three times: in the software itself, in the labour spent reconciling it, and in the decisions made on data no one trusts. Each has been measured, and the measurements are large enough that the usual response, that a business simply learns to live with it, starts to look like the expensive option.

Start with the sheer count of systems. Okta’s annual study of what companies actually run found the average organisation crossing a threshold it had been approaching for years: 101 applications, the first time the average has sat above one hundred.⁵That is the average across all sizes; a large enterprise runs far more. MuleSoft’s benchmark, drawn from more than a thousand IT leaders, puts the average enterprise at 897 applications, and finds that only 29% of them are integrated at all.⁶ Seven in ten applications, in other words, are islands. For a people business, the systems that hold the four stages of the loop are almost always on different islands, bought by different owners, and the ferry between them is a person with a spreadsheet.

The second cost is the reconciliation itself, and it is mostly invisible because it is disguised as work. When four systems hold four versions of the truth, someone has to decide which version to believe, and in most people businesses that someone is a meeting. The weekly operations review, the monthly business review, the deal desk, the resourcing huddle: a great deal of what passes for management in these firms is in fact manual integration, humans in rooms doing by hand what the systems cannot do automatically, reconciling the sale against the staffing against the cost. It is skilled, expensive labour, and it produces a number that is already out of date by the time everyone agrees on it. This is the tax our note on the hidden cost of disconnected systems tries to name.

The third cost is the one that compounds: decisions made on data no one quite believes. Gartner puts the average cost of poor data quality at USD 12.9m a year per organisation.⁷ That figure is usually read as a data-engineering problem, something for a cleanup project. In a people business it is a decision problem. When the pipeline number and the delivered-revenue number and the cost number come from systems that do not agree, every decision made against them carries a quiet discount for distrust. People hedge. They ask for the figures to be re-pulled. They wait for the meeting. The cost is not only the errors that slip through; it is the speed and confidence lost to the ones that might.

Notice what all three costs have in common. None of them is fixed by a better version of any one of the five systems. A faster CRM does not tell delivery the truth; a smarter ATS does not tell finance what the margin will be; a more beautiful dashboard does not turn a mirror into an actor. The costs come from the gaps between the systems, which means they can only be addressed in the gaps, at the level of the loop rather than the level of the tool. Fragmentation is not a failure of the individual systems; it is the absence of anything that sits beneath them and holds the decision they collectively imply. The rest of this report is about what that something is, and it begins by insisting on what it is not: another application on the pile.

What an operating system actually means here

The phrase operating system is easy to abuse, so it is worth saying plainly what it does not mean. It does not mean a single, all-consuming application that swallows the CRM, the recruiting system, workforce management, finance and BI and replaces them with one enormous piece of software. That project has been attempted many times, usually under the banner of a suite, and it fails for a reason that is structural rather than executional: the functions of a people business are genuinely different, they change at different speeds, and the best tool for running a sales pipeline is rarely the best tool for building a roster. A monolith that is adequate at five things is worse than five tools that are each excellent at one. Consolidation is not the answer. The right analogy is not the suite; it is the operating system of a computer, which does not replace the applications but gives them a shared foundation they can all rely on.

An operating system, in the sense that matters, does three things beneath the applications. First, it gives every function a common place to publish its facts, with the quality of the evidence behind each fact made explicit rather than assumed. The CRM does not just assert a forecast; it publishes the deals behind it with a label that says how firm each one is. Workforce management does not just assert a capacity; it publishes it with the assumptions it rests on. Finance publishes the realised numbers. The point is not to move the data, which integration already does, but to move it in a form that carries its own reliability, so that a decision made downstream knows how much weight each input can bear. This is the idea behind the evidence hierarchy: a measured fact and a hopeful guess are not the same input, and a serious system refuses to pretend they are.

Second, the operating system is where decisions are actually made, governed and scored, rather than merely reported on. A decision that spans the sale and the staffing does not belong inside the CRM or inside the recruiting system, because it belongs to neither; it belongs to the loop. So it needs a home that sits beneath both, where the options can be laid out, priced against the constraints that genuinely bind, and resolved by a named person whose choice is recorded. And once the outcome is known, it is scored against what was expected, in the same place the choice was made, so that the record is complete. A decision with its evidence, its constraints, its owner and its result held together is what we call a decision object, and it is the unit an operating system for a people business is built around.

Third, because everything is published and every decision is held in one place, the operating system produces something the five-system stack never can: one operating picture the four functions can share. Not four dashboards that happen to sit on the same screen, but a single representation of the loop in which a commitment made by sales is visible, immediately, as a constraint on delivery, and a limit discovered in delivery is visible as a fact the next sale has to respect. The functions keep their own tools and their own expertise. What they gain is a shared surface on which the whole loop is legible at once, which is the precondition for managing it as a loop instead of as four competing scorecards.

An operating system does not replace the five tools. It gives them a shared spine, and moves the decisions they were never built to hold onto it.

This is a smaller and more disciplined claim than the suite makes, and a more useful one. It leaves the applications in place and adds the one layer they all lack: a spine that holds facts with their quality, decisions with their constraints, and outcomes with their scores. The unit of an operating system for a people business is not the record and not the report; it is the decision, held long enough to be governed and scored. Everything that follows, the reasoning layer that reads the loop, the compounding intelligence that grows from scored outcomes, the governance that regulators are beginning to require, is a consequence of getting that one unit right. The discipline that names it is decision intelligence, and the next section takes the decision object apart to show what it holds.

The decision as the unit of account

Every discipline has a unit it accounts for. Accounting has the transaction. Manufacturing has the unit of production. A people business, if it is to be run well, needs the decision, and it needs to treat the decision the way accounting treats a transaction: as an object with a defined structure, recorded when it is made, and reconciled against reality when the result is in. Most people businesses have no such unit. Decisions are made in conversations and emails and meetings, and the only trace they leave is their consequence in some downstream system, long after the reasoning that produced them has evaporated. To build an operating system around the decision, you first have to define what a decision is made of.

Four things, held together. The first is the evidence, with its quality labelled. A decision rests on inputs, and those inputs are never equally reliable: a signed contract is firmer than a verbal commitment, a measured attrition rate is firmer than a manager’s hunch, last quarter’s realised cost is firmer than this quarter’s forecast. A decision object records not just the inputs but how much each can be trusted, so that the confidence in the decision is an honest function of the confidence in what it stands on. We call that overall reading business confidence, and its whole purpose is to stop a firm decision being built on soft ground without anyone noticing.

The second is the set of options, priced against the constraints that actually bind. A decision is a choice between courses of action, and each course has consequences that only become real when they meet a constraint. In a people business the binding constraint is usually not the one being discussed. A staffing plan is not limited by the number of desks but by the ramp time of new hires; a delivery date is not limited by ambition but by the slowest dependency. The operating system’s job is to find the constraint that genuinely governs the outcome and price every option against it, because the worst constraint decides whether a commitment can be kept, and a plan that ignores it is not optimistic, it is wrong.

The third is the human choice, recorded. An operating system for decisions is not an autopilot. The point of holding the evidence and pricing the options is to put a named person in a position to choose well, and then to record that they chose, what they chose, and on what basis. This matters for accountability, which we will come to, but it matters first for learning: a choice you cannot find is a choice you cannot learn from. The fourth is the outcome, scored against expectation. When the result is known, it is compared to what the decision predicted, and the gap is recorded. Not to assign blame, but to close the loop, so that the next decision of the same kind starts from evidence about how the last one actually turned out rather than from hope.

Held together, those four elements turn a decision from an event that vanishes into an object that persists. The place where the object is assembled and resolved is a decision room: a working surface where the evidence is laid out with its quality, the options are ranked against the binding constraint, the choice is made and owned, and the eventual outcome is written back. A decision worth making is worth keeping, and a decision object is simply the decision kept: its evidence, its constraints, its owner and its result, attached to each other and available to be questioned. This is the difference between a business that has opinions about why last year went the way it did and a business that has records. The full argument for the discipline is set out in the pillar essay on decision intelligence, and in the guide to what decision intelligence is.

The intelligence layer that reads the loop

Once the loop publishes its facts onto a shared spine and its decisions are held as objects, something becomes possible that no single system in the stack could ever do: a layer that reasons across the whole loop at once. This is the part where AI earns its place, and it is worth being precise about the job, because the loose version of the claim, that a model will run the business, is both wrong and dangerous. The right version is narrower and more powerful. An intelligence layer reads the loop as one connected thing, notices where a commitment in one stage is about to collide with a constraint in another, and proposes options against the facts, with its reasoning attached, for a human to decide.

The value comes from the crossings, which is exactly what the five separate systems cannot see. A model confined to the CRM can only reason about the pipeline; a model confined to workforce management can only reason about the roster. A model that can read the published facts of all four stages can notice that the deal about to be signed assumes a cost per interaction the current staffing plan cannot deliver, and that the constraint is not headcount but ramp time, and that the honest options are to move the date, change the price, or accept a known loss. That is a cross-loop inference, and it is only available to something that sits across the loop. We describe this capability, and its guardrails, in the guide to cross-module intelligence.

The discipline that keeps this useful rather than merely impressive is the same discipline the decision object enforces: the intelligence layer reasons against labelled evidence, prices options against binding constraints, and stops short of the choice. It does not decide; it prepares the decision so well that a human can decide quickly and defensibly. This is not a limitation grudgingly accepted; it is the design. A model that makes the call on its own produces speed without accountability, which is the worst trade a people business can make, because its decisions are exactly the ones a client or a regulator may later ask it to justify. A model that prepares the call produces speed with a record, which is the trade worth making.

The machine’s job is not to make the decision. It is to prepare the decision so well, against the real constraints, that a person can make it quickly and stand behind it.

There is a further reason to keep the human in the seat, beyond accountability, and it is empirical. The studies that find the largest gains from these tools find them where the tool helps a person reason better, not where it replaces the person’s reasoning. The intelligence layer of an operating system is built on that finding: it is a way of putting a well-prepared decision in front of a well-chosen human, at the moment the loop needs one, with all the evidence and every binding constraint already assembled. An intelligence layer worth having reasons across the whole loop, but hands the loop back to a person to close, with the case for each option already made. What that person decides, and how it turns out, becomes the raw material for the asset described next: an organisation that gets measurably better at the decisions it makes most often. The reasoning surface itself is described on the intelligence page.

Why this compounds into enterprise intelligence

Everything so far would be worth doing even if it stopped at a single decision made well. But the deeper reason to build an operating system around the decision is that decisions, once they are held as objects and scored against reality, compound. A people business makes the same kinds of decision thousands of times: which deals to pursue, whom to staff, how to price a given shape of work, when to intervene on an account. If each of those decisions is recorded with its evidence and its outcome, the organisation stops starting from scratch. The next decision of a familiar kind begins from a growing body of evidence about how the last hundred like it actually turned out. That is not a report. It is an asset.

The mechanism is the scored outcome. A decision object that is closed with its result, and compared to what it predicted, produces a small, durable piece of learning: for this kind of engagement, at this price, with this staffing assumption, here is what happened. Individually these are unremarkable. Accumulated across a business and across time, they become the thing a people business has always lacked and always needed: an institutional memory of its own judgement, held at the level of the decision rather than the anecdote. This is what we mean by enterprise intelligence, and it is categorically different from analytics. Analytics tells you what happened. Enterprise intelligence tells you what tends to happen when you decide a certain way, which is the only kind of knowledge that improves the next decision.

The reason the five-system stack can never produce this is now easy to state. Enterprise intelligence requires that decisions be recorded as decisions and reconciled against outcomes, and no system in the standard stack records a decision at all. The CRM records that a deal closed, not why it was pursued against the odds; the recruiting system records that a role was filled, not the reasoning about whether it should have been; finance records the margin, not the choices that set it. The learning that would improve the loop is precisely the information the loop’s systems throw away. Our note on why enterprise software should remember decisions makes the case that this forgetting is not incidental but designed in, and that undoing it is the whole opportunity.

Analytics tells you what happened. An operating system that scores its own decisions tells you what tends to happen when you decide a certain way. Only the second kind of knowledge improves the next call.

This is where the economics of a people business, which have no economies of code, finally acquire an economy of judgement. A firm that holds and scores its decisions gets better at the decisions it makes most often, and that improvement compounds silently, deal after deal, roster after roster, quarter after quarter. It is the closest thing a people business has to the advantage a software company gets from its codebase: an asset that grows more valuable the more the business is used. A people business that scores its decisions is the only kind that can genuinely learn, because it is the only kind that keeps a record of what it decided and what that decision was worth. The remaining question is whether a firm can choose to build this at leisure, and the answer, increasingly, is no, because the same architecture is becoming a legal requirement.

Why governance points the same way

There is a comfortable story in which governance is a cost centre, a set of constraints imposed from outside that a well-run business tolerates and works around. For a people business in 2026 that story is wrong, and the reason it is wrong is the single most useful argument in this report. The obligations regulators are placing on how these businesses decide describe, almost exactly, the architecture we have been building toward. A firm that holds its decisions as governed objects, with evidence, constraints, a recorded human choice and a scored outcome, is not merely well run. It is, more or less by construction, compliant. Governance is not pulling against the operating system. It is pushing toward it.

Consider what the EU AI Act actually classifies as high-risk. Annex III places AI used for the recruitment and selection of people, and for decisions about the terms of their work, the allocation of their tasks, and the monitoring and evaluation of their performance, squarely in the high-risk category.⁸ Those are not exotic uses. They are the core decisions of a staffing firm, a BPO and a consultancy, made thousands of times a day. High-risk classification brings obligations around risk management, human oversight, logging and transparency, and the penalties for getting them wrong are not nominal: up to €35m or 7% of worldwide annual turnover for the most serious breaches, whichever is higher.⁹ The timeline has been eased, not removed. The Digital Omnibus reforms deferred the high-risk obligations to 2 December 2027 for standalone systems and 2 August 2028 for systems embedded in regulated products.¹⁰ The direction is fixed even where the date has moved.

Now read those obligations as a specification. Risk management, human oversight, logging and transparency for an employment decision describe a decision that records its inputs, keeps a human in the loop, and leaves an auditable trail of how it was made. That is a decision object. The Act does not use the word, but the thing it requires, a high-risk decision you can reconstruct and justify after the fact, is exactly the object an operating system for a people business is built to hold. The guide to what the EU AI Act means for BPOs works through the specifics, but the structural point is simple: the compliant architecture and the well-run architecture are the same architecture.

The GDPR points the same way from a different direction. Article 22 gives a person the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, and where such decisions are permitted, it requires safeguards including the right to obtain human intervention and to contest the outcome.¹¹A decision object, with its recorded human choice, is precisely what makes that right real rather than theoretical. And Article 5’s accountability principle requires an organisation not merely to comply with the data-protection principles but to be able to demonstrate that it has.¹² Demonstrate is the operative word: it asks for evidence, held and retrievable, which is what a scored decision object provides and what a meeting and a spreadsheet do not. The enforcement behind these words is not hypothetical; cumulative GDPR fines passed €6bn for the first time, reaching roughly €6.11bn by early 2026.¹³ Our guide to GDPR for BPOs covers the operational detail.

Put the two regimes together and the conclusion is hard to avoid. The regulator is asking a people business to be able to show, for its most consequential decisions, what evidence it used, what a human chose, and how it turned out. That is not a burden bolted onto the loop; it is a description of a loop that remembers its own decisions. Governance is not a reason to postpone building an operating system for decisions; it is the clearest external confirmation that the decision, held and auditable, is the unit a people business will be required to account for. The businesses that treat compliance as a reason to build this now will find that they have also built the thing that makes them better run, which is the argument the next section turns into a path. The wider posture is set out on our trust page.

A path, not a rip and replace

The case made so far could be read as a demand to tear down the stack and start again, and that reading would kill it. No people business can pause the loop to re-platform, and none should try. The point of an operating system that sits beneath the applications rather than replacing them is that it can be adopted in stages, against the loop as it runs, starting wherever the loop leaks most. What follows is a maturity path, described so that a firm can locate itself honestly and see the next move, rather than a promise that the whole journey happens at once.

1. Disconnected. The five systems each hold their slice of the loop, and reconciliation happens in meetings and spreadsheets. Most people businesses live here. It is workable at small scale and quietly expensive at large scale, and it is where the costs in section four are paid in full.
2. Connected. Integrations move records between systems, so the same customer is not keyed in twice and BI can report across the stack. This removes duplication and improves visibility, but it does not create a shared decision; the systems still cannot agree on a commitment neither was built to represent.
3. Published facts. Each function begins publishing its facts onto a shared spine with the quality of the evidence labelled, so that a fact carries its own reliability. This is the first step that changes the nature of the stack rather than merely tidying it, because it makes the loop legible in one place, on honest terms.
4. Governed decisions. The decisions that span the loop move onto the spine as objects: evidence assembled, options priced against binding constraints, a named human choosing and owning the call. The commitments made in one stage become visible as constraints in the next, before the money is committed rather than after.
5. Scored outcomes. Decisions are closed against reality, their results compared to what was expected, and the gap recorded. The loop finishes closing. At this point the business has, for the first time, a truthful record of its own judgement rather than an argument about it.
6. Enterprise intelligence. The accumulated scored outcomes begin to teach the next decision, and the operating picture compounds. The firm gets measurably better at the decisions it makes most often, which is the economy of judgement a people business has always lacked.

The path is deliberately gradual, and the early stages are worth real money on their own; a firm does not have to reach the top to benefit. But the sequence matters, because each stage is the precondition for the next. You cannot govern decisions on facts you do not trust, and you cannot compound learning from decisions you never recorded. The right first move is almost always to find the handoff where the loop leaks most, the sale that outruns delivery, the hire that ignores the margin, and to make that one crossing a governed decision on published facts. The companion report, The State of Decision Intelligence for People Businesses 2026, tracks how far the sector has moved along this path, and how the forces pushing it are changing.

A people business does not need another tool. It needs an operating system for the decisions the tools were never built to hold.

That sentence is the whole argument compressed. The stack is not short a system; the average enterprise already runs hundreds. What it is short of is the layer beneath the systems that holds the decision the loop turns on: the sale that becomes a staffing constraint, the constraint that becomes a delivery risk, the risk that becomes a margin. The people businesses that will compound advantage over the next decade are the ones that stop buying tools for functions and start building an operating system for decisions.The tools were the right answer to the last question, how do we run each function well. The operating system is the answer to the question that decides the margin now, how do we make the loop’s decisions well, together, and remember what they were worth. That is what the platform is built to be, and the decision surface is where it starts.

Methodology & a note on honesty

This is a thesis piece: its purpose is to argue for a way of seeing a people business, not to report a single dataset. But an argument that leans on numbers is only as trustworthy as its numbers, so the same citation discipline applies here as to any of our reports. Every figure in this document maps to a named, dated, public source with a working link in the References, and each source is used at least once. Where a claim is illustrative rather than measured, the text says so; the staffing example in the second section is introduced explicitly as illustrative and describes no real company.

The sources are of three kinds. Decision-quality and economic figures come from analyst and professional-services research: McKinsey on the cost of ineffective decision making,¹ SPI Research on billable utilisation,²Concentrix’s own results filing on operating margin,³ and Harvard Business Review on how AI is changing the economics of outsourcing.⁴ Fragmentation figures come from Okta on application counts,⁵ MuleSoft on integration,⁶ and Gartner on the cost of poor data quality.⁷Governance figures come directly from the primary legal texts and their trackers: the EU AI Act’s Annex III⁸ and Article 99,⁹ a law-firm analysis of the deferred deadlines,¹⁰ the GDPR’s Article 22¹¹ and Article 5,¹² and the CMS enforcement tracker for cumulative fines.¹³

Three widely-repeated figures were deliberately left out, because when we went to verify them they did not hold up on their stated sources, and a gap is better than a number we cannot stand behind. The first is a frequently-cited claim that the largest organisations run around 231 applications; the Okta report we could verify states the average of 101 clearly but did not confirm the 231 figure for us, so we cite only the 101. The second is a claim of a 95%-plus correlation between decision effectiveness and financial performance, often attributed to a Bain article that, on inspection, does not contain that figure; we make the qualitative point about decision quality and finance without the unverifiable number. The third is a claim that more than 70% of organisations cite cost reduction as the primary reason to outsource; the Deloitte survey now frames cost as one of several drivers alongside talent and agility, so we did not use the older figure.

One source needs a note about access rather than accuracy. Gartner blocks automated fetching, so the page behind the USD 12.9m data-quality figure returns a forbidden response to a scraper while resolving normally in a browser; the figure is Gartner’s own, attributed to its analyst Melody Chien, and is among the most widely-cited estimates in the field. We flag the access quirk here rather than dress it up. The concepts that carry the argument, the decision object, the evidence hierarchy, the binding constraint, enterprise intelligence and the operating loop itself, are ONX’s own framing rather than external findings, and are set out in the linked guides and in the pillar essay on decision intelligence rather than presented here as measured fact.

A reference work earns its standing by being corrected, not defended. If you find a claim here you believe is wrong, a source that has been superseded, or a number we should have flagged and did not, we want to know. This edition will be revised as the figures move, particularly the EU AI Act timeline and the data-quality and application-count benchmarks, all of which are changing quickly.

References

Every figure in this report is sourced below. Third-party links open in a new tab. Where a figure is modelled rather than measured, or where a widely-quoted statistic could not be traced to its primary source, the report says so in the text.

1. Decision making in the age of urgency · McKinsey & Company, 2019. Survey of 1,259 respondents: only 20% say their organisations excel at decision making; 61% say most decision-making time is used ineffectively; inefficiency costs a typical Fortune 500 more than 530,000 manager-days (~USD 250m) a year.
2. 2025 Professional Services Maturity Benchmark · SPI Research, 2025. Average billable utilisation fell to 66.4%, from 68.9% the prior year, the lowest level the benchmark has recorded; SPI treats 70% as the minimum healthy threshold.
3. Concentrix Reports Fourth Quarter and Fiscal Year 2025 Results · Concentrix Corporation, 2026. Non-GAAP operating margin 12.8% of revenue (FY2025), down from 13.7% (FY2024); revenue USD 9,825.8m, up 2.2%.
4. AI Is Rewriting the Economics of Outsourcing · Harvard Business Review, 2026. Generative AI automates precisely the standardised, monitorable, rules-based tasks that made offshore labour arbitrage rational, pressuring the model the industry was built on.
5. Businesses at Work 2025 · Okta, 2025. The average number of apps per organisation reached 101, the first time above 100 after years of roughly flat growth.
6. Connectivity Benchmark Report 2025 · MuleSoft (Salesforce), 2025. 10th annual survey of 1,050 IT leaders: the average enterprise uses 897 applications, of which only 29% are integrated.
7. How to Improve Your Data Quality · Gartner, 2021. Poor data quality costs organisations an average of USD 12.9m a year (attributed to Gartner analyst Melody Chien). Gartner blocks automated fetching, so the page returns 403 to a scraper while resolving normally in a browser.
8. Annex III: High-Risk AI Systems (Regulation (EU) 2024/1689) · EU Artificial Intelligence Act, 2024. Point 4 classifies AI used for recruitment and selection, and for decisions on terms, task allocation and monitoring or evaluation of workers, as high-risk.
9. Article 99: Penalties (Regulation (EU) 2024/1689) · EU Artificial Intelligence Act, 2024. Up to €35m or 7% of total worldwide annual turnover for prohibited practices, and up to €15m or 3% for most other breaches, whichever is higher.
10. AI Act Update: EU Resolves to Change Rules and Extend Deadlines · Latham & Watkins, 2026. The Digital Omnibus defers Annex III high-risk obligations to 2 December 2027 for standalone systems and 2 August 2028 for systems embedded in regulated products.
11. Article 22: Automated individual decision-making, including profiling · GDPR (Regulation (EU) 2016/679), 2016. A person has the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects; permitted cases require safeguards including the right to human intervention and to contest the decision.
12. Article 5: Principles relating to processing of personal data · GDPR (Regulation (EU) 2016/679), 2016. The accountability principle, Article 5(2), requires the controller to be able to demonstrate compliance with the data-protection principles, not merely to comply.
13. GDPR Enforcement Tracker Report: Numbers and Figures · CMS, 2026. Cumulative GDPR fines passed the €6bn mark for the first time, reaching roughly €6.11bn as of the 1 March 2026 cut-off.