The acquisition of ClickSoftware, the Tel Aviv-based field service powerhouse, sharpens the focus on Field Service Lightning, particularly for Consultants with some exposure to Service Cloud. The product is a masterpiece and visually pleasing. Consultants should see a strong future in it.
In our last article, we covered how to get a high-level view on Field Service Lightning and all the wonderful things it has to offer. When scoping any project, it’s important to get a sense for where the complexity is – from the beginning – to stop the problems from stacking up at the end of the project. In this article, we look at how to identify some of the many scoping “gotchas” of Field Service Lightning.
Key Differences Between Simple and Complex Projects
Let’s look at some key differences between straightforward and complex setups:
|Jobs||Jobs are single visit, single resource work such as break/fix, maintenance, repairs or even sales||Jobs are multi-stage, take more than a day, require more than 1 resource, and have scheduling or part manufacturing dependencies|
|Processes Followed by the Team||Most teams follow similar but nuanced processes||There are various visibly different processes for different parts of the business and each business unit should be considered individually|
|Territories||Territories are clearly defined with boundaries which are rarely crossed. The territories are geographically small and have up to 20 people||Lots of primary, secondary and temporary relocation territories which change frequently or are “rostered” to share the travel between different resources each week|
|Scheduling||The out-of-the-box scheduling policies are a good fit for all the customer’s resources||Custom scheduling policies must be created with different rules for different parts of the business|
|Gantt View Requirements||The out-of-the-box Gantt is a good fit for all of the customer’s dispatchers||Customizations such as Custom Actions are required to achieve what the dispatchers need from the Gantt|
|Scheduling & Sequencing||A “Travelling Salesman” approach to creating appointments that start near the base/home and work their way back towards it||Resistance to move from approaches such as feeling the need to manually control the sequence and shape of the schedule|
|Mobile Requirements||All requirements for mobile can be contained within the FSL mobile app||The client needs custom components, pages and flows. It’s unclear whether FSL mobile will support the business requirements|
|Finance Processing||Information already available on the Service Appointment is enough to use for finance processing||Complex handling for finance is required e.g. measuring billed vs unbilled time, or calculating billable time based on variables.|
|Handling Bookings||Booking is handled within Salesforce, by the customer’s team||Booking is self-service and driven by external systems|
|Work Types||The client has already identified common “Work Types” which can be used to automatically define durations, skills required and materials required||The client has not given any thought to identifying repetitive tasks, or doing so is not a good fit for the business|
Having worked on dozens of Field Service Lightning engagements, I have noticed that compared with Sales & Service Cloud projects, Field Service Lightning requires a more intensive effort from the business team to help make it a success. If you notice any of the following red flags, be sure to escalate it internally and make your concerns known early:
1. A lack of buy-in from any level of stakeholder
2. There is a lack of technical leadership on the client-side
3. A big scheduling team feel threatened by the system’s automation capabilities
In this post, we’ve looked at the 10 key differences in project complexity, so you can spot a simple use case from a complex one. Armed with this knowledge, you will be able to run your FSL project smoothly and avoid the dreaded red flags. Next time, we will start digging into the technical detail on the product, as I continue to share what I’ve learned in my FSL journey so far.