Custom field service and job tracking software

Field service software lets you schedule technicians, push job details to their phones, capture the report, photos and customer signature on site, and invoice without retyping anything. Job tracking for construction adds time to the picture: progress, staged billing, snag lists. Off-the-shelf tools handle the standard case well. A custom build pays off when your contracts, job types or customers follow rules no amount of configuration can express.

This article is about the field: people who travel, work with a phone in one hand and a tool in the other, and often lose signal. Tracking work on a factory floor, around fixed machines, is a different problem, covered in our guide to production tracking software.

The six building blocks

Every serious product on the market offers these six blocks. The real question is not whether one exists, but which one fits the way you work, and what you do about the gap.

Offline mode decides adoption

In a demo, everything works. On a real job, the technician walks into an underground car park, a plant room or a farm with no coverage. If the app freezes at that moment, the paper notebook comes back out, and the software has lost.

Real offline support means:

• today's jobs downloaded in advance, with site history and documents;
• reports, photos and signatures saved on the phone, then uploaded automatically when signal returns;
• conflict handling: what happens when the office edits a job while the technician is filling it in offline?
• no loss and no duplicates, even if an upload is cut halfway.

This is the hardest part to build, and the hardest to evaluate from a sales demo. Ask to see it in airplane mode, on an ordinary phone. The choice between an installable web app and a native app matters here too; our comparison of web apps, PWAs and native apps covers the trade-offs.

Photos, reports and sign-off: your proof of work

The field report is what protects the business: it shows what was done, when, and what state the equipment was in. Three rules hold everywhere:

1. Timestamped photos attached to the job, ideally before and after, compressed on the device so they do not eat the technician's data plan.
2. Short input: pick lists, scanned or selected parts, voice dictation for comments. Nobody types an essay at the end of a long shift.
3. A locked document once signed: after the customer signs, the report should not change without an audit trail. For high-stakes documents, such as a handover certificate on a construction project, check with your lawyer which level of electronic signature your jurisdiction expects.

Scheduling: start simple

Everyone wants "smart" scheduling. In practice, automatic route optimisation is a project of its own, and it fails when the basic data is wrong: real job durations, who holds which certification, what stock sits in each van.

Start with a visual drag-and-drop board that flags conflicts: a missing skill, an overlap, an urgent job nobody has taken. Record actual job durations for a few months. Only then does assisted dispatching have data worth learning from.

Maintenance contracts: where standard tools often stop

Many service businesses live on contracts: annual preventive visits, a number of call-outs included, guaranteed response times by tier, parts covered or not. Those rules rarely match from one company to the next, which is exactly where configuration runs out.

A well-built module generates preventive visits automatically, tells the person taking the call what the customer's contract covers, and separates included work from billable extras on the invoice. If those calculations happen in someone's head, or in a spreadsheet next to the software, they are a strong candidate for a targeted build. The starting point is the same as when you replace a spreadsheet with a custom application: write the rules down as they are really applied, exceptions included.

Location tracking: stay on the right side of privacy law

GPS helps you dispatch emergencies and prove a visit took place. It is also personal data about your employees. In the UK, the ICO's guidance on monitoring workers says workers and passengers must be told about vehicle monitoring, that tracking during private use of a work vehicle will rarely be justified, and that more intrusive monitoring calls for a data protection impact assessment. The ICO also notes that this guidance is under review. Rules in the EU and elsewhere follow similar principles, with local variations.

The practical design choice: record location at job start and finish, not continuously, and never outside working hours. It is easier to justify and usually enough. For your own situation, take advice from a privacy lawyer.

Job tracking for construction: adding duration

For building and trade companies, the one-day call-out and the three-month project coexist. Construction job tracking adds its own needs:

• progress by work package, and hours logged per crew;
• staged billing, invoiced as work advances;
• snag lists recorded at handover, with photos, and their resolution;
• a site diary: weather, deliveries, incidents, visitors.

Software designed for repairs handles long projects poorly, and the reverse is also true. If your business mixes both, check that one system holds them in the same database, with the same customer and the same history.

An example we know from the inside: Izi-Devis

Izi-Devis is quoting and invoicing software for French building tradespeople, designed, built and run by LPR Studio itself. We do not cite it as a crew scheduling tool: it is first of all how a tradesperson produces quotes and invoices. It does cover part of the field work, though: job reports with before and after photos, a map of job sites, and staged invoices, all in a web app that installs on the phone.

What running it has taught us applies to any field service product:

• the phone is the main tool, not a cut-down version of the desktop;
• input has to fit between two tasks, which is why Izi-Devis quotes are dictated by voice;
• the report must lead to the invoice without retyping, or the office redoes the work in the evening.

What a first version should leave out

A custom field service project goes wrong when it tries to do everything at once. A sensible first release covers one job type end to end: intake, work order, field report, sign-off, invoice. Route optimisation, customer self-booking, inventory across vans and advanced analytics come later, once the core flow is used every day and you have real data. Our article on what to build first in an MVP applies directly: the goal of version one is that technicians stop reaching for paper, not that every feature exists.

Keep the old process running in parallel for a few weeks, with a small pilot team, and switch over only when the technicians themselves say the new tool is faster than paper.

Off-the-shelf or custom

Custom software is not justified by comfort but by the gap: hours of retyping every week, jobs that never get invoiced, incomplete reports that end in disputes. Our guide to custom software for small businesses helps you run those numbers.

Where to start

1. Ride along with a technician for a day and note every time they reach for a notebook or call the office.
2. List your job types and what each must produce: report, photos, signature, invoice, readings.
3. Measure the gap between your current tool and what the field needs.
4. Test in real conditions, in airplane mode, on your technicians' phones.

For the parts that are specific to you, we build a free visual prototype, presented over video within 5 working days: your technicians see the screens before anything gets built.