Best Practices for Work Order Planning and Routing for Field Service Companies
If you’re a field service company, chances are high that you’ve experienced issues with your work orders in some form or another. These complications can prevent you from delivering the quality services your customers have come to know and appreciate. Whether it’s a disjointed intake process, a missing detail on the work order, or a complex scheduling problem, there’s an easy fix to your troubles.
Your business relies on the efficient handling of work orders so that you can properly dispatch people to solve your customers’ issues. Whether it’s an installation, routine maintenance, or repair work, you rely heavily on work orders. D365 Field Service is designed to automate workflows and save you time in this regard.
We’ll explore the best practices for work order planning, explain how to optimize work order creation using templates, and clarify how to identify appropriate resources for each new job.
Dynamics 365 Field Service overview
Field Service is part of the Dynamics 365 Customer Engagement suite of solutions and includes robust functionality for any size field service company. D365 Field Service does require licensing, so if you were to install it, you would need to obtain licenses to run the application. A word of advice: this application is something you’ll want to install in a sandbox environment and explore rather than jump in headfirst out of curiosity.
That being said, it’s a fan favorite of our customers. D365 Field Service is very mobile friendly. In the field service industry, as you can imagine, technicians rely heavily on mobile devices out in the field.
There’s plenty to explore in D365 Field Service, but today we’re going to focus on incident types and the work order.
The work order is your master transaction type. It contains four subsets:
- Products
- Services
- Service activities
- Bookings
Your work order will handle the products you’ll need in order to resolve a situation or repair something. Naturally, there are services involved in the work order, some (or many) of which could become potential billing opportunities. In D365 Field Service, there’s an entity called Service Activities. Service activities are the different steps or tasks that your technicians have to undertake in order to complete a work order. Finally, there’s the booking. In booking a work order, you’ll need to find the appropriate resource to complete the work, based on location, skill set, and so on. All of these elements go into your master transaction type: the work order.
Incident Types
Incident types act as your work order template. All of the criteria we’ve just mentioned that make up a work order (products, services, tasks, etc.) are part of a template we can build in an incident type. If you’re running D365 Field Service and aren’t utilizing incident types, we hope this blog changes your opinion. Incident types dramatically expedite the building of a work order.
As we’ve said, you can add products to an incident type. You can also add services, service activities, and something D365 Field Service refers to as “characteristics” to incident types. Characteristics serve as the skill set needed by your resources to perform a function.
Let’s say, for example, that we need to repair a piece of equipment for a customer. You likely need a technician that has certain characteristics (i.e. skills). Your application allows you to find resources with specific characteristics — and even filter by how adept a technician is at a particular skill set.
Incident types can also be attributed to a service case entity. If you have the D365 Field Service application, you can turn cases into work orders. Therefore, you can also attribute an incident type to a case in the event that you will turn that case into a work order.
Real-World Examples of Incident Types
Sometimes you’ll receive a work order for something highly singular and specific, but very often in the field service industry you have known, common issues that you understand exactly how to handle.
Rather than build a commonly-requested work order from scratch each time you receive it, you can leverage incident types to build out templates that auto-populate your work order. That way, instead of editing every field, you can choose a work order template and make any necessary changes to the specific situation.
Here are some real-world examples of incident types:
- Unexpected reboot
- Line connection lost
- Replace broken part
- Replace core part
- Replace peripheral part
- Standard inspection
- Unit overheating
- Power fluctuation
You can build as many incident types as you’d like. We’ll use the “Unexpected reboot” example to delve further into incident types and work order planning best practices.
Building an Incident Type
In our fictitious example company, we service technical equipment. We want to design an incident type to templatize a known issue. Our company frequently gets calls from customers where our systems are suddenly and unexpectedly rebooted. Each time we receive one of these calls, we need to create a work order.
Rather than input the same data into each “unexpected reboot” work order, D365 Field Service gives us the option to pre-populate the order by using the incident type feature. We can include details such as:
- The estimated time it typically takes to repair
- Products that we know our technicians will need in order to perform this service/repair
- Which services will be necessary
- Which tasks must be completed by the technician
In order to perform this unexpected reboot, we know our technicians will need to perform four specific tasks. They’ll need to read codes out of the system, diagnose the issue based on those codes, perform the repair, and then test and validate that repair. Anytime we receive a work order for an unexpected reboot, we know these service tasks must be fulfilled.
We can input this into the incident type, so that whenever a new work order is issued, we don’t have to manually add those four tasks. The details, products, services, activities, and characteristics from our incident type will all populate in any new “unexpected reboot” work order.
If you’d like to see how to build an incident type from scratch, check out the video below. We’ll walk you through the incident type creation process, as well as explain the meaning of each entity within the incident type tabs. This short video is a great overview on work order planning best practices (and it uses the unexpected reboot example from above).
Work Order Planning Best Practices: Summary
Without using incident types, building work orders can be tedious. You can create work orders from scratch, sure, and build out your tasks, products, and services one at a time. Incident types, however, give you such a head start. In many cases, your incident type can build a complete work order for you.
It’s highly recommended that you look into using incident types. Without it, you’re likely relying on an expert within your company to build each work order. You’ll need someone who’s been around for a long time (and who has extensive corporate and on-the-ground knowledge) who can look at an incident and say, “we’ll need these products, these services, and this skillset from a technician.”
Save yourself time and allow your experts to spend their energy on other tasks. After all, if it can be templatized and automated, it’ll set you up for success in the long run.
If you’d like to learn more about how Dynamics 365 Field Service can benefit your organization, reach out to the experts at Stoneridge Software.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.