Entering the same data into multiple systems? You probably don't need new software
An order ends up in invoicing, CRM, inventory and then Excel. When the same information is entered three times, the problem is rarely the software. It's the connection between the systems.
An order comes in through the website.
Someone opens it and copies the customer details into the invoicing system. Then they update the CRM. They check stock somewhere else. At the end of the month, a few of the same numbers are entered into Excel for reporting.
None of these steps is difficult. That is exactly why a process like this can remain unchanged for years.
The real cost is not the few minutes spent copying data. It is what comes afterwards: an address mistyped in one system, a price updated in the shop but not in the quote, a payment marked in one application and forgotten in another.
And, sooner or later, the question nobody can answer quickly:
Which of the four versions is the right one?
The answer is rarely a new ERP. Often, it is an integration between the systems you already use.
Where this usually happens
The software differs from one company to another. The pattern does not:
- Orders from WooCommerce, Shopify or a marketplace are invoiced manually in another system.
- A salesperson enters customer details into the CRM, then somebody else copies them into a contract.
- A delivery status changes in one system and is manually entered into Excel for management reporting.
- A payment appears in the bank account and somebody has to mark the corresponding invoice as paid.
- A price or stock level changes in one place and has to be updated everywhere else.
There is one question that tends to expose these situations:
Where does somebody enter the same information for the second time?
Sometimes there is a good reason.
Very often, the answer is simply: “That is how we have always done it.”
That is a good place to look more closely.
What an integration actually does
Today, the information might move like this:
Online shop → person → invoicing → person → CRM → person → Excel
After an integration, the people no longer have to sit between the systems:
Online shop → invoicing, CRM, Excel
A new order can automatically trigger the creation of a customer record, the invoice, the stock update and the reporting update.
People remain involved where judgement actually matters: an unusual order, a customer asking for something different, an exception.
Technically, the connection is usually made through an API — a way for one application to ask another, “give me order 123”, or tell it, “issue the invoice for order 123”.
Many commerce, invoicing and CRM platforms offer APIs or other integration methods. Where an API is not available, file exports and imports are often an option. They are less elegant, but in many cases they are perfectly sufficient.
The part most integrations skip
Connecting two systems technically is often the easier part.
The decisions below determine whether the integration removes a problem or creates a new one.
Which system is the source of truth?
For each type of data, one system needs to be the source of truth.
The price is managed in the online shop or in the inventory system — not independently in both. Customer data also needs a primary system.
If you do not decide this upfront, the integration does not eliminate the four versions of the data.
It simply synchronises them faster — including the wrong ones.
Which way does the data flow?
A one-way synchronisation, where an order moves from the shop into invoicing and stops there, is relatively simple and predictable.
Two-way synchronisation is where things become more complicated.
If somebody changes a customer’s address in the CRM while the customer changes it in their account on the website, which update wins?
There is an answer to that question.
But it needs to be decided before an invoice is sent to the wrong address, not afterwards.
What happens when something fails?
Every integration should be designed on the assumption that, eventually, something will fail.
An application changes its API. A connection expires. A service becomes unavailable for an hour.
When a manual process breaks, somebody usually notices because a person is still involved.
A silent integration failure can be more dangerous because, by that point, nobody is checking every transaction manually.
Invoices stop being generated, and somebody discovers it three days later because a customer asks about one.
That is why a good integration needs three things from the start:
an alert when something goes wrong;
a safe way to retry failed operations without creating duplicates;
and a clearly defined person or team responsible for responding.
How do the other systems know something has changed?
A cancelled order.
A return.
A cancelled or corrected invoice.
The happy path — from an order to an invoice — is usually the easy part to automate.
What happens afterwards is what often gets forgotten.
If the integration can only create records but cannot update or correct them, people will end up fixing things manually again — except now they may have to fix them in several places.
Integration or new software?
New software makes sense when the current system can no longer support the way you work: it is missing capabilities you need every day, it is no longer maintained, or it cannot handle your volume.
But if each application does its job well and the only problem is that information moves manually between them, replacing those systems may be solving a much larger problem than the one you actually have.
An ERP migration can take months and change how everyone works.
An integration may take days or weeks, depending on the systems involved and the exceptions that need to be handled.
Is the problem the software — or the connection between the systems?
Not every connection is worth building either.
We covered the warning signs separately in What we would tell you not to automate: a transfer that happens twice a month, incorrect data at the source, or a process that changes every week.
What you can check yourself in an hour
Choose a process that happens regularly — an order, a quote, an invoice or a new customer — and follow the information from the first system to the last.
Write down:
- Where is the information entered for the first time?
- In how many other places is it entered again?
- Who transfers it, and how long does that take?
- What happens if somebody copies it incorrectly, and who notices?
- Which system should be the source of truth?
- When the information changes, how do the other systems find out?
If you find the same field being typed manually into three places, you probably have a good candidate for integration.
Short of an hour? What to automate first asks the same questions and answers them in two minutes.
If you cannot answer question five, there is something to clarify before you integrate anything.
What does the manual work really cost?
Suppose you process 40 orders a day and each one takes two minutes to get the information into the other systems.
For a single order, that sounds insignificant.
Across a day, it is 80 minutes.
Across a week, nearly seven hours — almost a full working day.
Across a year, using 46 working weeks, it adds up to more than 300 hours.
And that calculation does not include the time spent finding and correcting discrepancies between systems — work that usually appears in no report at all.
The difference between manual and automated work is not obvious on one order.
It becomes obvious through repetition.
If you want to run the numbers for your own process, our task calculator starts with exactly these inputs.
How we approach it
We do not start with:
“You need custom software.”
We start with the flow.
Where does the information originate?
Where does it need to go?
Where is it copied manually?
Which system is the source of truth?
And what happens when the connection fails?
Only then do we choose the solution.
It might be an API integration, a simple automation between two applications, or a small service that translates data from one format into another.
The conclusion might also be that the current process is already good enough.
If you want to start with one specific process, our 20-minute check does exactly that: we look at what is being copied manually, which systems are involved, and whether connecting them is actually worth it.
And if it is not worth doing, we will tell you before we build anything.