The five-tools-and-four-spreadsheets problem comes from normal growth, not bad decisions. Solving it does not mean moving everything to one platform. It means deciding which tool owns each type of information and connecting the rest around it.
Almost every small or medium business ends up in roughly the same place after a few years of SaaS adoption. There are five or six tools running in parallel, four spreadsheets stitching them together, a Line group for anything urgent, and a folder called Final_v3. The information is in there somewhere. Nothing moves between systems unless someone on the team does the moving by hand.
This is not a sign of bad decisions. It is the natural consequence of organic tool adoption, which is how most SMEs end up here. The fix is not “rip everything out and standardize on one platform”. It is integration, designed properly.
The problem is real and it is structural
Each tool was added for a good reason. The CRM was added because the spreadsheet pipeline was not working. The email tool was added because the CRM’s built-in email was weak. The booking platform was added because direct booking was leaking revenue to OTAs. The accounting system was added because the bookkeeper insisted. Each individual decision was sound. The aggregate result is that no two of these tools share the same picture of who a customer is, what they have bought, or what they need next.
The cost of this is invisible until you measure it. Most teams spend somewhere between five and fifteen percent of their time on the work of keeping tools in sync: copying customer details, reconciling reports, and chasing down the version of the truth that is closest to right. That time is not on anyone’s calendar as “integration work”, which is why it is invisible. Add it up over a year and the number is almost always meaningful.
Source of truth comes first
Before integrating anything, decide which tool is the source of truth for each key piece of information.
Customer records: probably the CRM. Bookings: probably the booking platform. Financials: definitely the accounting system. Inventory: whichever tool actually tracks it. Marketing audiences: probably the email platform, but check.
Designating a source of truth does not mean other tools never have that information. It means that when there is a conflict, one specific tool wins. Customer records can live in the email tool too, but the CRM’s version is the one that gets believed and synced everywhere else.
This decision is mostly social. The technical side is trivial. The hard part is getting agreement from the people who use each tool that the version of reality they prefer is not always the one that wins.
How APIs and webhooks actually work
Once the source of truth is settled, the question becomes how to keep everything else in sync with it. Two mechanisms do most of the work.
APIs let you ask a tool for data. “Give me all customers updated in the last hour” or “tell me everything about customer 12345”. You poll the source of truth on a schedule and update the other tools to match. This is straightforward to build and easy to debug, but it has a built-in latency: the other tools are always slightly behind.
Webhooks let a tool tell you when something changes. The source of truth pings you the moment customer 12345 updates, and you push that update everywhere else immediately. This is faster but more brittle: webhooks fail silently sometimes, and recovering from missed events takes care.
Most production integrations use both. Webhooks for real-time updates, scheduled API polls as a safety net to catch anything the webhooks missed.
When to centralize and when not to
There is a temptation, once you start integrating, to centralize everything into one mega-platform. This is rarely the right move. The mega-platform charges a premium for the breadth, gets updated more slowly than the specialists, and creates a single point of failure that affects every part of the business at once.
The better pattern is what Big Tech calls “best of breed plus integration”. Each specialist tool handles its domain well. Integration keeps them in sync. The cost is usually lower, the flexibility is higher, and switching one tool out for a better one is a project rather than a catastrophe.
Centralization is the right answer when the integration overhead exceeds the cost of moving to a single platform. This crossover is real, but it usually only matters at the higher end of the SME range, when you have ten or twelve tools and the integration burden is dominating the engineering work. Below that, integration is cheaper.
What good integration looks like in practice
A reasonable end state for an SME’s stack looks something like this. The CRM is the source of truth for customers. The booking platform writes back to the CRM whenever something happens. The email tool pulls audiences from the CRM nightly. The accounting system reads transactions from the booking platform on a schedule. A simple dashboard somewhere reads from all of them to give the senior team one view.
There are no spreadsheets stitching things together. Information moves between systems automatically, without anyone copying anything. When a tool needs to be replaced, the integration layer is what gets updated; the rest of the stack keeps working.
This is rarely the state any SME is in by default. Getting there is most of what an automation engagement is actually doing, even when the headline of the project is something more specific like “lead qualification” or “email nurture”. Integration is the foundation those workflows sit on. Building the workflow without fixing the foundation is the most common reason automation projects underperform.
The integration is the thing. The workflow is what makes the integration visible.