A Record Your Staff Open Before They Pick Up the Phone. Here Is the Benchmark We Would Set.

The developer keeps a tally for a week, out of curiosity. Twenty calls a day, on average.

Dispatch wants to know why the system put a certain driver on a certain route. Reservations asks why a rate did not apply. Accounts asks what a code on an invoice means. Each call takes ten minutes, and each caller is grateful.

There is a manual, as it happens. It was written when the system was new. It sits in a binder on a shelf, and nobody has opened it since the second year, because by then it was wrong.

What We Found

We looked at the public record on documentation that falls out of step with the systems it describes, and at one warning about documentation produced in a hurry. None of it is about logistics, travel or hospitality: the research behind this article holds no named firm in this sector and no figure for it, and every fact below is labelled cross-sector.

Documents that no longer match the system are common, and they do harm. In one vendor’s survey of several hundred technology leaders and practitioners in the US and UK, more than nine in ten reported harm to the business from a gap between the architecture as built and the documented standards. The survey is about software in general, not about booking rules.

Old systems are still the normal case. In another vendor’s survey of about 500 IT professionals in the US, about three in five organisations still use legacy systems.

A record nobody has checked can be worse than none. One engineer who expects to maintain a legacy codebase for years, writing on a developers’ forum about documentation colleagues had produced with AI tools, called it simply wrong, made up from start to finish, and added that sometimes no document is better than a bad one. It is one person’s account. We give it because it is the right warning about any record that nobody has checked.

Our reading: most firms have tried documentation once. It was written as a project, organised by screen and menu rather than by the questions staff ask, owned by nobody, and not changed when the system changed. After its first wrong answer, people went back to the person.

What a Record People Use Opens Up

A record of an old system is usually seen as the technology team’s homework. Our reading is that it frees more.

• The expert’s day comes back. Questions a page can answer stop reaching one telephone.
• Staff can answer a customer. Reservations, dispatch and accounts read why the system did what it did, and say so on the call.
• New joiners learn from a document, and not only by sitting beside whoever has been there longest.

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

Three Ways to Keep the Answers Out of One Person’s Phone, Weighed

Option	When it fits	What it risks
Write a manual as a project, approve it and file it	The system will not change again	The system changes and the manual does not; after its first wrong answer nobody opens it
Put an ask-the-system tool over whatever documents and code exist	The documents underneath are already checked and current	It can be no better than what it draws on; over an unchecked record it gives wrong answers faster. We do not offer one
A specification checked against the code and confirmed by your own experts, held by your firm, with a named owner on your side who keeps it current	The system matters, keeps changing, and staff ask about it every day	It costs money and your experts’ time now, and the owner is a cost every year, not once

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the specification is written, and fill in as it is confirmed and as any module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Rules behind fares, schedules and cancellation charges	In the code, or in a binder nobody trusts	Written down in plain words and confirmed by your own experts	The specification, with who confirmed each part
Questions only one person can answer	Not counted; “about twenty calls a day”	Counted, and falling at every review	Your own count, reported at every review
Where the record lives	In one person’s head, or a supplier’s files	Held by your firm, in a form any competent engineer or supplier can work from	The specification, handed over
Who keeps it current	Nobody	A named owner on your side, with time set aside	Your own arrangement; we do not keep it for you
The size of one commitment	A full documentation project, or nothing	The specification first; one module at a time if a rebuild follows, with the freedom to pause after any accepted module	The staged plan
Modules moved off the scarce technology, if you choose to	None	Each one written from the specification and shown to do what the old one did	The traceability matrix, module by module

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 a finished specification might look like this.

The question staff ask	The rule, in plain words	Confirmed by	Status
Why did this booking get that cancellation charge?	Group bookings of ten or more cancelled within 21 days are charged the group rate	Head of reservations	Confirmed; the business decided to keep it
Why was this driver put on that route?	Drivers are matched to vehicles by licence class first, then by home depot	Dispatch manager	Confirmed
What does code G7 on an invoice mean?	Not known: the code is set in one place and read nowhere	Nobody yet	Listed in the risk register for the business to decide

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 the application, the questions staff ask about it, and who answers them. 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, scheduling or dispatch application your firm built or had built, in one of the technologies we read: VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, and .NET Framework or classic ASP. 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 moving the parts you choose off the scarce technology, each new module written from the specification. 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 the specification is confirmed and 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. The record needs an owner for as long as the system lives, and that is a cost every year, not once. Changes made to the system by your own team or another supplier will make it stale unless they update it too. It will not answer in conversation: people have to look things up, and we offer no assistant to do it for them. We do not keep the record current, and we do not maintain, patch or run the old application; your own team or supplier does. We are not a staffing firm, and we supply nobody to own the record. We do not read COBOL, RPG, FoxPro or the languages of mainframe booking engines. We do not work inside a packaged reservation, booking or property management product, and we do not work on the systems that run aircraft, trains or vehicles. We have no published case of this work for a logistics, travel or hospitality firm.

At the end you hold the specification, confirmed by your own people, the risk register, and, for every module we rebuilt, the traceability matrix and the code. Keeping the record true, and deciding what comes next, are your firm’s.

What changes for the business:

Role	What they gain
CEO	The record is still true a year later, because someone in the firm owns it, so the firm does not slide back to asking one person.
CTO or CIO	The record is the first place the team looks, and no change to the system is counted as finished until the record matches it.
CFO	The record is paid for once and kept up by the firm as routine, and does not have to be bought again after each change of staff.
COO	Supervisors answer most questions about the system themselves, from a record their own firm keeps current.
Head of people	New joiners in reservations and dispatch learn the system from a document, and not only by sitting beside whoever has been there longest.

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

The case	What IOanyT does
This article names no organisation: we found no named logistics, travel or hotel firm in this position. Its figures come from two cross-sector vendor surveys and one engineer’s account.	For applications in the technologies we read, we produce the specification, checked by our engineers and confirmed by your own experts, for your firm to hold and keep current. We offer no assistant, supply no staff, and do not maintain the old application.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write the record once and check it against the code; your firm keeps it true, and nobody has to ring the same person twenty times a day.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →