Field Service Management Software: How to Set One Up

Field service management software turns every fault report and maintenance request into a service call, assigns that call a technician, an address and a time window, and documents the work once it is done. It differs from a helpdesk in exactly one structural way, and that one difference changes everything: the request does not close with a reply, it closes with a person who travels. Which means the software’s real output is not a list but a schedule — who goes where, inside which window, carrying which part. There are three ways to put it in place: a ready-made field service tool, the service module of the ERP or CRM you already run, or a custom build around your own process. Below you will find where it parts ways with a helpdesk, the life cycle of a service call, appointment windows and travel time, the assignment logic in code, van stock, the offline requirement, what you actually pay for, and the five mistakes that sink these projects.

Where it differs from a helpdesk

From a distance the two look identical: both have a numbered record, an owner, a priority and a target time. The difference is in how they close. A support ticket closes in writing; a service call only closes when somebody goes to that address and does the work. Three things follow from that, and none of them exist in a helpdesk: travel time, the stock of parts in the van, and the requirement to keep working in a basement with no signal. If your requests are resolved at a desk you are in the wrong place — we covered that setup in helpdesk and ticket systems. If part of the work finishes on site, keep reading.

The practical test: if closing a request requires somebody to travel somewhere, what you need is not a support system but a scheduling system. A helpdesk manages a queue; field service software manages a calendar.

The life cycle of a service call

Before choosing any tool, write your own process down in these seven steps; ready-made software and custom builds alike are constructed on this skeleton:

• Intake — the request arrives by phone, web form, WhatsApp or from a dealer and gets a number. The critical field here is not the customer but the equipment: without a serial number or a site id, history never comes together.
• Triage — can this be solved remotely? This is where the site visit is at its most expensive; every call closed on the phone is a fuel bill and a technician-hour saved.
• Scheduling — technician, date and time window assigned and communicated. Without a window, the promise you have made is "sometime today", and most complaints start right there.
• On the way — the customer is notified when the technician sets off. A small feature that measurably cuts down "where are you" calls.
• On site — work performed, time spent, parts fitted and photos where relevant. If part consumption is not deducted here, your warehouse records drift from reality inside a week.
• Closure — the service form is signed by the customer (on paper or on screen) and the billing basis is marked: chargeable, under warranty, or inside a contract. That single field determines your entire invoicing.
• Follow-up — an unresolved job gets a second visit scheduled on the same record, not a new number. That one rule is what lets you measure first-visit fix rate at all.

Appointment windows and travel time

In field service, scheduling is not about ordering jobs; it is about holding two constraints at once: the hours the customer is actually at the address, and the time it takes a technician to get from one point to the next. A plan that ignores travel time looks packed on paper and loses two jobs a day in reality.

• Keep windows honest. A two-hour window delights customers and cannot survive traffic; a three-to-four hour window in a city is both keepable and acceptable.
• Job duration depends on call type. Preventive maintenance and a breakdown do not take the same time; write a standard duration per call type, then correct it with real data.
• Schedule by area. Giving one technician jobs at opposite ends of the city on the same day is the most expensive mistake in the plan.
• Leave slack for emergencies. A calendar filled to 100% falls apart at the first urgent call; holding 15-20% of the day in reserve finishes more jobs in practice.

If you want customers to pick the slot themselves, that is a separate interface job; we detailed the booking side in building an online appointment system.

Assigning a technician: skill, availability, distance

Assignment is the intersection of three constraints, and the order matters: skill is a filter (without it, do not send them), availability is a filter (without it, they cannot go), and distance is a sort. The function below applies all three in that order and puts the technician who already carries the part first:

interface ServiceCall {
  requiredSkill: string;
  lat: number;
  lng: number;
  windowStart: string; // 'HH:MM' — when the customer is available
  windowEnd: string;
  estimatedMinutes: number;
  requiredParts: string[];
}

interface Technician {
  id: string;
  skills: string[];
  vanStock: Record<string, number>; // spare parts in the van
  busy: { start: string; end: string }[]; // blocks already booked today
  lastLat: number; // where the previous job ends
  lastLng: number;
}

const toMinutes = (hhmm: string): number => {
  const [h, m] = hhmm.split(':').map(Number);
  return h * 60 + m;
};

/** Rough travel time. A real project uses a routing matrix API instead. */
function travelMinutes(tech: Technician, call: ServiceCall): number {
  const dLat = (call.lat - tech.lastLat) * 111;
  const dLng =
    (call.lng - tech.lastLng) * 111 * Math.cos((tech.lastLat * Math.PI) / 180);
  const km = Math.sqrt(dLat * dLat + dLng * dLng);
  return Math.round((km / 25) * 60); // 25 km/h average in city traffic
}

/** Is there a start time inside the window where the job fits, travel included? */
function findSlot(tech: Technician, call: ServiceCall): number | null {
  const travel = travelMinutes(tech, call);
  let cursor = toMinutes(call.windowStart) + travel;
  const deadline = toMinutes(call.windowEnd);
  const blocks = [...tech.busy].sort(
    (a, b) => toMinutes(a.start) - toMinutes(b.start),
  );

  for (const block of blocks) {
    const blockStart = toMinutes(block.start);
    if (cursor + call.estimatedMinutes <= blockStart) break; // fits in the gap
    cursor = Math.max(cursor, toMinutes(block.end) + travel);
  }
  return cursor + call.estimatedMinutes <= deadline ? cursor : null;
}

