How to connect business systems that don't talk to each other.

Most businesses do not have a software problem. They have a translation problem.

The CRM holds the customer. The accounting system holds the invoice. The scheduling tool holds the appointment. All three are perfectly good pieces of software, and none of them knows the other two exist. So a person opens all three, reads from one, types into another, and the business quietly pays a salary to move data eight inches sideways.

The instinct is to solve this by replacing something. Usually that is the most expensive available answer, and often it does not work — because the new system inherits the same problem the moment you add the fourth tool.

The cheaper answer is a connective layer: something thin sitting between the tools you already own, whose only job is to move information from one and translate it for the next.

Why replacing the software usually doesn't fix it

Two reasons.

First, the all-in-one platform is only all-in-one until you need something it doesn't do. Every business eventually needs the specialist tool — the industry-specific one, the one your biggest client insists on, the one your accountant will not give up. The moment that arrives, the integrated platform is one more island.

Second, the migration cost is paid immediately and the benefit arrives slowly, if at all. Data has to be moved, staff retrained, edge cases rediscovered. Meanwhile the actual complaint — "I type the same thing into three places" — could often have been resolved without touching any of the three systems.

Replacement is sometimes right. It is right when the tool itself is genuinely failing at its own job. It is rarely right when the tool is fine and the gaps between the tools are the problem.

What a connective layer actually is

Strip away the vocabulary and it is a small set of rules:

• When this happens over here — a form is submitted, an invoice is marked paid, a deal moves stage —
• take these specific fields,
• translate them into the shape the next system expects,
• and put them there.

That is it. Most of it is not artificial intelligence at all, and it is worth being honest about that. The rules-based part — move this field into that field — is ordinary, reliable plumbing, and it should be built as plumbing.

Where a model genuinely earns its place is the part rules handle badly: reading an unstructured email and pulling out the four fields you need, summarising a long thread into a note, classifying an enquiry into the right queue. That's judgement on messy input, which is exactly what models are good at and rules are not.

The mistake is using a model for the whole chain because part of it needed one. That is the same distinction we drew in the difference between a model and a workflow — predefined steps beat autonomy on cost, predictability and repairability, and a connective layer is the most predefined thing in the building.

Three questions before you buy anything

Ask these in order. Most projects die correctly at question one.

1. What exactly is being retyped, by whom, and how often?
Not "our systems don't integrate." Specifically: Maria copies the client's name, email, service and date from the booking form into the CRM, about forty times a week. If you cannot say it that plainly, the problem is not defined well enough to solve, and the first version will solve the wrong half. This is the whole argument in what to automate first.

2. Is the process stable, or does it change every few months?
Connecting a stable process is durable. Connecting one that is still being figured out means rebuilding the connection each time it changes, which usually costs more than the retyping did.

3. What happens when it fails?
It will fail — an API changes, a field is renamed, someone enters a date in the wrong format. The right question is not how do we prevent it but how quickly does anyone notice, and what happens to the record in the meantime? A connection that silently drops one record in fifty is worse than no connection at all, because now nobody is checking.

If the answers to all three are good, the work is usually smaller and less exciting than expected. That is the sign it is the right work.

Start with one connection, not a platform

The failure pattern here is recognisable: someone maps every system in the business, designs a complete architecture, and eighteen months later has a diagram and no working connection.

Pick the single most-retyped path. Build that one. Run it for a month and count what it actually caught and what it dropped. Then decide whether the second one is worth it — with real evidence instead of a projection.

We use the same approach on our own operations. Our weekly business review is a set of connections between analytics, search data, pipeline and research, built one at a time over weeks, and it took the first three tries to get right. The parts that work are the parts that were boring. The clever parts got removed.

Studio Bananas Group works on automation the same way it works on everything else: diagnose first, and be willing to say the honest answer is "not yet."