What Is Field Service Management?

Field service management is how a service provider runs the work that happens away from its own building: logging a client's request, scheduling a technician, dispatching them to site, and closing the job out. Most definitions stop there, at the software that plans the visit. For a contractor delivering maintenance under a client SLA, the visit was never the hard part. The hard part is everything that happens around it.

Picture a Tuesday: forty open jobs across a dozen client sites, a contractor who hasn't acknowledged the 9am callout, a quote sitting unapproved for six days, and a completion report that still hasn't landed. None of that is a scheduling problem. It's a coordination problem, and it's the part field service management software quietly leaves to a human.

What is field service management?

Field service management, or FSM, is the practice of coordinating service work performed off-site, at a client's building rather than your own. The definition every major vendor agrees on, from ServiceTitan to IFS to Salesforce Field Service, describes a system for scheduling technicians, dispatching them by skill and location, and tracking each work order through to invoicing. That definition is correct. It's also where the industry has drawn the category boundary: field service management is treated as the software that plans and assigns the visit.

It's a large and growing category. The field service management market is set to grow from roughly $5.1 billion in 2025 to $9.17 billion by 2030 (MarketsandMarkets, 2025), a great deal of software built to answer one question well: who goes to which site, and when. If you run maintenance for clients, you've probably already bought some of it.

Here's what a practitioner learns quickly, though. FSM software is excellent at the schedule and mostly silent on what surrounds the schedule. The table below splits the two: what the software typically owns, and what still runs on a human underneath it.

Who actually runs field service management?

In practice, field service management is run by outsourced FM and hard-service providers, and contractors delivering maintenance for clients: the companies a building owner hires to keep the HVAC, the electrics, and the fabric working. They sit between a client who raised the fault and a network of engineers and subcontractors who fix it. That middle position is the whole difficulty. The provider owns the SLA but doesn't own the building, the tenant, or, often, the engineer who turns up. Everything they're measured on happens at the far end of a phone line.

So when a provider asks what field service management is, the honest answer isn't "scheduling software." It's the daily work of holding a two-sided commitment together across sites and parties you don't control, and the software is one tool inside that work, not the work itself.

The standard definition is a software definition

Look again at that consensus definition and notice who wrote it. It was written by the companies that sell the scheduling software. So the category gets defined as the thing they sell, a tool for planning and dispatching visits, and the definition quietly ends where their product ends.

Here's the position this post takes, and a practitioner can disagree with it: field service management software still assumes a human chases the acknowledgment, the quote, and the verification. That assumption holds no matter which FSM tool sits underneath. The scheduling engine can be world-class and the assumption is unchanged, because the coordination around the schedule was never in scope. It's missing by design, not by vendor.

For an in-house team that gap is an annoyance. For a service provider it's the business. Your SLAs are contractual and two-sided, your margin is set per contract, and the work you're judged on happens across dozens of client sites you don't control. The schedule is the easy part. The chase is the job.

The coordination happens around the schedule, not inside it

A contracted vendor rarely refuses a job outright. As one FM operator put it, "it's not if they accept, it's if they acknowledge in time." So a coordinator's real day isn't planning visits. It's chasing: chasing the acknowledgment, chasing a named engineer onto the job, chasing the RAMS, chasing the report that proves the work was actually done. Your FSM software will happily show a job as "assigned." It won't phone the human on the other end who has gone quiet.

Most tools track SLAs retrospectively, which means the alarm sounds after the breach rather than before it. For an in-house desk a breach is an awkward email. For a provider it's a penalty clause, and every acknowledgment that lands late feeds straight into a lost slice of contract margin. This is the invisible chase, the part of field service management that no schedule view has ever shown.

Scale it to a real operation. A provider running three hundred reactive jobs a month across its client sites, at roughly ten minutes of follow-up on each (the acknowledgment, the engineer, the report), loses well over a full working week every month to chasing alone. None of that week is billable. It's pure margin drag, and it grows with every new contract won.

This is the same failure that turns a facilities helpdesk into a queue nobody can clear: the work between statuses has no owner, so it piles up wherever there's a spare inbox. An AI helpdesk that answers and coordinates around the clock is one way providers are starting to close it.

The record says done. Did it?

The chase doesn't end when the technician leaves site. Someone still has to confirm the job was actually completed, and completion is where field service records quietly drift from reality. A status of "closed" is a claim, not a proof. The service report has to be collected, read, and checked against the scope that was requested, and on maintenance contracts a meaningful share of second visits happen because the first one didn't truly fix the fault.

There's a second, quieter tax on providers here. The same job often gets entered twice, once in the client's system and once in your own, because the two don't talk. That double entry runs ten to twenty minutes a job and gets priced into every contract tier, which means clients are effectively paying you to re-type data. A living record that writes itself as the work happens, mirrored across both systems, is what makes "where's my job?" answerable in seconds instead of days.

There's real money in the difference. When a fault comes back inside the guarantee window, a recall costs roughly what the original job did, and most maintenance contracts have no mechanism to recover it, so the provider eats the second visit. The only defense is proof: a completion record checked against the original scope, so a genuine recall is attributed to the resource that failed rather than quietly re-paid. Without that trail, verification defaults to trust, and trust is expensive.

The point isn't that FSM software is broken. It's that the record is only as true as the coordination that feeds it, and that coordination is exactly the part left manual.

What is field service automation, then?

Field service automation is the layer of FSM that strips manual steps out of the workflow: auto-routing a technician by location and traffic, generating the work order, firing the day-before reminder, pushing the invoice once a job is marked complete. It's genuinely useful, and it's what most "field service automation" marketing means: the software does the scheduling admin so a dispatcher doesn't have to.

But look at what it automates. It automates the steps that were already inside the software: the schedule, the record, the reminder. It doesn't automate the steps that live in phone calls, inboxes, and someone's memory: whether the contractor acknowledged, whether the quote came back, whether the report matches what was actually done. Automating the schedule and calling it field service automation is like paving the driveway and calling it a finished house. You can see the same line in what FM helpdesk automation actually automates: the intake speeds up, the follow-through doesn't.

For a service provider the distinction isn't academic. The steps automation skips are precisely the ones tied to your SLA penalties and your billing: the acknowledgment clock, the completion evidence, the invoice match. Automating the easy 80% and leaving the expensive 20% to a coordinator is why providers can buy excellent FSM software and still feel buried in follow-up.

Where Heyfixit fits, and where it stops

This is the gap Heyfixit works in. It doesn't replace your FSM software or your CMMS; those keep scheduling, dispatching, and holding the record. Heyfixit runs the coordination layer on top: it chases the acknowledgment and the named engineer, chases and validates the service report against the job's own scope, and reconciles the invoice line by line before it reaches your finance team. Your work order states don't change; what changes is who does the work between them.

The value lands where margin leaks today: coordination labor lifted off your coordinators' desks, verified completion instead of a ticked box, and an audit trail captured at source that holds up when a client disputes an SLA. One multi-site FM provider running this saw 60 staff-hours per week saved at 98% SLA compliance.

The honest boundary: Heyfixit is not an FSM or CMMS replacement, it never approves money or issues a client quote on its own, and judgment stays with your team. It's the coordination layer that sits on top of the tools you already run, through named integrations rather than rip-and-replace. If the chase is eating your contract margin, see how the coordination layer works.

Cover image by Raymond Yeung on Unsplash.

Vishak C Prakash

Co-Founder & CEO

Vishak spent six years as a digital transformation consultant to facilities management and real estate operators across the UK, Middle East, Canada, and Australia — working with teams at CBRE, Siemens UK, British Land, and Brookfield. He now runs Heyfixit, building AI agents for facilities management.

LinkedIn