I work in the integrations team of a consumer goods company. My job is to get systems that were never designed to talk to each other (an ERP, a field sales platform, databases older than some of my colleagues) to share information without anyone having to copy it by hand.<\/p>\n
After several projects, I came to an uncomfortable conclusion: when marketing and sales complain about the CRM, the CRM is rarely the problem. The problem is what happens between systems. In this article I explain why it happens, what I learned integrating systems in a real corporate environment, and a five-step method I now also use with small businesses. You don’t need a technical background to follow it.<\/p>\n
There’s one sign that gives the problem away immediately: everyone has their own spreadsheet. The sales rep keeps contacts in Excel because “the system isn’t up to date”. Marketing exports campaign leads to another sheet. And the CRM ends up as a record that gets updated whenever someone has a spare moment.<\/p>\n
You know what comes next:<\/p>\n
Switching CRMs fixes none of this. What fixes it is connecting what you already have.<\/p>\n
A prospect can come in through a form, WhatsApp, email, a phone call or an ad. Each channel stores the data in its own place. If none of them is connected to the CRM, someone has to copy and paste, and anything that depends on someone remembering will fail sooner or later.<\/p>\n
The moment a lead passes from marketing to sales is usually a forwarded email, a message in a group chat or a row highlighted in yellow. Without an automatic trigger, that lead sits in no man’s land for hours or days.<\/p>\n
I saw this up close in an integration project with a field sales platform. When we analysed how data moved, we found something nobody had documented: the ERP, the sales reps’ platform and the internal back office each had their own idea of what a customer was, with different fields, different codes and different rules. There wasn’t a single bug to fix. The real problem was that nobody had ever decided which system owned each piece of data.<\/p>\n
That analysis led to a data governance model for sales and marketing, which we now use to document every entity: where it comes from, who changes it and which systems it is replicated to. It sounds bureaucratic, but it saved us more arguments than anything else.<\/p>\n
The first reaction to this problem is usually a manual routine: someone exports the leads every Monday and imports them into the CRM. It works as a patch, but the information always arrives late and depends on that person never making a mistake or going on holiday.<\/p>\n
A real integration is event-driven. When something happens in one system, it triggers an action in another at that very moment. Technically, this is done with webhooks<\/a>, APIs or message queues, but for someone running a sales team what matters is the result: a form submitted at eleven at night is already in the CRM, assigned and with a notification sent, before the person has even closed their browser.<\/p>\n Where the lead comes in, what data it provides, who handles it and where it gets lost. This map always reveals steps nobody had written down and exceptions that only one person on the team knows about. If you automate without it, you’re just automating the mess.<\/p>\n This is the data governance lesson I mentioned earlier. For each important piece of data, you decide which system owns it: contact details in the CRM, tax status in the ERP, campaign history in the email tool. Data is copied from its source to everything else, never the other way round.<\/p>\nFive Steps I Follow in Every Integration<\/h2>\n
1. Map the Journey Before Touching Any Tool<\/h3>\n
2. One Source of Truth per Data Point<\/h3>\n