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

We’ve obviously spoken about implementation in the abstract before in this series, specifically with respect to replacing an old service provider, or implementing service technology for the first time, but I feel that it’s worth discussing the processes and pitfalls of what happens when the rubber hits the road.

We’ve seen how this can fail before. It’s important to build systems with employees in mind. This has been the subject of much of our discussion about selecting a service system to begin with. But when you’ve gone through the bid and selection process, what does the act of implementation look like?

There are ostensibly two stages to this—handling the technology, and handling your people. Let’s start with the tech.

Ripping Out the Old Wires

Whether you’re bringing in an end-to-end service system to manage all areas of service oversight, analysis, and optimization, or you’re installing a peripheral piece of software designed to enhance or simplify an experience, odds are good that you’re going to need to reroute some systems, and some thinking. I don’t need to tell you that timing is key, and most businesses build their sunset plans to overlap with deployment of a new solution.

How that looks can differ from business to business, and we’ll discuss in more detail exactly how that nuance can be developed below. It’s a tough balance, because you don’t want technicians to lean on old systems, and when a database is ported over, then that’s the end of it. But there’s inevitably benefits in holding off shutting the lights off until it’s time.

If you’re moving from one vendor to another, it’s often imperative that you look at how vendors have handled transitions from your old vendor in the past. There may be a list of considerations based on precedent, or there may be one particular integration partner that is more adept than others at managing and coordinating the transition.

Enabling Your Staff

Once the transition has begun, it’s time to start thinking about how you on-board staff. We’ve talked about the importance of building teams of player-coaches in the organization, how imperative it is to develop pilots (thus overlapping old a new technologies), and setting hard benchmarks for your team before, but it’s worth revisiting again.

This organizational agility will likely outlast your relationship with an implementation partner, so the onus of how effectively you wield the powerful tools you’ve been enabled with will depend greatly on how they are absorbed into your company culture. In my experience, small pilots are a great way to see what works with a given product.

If you’re going to pilot a new solution with, let’s say five percent of technicians, it’s important that they are not all high performers. Your pilot should represent the broad demography of your service technicians, with older and newer employees, and employees at different levels of output. It’s up to you whether you want to involve different disciplines in a pilot. In my experience many businesses opt to run pilots in a specific division first, then expand it out, but it’s feasible to run a pilot across all different types of service functions.

Pilots are meant to be temporary, of course, so taking it live is the next step. With a major update, many companies make rollout an event. We see organizations shut down operations for a day, onboard new technicians, sell the value of the new technology, and make every resource available to ensure success.

With any technology initiative, starting off on the right foot is imperative. Set yourself up for success with the right tools, a solid implementation plan, and the right people to take it over the finish line.

Tom Paquin
Author

Contributor, Future of Field Service