The Computer Arrives

Most people outside the recovery industry have little idea just how technologically advanced the average recovery control room has become. Fewer still realise the obstacles that had to be overcome to reach that point. I was fortunate enough to be involved from the beginning and witnessed first-hand the changes that transformed the way recovery operators received, managed and invoiced their work.

To understand why computers were embraced so quickly, it helps to appreciate how recovery work was administered in the early 1980s. There were numerous motoring organisations and work providers, each with their own charging structures. Most were based on a call-out fee and mileage rate, but the similarities often ended there.

Rates varied according to the time of day, location, vehicle type and the equipment used. Some schemes paid bonuses for repairs completed at the roadside. Commercial vehicle rates were divided into weight bands and frequently charged by the hour. No two organisations seemed to calculate their charges in quite the same way.

The result was that pricing was often left to a tired recovery driver, estimating mileages and trying to remember a bewildering range of special rates and allowances. Invoicing was frequently treated as a poor second to actually doing the job. One well-known Midlands operator was rumoured to visit National Breakdown each Christmas with a bottle of whisky in one hand and a carrier bag full of paper invoices in the other. Since this was first written, he has confirmed that the story was entirely true.

As Managing Director of National Rescue, I encountered these problems every day. It seemed obvious that a computer could perform the repetitive calculations far more accurately than any human operator, so I began teaching myself programming using BASIC on an Acorn computer.

Once I had mastered the fundamentals, I wrote a vehicle recovery program that automated much of the invoicing process. The effect was immediate. More work was billed correctly, administration time was reduced and the same staff could process significantly more jobs.

In 1985 I offered the program free of charge to fellow recovery operators through AVRO, then the industry's principal trade association. The article below appeared in AVRO News during 1986.

Motor Trade Software

Several companies adopted parts of the original program, but it soon became apparent that many operators needed more than software alone. Personal computers were still unfamiliar to much of the industry and there was a growing demand for a complete system that could be installed, supported and developed specifically for recovery operators.

Around this time the program was shown to Ian Lane, a gifted computer programmer who immediately recognised its potential. Ian agreed to redevelop the software for the emerging MS-DOS platform and together we began refining the concept into a practical business tool.

The result was BRCP (Breakdown and Recovery Control Package), the first software package written specifically for the vehicle recovery industry.

It quickly became obvious that the project could not be developed in spare evenings and weekends. Demand was growing rapidly and operators wanted both software and support.

Ian took the bold decision to leave his position at GEC Avionics and, together with my brother Geoff Lambert, formed Motor Trade Software, soon universally known throughout the industry as MTS.

The company's first offices occupied part of the north wing of the world-famous Brooklands Control Tower and Flying Club, shown here as it appeared during the 1980s.

BRCP Changes Everything

Today's recovery operators would probably struggle to imagine just how labour-intensive invoicing used to be. Every job was recorded by hand, often on several pieces of paper, before being manually priced using printed rate tables. To make matters worse, almost every motoring organisation used its own charging structure.

Many clubs also supplied their own paperwork, some of which doubled as an invoice. There was no standardisation. Every organisation wanted its forms to look different from those of its competitors. If the paperwork was lost or damaged while carrying out the recovery, there was a very real chance that the job would simply be forgotten and never invoiced.

In simple terms, you could complete the work and never get paid for it.

BRCP provided a practical solution. As soon as a call arrived, the operator pressed the F1 key and created a new job record while still taking the details. From that moment the job existed within the system and remained there until it was invoiced.

Colin Bailey of Southbank Recovery, one of the earliest users, later remarked that this feature alone paid for the software within the first few months.

One of the advertisements used by Motor Trade Software during this period struck a chord with many smaller operators. It depicted a man trying to do everything himself, juggling endless demands with little help from either staff or customers.

Brian Watson, owner of 3B's Rescue of Banbury, then in his sixties, used to laugh and say:

"I look and feel just like him, it's just that I'm a little more handsome and very much younger."

Once the telephone call had finished, the remaining details could be entered into the system. Job sheets were printed for the driver and, when the recovery was complete, the operator simply entered the mileage travelled — usually adding a couple for luck!

