System integration for your company: how to connect your programs so data moves on its own

One order, five programs

An order lands in the online shop. A staff member retypes it into the stock program to book the goods out, then into the accounting package to issue the invoice, then onto the courier’s website to print the label. Finally they paste the tracking number into an email to the customer. Five programs, one order, and four places where something can go wrong.

The more orders come in, the longer the customer waits for a tracking number and the more often something does not add up: stock says 12, the shelf holds 9, and the invoice went to the old address because the customer changed it in the shop and the change never reached the other programs.

I see the same picture in service and manufacturing companies, only with different programs. The CRM does not know the customer has paid. The production program does not know sales moved the deadline. The month-end summary is stitched together from three exports and never comes out right the first time.

What “connecting programs” means

A connection is an agreement between two programs: at this moment, program A sends this data to program B, in this shape, and program B knows what to do with it. An order paid in the shop appears within a minute in the warehouse as a picking document, in accounting as an invoice, at the courier as a shipment. No person is involved. A person only gets a list of exceptions: an order with no house number, a product that is out of stock, a payment that has not arrived.

A connection does not replace the programs. The shop is still the shop, accounting is still accounting. One thing changes: data is entered once, where it originates, and from there it moves on by itself.

Three ways to connect programs

Programs differ in how far they let you connect to them. In practice there are three routes.

A direct connection

Many programs written in the last few years offer a connection through which another program can fetch and send data. Online shops, courier systems, payment providers, popular invoicing tools. This is the best route: data moves immediately, and every transfer gets a confirmation that it arrived.

File exchange

Older programs, especially stock and accounting packages, often can only load and export a file. Then the connection runs at set times: at 6:00 the program picks up the orders file, at 18:00 it sends the stock file. The data is not instant, but often a few exchanges a day is plenty.

A robot clicking in place of a person

The last resort, when a program has neither a connection nor an export and file exchange is not an option. A program pretending to be an employee logs in, fills in fields and clicks. It works until the vendor changes the screen layout. I only build this when there is no other way, and I say plainly what risk it carries. More on the page about programs that cannot connect.

Typical flows in a company

The connections companies of 10 to 250 people ask about most often:

• Shop, warehouse, accounting, courier. An order entered in one place reaches everywhere it needs to go. Described in detail on the page about connecting an online shop.
• Your own system and the accounting package. Invoices issued from the system go to accounting, and payments from the bank come back to the system. Details on the page about accounting integration.
• CRM and the rest of the company. A salesperson sees in the CRM whether the customer has paid and what they ordered, without asking the bookkeeper.
• Website form and customer service. An enquiry from the website creates a ticket, assigns a person and sends the customer a confirmation.
• Supplier and manufacturer systems. Price lists and stock levels pulled from supplier portals on their own, on a schedule.
• Devices in the field. Data from sensors, scales, scanners or GPS receivers reaching the system as it happens. In the container terminal system data from the yard reaches the system as it happens, and the screen shows where every container stands.

When one program sits in the middle

With three programs, connections between them are enough. With six you get a web in which nobody knows where a value came from. Then it is better to put one program in the middle: your own system, with everything else connected to it.

The system in the middle holds one version of the truth about the customer, the order and the product. The shop, accounting and the courier take data from it and hand results back. Staff work on one screen instead of six. I build such a system from modules, meaning self-contained parts: order intake, warehouse, invoicing, dispatch. Each module connects a different program and can go live on its own. More on what that looks like in the guide on custom software and on the automation and integrations service page.

What can go wrong and how I prevent it

Data in two places. The customer changed their address in the shop and in the CRM, differently in each. Which one is right? Before building we agree, for every piece of data, one place that holds the truth, and the connection always flows from there, never both ways at once.

The program on the other side does not answer. The courier is down, accounting is mid-update. The connection remembers what it was meant to send and retries when the other side comes back. Nothing is lost and nothing goes twice.

Nobody knows what went through. Every connection has a log visible to staff, not only to a developer: what, when, where to, with what result. When a customer asks why they never got an invoice, the answer is on the screen, not a guess.

The vendor changed their program. If we agree on ongoing care, I check connections to external programs after each major update of theirs. Without care you get documentation and a log from which another developer can see what stopped working.

How it goes and how you pay

1. A call and a list of programs. Half an hour, online or at your place. You tell me which programs you use, who works in them and which data should flow between them. Then I check what kind of connection each one allows.
2. Scope in writing. I write down every flow step by step: what, from where, to where, when, and what happens on error. I give you the order, the timing and the prices, separately for each flow. We start with the flow that carries the most documents.
3. The first connection and trials on real data. The connection first runs alongside the way you work today until the numbers match on both sides. Then you stop doing it the old way.
4. Further connections and handover. You accept each one separately and pay after acceptance, usually at the end of the month. The code, the documentation and every credential pass to you with each stage you pay for, not only after the last invoice.

There is no price list on the site, because connecting a shop to an invoicing tool and connecting six programs through your own system in the middle are two different scopes. Prices come in writing once the flows are written down.

Tell me in the form below which programs you use and which data should flow between them on its own. I will get back to you with questions or a suggestion which connection to start with.