Custom FSM Software: Offline Mobile Work Orders, Dispatch, SLA

What custom FSM software means

FSM stands for field service management: the software that plans, dispatches, records and closes work carried out away from your own premises. A custom FSM solution is one built around a specific operation’s job types, checklists, contract terms and SLA rules rather than configured inside a product whose shape was decided by someone else’s business.

The difference shows up in three places. Off-the-shelf FSM prices per technician per month forever; a custom FSM system is bought once and the source code is delivered to you. Off-the-shelf FSM asks your operation to fit its job model; a custom one encodes yours, including the parts that are unusual. And off-the-shelf FSM treats offline as a feature; in a custom build for a field operation it is the design assumption, because basements and plant rooms have no signal. The trade is real in the other direction too: if your work fits a standard product, buy the standard product — there is a like-for-like price comparison on field service software pricing.

What this covers, and what it does not

This page is about the operation of a technical service organisation: the asset register, the maintenance plan, the mobile work order, dispatch and routing, SLA measurement, signed handover, van stock and the service record that all of it produces.

It is not a replacement for accounting. The completed job produces the data an invoice needs and hands it to the package the finance team already runs — see integrations. It is not a general CRM: it holds the service relationship, contracts and equipment, not a sales pipeline. And it does not tell you how to price a service contract; it tells you what each contract actually consumed, which is the input that argument has been missing.

The mobile work order

Everything the field system is worth comes down to whether the technician's screen is faster and more useful than a paper sheet. If it is not, it will be filled in afterwards in the van, and data entered afterwards is data invented afterwards.

What the technician gets before the job

The address and access notes, including the ones that never make it into an address field: which entrance, whose key, which floor, who to call. The equipment identity and its history, so the technician arrives knowing what failed here last time and what was replaced. The contract and its entitlements, so warranty and billable are not decided by guesswork on site. The checklist for this job type. And the parts likely to be needed, checked against what is actually in the van.

What the technician records on site

Arrival and departure times, taken from the device rather than typed. The fault found and the work done, with structured findings where a code is possible and free text only where it is not. Readings and measurements against the checklist. Parts consumed, scanned from the van stock rather than remembered. Photographs before and after. Any follow-up required, which becomes a new job rather than a note that dies in the report. Then the customer signature on the completed record.

The design constraints that decide whether it is used

One-handed operation, because the other hand is holding something. Large targets and high contrast, because the screen may be in direct sunlight or a dark plant room. Identification by scanning the equipment label rather than searching a list. Minimal typing. And a screen that never blocks on a network request, because the moment the technician waits for a spinner in a basement, the app has lost to paper.

Offline working, properly

Almost every field product claims to work offline. The claim is cheap; the design underneath is not. Lift shafts, basements, plant rooms, rural sites and industrial buildings with thick walls are the normal working environment of a service technician, not an edge case, so the offline path is the main path.

The device holds a working copy. The jobs assigned for the period ahead, plus the equipment history, checklists and parts data needed to complete them, are stored locally. The app reads from that store first and does not depend on a request succeeding.
Changes are queued as entries, not as a final state. Each action is recorded with the time it happened and sent in order when the connection returns. Sending a sequence of events preserves what occurred; sending only the end state loses the middle.
Identifiers are generated on the device. A job completion, a parts issue or a photograph carries an identifier created before it is sent, so a retry after an uncertain response is recognised as the same record instead of creating a second one.
Photographs queue separately. Images are large and connections in the field are poor. A job can be reported complete while its images upload in the background, and the record shows which items are still outstanding.
Conflicts are resolved per field. Field observations — readings, parts, photographs, signature — are owned by the device and the office cannot overwrite them. Scheduling data — appointment time, assignee, priority — is owned by the office and the device takes the update. What remains genuinely in conflict is flagged for a person; a silently discarded field observation is the failure nobody forgets.
Stale data is visible. The technician can see when the device last synchronised. Working from data that is two days old is fine as long as it is known to be two days old.

Dispatch, routing and the shape of the day

Dispatch is a scheduling problem with constraints that differ by company, which is exactly why generic tools tend not to fit it. The constraints that usually apply: which technicians are certified or authorised for this equipment type; who is nearest; who already has the required part in the van; what the contract promises for this customer; and what is already booked into the day.

The screen that matters is the coordinator's: today's jobs against today's technicians, with unassigned work, jobs at risk against their clock, and jobs that have not started when they should have. Route planning orders each technician's stops sensibly and keeps time windows the customer was given. Emergencies are the real test, because inserting an urgent call means deciding which planned visit gets moved, and the system's job is to show the consequence rather than to hide it.

Where the field organisation includes subcontractors, they get their own restricted access to their own jobs only, with the same record requirements and the same evidence. A subcontractor working outside the system is a hole in the service history and a dispute waiting to happen.

