6 Tips for Implementing Optimization in Field Service Lightning
Field Service Lightning’s Optimization functionality packs a serious punch, sometimes bringing multi-million dollar savings to field-based teams.
For those new to implementing Optimization for clients, there are a number of things to consider.
1. It’s a Journey
In a previous article for SalesforceBen, we took a trip around Chicago to demonstrate the perils of oversizing a Service Territory in Field Service Lightning. And like with Big Dave’s Big Day, implementing Field Service Optimization should be treated like a journey.
I’ve seen too many clients throw in a small amount of time to be able to set up Optimization but the reality is that - unless you’re feeling lucky - the process is going to involve several iterations of testing and feedback before it’s perfect.
2. Educate the Project Team
It’s important to be very clear about what Optimization can achieve. But also be equally upfront about what it doesn’t do in order to set expectations early.
This helps the testing process and avoids any time-consuming mismatches between you and the business right when you don’t want them - during UAT and go-live.
3. Start Small
The best way to roll out Optimization is often in iterations, first taking a small pilot group of Service Territories with varying characteristics.
This will help the business gain confidence in the tool and minimize the disruption that could be caused by 50 dispatchers overloading a Product Owner with questions.
4. Test It To Death
You’ll need testing data - and lots of it. If you’ve got a developer Sandbox, it’s time-consuming to try and recreate data from a production environment so you can use the handy Sandbox Berry tool to help you out.
Remember you’ll need data which spreads across the whole testing process so, depending on the length of the testing & UAT cycles, you may need to either (a) repeat the process of importing test data or (b) repurpose the data you’ve already brought across.
The dispatchers will need to get their hands very dirty during UAT in order to aid the transition away from their existing system.
And sometimes there will be exceptions, where the placements made by Optimizer at first don’t seem logical. These can normally be traced back to the Work Rules and Scheduling Objectives as well as the dates defined in the Service Appointments.
These exceptions will move you towards a shared understanding of the Optimization engine and acceptance from the client.
You can also take images of the before & after travel times to demonstrate it’s impactfulness on travel time.
5. Forget About Manual Optimization
For many teams that are used to lining up schedules manually, Field Service Optimization is a big leap of faith. Moving away from controlling the scheduling of every last appointment is a bigger step than you’d imagine, so clients will need to be educated and prepared to move from a system of discretion to a rules-based engine.
For example, I’ve seen clients who were dead set on their idea of creating “runs” which go along a main highway in a straight line and then back again in the same direction. The client had to become acquainted with a new way of doing things, as FSL does not support runs in a straight line (Unless this is the optimal route).
The engine is going to get it right in most cases and the dispatchers can handle exceptions on the Gantt - but for the bulk of Service Appointments the Optimizer knows better and will vastly reduce the efforts required in manual scheduling.
6. Careful with Large Territories
Due to the logic being based on the 'Travelling Salesman Problem', you’ll need to pay close attention to performance in large, rural territories with significant drive time.
A good solution to this is to group the more populous territories with the more rural territory.
Another way is to limit the exposure to that rural territory so it can only be serviced on specific days.
The more appointments available for a specific timeframe, the better the performance of Field Service Lightning Optimization.