Ticketing and field service software for maintenance and repair firms

Ordinary ticketing software is designed for support given from a desk: someone writes, someone else replies. A company that repairs lifts, boilers, refrigeration systems or office equipment needs something different. Field service software follows a person who physically travels to an address, with parts in the van, and comes back with a signed report.

That is why it has three sides: the dispatch desk, which receives requests and shares them out; the technician’s phone, where the work is recorded; and the equipment record, with its full history.

Field service software for teams that work on site, not at a desk

Without a system, a request passes through too many hands. The customer phones, the dispatcher takes a note, the technician receives the address in a message, and the report is written on a paper form that reaches the office when the van does. In the meantime nobody can say for certain whether the job is finished, which parts have left stock and what can be invoiced.

The ticket ties them all together. It can be opened from any channel (a call taken by the dispatcher, an email read automatically, a form, or a portal for those with a contract) and carries with it, right through to closing, everything recorded along the way.

Dispatch: who goes, where and with what priority

The dispatcher’s screen shows the open tickets, sorted by urgency and by the time left until the contractual deadline. Assignment takes account of the area each technician is in, what they know how to repair and how much work they already have. The application proposes, a person decides.

A map of the day’s jobs helps with grouping the journeys. Technicians’ positions are shown only if you decide they should be, after they have been informed, and only while the web app is open on the phone; employee tracking has rules of its own, which you clarify with your lawyer and your data protection officer.

• Priority: set by the type of fault and by the contract, not by how insistent the caller is.
• Reassignment: the ticket moves to another technician with its full history.
• Clear statuses: new, assigned, on the way, in progress, awaiting part, resolved, closed.
• Planned servicing: maintenance contracts generate tickets on their own at the agreed intervals.

The technician’s phone: photos, parts, signature

The technician installs nothing from the app store. They use a progressive web app (PWA), that is, a website that behaves like an app: it opens the camera and keeps the essential data on the phone when the signal drops, in a basement or a plant room, then sends it when the connection returns.

Working without a signal has limits, which we set at the outset: what can be filled in offline and what happens if the ticket is changed at the office in the meantime. The limits differ between Android and iPhone, where web apps face more restrictions (for example on sending data in the background), so we test on the team’s own phones. A signature drawn with a finger confirms acceptance of the work; it is not a qualified electronic signature, and its value as evidence is something you establish with your lawyer.

• The day’s list: the jobs in order, with the address opening directly in the navigation app.
• Photos: before and after, time-stamped and linked to the ticket.
• Parts and labour: what was fitted, from which stock (van or warehouse), how long it took.
• The service report: generated as a PDF and emailed immediately after signing.

Contractual response times and the history of each piece of equipment

Maintenance contracts usually specify how quickly you respond and how quickly you fix the fault. We enter these thresholds for each contract, and the ticket gets a clock. The clock takes account of the agreed working hours and stops in statuses that do not depend on you, for example while you wait for the customer’s approval for a part. Before a threshold is breached, the dispatcher is warned.

Each piece of equipment has its own record: model, serial number, location, contract. A QR code stuck on the unit opens it straight from the phone, with the previous jobs and the parts replaced, so a technician coming for the first time does not start from scratch.

The technology used and making the application part of the team’s routine

A PHP application built with Laravel runs on the server, on top of a relational database. Photos sit in separate storage, so that their volume does not slow the application down. If parts are kept in stock management software, we link the usage recorded on the ticket to it, to the extent that the software offers a way of exchanging data.

Resistance usually comes from the people in the field. It eases once the report on the phone takes less time than the one on paper, something we check by timing it together with them.

• The starting data: equipment and contracts imported from the existing spreadsheets, after a clean-up done by you.
• Dispatch: tickets, statuses and assignment, used at first only in the office.
• The pilot team: a few technicians work from their phones and say what gets in their way.
• The contracts: response times, alerts and reports, added last.

This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.