Aire Valley Catering: field service apps that work with no signal

The situation

AVC services and maintains commercial catering equipment. Its engineers use their phones to receive jobs, complete compliance reports, take photos and send it all back to the office.

Commercial kitchens are often in basements, behind thick walls, in buildings that were never designed with mobile coverage in mind. An app that needs a connection stops working exactly where the engineer needs it.

The office runs on a Microsoft Access application over SQL Server. So the problem wasn’t either end on its own. It was the gap between them, where a fleet of phones that are often offline have to send job data back complete and in the right order.

Four apps, two audiences

There are four apps across both app stores. Two are for engineers, on Android and iOS, and two are for AVC’s customers.

The engineer apps are native, Java on Android and Swift on iOS. That was a deliberate choice. Offline working drives everything else, and native gives the most control over local storage, queued work and sync that recovers when a signal comes back.

The customer apps are React Native, one codebase for both stores. The demands are lighter there, and keeping the two platforms identical matters more than control over the device.

Why offline decided everything

An engineer finishing a job in a plant room can’t wait for a signal. So the app records everything on the phone first, holds it in a queue, and sends it when a connection returns. It does this in the right order, without anyone pressing anything.

Getting that right is the hard part of any field app, and it’s where most of the ongoing work goes. Sync failures, upload problems and the quirks of particular handsets get dealt with as they come up. An engineer with a broken app can’t finish the job, and the next one is waiting.

What changed

The engineer apps are more reliable, and problems are answered faster. Job and compliance data reaches the office in better shape. AVC’s customers can now see their service activity on their phone, so questions that used to need a call answer themselves.

All of it was delivered as continuous improvement, without stopping the operation to do it.

In their words

Where it goes next

The roadmap for the next platform separates the apps and a new React web front end from the business system, with a defined API between them. Each part can then change at its own pace.

The offline working the engineers rely on is kept. Plenty of re-platforming projects quietly trade it away for neater architecture, and regret it later.

The long-term partnership behind this work