Nobody decides to have disconnected systems. Each one arrived as a sensible decision: a CRM when the sales team grew, an accounting package when the bookkeeper insisted, a help desk when support moved out of a shared inbox, an e-commerce platform, a scheduling tool, a spreadsheet that was only ever meant to be temporary. Each tool works. Each vendor can show that its part is doing its job.
The cost sits in the gaps between them, and it never appears on an invoice. It appears in people's weeks: in copying, checking, chasing and reconciling. Because it is spread thinly across many people, it is easy to mistake for normal work. This perspective is about making that cost visible, and about what to do once you can see it.
Where the cost hides
| Where | What it looks like | Who pays |
|---|---|---|
| Re-keying | The same customer, order or invoice typed into two or three systems | Operations, finance, support |
| Reconciliation | Month-end spent matching exports; meetings that open with "which number is right?" | Finance, leadership |
| Waiting | Work sits until a person notices it and carries it to the next system | Customers |
| Partial decisions | A renewal call made without seeing the open complaint; a payment chased mid-dispute | Revenue, reputation |
| Risk | Personal data copied into exports, spreadsheets and inboxes; shared logins for integrations | The whole organisation |
| The change tax | Every new tool or process change has to be threaded through fragile connections | Every future project |
Re-keying and drift
Every time data is typed again, it can be typed differently. A customer's address is corrected in the CRM but not in the finance system; an order quantity is changed in the shop but not in the warehouse spreadsheet. Within months each system holds its own slightly different version of the truth, and people learn which one to trust for which purpose. That knowledge lives in their heads, and leaves with them.
Reconciliation
Where copies drift, someone has to bring them back together. This is the work that fills month-end, and the reason so many leadership meetings begin by debating whose report is correct before anyone can discuss what to do.
Waiting
When people carry information between systems, work waits for them. The order sits until someone re-enters it; the support ticket waits until someone checks the delivery status in another tool. On the What we solve page the Guild describes this pattern as people acting as routers. Customers feel the delay even when nobody inside can see where it comes from.
Decisions on partial pictures
The most expensive cost is the hardest to measure. Each team sees its own system and acts on it. Sales calls to discuss an upgrade without seeing the complaint opened yesterday. Finance sends a firm reminder to a customer whose invoice is disputed because of a delivery error. Every decision is reasonable from inside one system and wrong from outside it.
Risk
Disconnection multiplies copies, and copies are where risk lives. Customer data exported "just for this report" sits in an inbox for years. An integration built by one enthusiastic person runs on their personal login. When a customer asks what you hold about them, or asks you to delete it, nobody can say with confidence where all the copies are.
The change tax
Finally, disconnection makes change expensive. Every new tool has to be wired into a tangle that nobody fully understands, so the organisation starts to avoid change altogether. The systems were bought to make the business more agile; their gaps make it less so.
Why agents make it larger, not smaller
It is tempting to see AI agents as the fix: put an agent in the gap and let it do the copying. Sometimes that is a reasonable bridge. More often it makes the problem worse.
An agent connected to five systems that disagree does not resolve the disagreement. It picks one version, usually without saying which, and acts on it confidently and quickly. It also needs credentials for every system it touches, which adds five more integrations to secure and own. An agent can only be as reliable as the context it acts from.
Atlas note — Before an agent touches a process, I map what it will depend on: every source, every owner, every place two systems claim to know the same thing. Most of the risk in an agent project is visible on that map before any agent exists.
The order matters. Connect and clarify the data first; then let agents work on top of it.
How to make the cost visible
You do not need a consultancy report to find out what disconnection costs you. You need to follow one thing all the way through.
- Pick one flow that matters — a new customer, an order, a complaint, a monthly invoice run.
- Trace it end to end. Every system it touches, every person who touches it, every time it is typed again, every time it waits for someone.
- Mark the sources of truth. For each piece of data in the flow, which system is supposed to be authoritative? If the answer is "it depends" or "two of them", you have found a seam.
- Count the seams that leak. Re-keys, manual exports, spreadsheets acting as systems, integrations with no owner.
| Step | System | Who | Typed again? | Waits for | Source of truth? |
|---|---|---|---|---|---|
| Order placed | Web shop | Customer | — | — | Web shop |
| Order entered for invoicing | Finance | Operations | Yes | Daily batch, by hand | Unclear |
| Stock updated | Spreadsheet | Warehouse | Yes | Email from operations | Spreadsheet (unofficial) |
| Customer asks "where is it?" | Help desk | Support | Looks up in two places | Warehouse reply | None |
One trace like this usually does more to change minds than any estimate, because everyone can see their own part in it.
What fixing it looks like
The fix is rarely a single new platform. It is a handful of principles applied seam by seam.
- One system of record per entity. Customers, orders, products, invoices: each has one authoritative home and a named owner. Other systems read from it or receive changes from it; they do not keep their own competing version.
- Shared identifiers. The same customer has the same identifier everywhere, or a maintained mapping between them. Without that, no integration can be trusted.
- A shared vocabulary. Agree what "customer", "active" and "order date" mean across systems. Integration practitioners call this a canonical data model; in plain terms, it stops every connection from inventing its own translation.
- Fix the most expensive seam first. Not everything at once. The trace shows which gap costs most in waiting, errors or risk.
- Prefer events where several systems care. When something happens that more than one system needs to know about, announce it once rather than wiring every system to every other. The field guide Designing Event-Driven Business Operations covers this in depth.
- Make every integration owned and observable. Each connection has an owner, monitoring, and a place where failures go instead of disappearing.
- Retire as well as connect. Sometimes the best integration is removing a tool whose job another system already does.
An example
Illustrative example, not a client engagement.
A small distributor sells through a web shop, invoices from an accounting package and tracks stock in a spreadsheet. The trace shows that every order is typed into accounting each morning, that stock is updated from an email, and that support answers "where is my order?" by asking the warehouse.
The first fix is not an agent. It is making the web shop the source of truth for orders, sending each new order to accounting automatically with the same order number, and moving stock into a system that both the shop and the warehouse can read. Only then does an agent make sense: one that answers order-status questions from a single, trusted record, and hands anything unusual to a person.
Questions to ask about your own systems
- For your customers, orders and invoices, can you name the one system that is authoritative for each?
- How many times is a new order typed by a person before it is invoiced?
- Which spreadsheets would stop the business if they disappeared tomorrow?
- Does every integration have an owner who would notice if it failed?
- If a customer asked you to delete their data, could you find every copy?
- Would an agent connected to your systems today get one answer, or several?
On the site, the Guild's starting point for "our systems don't work together" is integration, the Citadel and data architecture, and the first step is a map: sources, owners, gaps and the decisions that depend on them. Atlas's job is to keep that map honest. If you want to see yours, the Data Engineering & Intelligence page describes the landscape audit, and the Guild Assessment is the shortest way to start the conversation.
