By Tom Paquin

This is part of an ongoing series on the state and standards of service management software in 2020. Here are the previous articles in the series:

• What is Service Management Software?
• The Key Capabilities of Service Management Software
• The Attributes of Best-in-Class Service Delivery Software

Last time, we went through the specifics of service management software while looking specifically at the delivery of service. Now we’re going to take that a step further and discuss the operational underpinnings of service.

While the capabilities that we’ll discuss are of equal or outsized importance to service delivery as a whole, it’s easy to overlook some of these elements when thinking about service delivery in a purely binary sense. Many companies focus on the delivery of service just in terms of SLAs and appointments, not the broader operational infrastructure that your business functions in. Perhaps they have other systems to govern those, but it’s imperative that all these pieces fit together to create a comprehensive service technology web.

I have a tendency to spend an outsized amount of time talking about operational capabilities—specifically within the context of planning and scheduling—but we’re going to go broader today. Here’s a partial list of important utilities to consider when talking about operations:

• Planning tools
• Parts management
• Reverse logistics
• Driver routing
• Scheduling
• Simulations
• Enterprise resource management

Rather than focus on the act of service delivery directly, each of these tools do something more fundamental: They enable and ease the act of service delivery. Operational technologies serve an invaluable purpose: Take the burden of repetitive tasks off of the technician, the manager, the back office worker.

With that in mind, and as we said last week, these tools can vary dramatically from provider to provider in a number of different ways. Let’s use our favorite example: Planning and scheduling optimization. There’s a huge chasm of depth that can be plumbed within these solutions. The best optimization systems, as we often say, use artificial intelligence to quickly reroute technicians based on appointment, workforce, and external changes. Within most of the tools listed above, including optimization, there are a few common points of inflection that impact depth:

Scale: How many technicians/appointments can be managed in a single computation by your service software? While a cap of 500 technicians might seem like no big deal, you can run separate batches, the reality is that if a single technician passes from one batch to another, the whole system beaks down. There are literally thousands of different ways to run into issues if you’re forced to compromise on how you manage your service technology. Being able to manage the entire scope of your field staff in one instance in a service solution, with the ability to subdivide down to the branch level, provide a huge advantage in delivering accurate service. This is equally true about parts and depot management.

Speed: This one is pretty simple—if you can’t adjust schedules in the amount of time it takes to complete a simple service appointment, then the tool loses usefulness. The bets tools can handle scheduling, parts allocation, depot estimates, and everything else as quickly as possible.

Configurability: It’s important with any tool, really, to be able to subdivide based on types of appointments unique to your business. A teclo provider may have a huge number of consumer appointments and a relatively small number of commercial appointments, such as working on towers or satellite arrays. Can your parts systems appropriately manage, subdivide, and action on both? Are you able to manage technicians from different organizations in a single application? Your business is nuanced, you need to be able to reflect those nuances in your operational software.

Connectivity: Another simple one—everything needs to speak the same language. Not all of your tools need to come from the same place, but they need to be able to share datapoints. This is an incredibly low bar to clear, but I know a lot of enterprises that have a jumble of tools that exist in a vacuum. If that’s the case, how do you identify bottlenecks?