The Real Cost of Human Middleware
- Count four costs, not one: hours, decision lag, reconciliation error, experiments never run.
- Salary hours is the smallest line and the only one most business cases contain.
- Measure decision lag as the gap between a question and an answer the room will act on.
- Price reconciliation errors by the action taken, not by the cost of the correction.
- Value unrun experiments with your own win rate and uplift, never an industry figure.
- Present four separate lines with no total, so a doubted line can be discounted.
Last updated: October 2026
Every business case I have seen for the cost of human middleware prices it the same way: hours multiplied by salary. That number is real, it is easy to defend, and it is the smallest of the four costs involved. It is also the one most likely to get the proposal declined, because a figure that looks like a few days of somebody's month is not a figure anybody reorganises around. Omniconvert has run 70,000+ experiments across 2,500+ Shopify stores over 13 years in eCommerce, and in that time the pattern has been consistent: teams can describe the problem precisely and cannot price it.
The framework itself, what human middleware is and how a stack produces it, is set out in The Human Middleware Problem. This piece is about the arithmetic.
Why the usual number is too small
Start with the structure of the error rather than with the numbers. Hours are easy to count because they are visible and because somebody is paid for them. The three costs that follow are invisible precisely because nothing in the business records a decision that did not happen.
eCommerce managers spend roughly three hours a day assembling data [CROBenchmark Report 2026, Omniconvert]. Priced as salary, in a team of six, that is a meaningful but survivable annual figure, and it is the figure that usually gets presented. Priced as capacity, it is most of a working week per person diverted from the work the person was hired to do.
The difference between those two framings is the whole argument. One is a cost line. The other is a constraint on how fast the business can learn, and constraints are what finance teams reorganise around.
The Middleware Ledger
| Line | How to measure it | Why it is usually missing |
|---|---|---|
| Assembly hours | Two weeks of honest time recording | It is not; this is the one line everybody has |
| Decision lag | Question asked to answer accepted | Spread across several calendars |
| Reconciliation error | Decisions taken on figures later corrected | Recorded as a correction, not a cost |
| Experiments never run | Planned minus started, at your own win rate | Nothing records a test that did not happen |
Run all four for the same fortnight so the lines describe one period rather than four anecdotes. The exercise costs a few minutes a day from each person involved and produces a number that survives contact with a sceptical reader, which the salary calculation generally does not.
Decision lag is the line that sets your pace
Measure it directly. When somebody asks a question in a meeting, note the date. When a decision is taken on the answer, note that date too. The interval includes the data pull, the reconciliation, the second pull because the first disagreed, and the wait for the person who owns the join to come back from leave.
That interval is what determines how many decisions a quarter can hold. A team with a three-day lag can run a loop a week. A team with a two-week lag runs six loops a year and spends the rest of the time explaining why the last one is still being verified. The questions that wait longest tend to be the ones that need a join across systems, which is why anything resting on cohort analysis sits at the back of the queue.
It is also the line that makes the problem legible to people outside the growth team. A finance director who shrugs at assembly hours will not shrug at a quarter that can only hold six decisions, particularly where retention work is involved: a 5% retention lift can raise profits by 25 to 95%, a finding popularised in Harvard Business Review crediting Bain's Reichheld [Harvard Business Review, 2014], and retention decisions are exactly the ones that wait longest for reconciled data. The same argument applied to budget allocation is in how retention and acquisition should share a budget, where the faster-reporting side wins by default.
Reconciliation error, priced by the action rather than the correction
Data reconciliation is defined as the manual work of making two systems that disagree produce one figure a team is willing to act on, and the error in question is not arithmetic. It is the decision taken in the window before anybody noticed.
List the last two quarters. For each decision taken on a figure later found to be wrong, write down what was actually done: budget moved, a campaign paused, stock ordered, a test called early. Then price that action rather than the correction. The correction took an afternoon; the action ran for six weeks.
The decisions most exposed to this are the ones assembled from several systems at once, which in practice means anything built on customer retention metrics. Repeat rate, cohort revenue and churn all require a join, and a join done by hand under deadline is where two defensible figures become one wrong one.
Teams resist this line because it reads as blame. It is not. A figure assembled by hand from several systems under time pressure will sometimes be wrong, and that is a property of the arrangement rather than of the person. Pricing it is how you argue for changing the arrangement.
The experiments never run, which is usually the largest line
This is the line that changes the conversation, and it is the only one denominated in growth rather than in expense. Nothing in a business records a test that did not happen, so it has to be reconstructed from the plan.
Use your own numbers rather than anybody else's. Omniconvert Explore averages a 23.2% conversion uplift across 70,000+ experiments, and that figure is useful context and not your figure. Your win rate and your average uplift, taken from your own last two years, produce an estimate a finance team can check.
The arithmetic is deliberately conservative: planned tests minus started tests, multiplied by your win rate, multiplied by your average uplift, applied to the traffic the test would have run on. Every step rounds down. It still tends to produce the largest number on the page, which tells you something about where the cost of manual work actually lands. The underlying argument for why the testing loop is the engine is in why experiments beat opinions.
Most teams that try to cost this stop after the hours line, because the other three need somebody to admit something uncomfortable in front of colleagues: that a decision was taken on a wrong number, or that a test was planned and quietly dropped. Run the exercise as a measurement of the arrangement rather than of the people, and say so explicitly before you start, or the three lines that matter will come back empty.
AliveCor used Omniconvert to run a structured A/B testing programme and achieved +21% conversion rate, +5% revenue per visitor, and 94% statistical relevance across their experiments. [Omniconvert, AliveCor case study] The relevant part here is the third figure. A programme that reaches statistical relevance is one that ran enough tests to resolve them, and test throughput is exactly what the middleware line is consuming.
Present four lines, with no total
This is a presentation choice and it decides whether the work lands. Totalling the four produces a large, satisfying figure that a finance team will test by attacking the softest input, usually the unrun experiments, and a successful attack discredits the whole number.
Four separate lines behave differently. Each one is defended on its own method. A reader who distrusts the experiment estimate can strike it out and is still left with hours, lag and error, which is normally enough to justify the change on its own.
State the method under each line in one sentence, and state what you rounded down. Conservatism that is visible is worth more than precision that is asserted, particularly for a number that nobody else in the business has ever tried to produce.
What the ledger argues for, in the end, is removing the assembly step rather than scheduling it better. Omniconvert Commander (formerly Nexus) is an AI for eCommerce growth engine that unifies commerce data, prioritises experiments by True Profit, and generates campaigns and creative you approve before they go live. The point is not the tooling: it is that three of the four lines in this ledger exist only because a person is standing between two systems that should be talking to each other.
FAQ: the cost of human middleware
Four costs, of which salary hours is the smallest. The other three are decision lag, which limits how many decisions a quarter can hold, reconciliation error, which prices the decisions taken on figures that turned out to be wrong, and the experiments never run, which is usually the largest line and the one nobody records.
Because it is bounded by the number of hours in a week and the other three are not. Time spent assembling data costs a known amount once. A decision delayed by three days, taken on a wrong figure, or never taken at all compounds through everything that depended on it.
Time the gap between a question being asked and an answer the room is willing to act on. Not the gap to the first chart. Teams are usually shocked by the result, because the assembly work is visible and the waiting is distributed across several people's calendars.
It is the only honest way to cost a constraint. If your team planned twelve tests and ran five, the seven are not an aspiration, they are capacity consumed by something else. Multiply by your own historical win rate and average uplift rather than by an industry figure and the number is defensible.
Reporting addresses the presentation and leaves the assembly in place. A new dashboard built on the same manual joins moves the work earlier in the week rather than removing it. What removes it is a single source the whole team reads, which is an architecture decision rather than a reporting one.
Four separate lines, each with its own method stated, and no total. A total invites an argument about the weakest line. Four lines, each defensible on its own, lets the reader discount the one they doubt and still arrive at a number large enough to act on.
Pick one fortnight and record four things: the hours your team spends assembling data before any decision is discussed, the gap between each question asked and the answer the room accepted, every decision taken on a figure later corrected, and every test that was planned and not started. Four columns, two weeks, no tooling.
Then present them as four lines with their methods stated and no total. The hours line will be the one everybody expected and the smallest. The unrun experiments line will be the one that changes the conversation, because it is the only one denominated in growth rather than in cost.
Cost the constraint, not the salary
Run the four-line ledger for one fortnight and present the lines separately, with no total.