Stop typing the same data twice: getting your software to talk to each other
If your team copies the same customer, order or invoice from one program into another, you may not need new software at all. You may just need your existing programs connected. Here is what to think about first.
By KendratekPublished Updated 4 min read
Key points
- Decide which program is the "master" for each kind of information. Changes happen there and nowhere else.
- Use the official connection the software provides, not shortcuts that break with the next update.
- Things will go wrong sometimes. Make sure someone finds out straight away, not weeks later.
- Someone in your business should own each connection, not just the developer who built it.
Most businesses use several programs, and each one does its job reasonably well. Maybe it's accounting software like Tally, a customer list in a CRM, a stock system, an online store, or something built in-house years ago.
The trouble is in between them. The same customer gets typed in three times. Orders are exported, fixed up in Excel and imported somewhere else. And nobody is quite sure which program has the right price.
You rarely need to throw all that out and start again. Often it's quicker, cheaper and much less disruptive to connect what you already have, so information flows from one program to the next by itself. But it needs a little planning. Here's a checklist.
1. Decide which program is the "master" for each thing
For each kind of information (customers, products, prices, orders, invoices, stock), pick one program where it lives. Other programs can show it and use it, but changes are only made in that one place. Skip this step, and you'll end up with two programs overwriting each other's changes.
A typical setup looks like this:
- Customer details: usually the CRM or the accounting software.
- Products and price list: usually the stock or ERP system.
- Invoices and payments: almost always the accounting software.
- Order status: whichever program your operations team works in every day.
2. Describe each connection in one plain sentence
Before anyone writes code, write each connection as a sentence. For example: "When an order is approved, create a draft invoice in Tally with the customer, items and amounts." Then note down:
- What starts it: something happening, a set time each day, or someone pressing a button.
- Which way it goes: one way, or both ways (and if both, which program wins for each detail).
- Exactly which details move, and how codes in one program match codes in the other.
- How fast it has to happen: instantly, every few minutes, or overnight.
- What should happen if the other program refuses the data.
3. Use the official way in
Most modern business software has an official, supported way for other programs to send and receive data. Developers call it an API. Use it wherever it exists.
Avoid shortcuts like a robot that clicks through screens pretending to be a person, or writing straight into another product's database behind its back. They tend to break whenever the software updates, and the vendor may refuse to support you afterwards.
Older programs sometimes have no API. Then a simple, well-organized file exchange often works better than anything clever. That means an agreed file format, saved in a fixed place, and checked before it's loaded.
4. Plan for things going wrong
The internet drops. Software goes down for maintenance. Someone enters a customer code that doesn't exist in the other program. A good connection expects this and handles it calmly:
- It tries again if something fails temporarily.
- It never doubles up, so trying again doesn't create a second invoice.
- It keeps a record of what was sent, when, and whether it worked.
- It tells a named person when something keeps failing, instead of failing quietly.
- It lets you fix and resend an item yourself, without calling a developer.
5. Keep it secure
- Give each connection its own login with only the access it needs, not an administrator's password.
- Keep passwords and keys somewhere secure. Never in a spreadsheet or an email.
- Make sure data is encrypted as it travels, and think carefully before personal details move between programs.
- When staff or suppliers change, check who still has access.
6. Make someone responsible
A connection between programs is a small system in its own right. Someone in your business should:
- know it exists and understand, in plain words, what it does;
- receive its warnings;
- decide what happens when a rule needs to change.
Write down how it works, what it connects, where the passwords are kept and what to do when it breaks. Write it for the next person, not for the developer who built it.
When connecting isn't enough
Sometimes most of the work happens in the gaps between programs, or the number of connections keeps growing to cover a job none of your software really handles. Then it may be time for one focused application that does that job properly and connects to everything else. Our system integration work often starts with a connection and grows into that, step by step and on purpose.
If your team retypes data from one program into another today, tell us which programs are involved and how the work moves between them.