route optimization in field service management software

We’re polishing off an upgrade to our dynamic scheduler, which is a field service route optimization system that allocates engineers to jobs based on a number of criteria.

The technical details of how exactly it works are a bit of a trade secret, so I won’t get very much into detail about it, but I’ll give some broad hints – the field service optimization software works by assigning “costs” to decisions (does the engineer assigned have the right qualifications, does it bring the engineer into overtime, is it at the requested time, cost of the engineer’s hours, total hours worked, etc), and trying to minimise those costs.

In route optimization, field service is not really well covered in the market. Most route optimization systems are very simplistic. For example, they might assume that all engineers can do all jobs, or that we can simply assign a time to a job and the customer will be happy to work that into their schedule. You know how phone installation engineers keep turning up at your house when you’re not it? Yeah – bad optimization in their field service management software.

In my head as I’m building it, I keep imagining the job criteria as “pressures” – each of the criteria we are balancing acts as a kind of spring or elastic, trying to push and pull things this way or that to bring everything into place. Another way to imagine it is like how bubbles are created – they minimise their surface area efficiently, based on pressure from within.

From the user’s perspective, this must all be invisible – they should simply create a job and have it automatically assigned to the right person, or select a load of jobs, click “Schedule”, and have the field service job management software sort them into a reasonable solution.

Solving all of this so that it’s easy for the user is not a straight-forward thing for the developer. I mentioned “costs” – but what values should they be? Deciding exactly how “strong” the springs and elastics in the model should be is a difficult problem in itself! We’re considering writing a system after the current phase of development which will use neural networks to try figure out the right answer to this one. In the meantime, we have some pretty good values that give us results that look right.

The final parts we’re finishing off involve making sure that engineers get home after their day’s work at a reasonable hour (no routes that spend 8 hours meandering them 300km away from home and leave them stranded), and taking individual work hours and holidays into account. The field service engineer management software needs to take all of these into account, or the engineers will not be happy.

Our field service management software features are already impressive, but we think that after this phase is finished, it will leave the competition smoking 🙂

We have a number of clients already using this in their day-to-day work. If you’d like to join them, contact us for a demo.

New features in the Dynamic Scheduler

This week, we concentrated on development of one of our flagship features – the dynamic scheduler.

The dynamic scheduler is a field service scheduling software tool that lets you automatically assign jobs to your engineers. It tries to find the shortest route in order to finish the jobs, based on a number of criteria.

The field scheduling software can set your jobs so that they require that your engineers have specific skills. You can set work hours for the engineers so they are not assigned jobs in the middle of the night or weekend. You can “stick” some jobs so they must be done at specific times.

The work this week was on enhancing the job scheduling software so it has additional new features. You can now:

Set work-days and hours for your engineers. Previously, it was hard-coded that jobs would be assigned Monday-to-Friday, 9 to 5, and anything outside those hours would be heavily discouraged by the heuristic. You can now set “shifts” for your engineers, and specific work-days.

Set daily end-points for your jobs. Previously, the routes would be calculated from a “work-base” (for example, the engineer’s home) and radiate outwards from there, but there was no guarantee that the routes would lead the engineer back home at the end of the day. Because European law says that field-workers need to be paid for the hours it takes to get to/from work, this means some routes could end up with the company paying overtime as the engineer simply drives home from the last job of the day. The route planner now designs the routes so that routes end up every day at the work base. Basically, routes are loops now where they were previously strings.

The system would try its best to stop at 8 hours in a day. But if jobs are four hours each and there is 30 minutes travel between them, this could cause the planner to assign just one job per day. We have added in overtime rules to allow the planner to assign jobs that might stretch the daily work hours a bit.

We have also added a new feature to allow you to add any overdue jobs to the pool of jobs being scheduled. So you can say “I want to schedule jobs assigned between Tuesday and Friday, and put any overdue jobs into that mix as well”. With pest control scheduling software, you don’t want to have to wait too long for a job to be rescheduled, if it has already been put off once.

Some jobs require that a specific engineer do them. Maybe the customer likes the engineer, or they have specific knowledge of the job. You can now “stick” a user to a job so the scheduler doesn’t try assign the job to someone else. this is particularly useful in service industry scheduling software where the product being services is unique.