SLA clocks that people trust

A contract that promises a four-hour response is not measurable until three things are written down: when the clock starts, what stops it, and what pauses it. Most disputes about SLA performance are disputes about these definitions rather than about the work.

Start. Normally the moment the call is registered, not the moment it is assigned. Anything else measures the dispatcher, not the service.
Stop. Response and resolution are two different clocks and should never be reported as one. Arrival on site stops the first; service restored stops the second.
Pause. Waiting for site access, waiting for a customer decision, waiting for a part on back order. Without explicit pause rules the figure is unfair to technicians and is therefore disbelieved and then ignored.
Calendar. Whether the clock runs overnight and at weekends depends on the contract, so the working calendar is a property of the contract rather than a global setting.
Escalation before breach. A warning at a defined point before the target, to a named coordinator, is worth more than a breach report at month end.

With those defined, SLA performance per contract becomes a fact both sides can read the same way, which is the point. It is also the input to the contract renewal conversation that most service companies currently have without data.

Evidence: signature and photographs

The service report is the document that settles disagreements, so its evidential quality is a design concern rather than a formatting one. Around the signature we record the name and role of the person signing, the exact text they accepted, the timestamp, the identity of the device and technician and, where the customer permits it, the location. The photographs carry their own capture time and are stored as taken, not re-encoded copies. The whole bundle is written as an immutable record: corrections are made as additions with their own author and time, never as edits over the original.

Whether that amounts to a legally binding signature depends on your jurisdiction and your contract, and that is a question for your legal advisers rather than for us. What the system provides is evidence that is complete, contemporaneous and demonstrably unaltered after the fact — which is what most commercial disputes actually turn on.

Periodic maintenance planning

Planned maintenance is where a service business either makes its margin or loses it, and it is almost always run from a spreadsheet that one person maintains. The system replaces that with an asset register: every piece of equipment with its location, contract, service interval, checklist and full service history.

From the intervals the system generates the due visits, and the coordinator turns them into routes. Three rules keep the plan honest over time. A deferred visit stays visible as overdue with a reason rather than quietly vanishing. The next due date is calculated from the actual visit date, not the original plan, or the schedule drifts further out of step every cycle. And the checklist belongs to the equipment type, so a change to the procedure applies to every future visit without anyone reissuing paper.

The by-product is the number service companies most often lack: what each contract actually consumed in visits, hours and parts, against what it was priced at.

Multi-tenant, as we actually run it

Elevatora SAHA is our lift maintenance and field service product, running in production as a multi-tenant system: each customer company runs its own installation with its own database, its own users and roles, and its own configuration for checklists, contract types and service intervals. Before it, the maintenance calendar lived in a spreadsheet, work orders travelled to site on paper, and service history stayed in the technician's notebook; the office had to telephone someone to find out when a building was last serviced.

Separate databases rather than shared tables is a deliberate choice. It gives each company a hard data boundary, it lets one company's configuration differ without changing the product's behaviour for everyone else, and it means a restore or an export concerns one company only. For a group with several subsidiaries the same structure gives each unit its own operational boundary on a common product. The system is described alongside our others on cases.

Paper, generic app, or a system built for the operation

Criterion	Paper and phone calls	Custom field service system
When the office learns what happened	When the sheet arrives, days later, if it is legible	As the device syncs, with times recorded rather than recalled
Equipment history	Distributed across notebooks and folders; effectively unsearchable	Attached to the asset and visible on the technician's screen before the visit
Parts consumed	Written down sometimes; van stock is a periodic surprise	Scanned at the point of use and deducted from that van, with replenishment triggered
SLA measurement	Reconstructed after a complaint, from memory and call logs	Clocks with written start, stop and pause rules, and escalation before breach
Evidence in a dispute	A handwritten sheet with no photographs and an unclear signatory	Signed record with signatory identity, timestamps, photographs and an immutable history
Working without a connection	Not a problem, and that is paper's genuine advantage	Local-first storage with a queue, so the basement case is the normal case
Contract profitability	Unknown until the year is over, if then	Visits, hours and parts accumulated per contract as the work happens

When a custom field system is not the answer

A handful of jobs a week and one technician. A shared calendar and a phone are proportionate. The system pays back on volume, contracts and evidence, none of which exist yet at that scale.
No contracts and no planned maintenance. Purely reactive one-off call-outs with no asset register get most of the benefit from a simple scheduling tool.
Nobody will keep the asset register. Equipment, locations and intervals have to be maintained by someone. A plan generated from a stale register produces visits to the wrong places on the wrong dates, with the authority of a system behind it.
The real problem is capacity, not information. If the team is simply too small for the workload, better scheduling exposes that faster but does not fix it. Worth knowing before the project rather than after it.

