Field Service Management Software Cost: Offline Is the Architecture

Published estimates for field service management software run from $25,000 to over $300,000. Apptunix puts a custom build at $25,000 to $300,000+, and CISIN's own cost calculator returns $110,000 to $160,000 for its default of 50 technicians and 8 core features. Both read on 13 November 2026. The range is useless because every one of those numbers is pricing a feature list, and the feature lists are roughly the same: scheduling, a mobile app, work orders, invoicing.

What actually separates a $30,000 build from a $300,000 one is whether the thing works with no signal, and that is an architectural decision made in week one, not a feature added in month six.

Your technicians work in plant rooms, basements, lift shafts, substations, rural sites and buildings with thick walls. That is not an edge case, it is the job. The work order, the parts consumed, the photographs, the readings, the customer's signature and the time on site all have to be captured where there is no network and survive until there is one.

Offline-first and online-with-offline-fallback are different products at the same price point. Online-first means the app assumes a server, caches opportunistically, and degrades when the network goes. Offline-first means the device holds a real local database, every write succeeds locally, and synchronisation is a background process that must handle the case where the server changed too. The second is harder, costs more, and is the only one that works.

Three questions decide the number. Does a technician need to work a full shift with no connectivity? Does scheduling optimise routes, or just assign jobs? And does the job finish with a payment taken on site? Everything else (a customer portal, dashboards, a knowledge base) is ordinary work.

What does offline-first actually cost?

The honest version is that offline-first roughly doubles the mobile engineering and adds a sync layer to the backend that would not otherwise exist.

Every record needs an identity the device can create. A technician completing a job with no signal cannot wait for a server to allocate an identifier, so identifiers are generated on the device and must not collide. That rules out auto-incrementing database keys for anything created in the field, which sounds trivial and reaches into every table.

Every record needs a version and a change history. When a device syncs after six hours, the server may have a newer version of the same job: dispatch reassigned it, the customer rescheduled, another technician added a note. Deciding what wins is a product question with no universal right answer, and it has to be answered per field rather than per record.

The honest default is that field-captured facts win and office-captured intentions do not. A technician's record of parts actually fitted is a fact; dispatch's expectation of which parts were needed is a plan. The fact should survive. The reverse, letting a stale office record overwrite a completed job, is how trust in the product dies in the first month.

Some conflicts cannot be resolved automatically and must surface. Two technicians both completing the same job, a job completed after it was cancelled, a part consumed that stock says does not exist. Build the exception queue before you need it, because without one these fail silently and someone finds out at month end.

Attachments sync differently from data. Photographs are large, connectivity is intermittent, and a sync that blocks on a 12 MB image upload will never complete on a weak signal. Data syncs first and small, attachments follow in the background with resumable uploads, and the job is considered complete before its photos have landed.

Do you need route optimisation, or just assignment?

Every vendor sells optimisation. Most operations need assignment.

Assignment is a human deciding who goes where, with the software making it fast and visible. A dispatcher looking at a board, dragging a job onto a technician, seeing conflicts. For a team of fifteen covering a city, this is correct and it is cheap.

Optimisation is a solver. Travel time, skills, parts on the van, time windows, shift lengths, priorities and service level agreements, producing a route that is better than a human's. It is a genuinely hard problem, the hardest thing in this product, and it is worth building only when the fleet is large enough that a human cannot hold the board in their head.

The rule of thumb worth having is that optimisation pays for itself with scale and not before. Under about twenty technicians, a good board beats a mediocre solver, and most solvers are mediocre because the constraints that matter are local and unwritten: this customer will not let anyone in before ten, that technician is the only one the site trusts, this van has the ladder.

Buy the solver if you need one. Routing engines exist, they are well understood, and writing one is a research project. The integration cost is a fraction of the build cost, and the build has a real chance of producing worse routes than the dispatcher it replaced.

What is always worth building is the constraint model, because it is yours: skills, certifications with expiry dates, territories, shift patterns and parts availability. A solver is only as good as these, and most of the value of "optimisation" is actually in having recorded them properly.

Parts and stock on a van are an inventory system

The part that surprises people: a field service product is also a warehouse product, and the warehouse has wheels.

Each van is a stock location. Parts are issued to it, consumed on jobs, returned, and counted. A technician who fits a part with no signal has decremented stock that the server does not know about yet, and two technicians can both believe they hold the last one.

Consumption has to be recorded at the job, not at the invoice. Products that capture parts only at billing time lose the link between what was fitted and which asset it went into, which is the data that makes service history worth anything.

Serial numbers and warranty make this harder and are usually in scope. Knowing that this specific pump, serial number attached, was fitted to that site on that date is what lets you answer a warranty claim two years later, and it is what turns a service business into one that can sell maintenance contracts.

Returns and reconciliation are where the losses are. Parts taken and not used, parts fitted and not recorded, parts transferred between vans in a car park. A monthly reconciliation against physical count is an operational reality, and the software either supports it or the business stops trusting the numbers.

The asset, not the customer, is what this system is really about

Most field service products are built around customers and jobs. The ones that become indispensable are built around assets.

An asset is the thing you service: a boiler, a chiller, a lift, a pump, a generator, with a location, a serial number, an install date and a history. Customers change, sites change hands, contracts transfer. The asset stays, and everything valuable accumulates against it.

Service history against an asset is the data that compounds. Every visit, every part, every reading, every fault. After two years it tells you which models fail, which sites are expensive, which faults recur after a particular repair, and which technician's work comes back. None of that is available from a system that records jobs against customers.

