SocialNext runs conferences across Canada. For years, a ticket sale lived in one platform, the attendee's profile lived in a second, the newsletter list lived in a third, the community forum lived in a fourth, and the schedule for the actual event lived in a spreadsheet that got duplicated every time they ran a new one. None of those systems spoke to each other. The process holding it all together lived in the founder's head.
Everybody reads that as a tooling problem. It is a data problem, and you pay for it in small amounts for years before anyone hands you the bill.
Disjointed data and disjointed systems bring organizational velocity to a standstill. Everything creeps. You cannot keep pace with competitors because every piece of information sits in its own ecosystem and the only thing connecting them is a person doing it by hand. The fix is not buying one more platform that swears it does everything. It is deciding where the truth lives and wiring the rest of your stack to it.
What a scattered stack costs you
Every platform holds its own copy of the same handful of things. Companies, contacts, IDs, revenue, hours, budgets. The copies start out identical and drift apart the first time somebody updates one and forgets the rest.
For SocialNext that meant re-keying the same human being between ticketing, email and the community platform. It meant rebuilding every event's schedule by hand inside a form builder. It meant budgets, speakers, times and day-of itineraries in spreadsheets that got duplicated for the next event and then diverged from each other.
The industry numbers are worse than most people assume. MuleSoft's 2024 Connectivity Benchmark, a survey of 1,050 IT leaders, found the average enterprise running 991 applications with only 28% of them connected to each other. Eighty-one percent said data silos were hindering them. That sample is enterprise, companies with a thousand people or more, so read it as a direction rather than your reality.
Closer to home, Zylo's 2025 SaaS Management Index puts companies with 1 to 500 employees at an average of 152 applications. Zylo's customer base skews mid-market, so that number runs high for a ten-person shop and I would not quote it at a board meeting without saying so. Even discounted hard, it is more tools than anyone thinks they have.
The tax gets paid in attention. A 2022 Harvard Business Review study tracked 137 users across three Fortune 500 companies at the keystroke level and clocked roughly 1,200 toggles between applications per day, costing just under four hours a week in reorienting after each switch.
None of this hurt SocialNext for years. The founder held the whole map in his head and it worked. It started hurting the day he tried to hand pieces of it to somebody else.
You do not have one source of truth. You have one per entity.
"Find your source of truth" is the advice everybody gives, and it is half an answer. Where does that information live? It could be your CRM. It could be your project management system. It could be some hybrid of the two.
This is the same argument we made about building a digital structure for your organization, pointed at a narrower question. The sharper version is that you do not get one. You get one per entity. Your accounting software owns the invoice. Your CRM owns the deal. Your project tool owns the hours. Trying to collapse that into a single application is usually a worse idea than what you have now.
The thing that kills you is two systems both believing they own the same field. When your CRM knows the project budget and your PM tool also knows the project budget, you have a coin flip, and nobody in the company can tell you which side is currently up.
How do you tell which system owns a field?
Ask four questions, in this order:
- Which system does the record get created in first?
- Which system does somebody edit it in daily?
- Who gets hurt, and how badly, when it is wrong?
- Who outside your company touches it, and what are they willing to log into?
Whichever system wins owns that field. Everything else holds a copy, and the copy is read-only. Copies are fine. Copies that write back are how you end up with three versions of the same client and no way to tell which one to trust.
Why AI turns this from an annoyance into a real problem
Because the workarounds your team invented do not transfer to software.
Point an AI at your Salesforce and ask it about a specific client. Then connect it to your project management system and ask it to compare. The price you sold the project for in the CRM may not match what is in the PM tool, because the client asked for more features, somebody scoped the addition, and that number never made it back to the deal record. Your invoicing system agrees with neither. Three tables describe the same company, none of them agree, and the model has no way of knowing which one is current. That is a join problem.
There is a good objection here: matching records is something language models are good at. A February 2026 study of 755,540 labelled record pairs drawn from real sanctions-compliance work found LLMs beating the production rule-based matcher, with the best model hitting 98.95% F1. The join is usually right.
My argument is about the residual. Errors compound across multi-step work, and there is real research on the shape of it. Toby Ord's analysis of agent performance found success decaying exponentially with task length, because longer tasks contain more subtasks and failing any one of them fails the whole thing. A paper accepted at ICLR 2026 goes further and identifies what the authors call self-conditioning: models become more likely to make mistakes once their own earlier mistakes are sitting in the context window. One wrong record early does not stay one wrong record.
When a model grabs the wrong row, it tends to believe it. Stanford's ClashEval, presented at NeurIPS 2024, tested 1,200 questions and found models adopting incorrect retrieved content over their own correct internal knowledge more than 60% of the time.
I would argue the failure mode is worse than a person's, and I want to flag that this is my opinion rather than something I can point at a study for. A staff member who pulls up a client record showing a number that feels wrong stops and asks somebody. Software does not get that itch. It takes the wrong number, makes a decision, and carries on with total confidence, and unless you are reading every intermediate step you find out weeks later. In July 2025, Replit's coding agent deleted a live production database during a code freeze, reportedly after hitting empty query results, then generated fake data to cover it. One reported incident, not a study, and the root cause was never published. The behaviour is still the one worth worrying about.
Gartner predicted in July 2024 that 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, with poor data quality first on its list of reasons. In Informatica's survey of 600 data leaders published in January 2025, 43% named data completeness and quality as a top obstacle to getting AI out of pilot.
The upside is boring and worth having. When the information already sits in one place, every question needs less context assembled to answer it. Fewer lookups, fewer reconciliation steps, smaller token bills, faster answers.
Does MCP not solve this?
It solves the wrong half. Every platform is shipping a connector now, and that helps: an agent can reach into your CRM, your PM tool and your accounting software in the same breath, which was painful eighteen months ago.
Reach was never the hard part. Identity is. If the same company exists as three records with three IDs and three spellings of the name, a connector gives the model faster access to all three wrong answers.
The vendors are quietly proving the point
Watch what the platforms are doing. Monday sells a standalone CRM. ClickUp's stated strategy is replacing your whole stack. Pipedrive ships Projects. Each platform keeps annexing the neighbouring platform's job, so as your team experiments, the same client ends up living in four places under four slightly different spellings.
The most telling move came from HubSpot. At INBOUND 2025 they announced a wave of AI agents alongside a new Data Hub for unifying data. A CRM company shipped a data unification product because its own AI agents could not work without one. That is the argument of this article, made by the vendor with the most to lose from it.
The irony runs deeper. All of these companies are racing to build MCP servers and AI-friendly APIs so you can work inside their ecosystem more easily. Those same interfaces let you point Claude at your Monday account, have it read your data structure, and design a schema to replace them. They built the door out.
Was the Zapier era a mistake?
No. Those tools were great, and for a real reason.
Connecting two APIs used to require an engineering team. You needed webhook endpoints, cron jobs, somewhere to run it all, and somebody on call for every time a vendor shipped a new API version and broke your sync at 2am. Zapier and Make took work that was out of reach for a small company and made it a Tuesday afternoon. We ran Zapier, Make and n8n at various points and they earned their keep.
Then the cost of entry collapsed. An edge function or a small real backend now does the same job with better error handling, no per-task pricing, and code you can read. The middleman stopped being necessary.
There is a specific failure worth knowing about. Plauti, analysing over 12 billion Salesforce records, found more than 45% of new records entering a CRM were duplicates, and that records arriving through API integrations and web forms duplicated at roughly 80%, against 19% for manual imports. They sell deduplication software, so weigh it accordingly. The mechanism is not controversial though: the sync layer you added to fix your data problem generates a fresh one.
Picking a hub means picking a landlord
Say you decide your CRM owns the client and you wire everything to it. Fair enough. Understand what you just did: your source of truth now belongs to somebody else, and you pay per person for the privilege of reaching your own records.
Platforms act in their own interest. They hike prices. They move a feature you depend on behind a higher tier. They call it a pricing simplification. If your entire operation sits downstream of one vendor's product decisions, that vendor has a say in your operating costs and your roadmap, and you have no leverage. We wrote about where per-seat pricing goes wrong at more length, and it applies double when the seat is the door to your own data.
So the criterion is not which tool has the best features this quarter. It is whether you could leave. Can you get every record out, with relationships intact, into something else? If the answer is no, you are looking at a hostage situation with a nice interface.
What we deliberately did not consolidate
Most articles about consolidation skip this part, and it is the part that takes actual judgement.
We did not rebuild accounting. Xero stays, integrated rather than replaced. We could build invoicing. Our bookkeeping team is not going to learn bespoke accounting software for one client out of their whole book. The same logic covers the community forum, the newsletter platform and Slack. Rebuilding forum software, or a CASL-compliant email platform, is an enormous amount of work to arrive back where you started.
The rule we use: when a tool is mainly touched by people outside your company, people who are not financially motivated to learn your system, the friction of forcing them onto it outweighs the friction of keeping their data in a second place. Sync it into your spine and leave them alone.
For SocialNext that meant a ticket sold in RegFox flows through their platform, adds the buyer to CyberImpact, grants access to Circle, and lands in every report, with no exports and no double entry. Four systems, one owner per record. The whole rebuild is written up here if you want the detail.
We did eventually take this to its logical extreme for ourselves and built our own CRM rather than renting one. That is a bigger decision with its own tradeoffs, which is why it has its own article.
When you should not do this
If you are three people running a CRM and a Google Sheet, and it works, leave it alone. Consolidation projects fail all the time, they are expensive, and "our data is a bit messy" is not a business problem. It is just true of everybody.
The signal to watch for is delegation. The mess is free while it lives in one or two people's heads and those people do all the work. It starts costing real money the moment you need somebody new to do the job, because now the process has to exist outside a skull.
Some red flags that showed up for us and our clients:
- You cannot produce an accurate report for a sponsor or a board without somebody assembling it by hand from three places.
- Onboarding a new staff member means teaching them where seven things live and which two of them lie.
- Customers fall through a gap because one platform will not take a bulk import and somebody has to remember to do it manually.
- You want to point AI at your operations and cannot answer a basic cross-system question, like which clients are over budget.
How to pick your source of truth
A practical version you can run this week:
- List your entities, not your tools. Client, contact, deal, project, task, hour, invoice, subscriber. Usually a dozen or fewer.
- Name one owner per entity. One system per row. If you cannot decide, use the four questions above.
- Find the collisions. Where do two systems both write the same field? Those are your active bugs. Everything else is fine.
- Check the exits before anything else. Does each system have a real API and a real export? A tool with no API cannot sit in your core. It is either a leaf you accept manual reconciliation for, or it goes.
- Weigh rebuild against integrate. How much would replacing this cost, and what do you gain? Accounting, email and community platforms almost always lose that maths.
- Count the outsiders. Every external collaborator who would have to learn something new is a real cost. Bookkeepers, contractors, clients.
- Confirm you could leave your own choice. Whatever you pick as the spine, make sure the data comes out whole.
You do not have to do all of it at once, and you probably should not. Pick the two entities causing the most pain, give each one owner, make everything else read-only, and see how much quieter the week gets.
Untangling this is most of what our business automation work turns out to be in practice. Rarely the fun part. Reliably the part that makes everything after it cheaper.
