We spend quite a lot of time around here discussing what defines exceptional service delivery, whether it be the strategies for managing customer retention, transitioning to new business models, or navigating an unprecedented crisis. Through our often lofty discussions about these topics, it’s easy to forget that each organization is at a different point in their service journey, and for some, investing in field service software might not even be on their radar.

I was reminded of this recently when I was asked to answer the question in the title of this article. What an incredibly refreshing question! Putting aside all the bluster, all the acronyms, and all the business goals, actually defining the tool for its purpose was a great reminder of what it is that we are actually talking about here every day. So let’s try to answer the question:What is service management software?

I used to be a high school teacher, so would like to think that I’m pretty good at synthesizing definitions into as close to a singular idea as possible, then using that as the foundation to explore and connect more complex theories and practical applications, so let’s try that. Here’s what I came up with:

Service Management Software is a tool, or series of tools, that allow businesses to track, record, and optimize their field operations and service processes.

That doesn’t actually say much about what makes service management software important, or what makes for good service management software, or even what sort of things are tracked, recorded, and optimized, though. The truth of the matter is that answering those questions requires more than the software itself allows. It requires an intimate understanding of not just service operations, but business operations on the whole.

And that’s part of the challenge with defining service management software. Service functions for businesses are so complex, so diverse, so tribalistic, and so disconnected that getting a piece of software that fits around all the flailing tendrils of your business is not as easy as installing a new piece of project management software.

Don’t tell that to some vendors, though, who build their service software based on a binary checklist of service needs. Many companies, especially those new to the service game who are seeing the revenue potential of service management, build products with feature sets as basic as their other applications. This requires businesses to shove their service processes into a pre-built mold, which always means that you have to saw off elements of your service delivery plan (sometimes entrenched with years of experience) to compromise to software limitations, or invest in even more products to get back to square one.

Because of this, service management vendors that simply have a long list of capabilities, even if those capabilities look particularly flashy in a demo environment, need to be held up to greater scrutiny. Will this parts management system work for the multiple tiers of service appointments that I deal with? Does this crew management system allow me to manage my workers the way that they actually work, or does it just throw names into a list? Does this optimization software manage the scope of global appointments that my company much have oversight for?

So does that mean that depth of execution always trumps breadth of capabilities? Obviously not, but it’s important to understand how the two areas compliment each other. Then you’ll need to take it a step further, and look at what embedded systems exist today, and how they can be integrated or deemed redundant. Then you need to look at your one, five, and ten-year plans for implementation and ensure that there’s a development roadmap that matches up. Then you need to look at implementation, onboarding, the list goes on.

Each of these steps could take months or longer, of course, and there are often hundreds of considerations, stakeholders, and use cases. This new “Back to Basics” series hopes to tackle those issues one by one, and explore all those elements of service delivery, starting with the capabilities that set service apart. Whether you’re looking to invest in a whole new system, or pare down and streamline the systems you have, or just focusing on perfecting service delivery, these will service as an opportunity to revisit, dissect, and perhaps reimagine what actually defines service management software.

There are obviously a dense web of contradictions in even writing about this topic depending on the industry that you are in, and I’d like to flip over as many stones as possible. If you want to share a story or have a question with respect to this series, please don’t hesitate to reach out.

Tom Paquin
Author

Contributor, Future of Field Service