The software then calculated the correct rate using the built-in charging structures for the various motoring organisations. It automatically applied VAT and reminded the user about additional charges such as London loading, winching fees and other extras that were easily forgotten when working manually.

If the correct job time had been entered, the software would also apply the appropriate call-out and time-based rates. Changing the customer automatically recalculated the figures, allowing operators for the first time to compare the profitability of different contracts.

For night-time work, all the owner needed to do the following morning was check the details, correct any missed mileage or bonus payments and press F4 to produce an invoice.

Today that sounds entirely normal, but at the time it represented a significant change in the way recovery businesses operated. Hours of paperwork disappeared and much of the reliance on scraps of paper, notebooks and memory was removed.

Building on the success of BRCP, the team turned their attention to vehicle storage, workshop management and repair administration. The result was Garage Manager, an MS-DOS package launched in 1992.

Designed specifically for recovery operators and garages, Garage Manager proved an immediate success. Over the next decade approximately 1,200 copies were sold throughout the United Kingdom.

The Move to Windows

By the early 1990s the computer world was changing rapidly. Microsoft's Windows operating system was increasingly being supplied as standard on new computers and, although many recovery operators preferred the speed and simplicity of DOS for day-to-day job logging, it was clear that the future lay elsewhere.

In the end MTS bowed to the inevitable and began work on a Windows version of Garage Manager. The project was led by a young programmer named Stuart Johnson, assisted by Ian Lane.

Stuart did not have Ian's recovery industry background and was also constrained by the more structured Windows environment. As a result, some long-standing users felt that the new version took a little longer to master than its DOS predecessor.

Looking back, however, most users would agree that the decision was the correct one. Windows opened the door to features that were either difficult or impossible to implement under DOS.

Digital photographs could now be attached to vehicle records, allowing operators to record the condition of a casualty before recovery commenced. These images could be stored against the vehicle registration number and later used to answer customer or motoring organisation queries.

Later versions also integrated mapping systems, enabling operators to view the location of a casualty and, in time, the progress of the recovery vehicle travelling to the scene.

Perhaps most importantly, Windows made it far easier to connect multiple computers together. Networking would prove to be one of the most significant developments in the history of recovery control rooms.

Although MTS had been the first company to develop a software package specifically for the recovery industry, it would not have the market to itself for long.

In 1988 Sensible Computing launched its VTAR package, which would later evolve into VTRAK. The following year System Workshops introduced Recover IT, while at the 1989 AVRO Show Recovery Management Systems launched Recovery Package and DMW introduced ROSCO.

The following year Yezerski Roper released its RIMS system, while Superior Systems entered the market with Autogarage Manager.

A number of other software suppliers would appear over the years, but only two survived into the new millennium: MTS and Sensible Computing. By the time this history was first written in 2006, both companies remained active, although under new management and trading as Motor Trade Technologies and Laser Byte respectively.

MTS Flex Their Muscles

In 1991 the AA approached MTS with what seemed a fairly straightforward request. Could the company produce a computer-generated form that matched the layout of the AA's existing job completion paperwork?

Ian Lane looked at the problem and replied that it could certainly be done, but then asked a much more important question:

"Why do we need to put it on paper?"

Instead of reproducing an existing paper process, Ian suggested that completed jobs and invoices should be transferred electronically. The AA replied that it could not justify the cost of developing such a system.

MTS responded with an offer that would have far-reaching consequences. The company agreed to develop the system at its own expense on one condition: it had to be created as an open standard that could be used by other motoring organisations as well.

For the first time MTS used its unique position as the industry's principal software supplier to encourage a motoring organisation to adopt a solution that benefited the wider recovery industry. Fortunately the AA agreed, seeing no commercial conflict in the proposal.

The result was the first building block of what would become a common electronic communications standard for vehicle recovery.

Enter Mobitex

Having established the first foundations of a common electronic standard, MTS began looking at an even bigger challenge. If completed jobs and invoices could be transferred electronically, why not send the job itself directly to the recovery vehicle?

During 1992 the company began experimenting with the idea of transmitting recovery jobs over radio. The early trials proved that the concept worked, but achieving reliable results at a price operators could afford seemed almost impossible.

