By Tom Paquin

WBR’s Field Service USA Conference is an excellent opportunity to connect with business leaders, check in on old friends, and get a feel for how the industry is changing. I’m certain that there will be quite a bit of digital ink spilled on the topics uncovered at the event (We’ve already had a bonus podcast episode recorded while there), and there are quite a few things worth unpacking in the coming days and weeks. One thing that stuck with me throughout my conversations was that many service leaders are struggling with getting their technicians to actually use the systems that they’re supposed to.

This dilemma is obviously as old as technology itself (arguably older). There’s a 1999 Harvard Business Review case study titled Rich-Con Steel, still routinely used in MBA programs today, that serves as a cautionary tale for companies training and implementing new IT systems. In it, a tacked-on and poorly-vetted solution is ignored by fronline workers, inciting inaccuracies that ripple throughout the business, from order management, through inventory, and customer service. In real life, this ultimately led to the decline and bankruptcy of the Richards & Conover Steel Co., a Kansas City institution founded in 1857. The company’s building has been repurposed into luxury lofts. A cautionary tale, indeed. We’re 20 years removed from the failures of Rich-Con Steel, of course, and technology-adverse companies no longer have the luxury of doing nothing. This is especially true in service, where a break-fix mentality is increasingly rejected by customers, who expect little to no downtime, and rapid resolution when it happens. Fancy new technology investments can lay the groundwork to help organizations compete, but the resounding refrain from executives was that down-the-line execution was failing. This was true in a variety of technology categories, but for many, the failures seemed to stem from two specific pieces of tech: Augmented Reality, and Field Service Management itself. For service firms adopting AR, the issues seem to stem from a combination of tech limitations and workforce failures. On some remote job sites, techs lack the cellular connectivity for their AR solutions to work properly. More often, though, when they’re in need of support, many executives made it clear that their technicians go straight to phone calls, and leave it there. AR utilization failures can cause slowdowns, but failure in utilizing service management systems properly can lead to data inaccuracies that can impact business effectiveness catastrophically. When techs don’t log service appointments properly, delay or neglect part usage, or don’t take advantage of internal systems for invoicing, you suddenly and dangerously lose all visibility into how your business is run. One service leader indicated that he, manually, started and ended technicians’ service appointments for them in his system when he saw them reach a job site. That’s no way to run a business. With those problems in mind, here are a few things that can help smooth over your tech’s relationship with business systems. These may not be the right fit for everyone, but taking a step back and reevaluating your approach could save your company a lot of anxiety in the long run.

Pilot Programs Need to Be Exhaustive

I’ve said this before and I’ll say it again—Don’t just pilot new systems with your leading technicians. Also pilot them with mediocre performers, and, ideally, some new techs as well. This will give a much better vision of how systems can, and will, be implemented, both at different levels of tenure, but also at different skill levels. This will also help you build a practical implementation plan, especially when it comes to more abstract tools like AR. For example—If nine out of ten techs show no performance improvement through a specific job, but AR decreased onboarding time by half, that gives you a pretty solid business case for deploying AR as a training utility first, then further iterating for on-site opportunities.

Rollout Should be an Event

I’ve been in companies where rollout of a new system is part of a one-hour meeting, or done so piecemeal over the course of eighteen months. The former leads to technicians feeling unprepared and unsupported with new technology, while the latter allows employees to lean on old systems, often causing efficiency drags and inconsistent reporting. So—new technologies should accompany, generally, a week of initial training and shadowing. Use your pilots as player-coaches, form breakout sessions, and immerse the staff in your tools. Articulate the personal value for them—time saved, easier processes, access to better information. From a business process point of view, it may seem horrifying for the company to train for a week, but an upfront time investment pays dividends in the long-run.

Let your Techs Know Where They Stand

This is simple visibility. Technicians will be more inclined to use tools if they see others are using them, and they are given a gauge on their own performance. This is also a great way to glean some more value on reporting tools built into the hardware and software that you buy, by turning some of those reports towards the front-line workers most impacted by them. I would not advocate making utilization numbers, time-on-task, or repair times necessarily points for disciple, but they can be used as an opportunity for re-training.

Make Automation your Friend

Let’s think about our service leader from earlier, who manually started technicians’ appointments when they reached a job site. It would take virtually nothing to automate that task—A notification that a technicians received on a job site that says, “You have reached your job site. Would you like to begin your service appointment?” This brings them into the application, rather than doing the work for them. This baseline will only be built upon as more sophisticated AI processes automate more and more simple, repeatable functions. This is but one example.

Listen

Your technicians are not lazy, technology-adverse, or incapable of learning. A technicians’ hesitation to adopt a system derives from their desire to offer the best service possible, and the fact that they, the technician, have the best understanding of how to do that means that there’s a great opportunity to hear from them. Don’t just include them at the pilot stage, bring them into the decision-making process. Understand the worst part of their job. Invest in solutions that solve those problems, and you’ll have a team that respects your decisions, and uses your tools. It’s not hard, but it definitely requires more than simply buying a piece of software.