Skip to contentAnemo
EN
Contact

Disconnected Systems: Costs, Warning Signs, and Fixes

· 5 min read

Disconnected systems cost money in four measurable ways: staff re-entering the same data, decisions made from stale copies, time spent reconciling versions, and work that stalls waiting for someone to move information between tools. Most businesses can quantify all four in a fortnight, and the total is usually larger than the integration that would remove it.

This guide covers the warning signs, how to put a number on the cost, and how to fix it in an order that pays for itself.

Key takeaways

The warning signs

The same information is typed into more than one place. Orders re-keyed into accounting, customer details entered into both a CRM and a support tool, delivery addresses copied between systems.

Someone maintains a spreadsheet that joins two systems. This is the clearest signal, and the spreadsheet is doing the work an integration would do, unauditably, and dependent on one person.

Reports require manual assembly. If monthly reporting means exporting from three places and reconciling in Excel, the systems are not connected in any useful sense.

Nobody can answer a question in one place. "Where is this order" requiring two logins and a phone call is the customer-facing version of the same problem.

Two systems disagree and nobody knows which is right. The most expensive symptom, because it undermines trust in all the data.

Put a number on it

Cost How to measure it Typical finding
Duplicate entry Occurrences per week × minutes each × loaded hourly cost Usually the largest and easiest to defend
Reconciliation Hours per month spent comparing and correcting Concentrated in finance and operations
Delay Time between an event happening and the second system knowing Shows up as customer contact
Errors Rate of mistakes traceable to re-keying, and cost of each Small frequency, high individual cost

Sample rather than estimate. Time twenty real cases, or ask one team to log the work for two weeks. A fortnight of observation produces a defensible baseline and costs almost nothing, and it is far more persuasive than an assertion that things are inefficient.

Decide what should be connected, and what should go

Before integrating, ask whether both systems should exist. Integration preserves the current shape of the estate, including the parts that no longer earn their place.

A system used by two people for one report, or one whose function another system already covers, should be retired rather than connected. Retirement is the cheapest possible outcome and every estate contains a candidate.

Equally, if three systems each hold a partial customer record, the answer may be to consolidate rather than to build three integrations that keep all three in step forever.

Fix in order of volume, not irritation

The loudest complaint is rarely the biggest cost. Rank candidate integrations by how often the manual step happens, and start at the top.

For each connection, define before building: which system is authoritative for each field, the direction and trigger, what happens when the other side is unavailable, and who owns it when it breaks. Without the first of those, the answer becomes whichever code ran last.

A straightforward connection typically runs $2,500–$8,000; a bidirectional sync with complex mapping or an undocumented legacy system runs well beyond it. Price each separately, a single line item for "integrations" is the most reliable predictor of an overrun.

Choose the right mechanism

Approach When it fits
Direct API integration Both systems have stable, documented APIs
Integration platform Several connections, standard systems, limited engineering capacity
Scheduled file transfer Legacy systems with no API; batch tolerable
Shared database read Same vendor, same estate, controlled access, rarely a good idea across vendors

Real-time is not always required. If a nightly sync meets the business need, it is cheaper to build, easier to reconcile and simpler to recover. Match freshness to the decision the data supports rather than defaulting to immediate.

Build reconciliation from the start

Two connected systems drift. Retries cover minutes of failure, replay covers hours, and reconciliation covers everything else, including failures nobody detected.

Schedule a job that compares counts and totals across the boundary daily and alerts on the difference. This is the piece teams build after their first serious incident; building it first costs a fraction and is the difference between finding a discrepancy the next morning and finding it at month-end.

Measure the change you promised

Re-measure the same four costs three months after the integration lands. Duplicate entries removed, reconciliation hours recovered, delay reduced, error rate.

If the manual step is still happening, the integration did not cover the exception path, and staff have kept the old route because it handles a case the new one does not. That is the most common way an integration is delivered and does not pay.

If the work prompted by Disconnected Systems: Costs, Warning Signs, and Fixes leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Platform Foundation.

Frequently asked questions

What should be defined first?

Start by defining the expected result and owner for service boundary. Then follow one real example through data and integration, recording the data used, waiting points, exceptions, and evidence of completion. This creates a more reliable first scope than a screen inventory.

How should success be measured?

Review failure rate, latency, recovery time, and data accuracy together. Give each measure a definition, data source, owner, review cadence, and response when it crosses a threshold. A single speed or usage metric should not hide quality, rework, or abandonment.

Does this work always require new software?

New software is not automatic. If the underlying problem is policy, ownership, training, or an unnecessary approval, fix the process first. Configure an established tool when it supports the critical workflow and data boundary. Consider custom development only when a differentiating rule, integration, or experience creates clear value.

Related services

Related reading

Building the product for what comes next

We would rather deliver one product that holds up than three that have to be rebuilt. That standard is the same on every project, whatever its size.

Ali Boran GazelCEO

Contact us