Systems that pass work to each other, not to a person
Most teams are not short of software. They are short of connections between it, and the missing connections are being covered by somebody retyping.
How many people is your structure spending on moving information?
Five answers. It returns the share of the week a system could be holding, in people rather than hours.
How many people does this cover?
The team whose week you are thinking about, not the whole company.
How much of their week is routine?
Work that follows the same steps every time, where a checklist would do.
How many systems hold the same record?
Count the places one customer or job exists. Spreadsheets and inboxes count.
Is there one system everyone treats as the truth?
Not the one that should be. The one people actually check.
What does one person cost a year, all in?
Salary plus everything on top. A rough number is fine.
The answer
Answer the five
What it costs a year
—
Do this next
Show the numbers
Before anything gets bought
Want someone to look at where the information actually stops?
Send the numbers over and you get back which record needs an owner first, which two connections are worth building, and which of your systems is quietly already the source of truth.
Goes to one inbox.
In short
When systems do not talk, a person becomes the integration. That job has no title, appears in no budget, and is usually the most expensive thing a small team does. The fix is not more software. It is deciding which system owns each record, connecting only the two or three places where work actually stops, and removing the retyping that was holding it together. The shape of the team changes after that, not before.
What we take on
One owner per record
Every customer, job and invoice gets exactly one system that owns it, and everything else reads from that. Most arguments about whose number is right are two systems both being right about different things.
Only the connections that matter
Not everything wired to everything, which is how integration projects become permanent. The two or three handoffs where work stops and waits for a person, connected properly, with a monitor so a silent failure is seen by you rather than by a customer.
The retyping goes
Re-entry is the tax and it is invisible because it is spread across everyone. We count it in hours a week before touching anything, remove it, then show what came back and where it went.
What the roles become
When the routine work sits with the systems, the jobs change shape. Deciding what people do next is the part most projects skip, and it is the part that decides whether the saving is real or whether the work quietly reappears somewhere else.
The person who is the integration
Every growing company has one. They know the deal in the CRM has to be typed into the accounting system by Thursday, and that the date in the spreadsheet is the real one whatever the software says. None of it is written down because none of it needs to be while they are there. They are not slow. They are load bearing, and the business finds out how much only when they take two weeks off.
Software companies sell this as an integration problem, which makes it sound like something you buy. It is a decision problem first. Two systems holding the same customer will disagree eventually, and the only fix that lasts is naming which one is right and making the other read from it. That decision takes an afternoon. It is also the one nobody makes, because it means somebody has to accept that their tool is now the secondary copy.
Then the connections, and only some of them. Wiring everything to everything is how a project stops having an end. What matters is the small number of places where work actually stops and waits for a person to move it, connected properly and monitored, so that when a sync fails at two in the morning somebody knows before the customer does. Everything else can stay manual, and a fair amount of it should.
The structure question comes last, and it is the one being asked most at the moment: what shape is a team when the routine work is held by the systems? The honest answer is that headcount rarely drops. Capacity rises instead. The same people absorb the work that was queued behind them, and the roles that were mostly re-entry become the roles that are mostly judgment. Plans built on the other assumption tend to lose the people who knew how the place actually ran.
Questions we get
Do we have to replace our systems?
Usually the opposite. Most companies already own more capability than they use, and the gap is between the tools rather than inside them.
Replacing software is the most expensive way to answer a question you have not asked yet. The first pass is always what you have, what it already does, and what is being done by hand between the pieces.
How do you decide which system owns a record?
Whichever one the work naturally starts in, and whichever one people already trust when the two disagree.
It is less about features than about habit. If everyone quietly checks the spreadsheet before believing the CRM, the spreadsheet is already the source of truth and the honest move is either to make that official or to fix why the CRM is not trusted.
What about all the spreadsheets?
Some of them are the problem and some of them are the documentation. Worth telling apart before deleting anything.
A spreadsheet that exists because a system cannot do something is a requirement written in the only language available at the time. It usually describes the fix better than any specification would.
How long before anything changes?
The measurement takes about two weeks and produces numbers you can act on with or without us. The first connection usually follows within a few weeks of that.
Anyone quoting a date before seeing how the work actually moves is quoting a guess. The sequence matters more than the speed: measure, decide the owner, connect, then remove the manual step, in that order.
Does this mean fewer people?
Rarely, and we do not sell it that way.
What changes is what the same people spend the week on. A team absorbing its own backlog is worth more than a smaller team doing the same amount, and it is a great deal easier to live with. If headcount reduction is the goal, that is a different conversation and it should be had openly rather than dressed up as a technology project.
What happens when an integration breaks?
It will, and the difference between a good build and a bad one is entirely in what happens next.
Every connection we build reports when it fails, retries what is safe to retry, and holds what is not so nothing is lost silently. A sync that fails quietly is worse than no sync, because people stop checking.
More in the guides and every answer in one place.
Shaheer Shaikh, operations lead at LARVOL, a San Francisco AI company working with global pharma on clinical trial data and model benchmarking. Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. More about the firm