The Human Integration: When a Person Is the API

There is a role that exists in thousands of mid-sized businesses and has no standard name.

The person reads something in one system and types it into another. They watch an inbox and move things somewhere. They export a report and reformat it for someone else. They notice when two records disagree and fix the one they believe.

On the org chart they are an assistant, a coordinator, an ops person, an admin. Functionally, they are an integration layer. The business bought two pieces of software that don't talk, and hired a human to sit between them.

How to recognise it

The tell is in the job description. Read one for the verbs:

*"...transferring information between platforms, updating records, maintaining spreadsheets, ensuring data is accurate across systems, following up on outstanding items..."*

Every one of those verbs describes moving data, not deciding anything. That is a posting for middleware.

Contrast it with a role that genuinely needs a person, which reads differently — *handles client questions, resolves disputes, prioritises, judges whether something is ready.* Those verbs are decisions.

Most real jobs are a mix. The question is the ratio, and in a surprising number of cases it's 80/20 the wrong way.

Why it persists

It is not stupidity. It is that the human integration works immediately, requires no procurement, and costs a salary that comes out of a budget line nobody questions.

It also degrades invisibly. The person gets good at it. They build shortcuts, memorise exception cases, develop a feel for when something looks wrong. The business stops seeing the cost because the friction has been absorbed by someone competent.

Then they leave, and everyone discovers simultaneously how much undocumented work was holding the middle together.

What it actually costs

Take the fully loaded cost of the person, then multiply the fraction of their week spent moving data rather than deciding things. In the cases we have mapped, that fraction runs between 40% and 70% for roles that were hired as coordinators.

Then add the part nobody budgets: the error rate. Human transcription between systems runs 1–4%, and unlike software, humans make errors that look plausible.

The right response is usually not "automate the person away"

This is where most automation advice goes wrong, and it's why the resulting projects fail.

The goal is not to eliminate the role. It is to give the role back its judgement. The same person, freed from being the API, is usually the best person in the building to own the process — because they are the only one who understands every exception.

In practice the sequence is:

1. Connect the two systems for the 80% that is pure transfer
2. Route the exceptions to the person who already knows how to handle them
3. Let them spend the recovered time on the work that needed a human all along

Nobody loses their job. The job stops being beneath them.

When to leave it alone

If the volume is low, the systems are stable, and the person is content — leave it. Integration is not free to build or maintain, and a working manual process beats a fragile automated one every time.

Act when the volume is climbing, when the role has turned over, when errors are reaching customers, or when the person doing it is the only one who knows how.

That last one is not an efficiency problem. It's a continuity problem, and it gets more expensive the longer you wait.

Is someone on your team the integration between two systems? Tell us what's getting in the way →