How a service operation starts

Job types, checklists and contract terms

We write down the service typologies, the checklist for each, the warranty and billable rules, and the SLA definitions including the pause conditions. This is the step that decides whether the numbers will later be trusted.
Mobile screens tested by a technician

A clickable prototype in 2–4 weeks, reviewed by someone who will actually use it in the field rather than by a manager at a desk. Their objections at this stage are worth more than any later specification review.
One team live, including the offline path

A single team runs real visits with the app, and the offline behaviour is tested where it matters — in a basement, with the connection off, on a full working day. First module in production in 2–4 weeks at $3,000–6,000.
Whole fleet, then the office side

The remaining teams and subcontractors, then the accounting bridge for service invoicing and the reporting on contract profitability. A multi-department system is $8,000–15,000 over 4–8 weeks; the bands are on pricing.

The general build approach, ownership terms and handover documents are on custom software; the neighbouring operational patterns are on manufacturing and dealer portal.

Frequently Asked Questions

What does FSM mean in field service software?

FSM stands for field service management: the software that plans, dispatches, records and closes work performed away from your own premises. A typical FSM system covers the work order from creation to invoice-ready closure, including scheduling and dispatch, the technician's mobile screens, parts and time recorded on site, customer signature and photo evidence, SLA measurement and periodic maintenance planning.

When is a custom FSM solution better than an off-the-shelf product?

When your job model does not fit a standard product, when contract and SLA terms differ per customer, when offline working is a daily reality rather than an edge case, or when per-technician subscription cost over five years exceeds a one-off build. When your work is ordinary scheduled call-outs with standard checklists, a packaged FSM product is cheaper and faster and we will say so. The published comparison is on our field service software pricing page.

How does offline working actually work in the field?

The technician's device holds a local copy of the jobs assigned for the period ahead, together with the equipment history, checklists and parts list needed to complete them. Work is written to that local store first, so the app behaves the same in a lift shaft or a basement plant room as it does on the street. Each completed action is queued as an entry and sent when the connection returns, in order, with an identifier generated on the device so that a retry cannot create a duplicate. Photographs queue separately because they are large, which means a job can be reported complete while its images are still uploading.

What happens if the office and a technician change the same job?

Conflict rules are decided per field rather than by a general last-write-wins policy, because those two options are not equally correct. Observations recorded on site, meaning readings, parts consumed, photographs and the signature, are owned by the device and the office cannot overwrite them. Scheduling data such as the appointment time, the assigned technician and the priority are owned by the office and the device accepts them on the next sync. Where a genuine conflict remains, the record is flagged for a person rather than resolved silently, because a silently discarded field observation is the failure everyone remembers.

Is a signature captured on a phone screen worth anything in a dispute?

Its value comes from the record around it, not from the drawing itself. What we capture with the signature is the name and role of the person signing, the exact text they accepted, the timestamp, the device and technician identity and, where the customer permits it, the location. That bundle is written as an immutable record with the completed job, and the resulting report is issued as a PDF that both sides hold. Whether that constitutes a legally binding signature depends on your jurisdiction and your contract terms, which is a question for your own legal advisers; what the system guarantees is that the evidence is complete, contemporaneous and unaltered afterwards.

How are SLA response times measured, and when does the clock stop?

Every clock needs three definitions written into the contract record before it can be measured: when it starts, what stops it and what pauses it. Start is usually the moment the call is registered rather than the moment it is assigned. Stop is normally arrival on site for a response target and restoration of service for a resolution target, and those are two separate clocks that are often confused. Pause covers the periods that are genuinely not yours: waiting for site access, waiting for a customer decision, waiting for a part on back order. Without an explicit pause rule the reported figure is unfair to the technicians and nobody trusts it.

How are periodic maintenance visits planned?

From an asset register rather than from a calendar of appointments. Each piece of equipment carries its location, its contract, its service interval and its checklist, and the system generates the due visits from those intervals into a plan that a coordinator arranges into routes. Two details decide whether the plan survives contact with reality: a deferred visit must not silently disappear, so it stays visible as overdue with a reason, and completing a visit early or late must reset the next due date from the actual visit rather than the original schedule, otherwise the plan drifts a little further out of step every cycle.

What does a multi-tenant field service installation mean?

It means the same product serves several independent companies, with each one running its own installation and its own database rather than sharing rows in a common table. Elevatora SAHA, our lift maintenance and field service system, is built this way: every customer has separate data, its own users and roles, and its own configuration for checklists, contract types and service intervals. For a group with several subsidiaries the same structure gives each company its own operational boundary while the underlying product stays common, and it is also what makes a per-customer configuration possible without forking the behaviour of the software.

The job is finished when the record is finished, not when the technician gets back