Why your tools don't talk to each other
You bought six good products and got one bad system. The reason is arithmetic, not incompetence — and it is the single strongest argument for routing everything through one hub.
You bought six good products and ended up with one bad system. The scheduler does not know what the invoicing software knows. The inbox does not know either. Somewhere in the middle is a person retyping the same customer’s address for the third time this week.
This is not a failure of judgement about software. Every one of those purchases was probably correct on its own terms. The problem is arithmetic, and it gets worse in a shape most owners do not expect.
Connections grow faster than tools.
Wire tools directly to one another and the number of connections you need is not the number of tools. It is every pair: n × (n − 1) ÷ 2.
Four tools need six connections — annoying but survivable. Eight tools need twenty-eight. You did not double the complexity by doubling the tools, you roughly quintupled it. Route everything through one hub instead and the count is simply n: eight tools, eight connections.
Move the slider and watch the difference stop being theoretical.
6 tools, 15 connections. Add a tool, add 6 more lines.
Count the ones that hold customer data. Most owners land between five and nine.
Your data is the thing keeping you subscribed.
Software companies know that the cost of leaving is not the monthly fee — it is the three years of customer history trapped inside. A product that makes it trivial to move that history somewhere else has weakened the main reason you renew.
So the friction is frequently deliberate, and it shows up in a consistent hierarchy. Learning to read it takes about five minutes and tells you more about your options than any sales call:
- A public, documented API. The vendor has decided that being connectable makes them more valuable than being sticky. This is a genuinely good sign about the company, not just the integration.
- An “integrations” page and nothing else. They connect to the partners they chose. If your combination is not on the list, it does not exist, and no amount of asking changes that.
- A CSV export and a shrug. Common in older trade-specific software. Workable, but it means a human or a scheduled job is doing the moving, and it will never be live.
- Nothing. The data is visible on a screen and reachable no other way. Be very suspicious of anyone who offers to solve this with a robot that reads the screen for you.
An integration is not a thing you build. It is a subscription to somebody else’s decisions about their API.
Build is the small number.
Integrations are quoted as projects and behave like commitments. The build is the part you can see; the part that actually costs is that the other end keeps changing — fields get renamed, endpoints get versioned, authentication gets tightened, and none of it is announced to you in a way you will notice before it breaks.
Which produces the rule that matters: every connection you add is a permanent maintenance obligation, not a one-time cost. Six integrations is not six builds. It is six things that can break on a Tuesday for reasons that have nothing to do with you.
This is the real argument for a hub, and it is not an aesthetic one. Twenty-eight connections is not five times the maintenance of six — it is five times the surface area on which somebody else’s change can take your morning.
A system of record, not another app.
“Centralise everything” usually gets heard as “replace everything with one enormous product,” which is both expensive and a good way to end up with software that does nine jobs adequately and none of them well.
That is not what a hub is. A hub is a decision about authority:
- One place holds the customer record. When the phone number is wrong, there is exactly one place to fix it, and everything else learns about the fix.
- Everything else syncs to that. Your scheduler keeps scheduling. Your accounting keeps accounting. They stop being the thing you consult to find out who someone is.
- Disagreements have an answer. When two systems hold different addresses, you are not adjudicating — you already know which one wins.
The practical test: if a customer changes their phone number, how many places do you have to type it? If the answer is more than one, you do not have a hub, and no amount of new software will give you one until that question has an answer.
Sometimes the answer is to replace it, or to leave it alone.
Some tools genuinely cannot be connected. Older industry-specific software often has no API, no export worth the name, and no intention of adding either. Nobody can fix that with cleverness, and the fixes that look clever are the ones that hurt.
Two honest options, and one to refuse:
- Replace it — worth costing out properly, including the migration and the retraining, but only if the tool is not otherwise excellent at the job you bought it for.
- Leave it manual and bound it — accept a scheduled export, keep the typing to one predictable window a week, and stop paying to solve it. This is a legitimate answer and it is chosen far less often than it should be.
- Do not build a scraper. A robot that logs in and reads the screen works in the demo and breaks the first time the vendor moves a button — silently, and usually in a way that produces wrong data rather than no data. Wrong data is considerably more expensive than retyping.
Working out which of these applies to your particular stack is most of what a proper scope is for. It is also why the answer sometimes comes back as this one is not worth connecting — which is a result, not a failure.
- Point-to-point integrations grow as n×(n−1)÷2. Eight tools need twenty-eight connections; through a hub they need eight.
- Vendor friction is often deliberate — your trapped history is what makes leaving expensive, so being connectable works against them.
- Read the hierarchy: a documented public API, a fixed integrations list, a CSV export, or nothing. It tells you your real options in five minutes.
- An integration is a permanent maintenance obligation, not a one-time build. The other end keeps changing without telling you.
- A hub is a system of record, not a mega-app. The test: if a customer changes their phone number, how many places do you type it?
- Some tools cannot be connected. Replacing or bounding the manual work are both legitimate. Screen-scraping is not — it fails silently and produces wrong data.
Want this looked at properly, on your own numbers?
We scope the business first and tell you what is worth automating — including when the answer is that it isn’t.
What a missed call actually costs
Most service businesses lose more revenue to an unanswered phone than to anything on their price list — and almost none …
AIWhat AI can't do for your business
Everyone selling automation has an incentive to tell you everything is automatable. It isn’t. Here is the four-question …