When your systems do not talk to each other
The fix is a decision before it is a purchase. Which system is right when two of them disagree, and who is allowed to change it.
In short
Systems that do not talk are rarely missing a connector. They are missing a decision about which one is right. Name one owner for each record, count the hours going into moving data by hand, connect only the two or three handoffs where work actually stops and waits for a person, and monitor every connection so a silent failure is seen by you rather than by a customer. Buying an integration platform before making that decision buys a faster version of the same disagreement.
What we take on
Name the owner first
One system owns each record and everything else reads from it. Until that is decided, every connection you build is a way for two systems to argue with each other more quickly.
Count the retyping in hours
How many times one customer or job is entered by hand, by whom, and how long it takes. Two weeks of tallying is enough. Without this number there is no way to tell whether any of it was worth doing.
Connect handoffs, not systems
The places where work stops and waits for a person to move it. That is usually two or three points, not twenty. Wiring everything to everything is how these projects stop having an end.
Assume it will break
Every connection fails eventually. What separates a good build from a bad one is whether it says so, retries what is safe, and holds what is not. A sync that fails silently is worse than no sync, because people stop checking.
The order, and why it is this order
Start with the decision, because everything after it depends on the answer. Two systems holding the same customer will eventually disagree, and at that moment somebody has to know which one to believe. Naming that system takes an afternoon. It is also the step almost everybody skips, because it means telling somebody their tool is now the secondary copy, and that is a conversation rather than a configuration.
Then measure, before buying. The point of counting the retyping is not the total, it is the distribution: it is nearly always concentrated in one or two handoffs while feeling like it is everywhere. A fortnight of tallying tends to move the plan considerably, and it costs nothing but attention.
Then connect, and only the handoffs that measurement pointed at. The temptation is to do all of it while somebody technical is in the room, and that is exactly how a three week job turns into a permanent one. Two connections, finished and monitored, beat nine half built ones, and the second should not start until the first has run untouched for a fortnight.
Then remove the manual step the connection replaced. This gets forgotten remarkably often, and the result is a team doing the old job alongside the new system because nobody told them to stop. The saving only exists at the point somebody stops doing the thing. Write down what changed and who owns it, because a fix living in one head leaves when that person does.
If you would rather not run this yourself, we do it end to end, and the calculator on that page turns your team size and system count into what the retyping is costing you a year before anybody commits to anything.
Questions we get
Do I need something like Zapier or Make?
Often, and not always. For a handful of connections between mainstream tools they are the right answer and the cheapest one.
What they cannot do is decide which system is right, and that is the part that actually blocks people. Buying one before making that decision gets you the same argument at a higher frequency.
What if two systems both genuinely need to change the same field?
Then one of them still owns it, and the other gets a way to request the change rather than make it.
Two way sync on the same field is the source of most integration horror stories. It is possible, it is expensive to get right, and in a small business it is almost never worth it compared with picking a direction.
How do I know which system should be the owner?
Watch what people already trust. If everyone quietly checks the spreadsheet before believing the CRM, the spreadsheet is already the source of truth.
The honest move is either to make that official or to fix whatever made the CRM untrusted. Declaring a winner that nobody believes in changes nothing except where the arguments happen.
Our data is already inconsistent. Do we clean it first?
Clean only what the connection touches, and only once the owner is named. Cleaning everything first is a project that never finishes.
Expect the exercise to surface real disagreements about what a field means, which customer counts as active, when a job is finished. Those are worth settling and they are not really data problems.
Is a nightly export good enough?
Frequently, yes. Ask what decision is being made with the data and how stale it can be before that decision goes wrong.
Plenty of reporting is fine on yesterday. Anything a customer sees, or that decides whether somebody gets dispatched, is not. Real time everywhere is the most expensive default available.
How do I stop this running forever?
Scope it as a number of connections rather than as a state of being connected. Two, named, with a definition of finished for each.
Every integration project that never ends was scoped as the second kind. There is always another system, so the only way it stops is if stopping was in the plan.
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