Troubleshooting ServiceNow Field Service Management: A Practical Guide

Field Service Management troubleshooting is the work of finding why jobs are assigned, scheduled or closed in a way the field team did not expect. This guide sorts common symptoms into their likely causes and the first checks to make before anyone changes a live rule.

Symptom: Dispatch is Not Working as Expected

Symptom: Requests get assigned to field technicians, but not in the way you expect. Wrong technicians are assigned, or assignments are delayed.

Where to Look: Field Service Management dispatch rules determine who gets assigned. Rules should consider: technician skills (electrical work vs plumbing), location (nearest technician), availability (on shift, not on leave), workload (busy technician vs light technician).

Likely Causes: (1) Dispatch rules are too simplistic (round-robin without considering skills or location). (2) Technician skill matrix is incomplete; system doesn’t know who can do what. (3) Availability data is stale (technician marked on shift but actually off). (4) Territory mapping is wrong; assigned territory doesn’t match where requests come from.

Fix: Review dispatch rules. Confirm they include all relevant factors (skills, location, availability). Validate technician master data: are skill sets correct and complete? Are status and availability current? Check territory definitions; do they match your service geography?

Symptom: Technicians Complaining About Workload or Scheduling

Symptom: Field team says they’re overbooked or have inefficient routes. Frustration with scheduling.

Where to Look: FSM scheduling and routing optimisation. Are jobs scheduled in logical geographic order to minimise travel? Are technicians scheduled with enough buffer time for travel and administration? Are job priority and customer urgency factors built into scheduling?

Likely Causes: (1) Jobs are scheduled in order received, not geographic order; technicians are zigzagging across territory. (2) Scheduling doesn’t account for travel time; technician is booked solid with no buffer. (3) High-priority jobs are scheduled after lower-priority ones, causing delays. (4) No consideration of technician expertise in scheduling; technician assigned to work they’re not skilled at.

Fix: Enable route optimisation in FSM. Reorder jobs to minimise travel time and route overlap. Build travel time estimates into scheduling. Prioritise scheduling by customer priority and job criticality. Validate skill assignment. Allow technicians input on scheduling; they know their territory and workload better than the system.

Symptom: Low Adoption by Field Technicians

Symptom: Technicians are not using FSM. They’re still using paper, or using their own systems.

Where to Look: User adoption. Is the mobile app easy to use? Does it work on their devices? Does it provide value (clear instructions, navigation, time tracking)?

Likely Causes: (1) Mobile app is clunky or slow. (2) Technicians can’t see their assigned work clearly. (3) Required fields are confusing; techs waste time figuring out what to enter. (4) System doesn’t show completion confirmation; techs don’t feel confident the job was recorded. (5) No incentive for adoption; management isn’t pushing it.

Fix: Simplify the mobile app. Remove unnecessary fields. Test app on actual field devices; ensure it works reliably. Provide training and super-user support during rollout. Show technicians the benefit: faster job completion, fewer callback questions, better tracking. Make adoption mandatory with management support.

Symptom: High Repeat Visit Rate (Callbacks)

Symptom: Technician visits a job, but the issue isn’t fully resolved. Customer calls back; another visit is needed.

Where to Look: Job tracking, work instructions, quality assurance. Are technicians given clear, complete instructions? Are they required to document what they did (parts used, diagnosis, solution)? Is there quality review or customer confirmation before closing?

Likely Causes: (1) Work instructions are incomplete or unclear. (2) Technician is not trained or is rushing. (3) No quality control before job closure. (4) Customer is not satisfied with resolution but job is marked complete. (5) Parts inventory is wrong; technician doesn’t have the right part and does suboptimal fix.

Fix: Improve work instructions: be specific, include troubleshooting steps, common pitfalls. Quality review process: technician marks complete, but manager or customer must confirm. Track repeat visits by technician; low performers need coaching. Ensure parts are available and inventory is accurate.

When to Escalate