Then fortune intervened. MTS made contact with Karen Scott at RAM Mobile Data, who introduced the team to an exceptionally reliable packet-radio network called Mobitex.

Unlike conventional voice radio systems, Mobitex was designed specifically for data transmission. Messages could be sent electronically between computers and mobile terminals, opening up possibilities that had previously seemed beyond reach.

Initial trials soon began with several forward-thinking MTS customers, including C & S Motors, Groves Towing, Queens Motors and Southbank Recovery.

Those pioneering operators were unknowingly taking part in the earliest experiments of what would eventually become Turbo Dispatch, a system that would go on to transform the way recovery work was allocated and managed throughout the United Kingdom.

At the time, however, few people appreciated just how significant these developments would become.

Before examining Turbo Dispatch's often painful and occasionally turbulent birth, it is necessary to step back for a moment and understand the state of the recovery industry during the early 1990s.

The Need for Standards

To understand why Turbo Dispatch would prove so controversial, it is first necessary to understand how recovery work was still being administered during the early 1990s.

Despite the growing use of computers, much of the process remained remarkably inefficient. Job details were still being taken over the telephone and every motoring organisation seemed to have its own preferred sequence for recording information. Registration numbers, vehicle descriptions, locations and member details often arrived in a different order depending upon who was placing the call.

As a result, many controllers continued to jot details on pads, notebooks and, all too often, scraps of paper before re-entering the information into their computer systems. This was manageable on a quiet day, but far less efficient when control rooms became busy and telephones were ringing continuously.

At the other end of the process, progress was equally uneven. The AA had begun accepting completed job details on floppy disk, while National Breakdown (soon to become Green Flag) and Britannia were considering similar approaches.

Having spent many years running National Rescue's control room, I could see a much bigger opportunity. If the industry could agree common standards for exchanging information, there was no reason why the same details should be repeatedly written down, re-keyed and passed between different organisations.

The problem was that common standards required cooperation. Left to themselves, most organisations would naturally design systems around their own requirements. The industry needed a forum where competing organisations could sit down together and discuss the bigger picture.

Fortunately there were a handful of people within the major motoring organisations who recognised the same opportunity. They understood that improving communications would benefit everyone involved, from the clubs themselves to the recovery operators carrying out the work.

With this in mind, invitations were issued for what would become a remarkably important meeting.

The Brooklands Meeting

On a warm summer's day in June 1994, representatives from the major motoring organisations gathered at Brooklands Museum in Surrey, adjacent to the offices of MTS. Looking back, the meeting seems an obvious step, but at the time it was anything but.

The recovery industry had grown up around fierce competition. The AA, RAC, Britannia, National Breakdown and other organisations all had their own systems, procedures and ways of working. While they occasionally crossed paths, it was unusual to find them all sitting in the same room discussing a common objective.

To encourage attendance, the visitors were first treated to a tour of Brooklands. The opportunity to explore parts of the historic site not normally open to the public may have helped persuade a few people to accept the invitation. After all, few enthusiasts can resist the chance to spend time amongst historic aircraft, racing cars and engineering history.

Whatever the reason, the approach worked. For the first time representatives of the industry's major work providers sat down together to discuss the possibility of developing common standards for exchanging information.

Present that day were representatives from the AA, Britannia, Europ Assistance, National Breakdown and the RAC. Also attending was Colin Parlett, representing the neutral Institute of Vehicle Recovery (IVR) and myself.

The objective was simple: to investigate whether the industry could adopt common standards for the exchange of electronic information. Such standards would reduce duplication, improve accuracy and ultimately make life easier for both recovery operators and motoring organisations.

At the time nobody could have known just how important those discussions would become. The agreements reached during the following months laid the foundations for many of the electronic communication systems that would follow.

More importantly, the meeting demonstrated that even long standing rivals could work together when a proposal offered genuine benefits to the industry as a whole.

Turbo Dispatch Is Born

The Standards Committee meetings and the discussions that followed produced a number of important developments, but by far the most significant was the protocol that would eventually become known throughout the industry as Turbo Dispatch.

