Every small business ends up with the same client in four systems, and after a year they disagree. Connecting everything to everything is how that gets worse rather than better.
Every small business ends up with the same information in several systems. The client name is in the CRM, the accounting package, the project tool and a spreadsheet, and after a year they disagree.
The usual response is to connect everything to everything. That is where this goes wrong.
Ownership before integration
Most sync problems are ownership problems in disguise. If two systems can both write the same field, no integration design will save you, because you have built a race and last-write-wins is not a resolution strategy, it is a coin toss.
The fix is unglamorous and it happens on paper: decide which single system owns each field, and make every other system read-only for it. The CRM owns the client name. Accounting owns billing details. The project tool owns delivery status. Once that is written down, most of the integration becomes trivial.
You do not need two-way sync nearly as often as you think. You need one writer and several readers.
How to build it
1. Write the ownership table first
Every shared field, one owning system, a list of readers. This takes an hour with a whiteboard and it removes most of the difficulty from everything that follows. It is also the artefact that survives whoever built the integration.
2. Sync one direction wherever possible
One-way sync has no conflicts, no loops and no ambiguity about which value is correct. Reach for two-way only where a genuine business process requires editing in both places, which is rarer than it appears.
3. Prevent echo loops explicitly
Mark changes made by the integration itself and ignore them on the return trip. Without this, a change in one system triggers a change in another which triggers the first again, consuming quota and rewriting records all day while reporting success.
4. Use a stable identifier, never a name
Match on a system identifier or a shared reference. Matching on a client name breaks the first time somebody fixes a typo, and the resulting duplicate is worse than the typo was.
5. Decide what happens on conflict, and log it
Where two-way sync is genuinely needed, define which side wins and log every conflict resolved. A silent overwrite of somebody work is how people stop trusting the whole arrangement.
6. Reconcile on a schedule, separately from syncing
A weekly job that compares systems and reports differences. Sync handles the flow; reconciliation catches what the sync missed, and it will miss things.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Native integrations between your existing tools | Usually included. | Maintained by the vendors, which matters when an API changes. Field mapping is often shallow and rarely configurable enough. |
| Connector platform (Zapier, Make, n8n) | Per task, operation or execution. Sync fires on every record change, so volume is high by nature. | Fast to build and it handles authentication for you. The pricing model works against continuous sync specifically. |
| Apps Script or a small service against both APIs | Free with Google Workspace. | Full control of ownership rules, loop prevention and conflict logging. You maintain it when an API changes. |
| A scheduled export into one reporting layer | Free to low cost. | Often the right answer. If systems only need to agree for reporting, you may not need sync at all. |
What it is actually worth
The honest framing is that this automation prevents a cost rather than creating a saving. The cost is decisions made on wrong data, time spent working out which system is right, and the private spreadsheets people keep once they stop trusting the shared ones.
Your own measure: pick thirty records and compare them across systems. The share that disagree is your current data integrity, it takes an hour, and it is usually worse than anyone expects.
Consider whether you need sync at all. If systems only need to agree for reporting purposes, a scheduled export into one reporting layer is simpler, cheaper and cannot loop. Genuine bidirectional sync is a real engineering commitment and is frequently built where a nightly export would have been sufficient.
How it breaks
Echo loops. The classic, and it looks like success while it happens. Mark integration-originated changes.
Matching on a mutable field. Names, emails and addresses all change. Match on identifiers.
Silent failures. A sync that stops leaves two systems drifting apart with no signal. A heartbeat that confirms the job ran, plus the weekly reconciliation, is the defence.
The ownership table is never written. Everything else in this article assumes it exists. Without it you are guessing, and so is the integration.
How to tell whether it worked
Records that disagree across systems, sampled monthly, target near zero. Conflicts logged per week, which should be small and if it is not, your ownership model is wrong. And the number of private spreadsheets people maintain, which is the honest measure of whether the shared data is trusted.