Escalate if: Core dispatch rules aren’t working (system is making obviously wrong assignments even after troubleshooting). Mobile app has critical performance issues (crashes, can’t load jobs). Adoption remains stuck after several weeks despite support efforts. Callback rate is high and root cause is unclear.

Escalate to: Your Oblytech Field Service Management consultant for dispatch rule tuning. Your mobile app provider if performance issues persist. Management if adoption or quality issues are systemic.

Triage order when dispatch stops behaving

When a field service problem reaches the on-call administrator, the first question is not what broke but where the failure sits. A technician who cannot see a job may have a device problem, a sync problem, an assignment problem or a permissions problem, and each one leaves different traces. Working through the layers in a fixed order saves time, because the most common causes sit near the top. Check whether the affected person can see the record in the platform at all, then whether the record has the expected assignment, then whether the mobile device has received the change, and only then whether the rule that made the assignment behaved as designed. Starting with the rule is tempting because it is the most complex, but it is often the layer least likely to be at fault on a day when only one person reports the problem.

Keep a short note of every step, with the time and the record identifier. For the wider service side, see incident management and resolution. Field problems often come back after a fix, and a note made during the incident is the only reliable way to see whether the same path failed twice.

Diagnosing assignments that look wrong

An assignment that seems wrong is often correct under a rule nobody remembers writing. Read the assignment history for the job, including the rule or person that made each change. If the rule is named, read its conditions and check which of the technician’s attributes it used on that day. Attributes change: a certificate expires, a territory is redrawn, a technician changes shift. A rule that was right last month can produce a surprising result now because the data it reads has moved. Correct the data first, and only change the rule if the rule itself is wrong. Automation exception handling covers exception paths inside automations.

A safe sequence for changing a live rule

1. Copy the rule and its conditions into the change record before editing anything, so the previous version can be restored.
2. Test the change against the specific job that exposed the problem, and against two or three recent jobs that worked correctly.
3. Apply the change outside the dispatch peak, and tell the dispatch lead the time it goes live.
4. Watch the assignments made in the following hour, comparing them to what the dispatcher would have chosen.
5. Record the outcome, and close the incident only after the dispatch lead confirms the board looks right.

When the fault sits with the mobile app

Mobile problems are hard to reproduce from the office, so ask for the device model, the app version shown in the settings screen, and the time of the failure. Check whether the same technician has the problem on a second device or whether the problem follows a particular job type. A form that fails only for one job type often points to a layout or a required field rather than to connectivity. Do not ask a technician to reinstall the app in the middle of a shift without first saving their open work; the reinstall itself can drop unsynced changes. Integration error handling covers integration failures that look like device faults.

Keeping the incident from becoming a permanent workaround

Field teams adapt quickly. A dispatcher who learns to phone a technician instead of trusting the notification can keep doing it after the notification is fixed, and the old habit hides whether the fix worked. Once the incident is closed, ask the dispatch lead to confirm that the workaround has been stopped for a full working day and that the original channel is being used again.

Deciding what to fix in production and what to test first

Some fixes are safe to make on the live platform, such as correcting a wrong phone number on a customer site. Others change how every job is assigned and should be rehearsed first. Decide which category a fix belongs to before anyone edits anything, and write that decision on the incident. A fix that touches assignment logic, skills matching or the mobile form layout is never a quick fix, even when the change itself is small.

Who should be called in and when?

Call the dispatch lead as soon as dispatch is affected, because they can make operational decisions while the platform team investigates. Involve the platform owner when a rule or integration is implicated, and the device management team when the fault is confined to hardware or the network.

Is it safe to restart the sync for everyone?

Not without a plan. A forced sync for every device at once can overload the platform and create duplicate updates. Restart sync for affected devices in small groups and watch the record counts after each group.

What evidence should a post-incident note contain?

Record the first report, the record identifiers, the layer at which the fault was found, the change made, and the observation that showed the fix worked. A note without the last item is only a belief that the problem went away.