Although many people contributed ideas, there can be little doubt that it was Ian Lane who possessed both the technical ability and the foresight to create a communications standard that was sufficiently robust to survive, yet flexible enough to evolve with changing technology. Decades later, the principles he established remain at the heart of systems still in use throughout the recovery industry.

The committee also examined other areas where standardisation might benefit the industry. Universal fault codes and outcome codes were developed with some success. A common job clearance and customer satisfaction form was created and achieved widespread acceptance. Attempts to introduce common identification cards, however, achieved no success whatsoever.

Unfortunately not everyone shared the same commitment to a common standard. While participating in the discussions, the RAC continued developing its own alternative electronic transmission system known as EDI. When this became known it caused considerable disappointment and led some participants to question whether genuine industry cooperation was possible.

For a period the discussions stalled and communication between the parties largely ceased. Looking back, this was the first indication that creating an industry-wide standard would be far more difficult than many had hoped.

More worrying still, the RAC would not be the only organisation to challenge the concept. In the years that followed both the AA and National Breakdown would, for different reasons, attempt to steer the industry in other directions.

The Vision

The idea discussed at those standards meetings was both simple and revolutionary. Every control room involved in the recovery process would be linked electronically using a common communications standard.

Today such a concept seems entirely normal, but in the early 1990s it was remarkably ambitious. The proposed communications network would use the highly reliable Mobitex packet-radio system operated by RAM Mobile Data, chosen because of the impressive results already achieved during MTS field trials.

The process was designed to work as follows:

1. A stranded motorist contacts the police or other authority, who records the details electronically.
2. Those details are transmitted in Turbo Dispatch format to the relevant motoring organisation.
3. The motoring organisation verifies membership and forwards the job electronically to its local recovery agent.
4. The garage computer automatically creates a new job record, eliminating repeated telephone calls and repeated keyboard entry.

The most obvious benefit was speed, but accuracy was a very close second. Information only needed to be entered once, dramatically reducing the risk of misunderstandings, incorrect locations and transcription errors.

Controllers also gained greater flexibility. Unlike a telephone call, an electronic job could wait a few moments while the operator completed another task. Visual and audio alerts ensured that incoming work was not overlooked.

Once implemented, processes that previously took ten to twenty minutes were often completed in less than five. Automatic acknowledgements monitored the progress of each transmission and alerted users whenever the communication chain was broken.

One warning became particularly famous throughout the industry. Incoming jobs generated a distinctive gong sound, universally known as "the bong". If ignored, a spoken warning became increasingly persistent until the job was dealt with.

Only a handful of customers ever discovered that the increasingly insistent voice belonged to my wife, Christine Lambert.

Completing the Circle

The electronic transfer of jobs between control rooms was only the first part of the vision. The second was far more ambitious. If a job could be sent electronically to a recovery operator, why should the flow of information stop there?

The next stage was to extend the communication chain all the way to the recovery vehicle itself. Using the Mobitex network, controllers could select a vehicle within Garage Manager and transmit the job directly to a mobile data terminal installed in the cab.

Once received, the driver no longer needed to rely solely on voice radio instructions or handwritten notes. The job details appeared electronically and could be reviewed at any time during the recovery.

The benefits did not end there. When the vehicle arrived on scene, the driver could transmit an On Scene message back to the control room. This information could, if required, be passed all the way back through the chain to the originating motoring organisation and even the police.

Once the incident had been resolved, an outcome code could be transmitted in the same way, allowing everyone involved to know whether the vehicle had been repaired, recovered or otherwise dealt with.

The final stages were equally ambitious. After the garage completed its invoicing, the invoice itself could be sent electronically to the motoring organisation. Once payment had been authorised, a remittance advice could be returned electronically to the recovery operator.

Garage Manager was designed to process this information automatically. Matching invoices could be cleared from the sales ledger without manual intervention, leaving only disputed or unpaid accounts requiring attention.

Looking back today, such processes seem entirely normal. Modern internet-based systems perform these tasks every day. In the early 1990s, however, the concept was remarkably advanced. The aim was nothing less than a fully connected recovery industry, with information flowing electronically from the first report of a breakdown to the final payment of the invoice.

