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
• The Operational Capabilities of Service
• The Building Blocks of Customer Experience Excellence

This week, we’re looking at how an organization would implement a new service management platform to replace (mostly) manual processes. While many larger organizations generally have a solution in place today, under many circumstances, even those solutions are more of a hodgepodge of utilities than a unified platform. Moreover, as businesses in traditionally product-oriented fields pursue and expand service functions, as has been an ongoing trend, more businesses will need to unwrap service management software for the very first time. And of course smaller businesses who have relied on pen and paper are understanding and embracing the importance of software for their own growth. Today’s Back to Basics are for those groups (we’ll cover transitional software next time).

There are no shortage of shapes and permutations that businesses can take on their road to success, so mileage will inevitably vary. But, as we always say around here, there are a few key components that will tie organizations together when they’re looking at a solution for the first time.

Map Every Millimeter of your Workflows
Last year, I reiterated an old Harvard Business Review case study that has been jangling around in my head since business school, but it’s so obvious a failure point for businesses implementing new tools that it’s easy to overlook. You need to understand every single element of what your service technicians, backoffice, and depot employees are doing before implementing a new tool. This ensure that the software that you’re employing actually solves the real problems that employees are having, doesn’t overextend into nonexistent issues, and is a tool that will actually be employed on a daily basis.

There are a few key ways that you can make this work. One obvious element is choosing a development framework that involves frontline workers from the get-go. This will ensure not only an understanding of their duties, but also help make them advocates for the new software. Furthermore, as noted in the article referenced above, rollout should be an event, with iteration and feedback loops an element of standard protocol. This makes sure the software if giving employees enough cover, and doing in in a way that organically works alongside their job requirements.

Make a Sunset Plan for Redundancies
So you’re implementing a full-featured service tool, which has all the backoffice capabilities that we discussed last time. However, you had previously been running a customer engagement tool designed for small businesses that indexed all your customers, saved their payment info, their work history, and so on. This is now a redundant tool alongside your broader software investment. What do you do? Do you cut and run, forcing customers to re-enter their data manually? Do you continue to use the old tool, running (and paying for) software that does not integrate? Do you port over the data and sunset the old tool? Do you find a way to integrate the old tool into the new one?

There are options, and I’m not here to recommend one in particular (though I definitely would not recommend cutting your customers off, or running redundant systems). The important thing is to have a plan. Must you manually transition system information into the new platform? That would be an awful nightmare, but there are tools to help support that, and with that information in mind, you can build a realistic sunset plan for your older software. Regardless, your goal, and we’ve discussed ad nauseam, is a completely connected system of tools. No redundancies, no crossed wires, no cut wires. Who can help with that? Well…

Consider Implementation Partnerships
While they’re somewhat invisible to the daily discourse on Future of Field Service, we do talk to partners on here from time to time, and write about them as well. Typically, your software provider is going to recommend an implementation partnership to eliminate some of the development burdens and ensure ease of transition into new software environments. Sometimes, your software vendor themselves will have a consulting wing for that express purpose. While this can help with much of the technical, and some of the organizational strain that goes along with service software development, it can’t erase the last mile, which will inevitably come down to your unique business, and how internal teams are advocating for and engaging with the software to ensure its effective use and position within your organization.

Look Ahead
So you’ve mapped the necessary processes, and implementation is done. That’s it, right? Of course not. Technology, like fashion, is never finished. Today, right now, new advancements in areas of business modeling, device connectivity, and emerging technologies are setting up opportunities for much greater efficiencies for service providers, and far more advanced solutions for customers of service. That’s what we’re here for, of course, at The Future of Field Service! Keeping you plugged in to the latest trends and changes in the service industry. More than anything, it’s important to not be afraid to take additional steps on your technology journey, especially after you’ve just implemented a powerful new system. Know that you’ve just scratched the surface of your ROI potential, and that a solid Service Management platform is the foundation onto which you can build a successful digital-first organization.