Most FSM implementations don't fail because of the back-office software. They fail because the field app, the part that technicians interact with eight hours a day, either doesn't work in the environments where the work happens, or requires so many steps to log a job that engineers route around it.
The result is always the same: dispatchers operate on incomplete information, compliance records have gaps, and the service manager is manually chasing job updates by phone while the software sits unused in a technician's pocket.
This article covers what a field service mobile app must do to work in real maintenance environments, elevator machine rooms, fire panel plantrooms, refrigeration areas in food distribution centres, basement generator sets, and what differentiates a tool technicians will use from one they'll tolerate until they find a workaround.
The parking lot test
Before a technician drives to their first job with a new app, they typically spend a few minutes in the car park at the depot, or, if you're less fortunate, in a customer's car park five minutes before a job, figuring out how to log on, find their work orders, and understand what they're expected to do.
If that takes more than five minutes, the adoption rate will be low. Not because the technicians are resistant to technology, but because field engineers are practical people. When a new tool takes longer to operate than the old way, they go back to the old way. The old way is usually a phone call to the office.
The five-minute parking lot test is the most reliable early indicator of whether a mobile app will be used consistently across a field team. It should answer three questions without anyone explaining anything:
- What jobs do I have today, and in what order?
- What do I need to do at each job?
- How do I log that I've done it?
Everything else is secondary to those three.
Must-have features
Offline mode, non-negotiable
An elevator machine room typically has no mobile signal. The same is true of basement plant rooms, sub-station switch rooms, and the cold-store areas of food distribution warehouses. A field service mobile app that requires a live connection to function is not a field service mobile app.
Offline capability means the full job record, customer details, asset history, checklist items, required parts, previous visit notes, is stored on the device before the technician leaves the depot. Work completed without connectivity syncs to the server when the device next has a signal. Photographs taken offline are queued and uploaded when the connection resumes. Signatures captured offline are stored locally and synced on reconnect.
The underlying architecture matters here. Some apps store only a summary view offline and require connectivity to access checklists, parts data, or previous job history. That is not adequate. For a BS 5839-1 fire alarm service in a basement electrical room, the technician needs the full 40+ item checklist, the previous service record, and any open defects from the last visit, all without a signal.
The practical test: switch your device to flight mode before opening the app. Can you open a work order, complete the checklist, record parts used, take a photo, and capture a signature? If the answer is no, the app is not fit for purpose in a significant portion of the environments where critical infrastructure maintenance happens.
Photo capture with metadata
Photographs have become evidence documents in maintenance work. For access control and automatic gate maintenance, where a personal injury claim can be raised two to three years after the service date, a photograph taken at the time of the visit with GPS coordinates, timestamp, and the engineer's identity embedded in the metadata is a defensible record. A photograph emailed from a technician's personal phone is not.
The app needs to:
- Attach photos directly to the work order and specific checklist items, not to a general album
- Embed GPS coordinates at time of capture (not retrospectively from exif data that can be altered)
- Record the device ID and logged-in technician identity
- Timestamp photos to the second
For access control gate maintenance under EN 12453:2017, photographs of safety edge installations, loop detector condition, and force measurement indicators form part of the evidential record if a site later reports an incident. Courts have specifically asked for this documentation.
For elevator work, photographs of the car interior condition, any visible cable wear in the shaft, and door operator components create a visual condition baseline that narrows the dispute if a damage claim arises.
Digital checklists with mandatory field enforcement
A checklist that an engineer can mark complete without filling every field is not a compliance document, it's a list they can bypass under time pressure.
For a LOLER thorough examination under Schedule 1 of the Regulations, specific observations are required: condition of ropes and chains, condition of car safety gear, brake condition, speed governor operation, buffer condition. Each is a distinct record, not a single "all OK" checkbox. The software must enforce completion of each item before the job can be submitted.
The same applies to BS 5839-1 annual services, where the output document requires device-by-device test records, not a single system-level pass. If the app allows a technician to mark the job complete with 15 of 42 checklist items unclosed, the resulting record fails to demonstrate that the full service was performed, which is a compliance gap, not a minor admin shortfall.
Checklists should be configurable by asset type and job type, so a quarterly inspection generates a shorter list than an annual service, and an emergency callout generates a fault diagnosis workflow rather than a preventive maintenance checklist.
Parts consumption logging
When a technician replaces a door operator buffer, uses three metres of travelling cable, or fits a new capacitor to a fan coil unit, that transaction needs to be recorded against the work order at the point of use, not reconstructed from memory back at the depot.
Parts consumption recording in the field serves three functions:
- Job costing, actual parts cost attached to the work order before invoicing
- Van stock update, van inventory reflects what was used, so the next job's readiness check is accurate
- Reorder trigger, when van stock drops below a minimum threshold, a reorder alert is generated automatically
The minimum requirement is a searchable parts catalogue accessible offline, with quantity input per item. Ideally, the catalogue is pre-populated with parts relevant to the asset type on the job, a fire alarm service shouldn't require the engineer to search through fan coil unit parts to find the correct detector.
Customer signature capture
Electronic signature on the service record, captured on site before the engineer leaves. This eliminates the dispute about whether a service visit occurred, whether the client was informed of defects found, and whether the report was delivered.
The signature record should include the signatory's name (typed by the client or identified from the customer contact record), the date and time of signature, and the work order reference. Some platforms also capture the GPS location at time of signature, which removes the possibility of a signature being added later.
For sectors where customer sign-off is part of the contractual record, PPM visits where the facilities manager confirms site access and work completion, this is a contractual requirement, not just a convenience.
Navigation to site
This is table stakes. The app must open turn-by-turn navigation to the job address from the current location, integrated with the native maps application on the device. Engineers should not be switching between a work order app and a separate maps app, copying addresses manually.
For companies operating a fleet, the dispatching system should show estimated arrival times based on live traffic, not straight-line distance. An engineer who is nominally "5 km away" but is currently in a traffic jam is effectively 40 minutes out.
Nice-to-have features
Barcode and QR code scanning
For companies with a structured asset tagging programme, QR codes on panels, RFID tags on elevator components, barcodes on refrigeration units, scanning the asset code at the start of a job confirms the engineer is working on the correct asset. This matters when a building has multiple identical units in adjacent locations, or when an engineer is working a multi-asset site alone.
Barcode scanning for parts consumption removes keying errors when logging parts against a work order. A miskeyed part number is a stock discrepancy and a job costing error simultaneously.
Voice notes
In environments where typing is impractical, inside a lift shaft with gloves on, working in a server room at 16°C, on the roof of a building in January, a voice note attached to the work order is faster than typed text. The note becomes part of the job record and is transcribed automatically by the platform if the software includes this capability.
This is genuinely useful for fault diagnosis notes where the engineer wants to record their observations before they forget the detail: "Intermittent door-open fault on landing call, door operator brushes showing wear consistent with approximately 180,000 operations, recommend replacement at next visit."
Multi-language interface
This is listed as nice-to-have in the context of a single-country operation with a homogeneous workforce. For companies operating across multiple countries, or employing technicians who are more fluent in a language other than the local majority language, it becomes must-have.
A Polish-speaking engineer on a UK site, a Ukrainian-speaking engineer in a German facility, a Slovak technician working across Czech and Slovak sites, if the mobile app only presents in English or German, the engineer's ability to complete structured checklists accurately is reduced. Mistranslation of a checklist item is not a hypothetical risk; it is a documented failure mode in multi-national maintenance organisations.
A platform supporting 9 languages, including English, Spanish, Polish, Ukrainian, Slovak, Czech, Italian, Bulgarian, and Hungarian, allows each engineer to work in their own language while producing records that are stored and accessible in whatever language the service manager or client requires.
Red flags when evaluating apps
No offline mode, or offline mode with limited functionality. Any vendor who says "our app works offline" should be asked specifically: can a technician open a full work order, complete a multi-item checklist, record parts consumption, take photos, and capture a customer signature, all without a network connection? If the answer is anything other than yes, the offline capability is partial.
No photo metadata. Photographs without GPS and timestamp metadata attached at capture are not evidence documents. "The engineer took a photo" is a statement without proof. "The photograph was captured at 14:37 on 14 March at grid reference 51.5074°N, 0.1278°W by engineer ID 447" is a record.
Mandatory constant connectivity for checklists. If checklists are stored server-side and only downloaded at the moment of use, the engineer loses access the instant the signal drops. This is an architectural decision, not a feature gap, platforms built on real-time server queries cannot easily retrofit offline checklist storage.
No mandatory field enforcement. A checklist that can be submitted with uncompleted items is a liability generator. The service report that results claims a full service was performed. The incomplete data says otherwise. If those two facts are put next to each other by an inspector or a court, the outcome is predictable.
Checklist depth insufficient for compliance standards. A generic "task completed" checkbox per line item is not adequate for LOLER, BS 5839-1, or F-Gas record-keeping. The app needs to support structured data capture: dropdown selections, measured values with units, date fields, text input with minimum length enforcement.
No integration between field app and back-office. Some vendors sell the mobile app and the back-office system as separate products that loosely synchronise. This creates data consistency problems when the engineer's record differs from the office record, which happens more often than vendors admit. The field app and the back-office system should be the same application with different views.
Why technician adoption makes or breaks the implementation
The most common reason FSM implementations fail to deliver the expected return is not software quality, it's adoption rate. A platform that 60% of technicians use 70% of the time produces records for 42% of the work performed. The other 58% exists as phone calls, paper notes, or gaps.
Technician adoption comes down to three things:
The app makes their job easier, not harder. Technicians who previously carried paper job sheets and filled them in back at the depot will only switch to a mobile app if the mobile app is faster and more convenient for them, not just for the office. Pre-populated checklists for the specific asset type, parts relevant to the job already loaded, previous visit notes visible without searching, these make the engineer's life easier. A generic form that requires 15 minutes of typing to log a 30-minute job does not.
The app works where the work happens. An elevator engineer who tries to use the app in a machine room, loses their connection, and comes back to find their entries have not been saved will not try again. Offline sync must be reliable, not intermittent.
The engineer understands what they're being asked to do. Compliance fields that are mandatory but whose purpose is opaque, "enter value in field 14b" without a label explaining what 14b is, create resentment. The app should label mandatory fields in plain language, in the technician's preferred language, with help text where the requirement is not obvious.
The 9-language requirement for multi-national teams
Companies operating maintenance teams across multiple European countries face a practical workforce reality: technicians routinely work in countries where the national language is not their first language. This is not an edge case in the maintenance sector, it is the norm for companies operating in Poland, Germany, UK, Czech Republic, Slovakia, and neighbouring markets simultaneously.
For compliance purposes, the service record can be in the language required by the client or contract. For operational effectiveness, the engineer needs to complete the checklist in the language they think in. A Hungarian engineer completing a Slovak-language checklist for an elevator in Bratislava should be completing it in Hungarian, the data entered is what matters, not the language in which the form was presented.
An app that supports only one or two languages forces engineers to work in a second language under time pressure, in poor conditions, with mandatory data fields. The resulting records contain more errors and take longer to complete. The compliance risk is higher, and so is the repeat-call rate.
RemoteOps supports 9 languages across the full application, including the mobile app, covering English, Spanish, Polish, Ukrainian, Slovak, Czech, Italian, Bulgarian, and Hungarian. Each engineer selects their preferred language at account level; the system records and stores data in a language-agnostic format that is accessible to any user regardless of their interface language.
Frequently asked questions
Does the app need to work on both iOS and Android?
For most maintenance companies, yes. Field teams are rarely uniform in device preference, and company-issued devices split between both platforms. An app that only runs on one platform forces a hardware policy decision that has nothing to do with your software requirements. Check whether the iOS and Android builds are feature-equivalent, some vendors ship iOS first and Android as a reduced-functionality port.
How much offline storage does a fully loaded work order require?
A work order with the full checklist, attached PDFs, previous visit notes, and 10 photographs uses approximately 15–25 MB on the device. A technician with a full day of 6–8 jobs should expect 100–200 MB of offline job data. Most modern smartphones have at least 64 GB of storage; this is not a constraint in practice. The question to ask vendors is whether the offline data is encrypted on the device.
Can an engineer complete the same job simultaneously on two devices?
They shouldn't need to, and most platforms prevent it through record locking. The practical scenario where this matters is when a technician's primary device fails mid-job, the platform should allow the job to be resumed on another device without data loss. Ask vendors how their conflict resolution works when two versions of the same record exist.
What happens to photos taken offline when the app is reinstalled?
This depends entirely on where the app stores pending uploads, in isolated app storage or in the device's photo library. Ask vendors specifically: if a technician uninstalls and reinstalls the app before an offline sync completes, are the pending photos recoverable? The correct answer is that pending uploads are stored in a separate queue that survives app reinstallation.
Is a customer signature legally valid when captured digitally?
In most European jurisdictions, an electronic signature captured with a stylus or finger on a touchscreen is legally equivalent to a handwritten signature for routine commercial documents, including maintenance service records. The relevant regulation in the EU is eIDAS (Regulation 910/2014). For contracts or documents requiring a qualified electronic signature, additional identity verification steps are required, but for a standard PPM service record, a touch signature with a timestamped record is adequate.
For how RemoteOps handles mobile in the context of full FSM operations, from inbound call to completed invoice, see our FSM software buyer's guide. For companies transitioning from spreadsheets, see Moving from Spreadsheets to FSM Software. Current pricing is per technician with no seat limits on office users.