Not every part of the original vision was implemented exactly as intended. The proposal for police forces to create and transmit the initial job was trialled by organisations including Durham Constabulary, Thames Valley Police and the Metropolitan Police, but never achieved widespread adoption.

Nevertheless, enough of the system was implemented to demonstrate that the concept worked. For the first time, the recovery industry could see a future in which information travelled faster than the telephone call that had traditionally carried it.

An Open Standard

Beyond the immediate benefits of faster job allocation and improved accuracy, the possibilities offered by Turbo Dispatch were almost limitless. Recovery operators could potentially exchange work electronically, arrange vehicle rendezvous and transfer loads between operators. Even the industry's long sought-after "return load" could be managed far more efficiently, improving utilisation and reducing wasted mileage.

There was, however, one obvious weakness. The Turbo Dispatch protocol had been developed largely by MTS and initially worked only with MTS software.

Rather than using this as a commercial advantage, MTS took a very different approach. The company declared Turbo Dispatch to be an open protocol and relinquished all claim to ownership. Any software supplier was free to implement the standard within their own products.

In an even more remarkable gesture, MTS proposed that the source code for the Turbo Dispatch communications program (TD.EXE) should be made available to the motoring organisations. In the event only Green Flag and the RAC accepted the offer.

The objective was simple. If Turbo Dispatch was to become an industry standard, it had to belong to the industry and not to a single software supplier.

How Turbo Dispatch Worked

This is not the place for a detailed technical specification, but the underlying concept was surprisingly straightforward.

Every item of information that might need to be transmitted was allocated a unique four-digit identifier. Messages were then created as plain text records, each line consisting of an identifier followed by the associated information.

Even from this simplified example it is easy to identify the date, time, customer, vehicle details and location. Real messages naturally contained many more fields.

When a message arrived, the receiving software simply read the identifiers and placed the associated information into the appropriate fields. The principle was deliberately uncomplicated.

By using plain text files stored in electronic "in" and "out" boxes, Turbo Dispatch remained independent of any particular software package or communications medium. While the Mobitex network provided the initial transport method, the protocol could equally be carried over future systems such as the Internet, GPRS or TETRA.

During 1995 both Delta Rescue and Green Flag purchased suitable radio equipment and began conducting their own trials with operators already using mobile data terminals.

The first genuine breakdown job transmitted from a motoring organisation to a recovery operator using Turbo Dispatch was sent by Green Flag to Southbank Recovery in December 1995, just eighteen months after that first standards meeting at Brooklands.

Back Stabbing and Dirty Deals

In many industries such a breakthrough would have been followed by rapid development and widespread adoption. Vehicle recovery proved rather different.

It is important to stress that most of the people directly involved in developing the standards were genuinely committed to the concept. They saw little conflict between the various motoring organisations and generally believed that improving communication would benefit everyone.

As Brian Hagan of Green Flag often remarked:

"If Britannia do something to improve the service their agent supplies, it also improves our agent's service because they are usually the same guys."

Unfortunately the strongest opposition rarely came from the people attending standards meetings. It was more commonly found several layers higher within organisations, where decisions were often made by people with little direct experience of how the recovery industry actually worked.

During 1996 Green Flag unexpectedly halted further development work. Various explanations were offered at the time, although it later emerged that the decision had been taken at director level.

Rumours circulated that some individuals had begun to recognise the commercial value of controlling communications within the recovery industry and were exploring alternative approaches of their own.

Relations with the RAC were also becoming strained. The company had continued developing its own EDI system alongside the work of the standards committee. While EDI functioned adequately, it was seen by many operators as a proprietary solution rather than an industry standard.

Turbo Dispatch offered the prospect of a single terminal working for multiple motoring organisations. EDI offered no such advantage.

Matters came to a head when MTS was invited to a meeting with representatives of Paknet. It quickly became apparent that the discussion was not about technical standards but about who would ultimately control communications within the industry.

The meeting left a particularly strong impression on Ian Lane. Accustomed to solving problems through engineering and logic, he was unprepared for the suggestion that the outcome should be determined simply by the relative size of the organisations involved. For MTS, the issue was never about who was biggest; it was about creating the best solution for the industry.

