When systems don't talk: making hidden failures visible

Context

Your ERP works. So does your CRM. Yet when you look up a customer's address, the answer depends on which screen you open. To find out which address to use, you ask whoever last spoke to the customer. You have the data, but no agreed place to check it.

In service businesses, work often gets held up between systems. Someone copies a request from the customer portal into the ERP. An order confirmed over the phone stays in an email. The person who knows these routines keeps things moving, provided they're available and can keep up.

If this sounds familiar, you can start by examining a particular handover before deciding whether any system needs replacing. This is a representative scenario, drawn from our direct experience of working with processes like these. It describes recurring problems and how we approach them, rather than reporting results from an individual client project.

The challenge

1. Nobody has agreed which system to trust. Sales updates an address in the CRM; accounts changes it in the ERP. Which should take precedence? Both may be correct but serve different purposes: a billing address and an operating address, for instance. Before connecting the fields, you need to establish what they mean and who can change them. Otherwise, automation simply passes the disagreement between systems.

2. A person is doing the integration work. A request posted on r/ItalyInformatica on 15 April 2026 asks to "automate the various interconnections" between an ERP, messaging and booking portals. The need is straightforward: stop having to copy information that has already been entered elsewhere. When that handover depends on someone remembering to do it, their absence can leave you with outdated records and no way to tell what's missing.

3. The worst failure is the one nobody sees. A visible error gives you a chance to act. A connector can also keep running while some data stops getting through: a field changes format, the receiving system rejects a message, or a transfer remains incomplete. If you only check whether the software is running, everything looks fine. The connection is active, but the data isn't arriving. You carry on working with information you believe is current. The first sign of trouble may be a customer asking about a missing order.

4. Changing a field becomes a gamble. You want to add an option to a dropdown, but nobody knows how the other system will interpret it. There's no map of the fields or the rules for transferring them. You put off useful changes, or make them and wait to see what happens. To assess the risk, you need to know which transfers depend on that field.

The numbers worth looking at

Start with these questions. Existing logs may answer some; others will mean observing the work or beginning to collect data. If you can't answer a question yet, start recording the relevant transfers or time spent.

• How many entries do you copy by hand each week, and how much time does that take you and your team?
• How many customer records contain conflicting values across your systems? How many are duplicates?
• How many transfers have failed or are still waiting, and how long have they been in that state?
• How long is the gap between a failure and its discovery? How often does a customer alert you to it?
• How many orders failed to reach their destination last quarter, based on a comparison of orders due to be sent and those received?
• How many hours a month do you spend reconciling lists, finding discrepancies and correcting them?
• How much notice do you get of an interface change, and how long does it take to update the connection?

The approach

1. We agree which system holds the authoritative data. We work with you and the people using the records to choose the source for each piece of information. The ERP might hold the billing address, while the CRM holds the status of a sales opportunity. We document where changes should be made and which systems should receive them. If a field needs to be editable at both ends, we agree how to handle conflicts before automating the transfer.

2. We document the field mapping. For each field, we record its source and destination, including any conversion needed along the way. We specify what happens to an empty or unrecognised value. You should be able to consult this map to understand the implications of a change without having to work out the rules from the code. We update it alongside the connector: documentation left untouched after delivery soon loses its value.

3. We make transfer results visible and failed transfers recoverable. We log each transfer attempt with a reference to the record and its outcome. Temporary problems, such as a service being unavailable, trigger automatic retries with a limit. Invalid data needs correcting, so we put it in a visible error queue with an explanation you can understand. We define how to resume the transfer and prevent another attempt from creating a duplicate. We also agree who will check the queue and resolve the errors.

4. We check delivery and assign responsibility for alerts. Checking that a connector is running isn't enough. We compare what should have been sent with what has been received, and check for delays or unexpected gaps. We agree thresholds based on your activity: a quiet period may be normal or may signal a problem. Alerts go to someone responsible for acting on them, with cover for absences and instructions on what to check. These checks also need testing and maintenance.

What changes

You can check an order's transfer status: received, waiting or blocked by an error. When customer records disagree, you know which source to consult and where to make the correction. Before changing a field, you have a map to help you assess the effects.

That's the intended change in this scenario. Demonstrating it in your business takes evidence: successful transfers, deliberate failures during testing and verified recovery. Our tests include interrupting the flow so we can check that the alert reaches the person who needs to act.

The aim is to spot missing data without waiting for a complaint. Time saved and improvements in how quickly you detect a failure need to be measured in your own operation.

What people fear, and what we say

"The supplier changes the interface and we're stuck." It can happen. We keep the code that communicates with the supplier separate to contain the work involved, but a change can still require development and fresh tests. You need a maintenance budget and someone to keep track of the supplier's notices. We can't guarantee that every change will come with enough warning. We therefore also agree how to handle transfers left pending during an outage.

"Two-way sync will become unmanageable." If both systems can change the same record, you have to handle conflicts and updates that trigger further updates. We start with one-way transfers wherever they're sufficient. That has a cost in how you work: some changes will have to be made in the agreed source system, even if you're used to working elsewhere. Where you need two-way sync, there are more rules to define and tests to maintain. We help you weigh that effort against the benefit.

"We'll end up relying on you for every change." You own the integration code, which we hand over in a repository you control. We also provide the field mapping and instructions for handling errors and restoring transfers. We document which access permissions are needed and how to manage them; credentials stay in secure storage under your control. Preparing this material and training the people who will use it takes time, included in the work. Another supplier will still need to study the integration. The handover gives them what they need without having to ask us for essential information. We consider the work a success when you no longer need us to run it.

How we approach it today

We start with a handover that currently makes you copy or check data. With the people doing that work, we trace the transfer, identify the correct source and define how to detect an incomplete delivery. That gives us a basis for agreeing the scope and estimating the maintenance involved.

• Custom software and systems integration
• Our Odoo Partner path
• CRM and sales pipeline in an integrated ERP

Bring an example of a record that differs between your systems. Let's talk — 30 minutes, no strings attached.