A work order is a physical service assignment: a technician dispatches to a location, performs the work and closes the job. A case is a customer issue that may require multiple work orders and back-office investigation. A task is an internal action item, such as scheduling a callback, ordering a part or escalating to engineering. They are three different object types solving three different problems. Most field service organisations confuse them, route work to the wrong object, and lose visibility into actual service delivery.
What is a work order?
A work order is a service execution record. It represents a single assignment: a technician, a location, a time window and the work to perform.
Work orders own:
- Technician assignment: who is doing the work, their start date and their duration.
- Location details: customer site, equipment and access instructions.
- Service tasks: what needs to be done, such as replacing a compressor, diagnosing a network issue or carrying out annual maintenance.
- Labour and materials: hours worked, parts consumed, technician notes and completion photos.
- On-site execution data: arrival time, actual duration, customer signature and equipment readings.
- Status and closure: open, in progress, complete, with timestamps and completion notes.
A work order is not a case. It is not a repository for the customer issue description or root cause analysis, and it is not a communication record with the customer about the broader problem. It is a field execution record. It exists to answer one question: who did what, when, where and for how long?
What is a case?
A case is a customer issue. It represents a problem that needs resolution, regardless of how many work orders that requires.
Cases own:
- Issue description: what the customer reported or what your support team discovered.
- Customer context: who reported it, when they reported it and how urgent it is.
- Root cause and resolution: what actually caused the problem and what fix was applied.
- Timeline: when it was reported, when it was first addressed and when it was fully resolved.
- SLA and escalation: how long resolution should take, whether it has breached and whether it needs escalation.
- Communication history: all interactions with the customer about this specific issue.
A case may generate zero work orders (a knowledge-base answer to a customer question), one work order (a simple on-site fix) or five work orders (diagnostics, part replacement, reconfiguration, training and follow-up).
What is a task?
A task is an internal action item. It is something a team member needs to do to move work forward, but it is not a service delivery record and it is not a customer-facing issue.
Tasks own:
- Assignee: who needs to do this.
- Action: what specifically needs to happen, such as calling a customer, ordering parts, submitting a report or sending an email.
- Due date: when it needs to be complete.
- Status: open, in progress, complete.
- Priority: how urgent it is.
- Dependencies: whether this task waits on another task.
Examples: call the customer to schedule a follow-up appointment, order a replacement pump for inventory, review work order photos for quality, escalate to engineering for root cause analysis, generate an invoice for completed work. Tasks are not service delivery. They are workflow coordination.
How they relate: a real example
A customer calls about their HVAC system running inefficiently.
- Case created. Support creates a case: "HVAC system running cold, customer reports high energy bill."
- Diagnostic task. Support creates a task: "Call customer to schedule diagnostic visit." Assigned to the support manager, due today. The manager calls. Done.
- First work order. The field team creates a work order for tomorrow morning. The technician goes on site, runs diagnostics and discovers a refrigerant leak. Work order notes: "Refrigerant leak detected. Replacement compressor ordered. Scheduled for three days out."
- Ordering task. Support creates a task: "Order compressor from supplier, confirm delivery by Thursday." Assigned to the parts coordinator. This task tracks the procurement, not the service delivery.
- Second work order. Three days later, a second work order. The technician replaces the compressor and tests the system. Work order closed. System back to 95 per cent efficiency.
- Follow-up task. Support creates a task: "Call customer to confirm satisfaction and send warranty." Assigned to the support rep.
- Case resolution. Once the warranty is sent and the customer confirms, the case closes. Total time: four days. One case, two work orders, three tasks.
If this organisation had put everything into the work orders, they would have two messy records with conflicting information, no clear case-level SLA tracking and no way to monitor the ordering process.
Where organisations go wrong
Mistake 1: using work orders for case management
A technician completes the on-site fix, but the customer still needs configuration done remotely. Instead of creating a case-level note and a new task, the organisation adds a note to the work order: "Needs remote config. Will handle next week." Now the work order is closed, which is misleading because field execution is done but the issue is not resolved. Nobody monitors the remote configuration. The customer escalates three days later.
Fix: close the work order when field execution is complete. Use the case to track the remaining configuration work.
Mistake 2: treating tasks as work orders
A dispatcher receives "order replacement part" and creates a work order instead of a task. Now a technician is assigned to an open work order that has nothing to do with field execution. They cannot close it because the part has not arrived. The technician's schedule looks full. SLA tracking breaks.
Fix: if there is no field execution, create a task, not a work order.
Mistake 3: not creating cases at all
A technician is dispatched for a one-off repair. A work order is created and closed. Nobody tracks whether the customer's issue was actually resolved or whether it will recur. No SLA tracking, no pattern recognition (the same equipment failing repeatedly), no customer issue history.
Fix: for every customer issue, create a case. Work orders are the execution; cases are the business problem.
Mistake 4: not using tasks to coordinate
Work is scattered across chat messages, email threads and sticky notes. Did anyone order that part? Who is calling the customer back? Has engineering reviewed the diagnostics? Nobody knows. No audit trail, no due dates.
Fix: every internal action item that needs coordination gets a task with an assignee, a due date and a status.
Business impact: the cost of confusion
SLA compliance failure
A service organisation promises same-day technician arrival for urgent cases. They measure this against work order creation time. But customers are creating cases, and it takes two hours for the dispatcher to create the work order. The work order SLA is met (the technician arrives the same day), but the case SLA is missed (the customer waited two hours for acknowledgement). Management thinks they are hitting targets. Customers think they are slow. The organisation is measuring the wrong object.
Visibility collapse
A customer has three work orders over a week. The technician sees three separate jobs. The customer sees three separate visits. Nobody, not the technician, the dispatcher, the customer or support, has a unified view of the issue. One technician tries something. Another technician does not know and tries something contradictory. The result is customer frustration and serious churn risk from a poorly coordinated multi-week repair.
Data quality decay
When work orders are overloaded with case information, technicians add inconsistent data. One technician adds detailed notes; another does not. Now you cannot run accurate analytics on how long repairs take or what your first-visit fix rate is, because the data is scattered across cases, tasks and work order notes.
What we would actually do: practitioner judgement
In a field service operation with 50 or more technicians, enforce strict object boundaries. Work orders are for field execution only. Cases are for customer issues. Tasks are for internal coordination. Each object has one job.
A case is created the moment a customer reports an issue or you identify one. That case gets an SLA, and you measure SLA against cases, not work orders. A support team owns case resolution. A field operations team owns work order execution. They are different accountabilities, and tasks bridge them.
For every work order, there is a case. For every case-level follow-up action, there is a task. Technicians close work orders when field work is complete. Support closes cases when customer issues are resolved. Project managers monitor tasks to ensure coordination. This separation is uncomfortable because it requires three different views and three different teams thinking about the same customer issue. But it is the only way to get accurate SLA compliance, visibility and data quality.
Use tasks to eliminate chat and email coordination. "Who is ordering the part?" becomes a task. "Who is calling the customer?" becomes a task. "Who is reviewing the diagnostics?" becomes a task. When work is scattered across messaging apps, you have no audit trail, no due dates and no accountability. Tasks solve this.
The honest concession: when this breaks down
If you have fewer than ten technicians and simple service, mostly same-day fixes with few follow-ups, you can get away with combining cases and work orders. A single record per customer issue works fine, and the overhead of separating objects is not worth it.
If your service is highly complex, with multi-week repairs, multiple technician specialisms and extended customer communication, this separation is non-negotiable. But it means training dispatchers, technicians and support staff on three different ways to think about a single customer issue. That is hard, and many organisations skip it and suffer.
Frequently asked questions
Should every customer issue generate a case?
Yes. A case is the customer issue. Even if a customer calls with a quick question and you answer it immediately, create a case. You need the record for SLA tracking, analytics and pattern recognition. Close it immediately if you resolved it immediately, but the record matters.
Can a case have zero work orders?
Yes. "Can you send me the user manual?" creates a case. You send the manual. The case closes. No technician visit needed, no work order.
What happens when a technician discovers a new problem on site?
The technician notes it in the current work order. Back at the office, support reviews the note and decides: is this part of the original case (same issue, deeper diagnosis needed), or is it a new issue (new case, new work order)? The field team discovers; the back-office team decides. This separation clarifies accountability.
Can a task generate a work order?
Sometimes. A task to schedule a technician visit might result in a work order being created. But the task tracks the scheduling action; the work order tracks the execution.
How do you prevent tasks from being forgotten?
SLA-driven review. Every Friday, review all open tasks. Ask: is this still needed? Is the due date realistic? Does the assignee need help? Tasks need governance just like cases do.
The one thing vendors will not tell you
Most field service platforms let you create cases, work orders and tasks, but they do not enforce boundaries. So implementations get messy: work orders stuffed with case information, cases that are really task coordinators, tasks that are really work order fragments. The system is flexible, which means organisations can, and do, use it wrong. If you are buying field service software, spend time during implementation forcing clean object boundaries. It feels restrictive and your team will resist. Do it anyway. Three months in, you will have audit trails, accurate SLAs and data you can trust.
Summary
A work order is a field execution record for one assignment at one location. A case is a customer issue that may span multiple assignments and timelines. A task is an internal action item. They are three objects, so do not collapse them into one. When you keep them separate, you get clear SLA compliance, visible coordination and reliable data. When you collapse them, you lose accountability and create confusion that costs customers and revenue.