Fortunately MTS was not alone. By this stage RAM Mobile Data (later Transcom), through long-time account manager and friend Laurie Bright, had become a strong supporter of the project. While there were undoubtedly commercial interests on all sides, Laurie and his colleagues consistently backed the principle of an open industry standard and offered MTS whatever assistance and protection they required.

It soon became clear to all the motoring organisations, through feedback from their representatives on the Standards Committee, that MTS would resist to the end anything other than a common industry-wide standard.

The AA eventually abandoned attempts to pursue alternative approaches and concentrated instead on producing an interface to the Turbo Dispatch standard. It is widely accepted that this was largely due to the influence of the AA's Evan Anderson, who could see advantages that others had missed.

Evan recognised that Turbo Dispatch was an open standard. Because the protocol was freely available to any software supplier, no single company could gain a monopoly over it. The success of the system depended upon everyone using the same language, regardless of whose software sat behind it.

This view was shared by many of the people directly involved with the project. They understood that a common standard increased choice rather than reducing it, allowing recovery operators, motoring organisations and software suppliers to work together without becoming dependent on a single provider.

By that winter the AA, Delta Rescue, Europ Assistance and Green Flag were all live and transmitting significant volumes of work over the air.

By the winter of 1997 the AA, Delta Rescue, Europ Assistance and Green Flag were all transmitting significant volumes of work via Turbo Dispatch.

Then, in March 1998, came perhaps the clearest endorsement yet. The AA's Bill Diegutis announced that agents using Turbo Dispatch would receive enhanced rates, worth up to fifteen per cent more in some circumstances.

It was one of the few occasions on which a motoring organisation directly shared some of the savings generated by improved technology with the recovery operators who had invested in it.

An Unexpected First

Before continuing with the final and most troubling part of the Turbo Dispatch story, one small but historic event deserves to be recorded.

By August 1997 a number of Queens Motors recovery vehicles had been equipped with Astir mobile data terminals and GPS tracking units linked to Turbo Dispatch. At the time this was still very much pioneering technology.

During one recovery a driver was working on a customer's vehicle when he suddenly heard his own recovery truck being driven away. The vehicle had been stolen. Police were immediately notified and, using location data supplied by Queens Motors' control room, the vehicle was intercepted and recovered just fifteen minutes later.

Today such an outcome would hardly raise an eyebrow, but in 1997 it was one of the earliest demonstrations of how vehicle tracking technology could be used in the recovery industry.

The Industry Decides

In the spring of 1999 the newly renamed Recovery Industry Communications Standards Group held its first meeting. Among the topics discussed was the forthcoming launch of a new communications product called Vehicle Recovery Manager, developed by Unipart and their partner Mobile Radio.

The product received considerable encouragement from the RAC and was promoted heavily within the industry. Nevertheless, recovery operators showed little interest and the anticipated take-up failed to materialise.

Unipart soon decided to concentrate on its core business and withdrew from the project. Shortly afterwards, Vodafone/Vodata and Mobile Radio relaunched Vehicle Recovery Manager as a joint offering.

Throughout this period many operators and software providers became increasingly concerned that commercial interests were threatening to fragment an industry that had worked hard to establish a common communications standard.

The clearest indication of this was the continued delay in the RAC's implementation of Turbo Dispatch, despite having participated in its development for several years. The RAC eventually issued a statement confirming its intention to support Turbo Dispatch once other development priorities had been completed.

In the end the industry made its own decision. Vehicle Recovery Manager failed to gain significant support and recovery operators continued to adopt Turbo Dispatch. Even companies that had initially pursued alternative solutions ultimately sought integration with the standard.

One such company was Eriksons Motoring Services, who eventually approached MTS to obtain Turbo Dispatch connectivity. Their management later expressed gratitude for the professional and fair manner in which they had been assisted, despite the political manoeuvring that had surrounded the project.

Following these events the original standards group began meeting once again and a degree of cautious cooperation returned. Discussions expanded into related areas, including the use of communications standards within the growing home-services sector being developed by several motoring organisations.

