Your Systems Are Already Joined, by Files, Scripts and Spreadsheets. Here Is the Benchmark We Would Set.

At month end the accounts team finds three days of consignments that were never invoiced. They were booked and delivered. They were never billed.

It takes a day to find out why. Every night at two, a small program copies the day’s consignments from the booking system to the accounts package. Eleven nights ago it stopped. It raised no alarm, because it was never built to.

The program was written eight years ago by a contractor nobody can now name. It is not on any list of the firm’s systems. Until this week, nobody in the building knew it existed.

What We Found

We looked for public evidence on how firms in this sector join their systems when the systems do not share on their own, and on what it costs when a join fails.

First, what we did not find: no public evidence at all on the scripts, timed files and spreadsheets that join booking, dispatch, tracking and billing systems in this sector. No count, no case and no cost. What follows is the nearest the record comes, and it is about something a little different.

Much of the joining in this sector is done by hand. Two software vendors’ co-founders, quoted in the Indian trade press in 2025, said that the great majority of Indian warehouses still run without any dedicated supply chain software, and most small firms still rely on paper, messaging apps and spreadsheets. A freight software vendor’s own research from 2023 found that about a quarter of the few dozen freight forwarders, logistics providers and ocean freight intermediaries it surveyed still worked entirely by hand; the source states no country.

Those figures describe firms with little or no software, not firms with old software. We give them for one reason: where systems are few or do not meet, the spreadsheet and the message are the joins. A firm with four systems usually has both kinds, the ones a program makes and the ones a person makes.

Old systems are widely seen as hard to fit with newer ones. In one cross-sector survey of about 500 IT professionals in the US, which is not about this sector, about two in five named incompatibility with modern systems or tools among the top issues with their old systems.

What a List of Your Joins Opens Up

A list of the places where data crosses between systems is usually seen as the technology team’s homework. Our reading is that it frees more than that team.

• Failures get an owner. A stopped file becomes someone’s job before it becomes missing invoices at month end or a missing delivery note at the depot.
• Mismatches get a cause. An invoice weight that is not the carried weight is traced to the crossing where it changed, and not blamed on “the systems”.
• Change becomes possible. A join that is written down can be altered when a system is updated. An unknown one can only be avoided, with everything it touches.
• The hand-offs get counted. The copying that staff do between screens is real work. Once it is listed, it can be reduced stage by stage, and the people doing it move from copying to checking.

This is our reading. It is not a measured market figure.

Three Ways to Look After the Joins You Have, Weighed

Option	When it fits	What it risks
Fix each join when it fails	There are few joins, and the people who made them are still there	Each failure is found by its effects, often days later. Each repair adds one more rule nobody wrote down
Put a connection or integration product across the systems, bought from a supplier or built for you, and move the joins onto it	The joins are already known, and the systems at each end are sound	The joins nobody listed are not moved, and keep running beside it. Someone must run and watch it. This is your choice and another firm’s product; we have none
List every join, give each an owner on your side, and rebuild the ones that matter as modules	The systems are used every day, and some joins carry rules the business depends on	It takes stages and costs money before anything is rebuilt. Some joins will be missed until they fail

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Joins between systems, by program and by hand	Known in parts, to the people who make them	Every one listed: what it carries, from where to where, how often, and whether a program or a person makes it	The map of the system as it stands
Mismatches between systems	Blamed on “the systems”	Each kind traced to the join that causes it	The risk register
An owner for each join	Nobody, or whoever set it up	A named owner on your side for every join	The list beside the specification
The rules each join applies	Known only to the code or the person	Written in plain words, each marked keep, correct or retire by the business	The specification
The joins that matter	Left alone, because they work	Rebuilt as modules, each proven against what it replaces	The traceability matrix
The size of one commitment	A new platform, or nothing	One module, with the freedom to pause after any accepted module	The staged plan

The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a logistics, travel or hospitality firm.

A small part of the finished list might look like this.

Join	Made by	Owner	Status
Consignments from booking to accounts	A nightly program on a spare machine	Finance controller	Its rules written down; rebuilt as a module and accepted in stage 1
Weights from the depot to dispatch	A clerk re-typing from the weighbridge slip	Head of operations	Counted; the depot’s figure named as the source; in the stage 2 plan
Status from dispatch to the customer portal	A timed file, once a night	Head of sales	Listed; in the stage 3 plan
Positions from the vehicles	Devices in the vehicles	Not ours	Outside our work

The rows above are an illustration, not taken from a real firm.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about your systems, the joins you know about, and the last one that stopped. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the booking, dispatch, tracking or billing application your firm built or had built, and the places where it meets your other systems. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the joins that matter, rebuilt as modules. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This has a price. Finding the joins takes patience, and some will be missed until they fail, because nobody remembers them. Joins made by hand appear in no code, so only your staff can point to them; they are the finding, never the fault. Writing down the rules will turn up some that nobody can explain and some that are wrong, and each needs a decision from the business. A spreadsheet that rests on someone’s judgement is not wholly replaced by a program. We have no connection or integration product. We do not run, host or monitor the joins or the rebuilt modules; your own team does, and the owner on each line is someone on your side. We cannot change another supplier’s packaged product; where one sits at the end of a join, we work only with what it already lets other programs send and receive, and if it changes, the join must change too. We do not clean, correct or reconcile the records that already disagree, or what went astray while a join was down; your own people put those right. We do not work on the systems that run aircraft, trains or vehicles. None of this makes several systems into one. We have no published case of this work for a logistics, travel or hospitality firm.

At the end you hold the list of joins with an owner beside each, the specification, the traceability matrix for every module we rebuilt, the code of those modules, and the filled-in benchmark.

What changes for the business:

Role	What they gain
CEO	The business no longer depends on a nightly file and a spreadsheet that one person understands.
CTO or CIO	Every script, timed file and spreadsheet that joins the systems is written down with an owner, and every join rebuilt as a module is proven against the old one.
CFO	The joins that carry consignments into billing are on a list with an owner, so a stopped one is someone’s job before it becomes missing invoices at month end.
COO	Every join the depots depend on is on a list with an owner on the firm’s side, and operations is no longer the first to notice from the paperwork.
Head of sales and marketing	What customers and agents are told about a booking comes from joins the firm knows it has, each with an owner.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
In a vendor’s 2023 research, about a quarter of the freight forwarders and logistics providers it surveyed still worked entirely by hand.	We have no connection product and do not supply freight software. For a firm’s own applications, we list the joins its systems already depend on, including those done by hand, and rebuild the ones that matter as modules.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The next time a join stops, the firm should already know it exists and who owns it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →