ServiceNow Field Service Management: Where Dispatch Logic Breaks and What Fixes It
A regional operations director at a lift maintenance company outside Milan called me in late September. They run around four hundred service engineers across northern Italy, Austria, and Slovenia, every one of them driving a van and carrying a laptop with the ServiceNow mobile agent on it. The platform had been live for fourteen months. Dispatch was broken.
The specific complaint was that the automated scheduling engine was producing routes that engineers refused to run. Jobs that should have gone to the nearest qualified technician were landing with someone two hours further out. Priority tickets were being queued behind preventive maintenance visits. Customers were calling the service desk directly, bypassing the portal, because the portal said “scheduled for tomorrow” when the engineer was actually three days out. The operations director showed me a Monday dispatch screen with sixty-three jobs assigned to the automated solver and forty-one manually overridden. The dispatcher had become a human reconciliation layer between what the system said and what the engineers actually did.
She asked me how a ServiceNow field service management implementation signed off as a success twelve months earlier had turned into a dispatch pattern her team no longer trusted. The answer, as it almost always does, lived in the data model and the three or four scheduling rules nobody had looked at since go-live. ServiceNow FSM is not failing on this instance. The configuration is failing. The difference matters.
Why Dispatch Fails Twelve Months After a Clean Go-Live
The scheduling engine inside ServiceNow field service management is a solver. It takes constraints, weights, and candidate resources, and it produces an assignment. That is all it does. The quality of the output is bounded by the quality of the inputs. In nine out of ten FSM instances I audit a year or more after go-live, the inputs have drifted far enough from reality that the solver is doing excellent work on a model of a business that no longer exists.
The first drift is skills. At go-live, the skills matrix is tidy. Each technician has three to five skills attached, each one maps to a work order category, and the solver can filter the candidate pool cleanly. Twelve months in, HR has hired forty new engineers, promoted a dozen, and seconded six from a sister division. The onboarding checklist for a new field engineer in most mid-market FSM deployments has no step for “add skills in ServiceNow.” Field managers assign work verbally. The result is a skills table that still looks correct for the people who were there at go-live and is wrong for everyone hired since. The solver sees a smaller pool of qualified engineers than exists, routes jobs further, and makes dispatchers look like they are overriding good decisions.
The second drift is territories. Territory boundaries are often drawn once, during discovery, by a solution architect who flew in from Zurich with a map and the operations director’s best guess at service area. Over the next twelve months the business opens a new depot, loses two postcodes to a competitor, acquires a maintenance book from a bankrupt rival, and reassigns three engineers to cover a new motorway corridor. Nobody updates the territory table. The solver keeps routing jobs across old boundaries. Travel time estimates compound the error. Engineers who used to work the Verona corridor now drive to Trieste twice a week because the solver still believes they live where they lived at go-live.
The third drift is work order types. At the start of an FSM programme the catalogue of work order types is tight. Preventive maintenance, corrective maintenance, emergency callout, installation, decommission. Twelve months later there are forty-seven types, most of them created by a field manager who needed a specific SLA profile for a specific customer and could not get IT to prioritise the request. Each new type is a bypass of the standard scheduling logic. Each bypass creates a small island of jobs the solver cannot optimise against the main queue. The island grows. Dispatchers learn to work around the main queue because the main queue no longer represents the actual mix of work.
None of this is a platform problem. It is a data stewardship problem. The platform is doing what it was configured to do. The configuration is being allowed to decay because nobody owns the ongoing maintenance of the inputs the solver depends on.
The Work Order Lifecycle Nobody Owns
The second structural failure I see repeatedly inside mid-market FSM deployments is a work order lifecycle that nobody owns end to end. The service desk owns the intake. Dispatch owns the scheduling. Field engineers own the execution. Finance owns the closure. Each team owns a stage. No team owns the transitions between stages. The transitions are where the money leaks.
A work order enters the system from a customer portal, a phone call, or an IoT alert. The service desk triages it, categorises it, and either dispatches directly or sends it to the dispatch queue. On average, in the deployments I review, around twelve percent of work orders arrive with incomplete customer location data. Another eight percent have incorrect equipment references. The dispatcher inherits these errors. The dispatcher does not have the time or the mandate to go back to the customer to clarify, so the work order gets scheduled with best-guess data. The engineer arrives on site. The equipment is in the basement, not the roof. The job takes four hours instead of two. The parts on the van do not fit. A second visit is booked. The customer SLA is breached. Nobody in the chain is accountable for the fact that the work order entered the system with bad data twenty-six hours earlier.
The fix is not a technology fix. It is an ownership fix. One role, usually a dispatch team lead or a service operations manager, has to own the quality of every work order from intake to closure. That role has the authority to send a work order back to the service desk for completion before it enters the schedulable queue. That role has the authority to flag an engineer for a repeat visit caused by missing data. That role reads the weekly work order quality report and takes action on the three or four categories of defect that are costing the business the most. Without that role, the lifecycle has no owner and the defects compound.
Inside ServiceNow, this maps to a specific build pattern. The work order state model needs a “pending validation” state between creation and schedulable. The dispatch queue should filter out pending validation records. A simple dashboard shows the service desk how many of their creations are being held, who is holding them, and why. The build is three days of configuration. The hard part is getting a human to own it.
Three Boundaries ServiceNow FSM Needs to Hold
Across the FSM instances I audit, the implementations that work have three boundaries intact. The ones that drift have at least one of them broken.
The first boundary is between scheduling data and operational data. Skills, territories, work order types, SLA profiles, and travel time matrices are scheduling data. Technician availability, parts inventory, and real-time job status are operational data. Scheduling data changes monthly. Operational data changes by the minute. The two have to be managed by different cadences. A platform that lets a field manager edit a territory table at ten in the morning and have the solver pick it up by eleven is not a platform. It is a liability. Changes to scheduling data belong in a weekly change window with sign-off from the operations manager. Operational data flows in real time.
The second boundary is between the dispatch role and the service desk role. These are different jobs. A dispatcher optimises against a schedule. A service desk agent captures a request. The temptation inside mid-market deployments, where headcount is tight, is to collapse them into one role. This never works. The two jobs have different success metrics, different time pressures, and different information needs. Collapsing them creates a role in which neither job is done well. The service desk takes longer to clear its queue because the dispatcher part of the job is more urgent. Dispatch makes worse decisions because the service desk part of the job steals the attention needed for scheduling.
The third boundary is between standard work and emergency work. Standard work follows the solver. Emergency work follows a human. A platform configuration that tries to automate emergency dispatch is a platform configuration that fails under pressure. When a critical callout comes in at eleven on a Friday evening, the dispatcher needs to see who is available, who is nearest, who has the right skills, and who is willing to take the job. The solver can provide the information. The human makes the decision. An FSM instance that forces emergency work through the solver either delays the response or produces assignments the dispatcher immediately overrides, which breaks the audit trail of why the response took as long as it did.
Where to Start, Practically
If you are twelve months in on a ServiceNow field service management programme and the dispatchers are overriding more than a quarter of automated assignments, the fix is almost never a new product. The fix is in the configuration you already own and the data stewardship you do not. In order of impact.
Pull the skills matrix. Count the engineers hired in the last twelve months and compare against the skills table. Any engineer with fewer than three skills attached is a candidate for an incomplete record. Any engineer hired since go-live with zero skills attached is a solver blind spot.
Audit the territory table against the operational reality on the ground. Ask the regional operations managers where their engineers actually work. Compare against what the system believes. Close the gap in a single update, with sign-off, in a weekly change window.
Count the work order types. Any count above fifteen in a mid-market deployment is a signal that the catalogue has been used as a workaround for a scheduling rule. Consolidate.
Appoint a work order quality owner. One name, one job, one weekly report. The role does not need to be full time. It does need to exist.
The lift maintenance company in Milan did these four things across six weeks in October. The override rate on the Monday dispatch screen is now under twelve percent. The dispatchers trust the solver again. The platform did not change. The inputs did.
If you are not sure whether your FSM configuration has drifted this far, or whether the override pattern your dispatchers describe is a data problem or a scheduling rule problem, the fastest way to find out is the Milic Media 10-Day Instance Health Report. We pull the skills matrix, the territory table, the work order type catalogue, and the override rates from your production instance and tell you what is actually going on inside the solver. The output is a fixed-fee diagnostic, not a sales pitch, and it has fixed more FSM configurations in the last six months than any new build we have shipped. If you want to see where this kind of work fits into the broader portfolio, our consulting services page is the shortest honest summary of what we do.
Mladen Milic runs Milic Media Kft, a boutique ServiceNow consultancy delivering implementation, health audits and HRSD work across the EU. Reach him at mladen@milicmedia.com.