If you run a team that spends the day away from a desk — technicians, installers, cleaners, security staff, maintenance crews — you already have a field service management system. It might just be a whiteboard, a shared spreadsheet, three group chats and a folder of paper job sheets on the passenger seat.
Field service management (FSM) software is the attempt to put that patchwork in one place: one record per job, one schedule everyone reads, one honest set of times, and one document at the end that proves what was done. This post explains what that actually involves, in plain terms, and what to look for if you are evaluating it for the first time.
The four jobs FSM software has to do
Strip away the feature lists and every FSM tool is trying to answer four questions:
- What needs doing, and where does it stand right now? (work orders)
- Who is working, where, and when? (scheduling)
- When did they actually start and stop? (time and attendance)
- What was done, and can we prove and invoice it? (documentation)
A tool that only answers one of these tends to create work somewhere else. Scheduling software that does not know when a job finished still leaves someone chasing timesheets. A time clock that does not know about the rota cannot tell a late start from a shift that was always meant to begin at nine.
Work orders: a job is a record, not a message
The core object is the work order — the job. In a chat-based setup, a job exists as a message that scrolls away. In an FSM system it exists as a record with a status that everyone sees at the same time: new, assigned, accepted, en route, arrived, in progress, completed. Blocked and cancelled are statuses too, because real days have both.
That single change removes most of the "where are we with the Müller job?" phone calls. The dispatcher can see it. The office can see it. So can the customer, if you give them a portal.
Around the job sit the things that make it self-contained: subtasks and checklists, photos and file attachments, comments, priorities, due dates, and a timeline of who changed what. Better systems let you define more than one type of job with its own workflow — a repair does not move through the same steps as an annual inspection, and forcing both into one status flow is how people start ignoring the statuses.
Scheduling: two different shapes of workforce
Most field companies are not one thing. They have fixed-site people — staff at a warehouse, an office, a client site, working shifts — and mobile crews going job to job. These need different planning.
Fixed-site work is a rota problem: plan who is at which location on which day, and let people see their shifts on their phone. Mobile work is a routing and dispatch problem: who is nearest, who is free, who has the right skills.
Whichever shape you have, the parts that matter in daily use are unglamorous: weekly availability, time-off requests with a proper approval step, and reminders before a shift starts. A schedule that lives only in the office and gets relayed by phone is not a schedule.
Time and attendance: GPS, and where it should stop
This is the part people have opinions about, and rightly so.
The standard approach is geofenced clock-in: you define your locations with a radius, and when someone clocks in, the app checks a single GPS position to confirm they are inside the ring. That is enough to make attendance records trustworthy without following anyone around. Office staff can clock in from the browser instead.
Once the clock knows about the rota, it can do useful things on its own — flag a late start against the tolerance you set for that shift, notice a no-show, handle sites in another timezone correctly. And when someone leaves the geofence mid-shift, that should be a workflow with a resolution, not a silent red mark.
Be clear with your team about the boundary, because it is a fair question. Purpose-bound tracking means a position at clock-in and clock-out, and route recording while someone is on the way to a job — not continuous monitoring of an entire day. Workers being able to see their own records goes a long way towards making this feel reasonable rather than imposed.
Documentation: the report is the deliverable
The last step of a job is proof. A digital service report captures the work summary, before-and-after photos, the parts used and their quantities, how long the work took, and signatures from the technician and the customer — on the phone, on site, while the customer is still standing there.
Two things follow from that. The report attaches to the asset as well as the job, so next year's technician can see the maintenance history instead of guessing. And the office can invoice from it immediately, rather than a week later when the paperwork finally arrives.
How to evaluate a system
A short, practical checklist:
- Try the mobile app the way the field will use it — outdoors, with gloves, on a weak connection. If it is awkward there, nothing else matters.
- Check whether you can model your workflow, or only the vendor's.
- Look at roles and permissions. A dispatcher, a team lead and a subcontractor should not see the same things.
- Ask what happens offline, and what happens when a phone battery is low.
- Read the pricing model carefully. Per-seat pricing that charges an office manager and a mobile technician the same rate gets expensive fast for field-heavy teams.
Where to start
Do not roll out everything at once. Pick one crew and one job type, run it fully digitally for a few weeks, and see what breaks. The friction you find in the first fortnight is the real requirements document.
HBCField is our take on this: work orders, shift scheduling, GPS time and attendance and service reports in one platform, with a web app for the office and a mobile app for the field. There is a 14-day free trial on the Professional tier if you want to try it against a real week's work — no credit card needed to start. You can also see how it maps to specific trades on the industries pages.