Most businesses today already use software across almost every part of their operation. Marketing teams have campaign and analytics tools, Sales has CRM, Customer Service works across messaging platforms, Finance relies on document and payment systems, and Operations may use spreadsheets, inventory software, or internal applications. From the outside, it can look like the business already has all the tools it needs.
But once we look at the actual workflow, a common problem starts to appear. Having more software does not necessarily mean having more connected data. In many cases, the opposite happens: information becomes distributed across more systems, while people spend increasing amounts of time switching between applications, exporting files, copying information, and checking whether the data in one system still matches another.
This is something I have encountered repeatedly while working with CRM, Digital Marketing, Customer Data, and Business Operations, and it is one of the reasons HostDrift has gradually evolved toward the idea of Connected Business Systems.
The Problem Is Not a Lack of Software
When a business encounters a new operational problem, the natural response is often to add another tool. A lead-management problem leads to a CRM, the need for better website visibility leads to Analytics, campaign requirements lead to Marketing Automation, privacy requirements introduce Consent Management, and Sales may eventually add separate systems for quotations, invoices, and payments.
There is nothing inherently wrong with using specialized software. Each platform can solve a particular problem very well. The challenge appears over time, when customer and business data becomes distributed across different systems and each application begins to represent the same customer in a different way.
A single person may be an anonymous visitor on the website, an email address inside a marketing platform, a LINE User ID in LINE OA, a customer record inside CRM, and a company name or phone number inside a quotation system. Technically these may appear to be separate identities, even though they all belong to the same person.
If those identities cannot be connected, each team ends up seeing a different version of the same customer. This is one reason why concepts such as Customer 360° sound simple in theory but become significantly more complex when implemented in real operations.
Integration Is More Than Having an API
When people talk about system integration, APIs are often the first thing that comes to mind. APIs are important, but I do not think good integration should begin with the question, “Does this system have an API?” A more useful starting point is, “What information needs to move, where does it need to go, and what needs to happen next?”
Imagine a customer submitting a form on a website. Should that information automatically enter CRM? Should the system immediately create a new lead, or should it first check whether the customer already exists? Should a follow-up task automatically be assigned to the Sales team? If the form includes consent preferences, should those preferences travel with the customer record?
If that lead later becomes a paying customer, Marketing may also need to know that the conversion happened so the person is no longer treated as a prospect. These are primarily business workflow questions. APIs, webhooks, and queues are simply technologies used to make the designed workflow possible.
Multiple Systems Can Create Multiple Versions of the Truth
Another common problem is that organizations may have plenty of data but are no longer certain which version is current. Sales might update a customer’s phone number in CRM while the marketing platform continues using the old number. A customer may change their email address while the newsletter system still stores the previous one, or a customer may withdraw consent while another platform never receives that update.
The same customer may also appear as several duplicate records simply because they entered the business through different channels. At that point, the problem is no longer limited to data quality; it begins to affect the customer experience as well.
Customers may receive duplicate messages, irrelevant campaigns, or separate contacts from multiple teams that are unaware of each other’s activity. In privacy-related workflows, the problem becomes even more important because one system may continue using data after the consent state has already changed elsewhere.
Connecting data therefore does not simply mean moving everything into one database. The more important objective is to help different systems operate with as much of the same context as possible.
Does Everything Need to Live in One System?
I do not think it does. CRM should be strong at customer relationships, sales pipelines, and team workflows. A CDP should focus on customer profiles, behavioral events, and data signals, while a Consent Management platform should be responsible for permissions, preferences, and privacy information.
Quotation software should focus on document workflows, while Inventory should manage stock, assets, locations, and operational information. Trying to make a single application handle all of these responsibilities can eventually create a platform that is unnecessarily large and difficult to operate.
A more useful approach is to define what each system needs to know, which information should be shared, which system owns the original data, and which other systems need to be informed when that data changes. This is an approach I increasingly use while developing HostDrift: each platform remains focused on its own purpose, while the context that genuinely needs to move across the business can be shared.
A Single Source of Truth Does Not Mean One Database
“Single Source of Truth” is a common phrase in data projects, but it does not mean that every piece of business information must live inside one database. Different systems can legitimately own different types of data.
CRM may be the authoritative source for Lead Status, while CDP owns Behavioral Events, Consent Management owns Consent State, Quotation owns Document Status, and Inventory owns Stock Quantity. The important thing is that other systems know which source should be trusted for a particular type of information.
If a customer withdraws consent, CRM and CDP should not maintain independent and potentially conflicting versions of that consent state. Instead, they should refer to the platform responsible for consent. This reduces the risk of several systems maintaining different versions of “the truth” and gives data synchronization a clearer structure.
People Often Become the Integration Layer
One thing I have found particularly interesting is what happens when software systems are not connected: people become the integration layer.
Someone exports an Excel file from one system, opens another application, copies the information, checks the values, sends the file through email or chat, and another team uploads it into another platform. From a technical perspective, this is still a form of data pipeline; it is simply a pipeline where a person is acting as the middleware.
Human review will always be necessary in many workflows, and not every process should be automated. However, when the same task happens every day using the same rules and requires very little judgment, there is usually an opportunity for technology to handle at least part of the process.
For me, automation is not about removing people from a workflow. It is about removing repetitive steps that do not require human judgment, allowing people to spend more time on work that requires context, decision-making, creativity, and communication.
Connected Systems Should Start with Workflow, Not Technology
When I first started thinking about integrations, I also looked at the problem too much from a technical perspective: which platform has an API, which one supports webhooks, and which databases can be synchronized. The more systems I built, the clearer it became that technology should come after the workflow has been understood.
Before connecting two systems, we should first understand what information needs to be sent, when it should be sent, what event starts the process, what happens when delivery fails, which system owns the primary record, who is allowed to access the information, and under which consent state that data can be used.
Once these questions are clear, selecting the technology becomes much easier. Some workflows may use APIs, others may rely on webhooks or queues, and some processes may not need to operate in real time at all. Technology should be selected to support the workflow, rather than forcing the workflow to adapt to the technology.
Why HostDrift Is Becoming More Connected
CRM, CDP, Consent, Quotation, and Inventory originally came from different operational problems. As those platforms developed, however, the relationships between them became increasingly visible. The customer inside CRM is also the customer profile inside CDP, the data used by CDP needs to respect Consent, a Sales workflow inside CRM may eventually create a Quotation, and a completed purchase may later affect Inventory.
The goal is therefore not to merge every HostDrift platform into one enormous application that tries to do everything. The direction is to keep each platform clear in its purpose while allowing the right context to move between them.
Many businesses may not actually have too little software. They may already have more than enough. The problem is that each system is working independently, and when information cannot move naturally through the workflow, people end up connecting those systems manually again.
For me, a Connected Business System is not about building the biggest possible platform. It is about making sure the right information reaches the right people and systems at the right time. That is one of the ideas I continue to explore and develop through HostDrift.
