Connecting tools is an afternoon's work these days. There is a ready-made building block for almost every combination, and where there is not, an automation service sits in between. That is exactly why an integration is so often the first answer to a problem that was never a data problem. An interface does one thing very well: it carries a record from A to B. What it cannot do is decide what should happen once the record arrives. Where that decision is missing, the process does not get better, it just gets confusing faster. This piece is about telling the two cases apart before you build anything.
Why is so much sitting side by side in the first place?
Because tools get bought one at a time and nobody owns the space between them. European business statistics show how far apart this is drifting, particularly in small firms. Eurostat has measured for years how many companies run a system that shares information between different functional areas, meaning between sales, purchasing, accounting and the warehouse. In Austria, among firms with 10 to 49 employees, that is 30.9 per cent. The EU average is 41.1 per cent, Germany sits at 37.5 per cent.
Two things stand out. First the direction: Austria was above the EU average in 2021 and sits below it today. Second the order of magnitude. Turned around, roughly seven in ten small Austrian firms work without a system that passes data between areas on its own. For CRM the picture is starker still: 25.4 per cent of small Austrian firms use CRM software at all, according to the same survey.
That is not a failing, it is a description of the situation. If you start small you buy one tool for the calendar, one for invoices, one for the newsletter, and for years that is the cheaper and faster decision. For contrast, the other end of the scale: identity provider Okta counts an average of 101 applications per customer organisation in its Businesses at Work 2025 report. Those are larger companies with a central sign-on, and the figure does not transfer to a five-person business. The direction holds anyway: it is not getting fewer.
What does all that side-by-side actually cost?
Not the licences. What costs is the switching. A study by Rohan Narayana Murty, Sandeep Dadlani and Rajath B. Das, published in Harvard Business Review on 29 August 2022, analysed the on-screen activity of 137 employees across 20 teams at three Fortune 500 companies. The result: around 1,200 switches between applications and windows per person per day. That adds up to just under four hours a week spent purely on reorienting after a switch, roughly nine per cent of working time.
That finding is why the reflex "let us just connect them" almost always sounds right. And in a share of cases it is right. Every switch that disappears because a record shows up in the right place on its own is a real gain. The mistake happens one level below, in the cases where the switching was never the problem.
What can an integration do, and what can it not?
An integration carries. A webhook pushes a record onward, an API fetches it, an automation service creates a copy. All three do exactly what the rule someone wrote earlier says. Three things they do not do.
They do not decide. If the calendar holds a different appointment from the CRM, the winner is not the correct one but the one written last. An integration knows no precedence until somebody sets it. That is precisely why a single source of truth is not a technical question: deciding which system leads for which kind of data is a human call, not a tool setting.
They do not become responsible. A record that travels from A to B has no owner in B. If nobody has decided who picks up the enquiry, it now sits in a second system rather than one. The media break is gone, the open question is not.
They do not speak up. That is the uncomfortable one. Integrations fail silently. An expired access token, a renamed field, a changed rate limit at the provider, and the transport stops. Nobody gets an error message, because the error message sits in the log of a service nobody has opened in months. In our own work this usually surfaced from the customer side: somebody asks why they never heard back.
How do you tell which case you are in?
With two questions you can answer in five minutes. First: is the data you need sitting somewhere else? Second: is the rule settled for what should happen to it once it arrives? The two answers give you four situations, and only one of them is a job for an interface.
The test behind it is a single sentence, and it is uncomfortably reliable. Write down: when X happens, Y decides according to rule Z. For example: when an enquiry arrives through the form, the person in sales decides within four hours, against the exclusion list, whether it goes into the quote lane. If that sentence stands, the integration is simply diligent work. If you cannot write it because the Y or the Z is missing, then the interface is not the solution but a way of making the gap invisible. The thing does happen afterwards, it is just that still nobody does anything with it.
A second warning sign is the count. When a task needs three or more connections for a case to run through, technology is rarely the culprit. Usually the process grew around the tools over the years rather than the other way round, and each further connection cements it. That is the point where a look at your process costs pays off more than the next building block.
Three levers for the next fortnight
1. Name a leading system per kind of data, not per tool. Customer, quote, appointment, invoice: for each of those four there is exactly one place where the valid state lives. Everything else is a copy and may be overwritten in case of doubt. That one sentence resolves more data conflicts than any reconciliation logic, and it costs nothing but half an hour of argument.
2. Write the if-then sentence before every new connection. If it does not fit on one line, the process is not clear enough to be automated yet. Then the next job is not the connecting, it is deciding who is responsible and what they follow. That is less comfortable than a building block, but it is the work that holds.
3. Give every existing connection a name and a failure path. A list with three columns is enough: what flows where, who notices when nothing flows any more, and how they notice. In our experience, anyone who compiles that list once finds two connections nobody needs in the same pass, and at least one that has been standing still for weeks.
If you want to know which of your connections genuinely take work off your hands, and where you are missing a decision rather than an interface, let us look at the chain together. 🔗