The Four Surfaces: Where Enterprise Work Actually Lives (and Why "Integration" Only Covers One of Them)
The systems that cost your business the most aren't getting an API — and every vendor's integration story quietly skips them.
On 4 April 2020, at his daily COVID briefing, the Governor of New Jersey asked for volunteers. Health-care workers, first. Then, in the same breath, anyone who could write COBOL — a programming language from 1959 — because the state's unemployment system ran on it, and the system was buckling.
More than 362,000 New Jersey residents had filed for unemployment in two weeks. The mainframes processing those claims were, in the governor's words, more than forty years old, and he said out loud what everyone was thinking: one of the post-mortems would be how the state had got to the point of needing COBOL programmers at all. Two days later, volunteers had come forward. Somebody had nicknamed him the COBOL King.
What that story shows is what the absence of a modern interface costs when volume arrives: a forty-year-old system, a governor asking strangers for help, and hundreds of thousands of claims still processed by people, typing. It doesn't show the system could never be modernised — states have spent years and fortunes trying since. It shows that in the week the claims arrived, none of that mattered. The work was on the wrong side of the door.
Every enterprise has a New Jersey — a legacy system with no API and no realistic path to one. The ERP module nobody will touch. The supplier portal with no export. The PDF that arrives by email at six and has to be re-keyed by nine. When a vendor tells you they integrate with your systems, the useful question isn't whether. It's which of your systems they mean — because in most back offices, the ones that cost the most money are the ones with no door.
Read the third one twice. It comes from an integration platform's own commissioned survey — the people selling the doors are the ones reporting that the doors aren't there. It is also the oldest figure here, December 2024, in a market that has turned over twice since. That is not a weakness in the number. It is the point: this has been true for a while, and buying more connectors has not moved it.
First, understand what "integration" actually means(and what an iPaaS connector can't reach)
An API — the door a system offers so other software can ask it for data — is a wonderful thing when it exists. Connector platforms, the products that plug one system into another, are built entirely on that door, and rest on three assumptions: the system has a door; the door opens onto the thing you actually need; and you're allowed to use it.
In a real back office, at least one of the three fails most of the time. The module has no door. The door doesn't reach that field. The licence doesn't cover it. The supplier isn't a system at all; it's a person with a spreadsheet.
And here is the distinction the whole piece turns on. The surfaces we're about to name aren't about whether a machine can reach something — email has a door, and so does nearly every modern application. They're about what the machine finds when it gets there. Through an API it finds data: structured, typed, ready to use. Through a screen, a document or an inbox it finds work — something a person would otherwise have to read, interpret and re-key before any data exists.
So the question isn't "can you integrate with our systems?" It's: on how many of our surfaces does the machine find data — and on how many does it find work?
So let's name them: the Four Surfaces
Think of the automation as a new employee. There are only four ways they ever get hold of information. They ask a system for it. They log in and look. They open a file. Or they read what came in the post.
When a machine gets there, does it find data — or does it find work?Data is the API surface. Work is the other three — and "integration" is the word vendors use for the first one.
API: the surface every demo runs on(where system integration already works)
This is the surface where automation has always worked. The ERP posts a journal, the CRM returns a customer record, the bank confirms a payment — machine to machine, no one watching. Nothing in this piece argues against it. If your process lives here, buy the connector and move on.
The catch is sizing, and the door is often narrower than it looks: the ERP has an API that creates a purchase order, but not one that reaches the approval screen where the order actually waits. A vendor's connector catalogue is a list of doors that already exist, not a map of where your work happens. In our experience, the processes that cost the most touch this surface least: they start in an inbox, pass through a document, and end on a screen, with the door somewhere in the middle for a single lookup.
Of your ten most expensive processes, how many touch a system with no usable door — and for the rest, where does the expensive step actually sit?
Screen: the swivel-chair economy(automating legacy systems with no API)
Picture the clerk with two monitors. On the left: the supplier portal, the customs system, the forty-year-old claims application. On the right: the ERP. The job is to move what's on the left into what's on the right, all day, without a mistake. Nobody designed that job. It exists because the system on the left has no door and the system on the right needs the data anyway.
New Jersey is this surface at state scale. When 362,000 claims arrived, the fix wasn't integration — there was nothing to integrate with. The fix was people, and then volunteers who could read the language the screens were written in.
At everyday scale it has been measured. In 2022, researchers writing in Harvard Business Review tracked 137 workers across three Fortune 500 companies for up to five weeks. They toggled between applications roughly 1,200 times a day and spent just under four hours a week reorienting after each switch — about 9% of their working time. It's one study and a small sample, but it's the swivel chair with a number on it, and nobody designed that either.
Screen automation earned its bad reputation here: the first generation of bots memorised exactly where each button sat, and broke the day a vendor update moved it — usually on a Monday morning with nobody watching. We'll come back to what changed.
When the screen changes, what breaks — and who finds out first: the automation, or the customer?
Document: the data is in there somewhere(intelligent document processing)
The invoice, the bill of lading, the KYC pack, the supplier's spreadsheet. The data exists; it's just inside something that has to be read first. And "read" here means what a person means by it: which layout is this, which page has the total, what is the stamp covering, does this line add up.
We've written about this surface at length in The Data-Readiness Myth. The short version: OCR was never the hard part, roughly a third of the documents a back office receives are the ugly kind, and the workflow that reads them is usually how the data gets fixed. If document intake is your bottleneck, read that piece first and come back.
Of the documents your process depends on, what happens to the ugly third?
Inbox: the front door nobody’s watching(email and shared-mailbox triage)
Most back-office work doesn't start in a system. It starts in a shared mailbox. Please find attached. Following up on the below. Can someone look at this. An attachment or three, a request buried in paragraph two, addressed to a mailbox four people share and none of them owns. Before anything can be automated, somebody has to decide what it is: which process, which customer, what's attached, whether it's urgent. That decision is the work, and it happens before any system is touched.
The IRS is this surface at national scale. In June 2022 the National Taxpayer Advocate reported 21.3 million unprocessed paper tax returns — with millions more, in the report's words, not yet classified — and eight-month backlogs in processing taxpayer correspondence. Not yet classified means the mail had arrived and nobody had yet decided what each piece was. The returns themselves were documents; deciding what each one was is inbox work. The processing backlog everyone talked about sat behind a triage backlog nobody could see.
Connector platforms can notice a new email. Screen bots can route it by a fixed rule, until the first email that doesn't fit. An AI assistant can summarise it. None of them hands the work into a process with a reason attached — and that handover is the whole surface.
What decides what an incoming email is — and whether it enters a process — before any downstream automation runs?
The table: iPaaS vs RPA vs AI assistants vs a unified stack
Here's how the four kinds of automation you'll be offered cover the four surfaces. Plain names in the headers; the trade terms in small print.
Read it across: connector platforms answer one row, and they answer it well. Read it down: the only column that reaches all four is the last one — and that's the column we sell, so treat it as a claim to be tested, not a fact to be read. The next two sections exist to earn it.
The twist, though, is in the first column. Deploying more connectors solves the surface where the machine already finds data. It does nothing for the three where it finds work — and that's where the clerk with two monitors spends the day.
Five objections
"Our ERP vendor is shipping APIs next year."
Some will. The long tail — the forty-year-old claims system, the customs portal, the supplier who emails a spreadsheet — won't, and the long tail is where the cost is. The same goes for replacing the system: it takes years, and on day one of the new one the process still starts in an inbox. Wait for the door and you're waiting for the cheapest part of the problem to solve itself.
"Screen automation is brittle."
It was. What changed is that the automation now finds the button again: it captures what an element is at design time, not just where it was, and looks for it again at run time. When it can't, it says so, with a reason, instead of failing silently. How that works is in the engineers' paragraph below; whether it works on your screens is what the inventory at the end is for.
"Isn't this just RPA?"
Partly — and we've built a great deal of it. RPA reached three of the four surfaces, with three separate toolkits, and broke whenever a surface changed. The difference isn't reach. It's whether a changed screen, a new layout or an unexpected email is a harder case or a broken bot — and whether one workflow covers all four surfaces, or four tools with four owners do.
"Isn't this just hyperautomation with new labels?"
The four-way split isn't new, and we're not claiming it is. Gartner named this convergence years ago — connector platforms plus screen automation plus document processing plus communications mining — and several vendors now sell a suite that ticks all four boxes. The argument isn't about the taxonomy. It's about the seam. A suite assembled from four products is usually four runtimes, four sets of credentials, four audit trails and four teams, and a process that crosses surfaces breaks at every handover — quietly, because no single tool owns the whole path. One workflow, one owner and one log is a different claim from one vendor, four logos. Ask whoever is selling you the suite which of the two they mean.
"If it can reach all four surfaces, it can reach everything."
Reach and rights aren't the same thing. Being able to read a screen says nothing about where that data then goes, who else can retrieve it, or what the automation is allowed to do with it. Those are four separate questions, and we answered them in a separate piece because they deserve one: The Four Exits.
How AutomatR covers all four
We built the platform around a single fact: most processes don't live on one surface. A customs filing starts in an inbox, passes through documents, needs one lookup through a door, and ends on a government portal's screen. If four tools cover those four steps, four teams own the process, and it breaks at every handover.
A screen element is captured at design time as a set of properties — its label, its role, its position relative to its neighbours — rather than a single fixed path. At run time the engine resolves those properties against the live page and picks the best match; when no candidate clears the threshold, the step raises an exception with the candidates and their scores attached instead of clicking the wrong thing. That is the part worth comparing across vendors: property-based matching is a decade old and everyone has some version of it, but most heal silently — and a silent heal on a payment screen is worse than a clean break. Here a healed resolution is logged as a change, before and after, so it is auditable and reversible. Inbox items enter through a queue: each message is classified against the processes the workflow knows, its attachments are routed to document extraction, and the item carries its classification, confidence and reason into the workflow. The AI designs the workflow; a deterministic engine runs it — which is why a healed step and a triaged email both leave a trail.
The process we know best crosses all four surfaces in production: customs documentation for importers — arriving by email, read from the shipment pack, checked against master data through a door, and filed on the government portal's screen. One workflow, one owner.We're not going to quote you a percentage for it. Ask us in a demo for the three numbers that actually describe a cross-surface deployment — how long it has run, what it handles in a month, and how many times a surface changed underneath it without the work stopping — and we'll give you ours. Ask every other vendor the same three. Notice how many answer with a percentage instead.
Two to three weeks to live on the first process is what we quote — and by the standard we just set, that's our number, not a verified one. Ask us whether we hit it on the last three, and ask the same of anyone else quoting you a timeline. The part that isn't a claim is why it's weeks rather than a replatforming programme: nothing has to be replaced for the workflow to reach the surface.
The Integration Inventory
Take a sheet with four columns — API, Screen, Document, Inbox — and list your ten most expensive processes down the side. For each one, tick every surface it touches. Then look at three things.
- 01How many processes tick more than one columnMost do. That’s the number of processes a single-surface tool can’t finish.
- 02How empty the API column isThis is the surface your integration story covers. Count how much of the sheet it leaves out.
- 03Where the expensive step actually sitsCircle it for each process. It’s rarely in the API column.
For the steps you circled, ask the four questions from the surface sections above — they tell you what a vendor has to prove. Then take the sheet to any vendor, including us. If their answer to all ten is "we have a connector for that," they've read one column of your sheet.
Fill it in, send it back through automatr.tech/contact, and we'll come back with which of the ten we'd start with, and why.
New Jersey's answer, in April 2020, was to ask strangers to learn a language from 1959.
Of your ten most expensive processes, how many run on a system that will ever have a door?
Further reading: going deeper on the four surfaces
- →The Integration Inventory — one-page worksheet (PDF)automatr.tech/blog/four-surfaces-integration-inventory.pdf
- →The Four Exits — where the data goes once the automation can reach it: control, not reachautomatr.tech/blog/four-exits-agent-data-leaks
- →The Data-Readiness Myth — the Document surface, in depthautomatr.tech/blog/data-readiness-myth
- →AI Agents Have a Meter Runningautomatr.tech/blog/ai-agent-token-economics
- →Deloitte, "AI Agents are Only the Beginning" (Aug 2026)deloitte.com/us/en/about/press-room
- →National Taxpayer Advocate, mid-year report to Congress (June 2022)irs.gov/newsroom
- →Harvard Business Review, "How Much Time and Energy Do We Waste Toggling Between Applications?" (Aug 2022)hbr.org
- →The Register, "COBOL-coding volunteers sought…" (April 2020)theregister.com