It is also what a customer will not leave. A business that has five years of asset history in your product is not switching, and that is a more durable moat than any feature.

The hard part is asset identification in the field. A technician standing in front of a unit needs to find the right record in seconds, which means QR or NFC tags on the equipment, a fast search by serial, and the ability to create an asset on the spot when the tag is missing or the record was never made. The last one matters most, because the data will always be incomplete and a system that refuses to proceed without a matching asset gets worked around.

Asset hierarchy comes up later and is painful to add. A site contains systems, a system contains units, a unit contains components. Decide early how deep that goes, because flattening it afterwards loses history.

The job sheet is a legal document in disguise

What the technician fills in is not a form. It is the record that gets produced when something goes wrong.

The customer signature matters and so does what it is attached to. A signature captured against "job complete" establishes very little. A signature captured against a specific list of work done, parts fitted and readings taken, with a timestamp and a location, establishes a great deal. The difference costs nothing to build at the start.

Readings and measurements need units and ranges. A gas pressure, a temperature, an insulation resistance. Capture them as typed values with expected ranges rather than as free text, because the moment they are text they cannot be trended, and trending is how you sell preventive maintenance.

Certifications and compliance certificates often have prescribed formats. In regulated trades the document that leaves the site has a legally defined shape, and generating it correctly from captured data is a feature with real value and real liability attached.

Photographs before and after are the single highest-value thing a technician captures and the thing they will skip if the form is slow. Two taps, offline, with automatic association to the job, or it will not happen consistently.

Retention runs long. Service records on an asset are consulted across its life, which for industrial equipment is decades. Decide retention deliberately and price the storage.

Contracts and SLAs are where the recurring revenue is

Reactive call-outs are a business. Maintenance contracts are a better one, and the software decides whether you can run them.

A contract defines what is covered, how often, and how fast. Planned visits at an interval, response times by priority, parts included or charged, and a price. The system has to generate the planned work automatically, because a contract that relies on someone remembering to schedule the quarterly service is a contract that gets breached.

Response-time clocks need defining precisely and are usually fudged. Does the clock start when the customer calls, when the job is created, or when it is assigned? Does it stop on arrival or on fix? Does it pause overnight, at weekends, when waiting for a part, or when the site is inaccessible? Every one of those is a commercial decision written into a contract, and the software has to implement whatever was actually agreed rather than a single hard-coded rule.

Breaches need to be visible before they happen, not reported afterwards. A dashboard showing yesterday's missed targets is an autopsy. The value is in the alert at 70% of the clock while something can still be done.

Contract profitability is the report that changes behaviour. Revenue from the contract against the cost of the visits and parts actually delivered under it, per contract. Most service businesses discover that a minority of their contracts are unprofitable and cannot say which until a system tells them.

Renewals and price escalation belong here too, since contracts expire quietly and a lapsed contract is lost revenue nobody notices.

Getting paid on site, and why it changes the build

If the job ends with money changing hands, the product crosses into payments and the scope moves.

Taking a card payment on a phone in a customer's house brings a payment provider, a reader or a tap-to-phone integration, refunds, failed-payment handling and a reconciliation that finance will check. It is well-trodden work but it is not free, and it brings compliance obligations you should not discover late.

Quoting on site is the higher-value feature and the one more often skipped. A technician who can produce a priced quote for remedial work before leaving converts far better than a follow-up email two days later. That needs a price book on the device, offline, with the same versioning problem as everything else.

Invoicing usually belongs in the accounting system you already have, not in your product. Generate the data, push it, and let the finance team work where they work.

What the customer sees, and why it pays for itself

The customer-facing layer is usually cut first on budget and is one of the few features with a measurable return.

Most inbound calls are "where is my engineer". A booking confirmation, a narrowing arrival window, and a notification when the technician is on the way removes the majority of them. This is the same pattern parcel delivery solved a decade ago and most service businesses still have not.

A report after the visit closes the loop. What was done, what was found, what needs doing next, with photographs. It justifies the invoice before the invoice arrives, which shortens payment times, and it carries the quote for remedial work at the moment the customer cares most.

Self-service booking is lower value than it looks for complex work, because the customer cannot assess what is needed or how long it takes. It works well for routine, fixed-duration visits and badly for diagnostics.

Keep the portal thin. A login that shows assets, history, upcoming visits and documents covers almost all of the demand. Elaborate customer portals are built, launched and then used by a handful of people, while a well-timed notification is used by everyone.

For commercial customers, the report format may be contractual, and sending it in the agreed shape on the agreed schedule is part of the service rather than a nicety.

What we would build first, and what we would not build at all

The offline data layer and sync come first, before any screen that matters. This is the decision that cannot be reversed, and proving it on real devices in real dead zones is a two-week exercise that de-risks the whole project.

The job sheet second, deliberately short, because it is the only screen a technician uses all day and every extra field is a field that gets filled with nonsense.

The dispatch board third. Assignment, not optimisation, with the constraint model recorded properly so that a solver can be added later if the fleet grows into needing one.

Parts and stock fourth, which is often where a second phase should start rather than being crammed into the first.

What we would not build is routing optimisation, mapping, or payments. All three are better bought, and the integration cost is a small fraction of the build cost with a much better result.

Our rate band is published: $40 to $100 an hour by role, blending to $60 to $70 for a mixed team, with the sync layer sitting at the top of that band. We do not quote a fixed total before a discovery that establishes the connectivity reality of your sites, the size of the fleet, and whether money changes hands at the door. What we will tell you now is that a quote which does not mention conflict resolution has not understood the product.