By Tom Paquin

We are quick to point out here at Future of Field Service that service does not stop and start with appointment booking. Service—true service—extends throughout a company’s lifecycle, and properly operationalizing, automating, cataloging, and tracking service requires a holistic understanding of business elements, from human resources, to parts, to procurement, to fleet management, and everything in between. 

To cover their inability to meet these expectations, many service software providers gloss over their lack of capabilities by developing wide networks of ISVs: Independent Software Vendors. ISVs offer software that, when sold in tandem with a platform, provide functional support absent in the core system.

There are invariably some benefits to working with ISVs. If you work in a specialized industry, ensuring that you have all the modules that you need to be successful often requires configuration across a broader network than just what a core function offers. Furthermore, integration flexibility offers the ability to add on modules on the fly, so you can start with a core system, and deploy new systems as-needed. 

For all the good, though, there’s a bad side, and it comes when you tip the scale from supported ISVs towards building an ISV Frankensystem on an underpowered core platform. The reality is that if you’re buying roadmap or implementations, you’re not buying software stability, and it’s imperative that you explore those options out of the gate. Here are some traps to avoid:

Implementation
We all know that you want to avoid as much customization as possible when implementing any system. Doing so means that the software is less likely to break, updates and further integrations are easier, and your “vanilla” experience is easier to support. ISVs often lead to a ballooning effect with customizations, which in turn increases the cost, resources, and time associated with implementing a new product. 

Updates
The fraught nature of this patchwork post-implementation means that updates then can become a challenge. With inconstant product-by-product upgrade cycles, you suddenly run the risk of incompatible software, certain business-critical modules losing support, or inconsistent compatibility issued with specific hardware or internal processes. 

Apps
We know that getting technicians to push the buttons they need to in order to use their software is often easier said than done, so using a specific FSM mobile app piles another layer of challenges on top of that. ISVs have the potential of extending that swath of apps beyond one to several, each, again, with their own UI ad idiosyncrasies. In the world of mobile apps, consistency is key, and more solutions means more possible failure points. 

These are a few examples of where ISVs can let you down. I would preface this by saying that not all ISVs or ISV relationships are created equally. Many are very well-integrated, communicative with the core vendor, and avoid many of these pitfalls. But the broader the ISV network you employ, the more you roll the dice. That’s why it’s important to evaluate what actually comes in the box when you’re investing in new service technology.