These meetings continued until the retirement of Ian Lane and Andy Lambert at the end of 2006. Thereafter the concept of regular group meetings gradually lost momentum and was replaced by more occasional discussions with individual software suppliers.

Finally, in 2000, after some six years of involvement with the standard, the RAC went live with Turbo Dispatch and joined the other major motoring organisations already using it.

For recovery operators the benefits were substantial. Work could be received instantly into whichever software package they chose to use, using a single communications link and a single set of airtime charges. Hours spent answering telephones and manually re-keying job details became a thing of the past.

Response times improved, controllers became more productive and operators were able to handle increasing workloads despite steadily tightening margins. Most importantly of all, the industry finally possessed a common communications standard that belonged to everyone.

The Road Not Taken

Yet it would be wrong to describe Turbo Dispatch as a complete victory. While the standard survived and became widely adopted, many of the features originally envisaged by its designers were never fully implemented.

Looking back, the industry chose to adopt those parts of the standard that delivered immediate benefits to the motoring organisations, while many of the features that would have saved recovery operators time and money were quietly left behind.

1. Apart from the AA's temporary incentive scheme, operators who invested in the technology received little direct financial assistance, despite the substantial savings enjoyed by the motoring organisations. During the London trials alone, the AA quoted savings of approximately £33,000 per month.
2. Paperless invoicing on the completion of the job using the Turbo Dispatch standard across all motoring organisations was never implemented.
3. Electronic payment remittance, allowing Garage Manager and similar systems to automatically reconcile invoices and clear sales ledgers, was never implemented despite being one of the greatest potential time-savers for recovery operators.
4. Automatic transmission of vehicle locations using latitude and longitude data, allowing casualties and attending recovery vehicles to be displayed together on a map, was properly implemented by only a small number of organisations.
5. Electronic messaging relating to job queries was never fully developed, meaning operators still had to telephone motoring organisations and wait in queues whenever a problem arose.
6. Integration with police systems never became a reality. Thames Valley Police and the Metropolitan Police both participated in early trials, but eventually abandoned the concept after waiting in vain for wider adoption.

None of this detracts from what Turbo Dispatch achieved. It transformed the way recovery work was allocated, reduced response times and eliminated vast amounts of duplicated effort. However, those who were involved from the beginning cannot help wondering what might have been achieved had the original vision been carried through to its conclusion.

The End of an Era

In 2006 Ian Lane and Andy Lambert, having spent more than twenty years helping to shape the technological development of the recovery industry, decided that the time had come to move on. MTS was sold and Ian retired from the business.

The final meeting of the Recovery Industry Standards Committee took place at Heathrow on 12 April 2006. Present were representatives from the AA, Britannia, Europ Assistance, GESA IPA, Green Flag, Mondial and the RAC. Also attending were representatives from C & S Motors, CMG and Queens Motors on behalf of the recovery operators, together with delegates from BT, MTS and the Police. Looking around the room it would have been difficult to imagine that the standard first discussed at Brooklands in 1994 would still be influencing the way recovery work is exchanged decades later.

Looking back, it is difficult to think of another period when so many competing organisations were prepared to share ideas, exchange information and work together towards common standards. While there were disagreements along the way, the level of cooperation achieved during those years was remarkable.

Turbo Dispatch ultimately achieved what its supporters had hoped for. It transformed the way recovery work was allocated, reduced response times and removed vast amounts of duplicated administration. In much the same way, Garage Manager and BRCP had earlier transformed the way recovery operators managed their businesses.

Yet it is equally true that the original vision was never fully realised. Many of the ideas discussed around those committee tables remain as relevant today as they were in the 1990s. Looking back, one cannot help wondering how much further the industry might have progressed had all parties remained committed to the wider objectives rather than simply the immediate gains.

Nevertheless, the standard survived. More importantly, the principle behind it survived: that recovery operators, motoring organisations and software suppliers benefit most when they speak a common language and work to common standards.

In later years further developments would continue under organisations such as APEX Networks, supported by people including the webmaster's long-time friend David Brinklow. Whether the full potential first imagined in the 1990s will ever be reached remains to be seen, but the foundations laid during those years continue to influence the recovery industry today.