ServiceNow Field Service Management Requirements Workshop Questions

This page gives the questions to ask in a requirements workshop for ServiceNow Field Service Management. It covers the service model, scheduling and work orders, skills and resources, mobile and offline use, integrations, and performance governance, and how to turn answers into decisions.

Service Delivery Model and Scope Questions

What field services does your organization provide? Understand whether the organization provides on-site repairs, installations, preventive maintenance, emergency response or inspections. The scope determines what data Field Service Management needs to track.

How many field technicians do you have and where are they located? Are they distributed across multiple regions or concentrated in one area? Are they employees or contractors? Can they work remotely between jobs or must they return to a depot? This determines scheduling complexity and software requirements.

How do customers request field services? Do they call a dispatch center, submit online requests, or trigger automatic dispatch from monitoring systems? Understanding request channels determines integration needs and routing logic.

Scheduling and Work Order Management

What is your current work order volume per day? If you dispatch 50 work orders daily, you need reliable scheduling and queue management. If you dispatch 500 daily, you likely need optimization algorithms.

How are work orders currently assigned to technicians? Is there a central dispatcher who assigns manually, or do technicians pull work orders from a queue? Are assignments based on location proximity, skill match or workload balance? Replicating the current process in ServiceNow ensures acceptance; optimizing the process while implementing requires change management.

How much notice do technicians need to arrive at a job site? Same-day appointments require tight scheduling; multi-day jobs allow more flexibility. Batch-scheduling jobs by technician territory is more efficient than one-at-a-time assignments.

Do you have service level agreements with customers about response time? If you promise same-day or two-hour response for emergency calls, your scheduling must accommodate priority and rush assignments. If most work can be scheduled days or weeks ahead, you can optimize for efficiency rather than responsiveness.

Skills and Resource Management

How many different skill sets do your technicians have? If all technicians are generalists, assignment is simple: prioritize by location and workload. If technicians specialize (HVAC, electrical, plumbing), you must match skills to work order requirements. ServiceNow can track skills and filter assignment candidates automatically.

How often do technicians need retraining or certification renewal? If certification is required for certain job types, the scheduling logic must exclude uncertified technicians. Tracking training expiration dates prevents non-compliant dispatch.

Do technicians have tools and parts assigned to them or do they collect them before jobs? If tools are vehicle-resident, the model is simple: dispatch the technician and they have what they need. If technicians must collect parts from a warehouse, you need to model parts availability and pickup time. If parts must be delivered to the job site, you need to coordinate logistics.

Mobile and Offline Capability

Do field technicians use mobile devices to access work orders? If yes, you need a mobile app (ServiceNow offers Field Service Mobile). What must the app do? Must technicians capture work completion data offline and sync when connectivity returns? Must the app show maps and navigation to job sites? Must it capture customer signatures or photo evidence?

What connectivity do technicians have in the field? If they have reliable internet throughout the day, real-time synchronization is feasible. If connectivity is intermittent, design offline-first workflows where technicians download work orders before leaving the depot.

Integration and Data Exchange

What systems feed work order data to Field Service Management? Customers (through portals), monitoring systems (automated alerts triggering work orders), service desk (escalating tickets to field dispatch). Each integration requires mapping and transformation logic.

What systems need updates after a work order is completed? Finance (for billing and labor tracking), inventory (parts consumed), customer account (service history), monitoring system (resetting alerts after repair). Design integrations for completion data flow so manual entry is not required.

Performance Metrics and Governance

How do you measure technician productivity today? Jobs completed per day? Revenue per technician? Customer satisfaction? Understanding current metrics determines what KPIs to track in ServiceNow.

What compliance requirements apply to field work? Documentation of work performed, customer sign-off, safety certifications, parts traceability? These determine data collection and audit trail requirements.

Running the workshop so that answers become decisions

Many requirements workshops end with a long list of answers and no clear next step. A common reason is that the questions were asked in a room where nobody had authority to settle the disagreements they surfaced. A field service workshop needs three things before it starts: a named decision owner for each area, a pre-read that asks people to bring real numbers rather than impressions, and a decision log that is open on screen during the session. Each answer should be recorded as one of three things: a decision, an assumption that needs proof, or an open question with an owner and a date. If an answer does not fit one of those boxes, it is probably not yet an answer.

The questions below are meant for the working sessions that follow the first kick-off. They focus on what the team will do when the system is live, where the answers often conflict, and what to write down when they do.

Where dispatch and the field disagree about the day

Dispatchers often describe the schedule as a plan, and technicians often describe it as a list of things that have already changed. Both descriptions are accurate from their side. Ask each group to describe the last three days in which a job moved after it was assigned, and why it moved. The reasons often fall into a short list: a customer canceled, a part was missing, a job ran long, or a technician was pulled for an emergency. Those reasons tell you which rescheduling paths the platform must support on day one and which can wait for a later release.

A sequence for the working sessions

1. Open with the decision log and confirm which decisions from the previous session are closed, reopened, or still waiting.
2. Take one process at a time, from the moment a request arrives to the moment the invoice or record is closed, and ask the group to walk it end to end using a real recent example.
3. At each handover between people or systems, ask who holds the work and what they need in order to act. Where a handover crosses to another platform, the integration patterns guide covers common shapes.
4. Where two people describe the same step differently, record both versions and assign one person to reconcile them by the next session.
5. Close the session by reading back every entry in the decision log and asking the owner of each open item to confirm the date.

Questions that surface problems later rather than now

Some questions reveal risk only when asked in a particular way. Ask what happens when a technician finishes a job without a signature the customer agreed to give. Ask who can reopen a closed visit and whether the reason is recorded. Ask how the team handles a visit that was done on paper and must be entered afterwards. These answers show whether the process has an exception path or only a happy path, and the happy path is the one that will be documented in training.

What to park, and how to park it

A parking list is useful for good ideas that would make the first release too heavy. Some of those ideas belong in the later use cases, which is a sensible place to park them. Each parked item needs a sentence describing the workaround the team will use in the meantime and the person who will review the item at the next milestone. An item parked without a workaround can become a hidden requirement that appears during testing, when changing it costs far more.

What good output from the workshops looks like

At the end of the series you should be able to hand the design team a decision log, a list of assumptions with named owners, a short set of process maps that match what people actually do, and a parking list with workarounds. If any of those four is missing, the next phase will be built on guesses. The log is also the document to show a sponsor who asks why a feature was not built, because it shows which decision was made, when, and by whom. The same log can carry the decisions from requirements workshops into later design reviews.

What is the right size for a workshop group?

Limit the core group to people who can settle a decision on the spot, and invite specialists only for the sessions that need them. A dispatcher, a technician lead, a finance contact and a platform owner often cover most decisions. Bring others in for their area only, and let them leave once that area is closed.

Should the business or the platform team run the workshop?

The business should own the decisions and the platform team should own the feasibility questions. Pair them in the room so that a requirement can be tested against the platform while the people who want it are still there to clarify what they meant.

What if a senior stakeholder rejects a decision after the workshop?

Reopen the entry in the decision log with the new evidence, record who asked for the change, and schedule the change for review with the same people who made the original call. Silent changes made outside the log are a common source of rework in field programs.