export function rankTechnicians(
  call: ServiceCall,
  technicians: Technician[],
): { techId: string; startsAt: number; travel: number; hasParts: boolean }[] {
  return technicians
    .filter((t) => t.skills.includes(call.requiredSkill)) // 1) filter: skill
    .map((t) => ({ t, slot: findSlot(t, call) }))
    .filter((c): c is { t: Technician; slot: number } => c.slot !== null) // 2) filter: availability
    .map(({ t, slot }) => ({
      techId: t.id,
      startsAt: slot,
      travel: travelMinutes(t, call),
      hasParts: call.requiredParts.every((p) => (t.vanStock[p] ?? 0) > 0),
    }))
    // 3) sort: carries the part first, then shortest travel
    .sort(
      (a, b) =>
        Number(b.hasParts) - Number(a.hasParts) || a.travel - b.travel,
    );
}

The list this function returns is a suggestion, not a decision — and it should stay that way. Systems that fully automate field scheduling get pushed back on because of things the scheduler knows and the system does not: past friction with that customer, the technician who holds a pass for that site, the van that is in for service today. The right arrangement is simple: the system ranks, a human confirms.

Van stock and spare parts

The warehouse side of field service has a problem of its own: stock does not sit in one place. Beyond the main store, every van carries its own inventory, and that inventory changes every evening. Four rules make it manageable:

• Every van counts as a warehouse. A part leaving the main store is not gone; it transfers into the technician’s stock. Without that definition, a physical count will never match the system.
• Consumption is deducted on the service form. The technician marks the part fitted while closing the job; the system deducts it from that van and adds it to the billable lines.
• Set minimum levels for critical parts. When van stock drops below the threshold, a replenishment request opens automatically — do not expect the technician to remember.
• Track faulty-part returns. Returning a warranty-replaced part to the manufacturer is a separate flow, and when it is forgotten it is a direct loss.

If you already run a system for the main warehouse and purchasing, the two must not overlap; we covered where basic stock control stops being enough in stock control software versus a custom build, and the production link in production tracking and MRP.

The field app has to work offline

This is the most underestimated and most expensive requirement in field service projects. The technician may be in a basement, a lift shaft, a factory floor or a facility outside town. With no connection, the app has to keep working and send the record once signal returns. In practice that means three things: the day’s jobs download to the device in the morning, forms and photos are stored locally, and sync happens in the background when connectivity comes back. For everything else there is a single design rule — gloves, sunlight and one-handed use: big buttons, few fields, very little text.

If you also want working hours and travel logged in the same app, it must not collide with a separate system; we drew that boundary in time and attendance software (PDKS).

Warranty, contracts and invoicing

The money side of service software reduces to one question: is this visit chargeable? The answer comes from three sources, and all three have to be defined in the system:

• Equipment warranty — start and end dates tied to the serial number. Technicians deciding this from memory on site is the single most common source of lost revenue.
• Maintenance contract — how many preventive visits and how many breakdown visits the annual contract includes, and what falls outside it. If the system does not count the contract quota, nobody does.
• Chargeable service — labour, travel and parts as separate lines. Write down upfront whether the travel charge is fixed or distance-based; it is the line most often argued about on site.

Turning a closed form into an invoice is an integration job; we covered the accounting side in accounting software integration and the e-document side in e-invoice integration.

Ready-made tool, ERP module, or custom software

Three routes, and the choice depends on how standard your service business is:

• Ready-made field service tool — starts fast, arrives with a mobile app, runs on a subscription. The right choice for most businesses doing installation and repair. Its limit: when your own form structure and warranty rules do not fit the tool’s data model, you change the process to suit the software.
• The service module of an ERP or CRM — the least integration pain, because customers, stock and invoicing already live in the same place. If you have an existing system, look here first; the weak spot is usually the mobile app.
• Custom software — the only realistic route if you carry complex equipment-level warranty rules, customer-specific service levels, regulator-mandated inspection forms, or a service model that runs through a dealer network. We compared the criteria in custom software versus an off-the-shelf solution.

What you actually pay for

Comparing one headline number will mislead you; in these projects the budget splits into four items:

• Software — a per-technician subscription for a ready-made tool, or day-rate development for a custom build. We broke down how custom pricing is constructed in the cost of custom software.
• The mobile side — the field app is at least half the project. Projects that focus on the web side and leave mobile for "later" mostly stall in phase two; if the technician does not use it, there is no system.
• Devices and field hardware — tablets or rugged phones, mobile printers and scanners where needed, plus connectivity.
• Data preparation and training — loading customer, equipment and warranty data, and training the technicians. If your equipment inventory is scattered, this item exceeds the software.

Five mistakes that sink the project

• Recording customers but not equipment. With three units at one address, nobody can say which one keeps failing — and without that, neither warranty nor quality can be measured.
• Giving no appointment window. "Sometime today" produces the same dissatisfaction as not turning up, and it ties up your phone line.
• Leaving travel time out of the plan. A calendar that looks full on paper loses two jobs a day in the field; this is the most concrete efficiency loss there is.
• Designing the mobile app for a desk. Long forms and ten mandatory fields push technicians into filling everything in, invented, at the end of the day. This one decision determines data quality.
• Switching everything on at once. Call management, scheduling, van stock, contract tracking and invoicing in the same month means the team trusts none of it. The order is clear: calls and scheduling first, parts next, invoicing last.

Conclusion

Field service software does not make service faster; it makes visible who went where, when, and what they did there — you do the speeding up. Success therefore has nothing to do with the brand on the tool and everything to do with three things: records kept per piece of equipment, scheduling that honestly accounts for travel time, and a mobile app the technicians actually use. If your service work is standard installation and repair, start with a ready-made tool or the module in your existing system; if you run through a dealer network, carry complex equipment-level warranty rules, or produce regulator-mandated inspection forms, take a look at our corporate solutions service or request a quote with a note about your technician headcount and daily call volume.