Picture your three most experienced operational staff — not the people managing teams, but the ones embedded in the work itself, processing the high-volume cases that keep the business running. For every hour they spend on tasks that actually require their judgment, estimate how much time they spend doing something else: switching between screens, re-entering information that already exists somewhere in another system, waiting for a report to be manually pulled together from four sources that don’t connect to each other.
That is not a workflow inefficiency. It is a structural problem — and it has a name.
What the Human API problem is
An API, in software terms, is a connector. It allows two systems to exchange information automatically, without a person in the middle. When software systems don’t connect — and in most mid-market service companies, the majority don’t — businesses build a substitute: a person who opens system A, takes the output, and carries it into system B. That person is acting as a human API.
The pattern is remarkably consistent across sectors where operations are screen-based and volume is high. A mid-market insurance company processes each claim through four separate platforms that were never designed to communicate: one for intake, one for compliance documentation, one for reserve calculations, one for correspondence. Between each platform, an analyst manually carries the relevant data — case number, status, financial figure, decision code — from one screen to the next. In a staffing business, placements are reconciled between a CRM, a payroll system, and a client-reporting portal by a coordinator who exports, reformats, and imports each dataset by hand. In a healthcare back-office, prior authorisation requests move through a sequence of clinical, administrative, and billing systems with a different person managing the handoff between each pair.
None of these people would describe their job as bridging software gaps. They would say they are processing claims, managing accounts, or coordinating placements. But as we have examined in detail when looking at what drives manual-process overload in growing service companies, a significant portion of their working day — typically two to four hours — is consumed by data transport that software should be handling automatically.
In a typical mid-market service operation, a single case file touches five or more disconnected systems — not because the work requires it, but because the systems were never designed to communicate.
Why Human APIs are expensive and invisible at the same time
The Human API problem compounds in two directions simultaneously.
First, it scales with volume. When the business is small, one person manually bridging two systems is a manageable workaround. When volume increases, the default response is always the same: hire another person to help with the bridging. And another. Headcount grows not because the underlying work has become more complex, but because the data-transport burden scales proportionally with output and no one has asked whether it has to.
This is the mechanism behind the Manual Wall — the operational growth ceiling where adding headcount stops improving margins. Revenue increases; the cost base increases with it. The extra staff are absorbing friction, not adding capacity. When a company’s operations depend on people manually carrying information between software, hiring more people to carry it faster is not a fix. It is a compounding cost.
Second, Human APIs are structurally invisible. They do not appear as a line item on any report. They show up as salary, employer taxes, benefits, and management overhead — but no invoice reads “14 hours per week of data transport across eight staff.” The cost is distributed across roles that look busy and productive. Output is happening. The fact that a substantial portion of it is an architecture workaround is genuinely hard to see without looking for it deliberately.
There is a further layer of invisibility worth noting: the people doing the bridging are often the most reliable people on the team. Data transport does not require skill, but it has typically migrated to the most conscientious staff because accuracy matters when information has to move without errors. Fixing the Human API problem means giving those people their time back — and for most operations leaders, it is the first time they see what those people are actually capable of when they are not doing data entry.
How to calculate what your Human APIs are costing you
The starting point is a time-mapping exercise, not a technology conversation.
Ask each team member to track, for five working days, every instance where they move information from one system to another — export to import, copy to paste, read from one screen and type into another. Log the workflow name, the systems involved, and the time taken per occurrence. Total the results by workflow pattern, not by individual.
Some patterns will be small — ten or fifteen minutes a day across two or three people. Others will be substantial — ninety minutes per day across eight or ten people. The patterns that aggregate to half an FTE or more across the team are your priority queue.
The threshold matters. Digital Forms applies a viability floor called the 0.5 FTE gatekeeper rule: no automation gets built unless it can demonstrably free at least half a full-time employee’s time. Below that threshold, the cost of building and maintaining the automation typically outweighs the return. At 0.5 FTE and above, the ROI is reliably positive within the first year.
In a mid-market service company processing 400–600 cases per month, this exercise typically surfaces three to five high-priority Human APIs and ten to fifteen lower-priority ones. The top three commonly account for 80% of the recoverable time. At a mid-market operational salary of £40,000–£55,000, eliminating those three patterns can represent £200,000–£400,000 per year in recoverable staff cost — cost currently categorised as headcount rather than what it actually is: an architecture tax that compounds with every new hire.
The Human API is the most expensive invisible line item in your P&L. It does not appear on any invoice. It shows up as headcount.
What makes Human APIs difficult to remove — and what makes it easier than expected
The instinctive response is to upgrade the systems. This is usually the wrong first move, for two reasons.
First, the underlying systems are often fine. The Human API is not evidence that the platforms are bad — it is evidence that the connection layer between them was never built. Replacing an ERP to eliminate a manual bridging step is the operational equivalent of rebuilding a road because two telephone cables need connecting. The problem is smaller and more specific than the upgrade response assumes.
Second, the people doing the bridging have built significant tacit knowledge around the workaround. They know which edge cases break the manual process. They know which fields the receiving system actually uses versus silently ignores. They have built compensating checks because errors downstream are costly and sometimes regulatory. Any fix that does not account for this knowledge will miss the edge cases and create new problems further along the workflow.
What works instead is designing the replacement before building it: mapping the workflow step by step, identifying where human judgment is genuinely needed versus where a person has been drafted in to compensate for a missing connection. This distinction matters practically, because the right technical fix varies significantly depending on the answer.
There are three common approaches. A direct connection between the two systems, built using each system’s own capabilities — right when both platforms support it and the data involved is consistent. A workflow automation layer that monitors one system and writes to another — right when direct connection is not available, which describes a substantial proportion of the legacy software that mid-market companies run on. And platform rationalisation, where two systems being manually bridged are replaced by one that covers both functions — an approach that sometimes eliminates three or four Human APIs at once without building any new automation at all.
Choosing correctly among these — without overbuilding, and without replacing systems that still serve their purpose — is where the mapping work pays for itself many times over.
What the fix actually produces in practice
Consider a mid-market TPA processing several thousand insurance claims per month — the type of operation we have written about in examining why adding claims analysts does not fix a throughput problem. Each claim moved through five disconnected systems. The full per-case workflow ran to 27 distinct screen interactions; 11 of those involved no decision-making whatsoever, only data being carried from one screen to the next.
Eliminating the top three Human APIs in that operation — a manually maintained spreadsheet bridging two platforms, a compliance cross-reference performed by reading two screens side by side, and a correspondence log updated by hand — reduced per-case screen interactions from 27 to 9. The staff who had been managing the bridging were redeployed to the escalation and dispute cases that require experienced judgment. Volume increased without a proportional headcount increase. The operation became something the business could actually scale.
This is the shape of result that operational transformation in a 60-day window typically produces — not a multi-year restructuring programme, but a specific, measurable change in how work moves through an operation. The gains are real, they arrive quickly, and they compound because the architectural fix holds as volume grows, unlike the headcount workaround it replaces.
Where to start: the Human API diagnostic
Begin with the mapping exercise. Five working days, across the full operational team, tracking every instance of manual data transport by workflow pattern. Total it by pattern. Identify the top three by aggregate time consumed.
For most operations leaders, that exercise alone reshapes the conversation. What felt like a staffing problem — always understaffed, always behind — becomes a specific list of workflow patterns with specific, calculable costs. The question of what to build, and in what order, becomes answerable.
Your Human API index is the number of steps in your highest-volume workflow where a person moves data from one screen to another with no decision in between. Most operations leaders who calculate this number for the first time find it higher than they expected — and the gap between that number and zero is where the recoverable time lives.
The case for structured external support at this stage is straightforward: deciding which fix applies to which Human API without overbuilding or displacing systems that still work requires a diagnostic discipline that takes longer to develop internally than it does to bring in. A Strategic Diagnostic Workshop maps this in four weeks: workflow by workflow, Human API by Human API, with a prioritised build list and a clear ROI case for each item.
The first items on that list — designed to deliver measurable return within six weeks — are how the work funds itself. The output feeds directly into the full delivery sequence: Workshop → Roadmap → Quick Wins → External CDO Partnership, each stage funded by the return from the last. The output is not a strategy document. It is a shorter list of things that used to take your people’s time.
The Human API problem has been accumulating in most operations since the second or third software system was added. It compounds with every new hire drafted in to bridge a gap that software should close. What has changed is that the tools to close these connections are now faster and more maintainable than the people currently bridging them.
For most mid-market service companies, eliminating the top three Human APIs is achievable within six to eight weeks. The recoverable time shows up in the following month’s operational numbers. Where to sequence that work — and how to connect it to a broader digital transformation strategy — is the question after the mapping is done. The question before it is simpler: how long do you want to keep paying people to do what software should.
