Why Your Software Doesn't Talk to Your Other Software

Every business past a certain size has the same complaint: the scheduling system does not know what the CRM knows, the accounting package needs the same information typed again, and somewhere a person is the integration. Understanding why is what lets you judge a quote to fix it.

Reason one: one system has no usable way in or out

An API is the door software provides for other software. Not every product has one. Older industry-specific systems — the kind that have run a trade for twenty years — frequently do not, or have one that only reads.

When there is no door, the options get worse quickly: scheduled file exports, screen-scraping, or database access if the vendor permits it. All are more fragile and more expensive to maintain than a real API, and all break when the vendor updates their software.

This is the reason that most often makes an integration a bad investment. If one side has no API, the honest conversation is about whether to replace that system rather than build scaffolding around it.

Reason two: they identify the same customer differently

This is the most common technical reason and the most underestimated. Your CRM knows a customer by an internal ID; your accounting system knows them by a different one; your scheduling tool matches on email; and the field app matches on phone number.

Now consider a real household: two people share an email, the business has two locations under one name, someone changes their phone, and a company is entered twice with different spellings. A machine cannot reliably tell whether “J Smith” at one address is “John Smith Plumbing LLC” at another. It will either merge two customers who are not the same — which puts one person’s invoices in front of another — or split one customer into two, which is how a loyal client gets a first-time-customer greeting.

Solving this means choosing a matching key and cleaning the data so it is reliable. That cleanup is usually the largest line item in an integration quote, and it is the one people try to cut. It is also the one that determines whether the integration works.

Reason three: nobody decided which system is right

Two systems hold an address for the same customer and they differ. Which one wins?

That is a business decision, not a technical one, and until someone makes it the integration cannot be built. Made badly, it produces the worst outcome available: the two systems overwrite each other in a loop, and the record flips depending on who edited last.

The workable pattern is to name a system of record per field — addresses are authoritative in one place, payment terms in another — and make the others follow. Unglamorous, occasionally political because it tells a department their copy is secondary, and absolutely required.

Reason four: the vendor would rather you did not

Some products make integration deliberately difficult. API access sits behind the highest pricing tier, rate limits are set low enough to be impractical, data export is offered in a format designed to be painful, or terms prohibit the use you have in mind.

This is a business strategy, not an oversight: switching costs are what keep customers who would otherwise leave. It is worth knowing because it changes the negotiation. Sometimes the access exists and is simply priced; sometimes asking directly, especially at renewal, produces a different answer than the documentation does.

Why do integration quotes vary so wildly?

Because the same sentence — “connect these two systems” — covers jobs that differ by a factor of fifty. What drives the number:

• Direction. One-way is far simpler than two-way, because two-way requires conflict rules (reason three).
• Timing. A nightly sync is straightforward. Real time means handling failures, retries and partial states.
• Data condition. Clean, consistently identified records versus twelve years of duplicates.
• API quality. A well-documented modern API versus one that is undocumented, throttled, or absent.
• Volume and history. Syncing new activity is one job; migrating years of history is another.

A quote that arrives without questions about these five was produced without knowing which job it is.

What to ask before commissioning an integration

1. Does each system have a documented API, and is it included in our current plan? Confirm in writing, not from a salesperson’s recollection.
2. Which single field will match records between them, and how clean is it today?
3. Which system wins for each field that both hold?
4. What happens when the sync fails: who is told, and how do we catch up the backlog?
5. Who maintains this when one vendor changes their API, and what does that cost annually?

The last question is the one that separates a system still running in three years from one that broke quietly in month seven and was replaced by a person with a spreadsheet, which is, almost always, exactly where you started.