Customer Service Management (CSM) manages the customer-facing service relationship, while Field Service Management (FSM) manages the operational work performed at a customer or service location. You need both when a customer issue begins as a service Case but requires physical work such as inspection, repair, installation or maintenance.
A manufacturer receives an urgent call because production equipment has stopped working. A customer service agent creates a Case, verifies the customer's entitlement and guides the operator through remote troubleshooting. The problem cannot be resolved remotely, so an engineer must visit the site. What looks like one customer issue now crosses two connected operating models: CSM manages the customer journey, while FSM manages the field work.
What is ServiceNow Customer Service Management?
ServiceNow Customer Service Management manages customer requests, issues and communication through the customer service Case. The Case provides the context needed to understand the customer problem: who raised the request, which account or consumer is affected, what product or asset is involved, whether a contract or entitlement applies, what business impact exists, what troubleshooting has already been completed and what communication has taken place.
That makes CSM more than a ticketing system. The Case connects the customer request with the relevant product, contract, entitlement and service history. Agents can use that information to validate entitlement, review previous Cases, search knowledge, perform remote troubleshooting, involve specialist teams and keep customers informed.
When several internal activities are required, related Case Tasks can support the resolution. A technical investigation, warranty review or commercial check can happen without creating a field-service process. The Case remains the record representing the overall customer issue.
What is ServiceNow Field Service Management?
ServiceNow Field Service Management manages work that must be performed at a customer site or another physical location. Its main operational records are the Work Order and Work Order Task. A Work Order represents the overall field-service requirement: why the visit is needed, where it will happen, what customer or equipment is involved and what outcome is expected. A Work Order Task represents a specific activity that can be scheduled and assigned to a field agent.
FSM manages information that belongs to field execution, including service location, territory, dispatch group, required skills, technician availability, appointment windows, expected duration, travel, parts, tools, safety requirements, site access and completion evidence. This is why FSM is more than a queue for technicians. It coordinates people, skills, time, location, inventory and execution.
What is the difference between CSM and FSM?
CSM manages the customer's issue and service experience; FSM manages the operational work required to resolve it in the field.
| Area | CSM | FSM |
|---|---|---|
| Primary purpose | Customer requests, issues and communication | Plan, dispatch and execute field work |
| Primary records | Case and Case Task | Work Order and Work Order Task |
| Primary users | Service agents and support teams | Dispatchers, field agents and technicians |
| Main focus | Customer outcome and service experience | Operational execution |
| Work location | Contact centre or remote support | Customer site, depot or service location |
| Scheduling | Service-level management | Technician schedules, territories and time slots |
| Equipment context | Identifies affected product or asset | Uses equipment details to perform work |
| Parts and tools | May identify a possible need | Supports requirements for execution |
The distinction matters because a field visit and a customer issue are not the same thing. A technician can complete a visit without resolving the customer's overall problem, and a Case can be resolved without any field visit.
Why is a Case different from a Work Order?
A Case owns the customer outcome, while a Work Order owns the field requirement. Consider a customer reporting that a generator is shutting down unexpectedly. The Case should retain the customer's description, business impact, account and contact, affected equipment, contract and entitlement, troubleshooting completed, communications and overall resolution status.
The Work Order should translate the need for on-site intervention into an executable job. It should define the service location, equipment, work to be performed, required skills, expected duration, parts or tools, appointment requirements, safety and access instructions and expected field outcome.
The customer does not care how many internal tasks or visits are required. They want the original problem resolved. The Case provides that continuity, while the Work Order gives the field team the structure required to execute the work.
When do you need CSM only?
CSM may be sufficient when most customer requests can be resolved remotely or by office-based teams. Typical examples include software support, billing enquiries, subscription administration, account changes, product-information requests, complaints, remote configuration support, warranty questions, customer onboarding and knowledge-based resolution.
These processes still require customer, product, entitlement and communication context, but they do not require technician scheduling, territories, travel, parts management or mobile field execution. A Case Task is often enough when another team must contribute to the resolution but does not need the full field-service model. A billing specialist investigating an invoice, for example, can work on the Case without creating a Work Order.
When do you need FSM only?
FSM may be sufficient when the organisation performs planned or operational field activities that do not begin with a customer service request. Examples include preventive maintenance, routine inspections, equipment installation, meter reading, infrastructure surveys, facilities maintenance, scheduled asset servicing, regulatory inspections and planned equipment replacement.
A Work Order may originate from a maintenance schedule, asset condition, IoT alert or another operational process. There may be no customer complaint to manage. Even in an FSM-only model, accurate location, asset and equipment information remains essential. A technician cannot perform the work effectively if the site is wrong or the affected equipment cannot be identified.
When do you need both CSM and FSM?
You need both when a customer service request can require physical work and the organisation must manage the journey from initial contact through field execution and final resolution. Typical examples include medical equipment repair, industrial machinery support, telecommunications installation and repair, home appliance servicing, energy and utility services, security-system maintenance, on-site technology support, vehicle or fleet servicing and warranty inspection or repair.
In these situations, CSM manages the customer conversation, entitlement, troubleshooting and overall resolution. FSM manages the technician, appointment, travel, parts and on-site activity. The two processes should work together without losing their separate responsibilities.
Where does the CSM-to-FSM handoff go wrong?
The biggest failure is treating the handoff as "create a Work Order from the Case" instead of designing what information, ownership and outcome must cross the boundary.
First, the organisation needs to confirm that on-site service is actually required. Remote troubleshooting should use the Case, product, symptoms, knowledge and entitlement information to determine whether the issue can be resolved without dispatch. Sending a technician too early increases cost; delaying a required visit damages the customer experience.
Second, the Work Order must carry enough service context. A Work Order containing only a Case number and short description forces the technician to reconstruct the problem. The handoff should consider the customer and contact, service location, affected asset or install base item, product model and serial number, reported symptoms, troubleshooting completed, priority, business impact, contract and entitlement, site access, safety instructions, required skills, parts or tools and appointment commitments. The architect must also decide what should be referenced and what should be copied. Shared data can reduce duplication, while important operational details may need to be preserved in the Work Order.
Third, Case priority must become a realistic field commitment. Case priority reflects customer and business impact, but FSM must also consider technician availability, territory, skills, schedules, travel time, parts availability, appointment capacity and contractual commitments. Simply copying "Priority 1" does not guarantee the right field response.
Fourth, the Case should normally remain open while field work is in progress. Creating a Work Order means the issue has moved into fulfilment, not that the customer's problem is resolved.
Finally, FSM must return a meaningful outcome. "Work completed" is rarely enough. Customer service may need the technician diagnosis, work performed, parts used, completion notes, checklist results, photographs, customer acknowledgement, equipment status, whether another visit is required and whether follow-up or replacement is needed.
What does a practical CSM-to-FSM flow look like?
A connected process moves from customer contact to Case creation, troubleshooting, field-work decision, Work Order creation, dispatch, execution and final Case resolution. A practical ServiceNow flow is:
Customer contact → Case creation → customer and entitlement validation → remote troubleshooting → resolution or field-work decision → Work Order creation → context transfer → Work Order Task creation → scheduling and dispatch → field execution → field results → Case resolution
This is not simply a one-way integration. CSM supplies customer, product, entitlement and troubleshooting context to FSM. FSM returns execution status and field results to CSM. The reference implementation describes 14 distinct steps from customer contact through final Case resolution. The important point is that creating the Work Order is only one step in the overall service journey.
What would we actually do in a ServiceNow implementation?
We would start with one real service journey rather than attempting to design every possible Case and Work Order scenario at once. For example: a customer reports equipment failure, the agent performs remote diagnosis, the issue requires a site visit, the technician completes the repair and the Case is finally resolved.
First, we would define the exact trigger for field intervention and the minimum information required before a Work Order is created. Second, we would define ownership clearly. CSM should remain responsible for the customer conversation, Case lifecycle and final customer outcome. FSM should own field execution, assignment, scheduling, technician activity and Work Order status. Third, we would deliberately map the information that crosses the boundary. We would not copy every available Case field into the Work Order simply because it is technically possible. Finally, we would test exceptions such as changed locations, unavailable parts, rejected assignments, appointment changes, incomplete work and repeat visits. Those scenarios show whether the architecture works beyond the happy path.
What business impact comes from getting CSM and FSM right?
A well-designed CSM-FSM process improves customer experience while making field operations more efficient. Customers do not have to repeat the same information when a technician arrives, and service agents can provide more consistent updates. Technicians receive better diagnostic context and can arrive with the appropriate skills, parts and equipment information.
The model can also reduce service cost. Issues that can be resolved remotely remain in CSM, while genuine field requirements move into FSM, reducing unnecessary dispatches and repeat visits. It also creates clearer accountability. The Case owner remains responsible for the customer outcome, while dispatchers and field agents remain responsible for operational execution. Management gains better visibility into which Case types generate field visits, why appointments are delayed, where repeat visits occur and whether completed field work actually resolves customer issues.
What is the honest limitation of the ServiceNow approach?
ServiceNow provides the building blocks for a connected CSM and FSM process, but the platform does not remove the architecture work. The project team still has to decide which record owns each piece of information, what triggers the handoff, which fields should be mapped or referenced, how later changes are handled, what field results return to the Case and how exceptions are managed.
One important constraint is that Case and Work Order changes do not automatically stay synchronised. For example, if a customer changes the service location after the Work Order has been created, the Case may contain the new information while the Work Order still contains the old location unless the implementation deliberately handles the change. That specific failure mode is why the CSM-FSM boundary needs to be designed as a process, not just configured as a relationship between two records.
Frequently asked questions
Is every CSM Case converted into a Work Order?
No. A Case can be resolved through remote troubleshooting, knowledge, customer communication or internal Case Tasks. A Work Order is needed when physical or operational work must be performed.
Can FSM work without CSM?
Yes. FSM can support planned maintenance, inspections, installation and other operational field activities that do not begin with a customer Case.
What is the difference between a Case and a Work Order?
A Case manages the customer issue and overall resolution journey. A Work Order manages the operational requirement for field work, including location, skills, scheduling, resources and execution.
Should the Case be closed when the Work Order is created?
Normally, no. Creating the Work Order means the issue has moved into fulfilment; it does not mean the customer's issue is resolved. The Case can remain open while field work is scheduled and completed.
What information should move from CSM to FSM?
The handoff should provide enough context for effective execution, including customer and contact, location, affected equipment, symptoms, troubleshooting completed, priority, entitlement, access information, skills, parts or tools and appointment commitments.
Does a completed Work Order mean the Case is resolved?
Not automatically. FSM should return the field outcome, and CSM should determine whether the original customer problem has actually been resolved or whether further work is required.