ChatGPT
Claude
Google AI
Copilot
A technician who starts in one suburb was offered a job two hours away, then three jobs on the way back that only existed because the first offer had dragged them across the territory. The skill matched. The travel, calculated inside a huge fence, looked acceptable to the scheduler. The fence was a sales region. Nobody had decided it was a service patch. The day was spent on the road, and the board called it an efficient route.
People still search for FSL optimization. FSL is Field Service Lightning, the old name. The product is Agentforce Field Service and Operations, formerly Field Service. The travel question is already answered in the help page, and the answer is not a percentage.
"A scheduling optimizer that allocates resources to appointments in the most efficient way possible by accounting for worker skill level, travel time, location, and other factors." Travel time is in that sentence. Anyone promising a cut of a certain percent is selling a number Salesforce did not publish, and this page will not invent one.
Territories are the other half. "Set up multilevel service territories that represent the regions where mobile workers can provide services." If the region is wrong, the travel the optimizer accounts for is travel you forced.
Territory shape
A territory that follows a sales patch, a postcode list nobody has revisited, or a state boundary will offer jobs that look efficient inside a bad fence. The technician drives the fence. Shrink or split the territory so the jobs inside it cluster, and so the person who starts in that patch is the person allowed to work it.
The shape is a permission, not a paint colour. Membership says where this person may be sent. If the shape is wrong, every drive inside it is a legal drive, and the optimizer will take the ones that fit the skill. You cannot scold the route for obedience. You change the shape, then you look at the drives again.
Multilevel territories let you keep a parent for reporting and a child for the real patch. Put the technician on the level that matches where they may go. Membership of a huge parent, because it was quicker to assign, is how a city technician becomes eligible for a job two hours away. The optimizer will take that offer when the skill matches. It is being consistent.
Do this with the dispatcher and a fortnight of actual drives, not with a slide. Which hops were absurd, and which territory boundary allowed them? Change the boundary. Then look again. One redraw is rarely enough, and a redraw done from memory will protect someone's favourite suburb. The favourite suburb is often the one a senior technician lives near, or the one a salesperson did not want to lose. Neither of those is a service boundary. Say so in the room, and draw the child patch the work actually clusters in.
Contractors make the shape honest or they make it worse. Their patch is the patch in the agreement, not the employee's territory "for now." A contractor left on the parent will be the efficient choice for far-away work whenever they are the one with the skill that day. That drive is not a travel-time mystery. It is membership. The hours they do not work are the same class of error. A person who is not there cannot save a drive.
How to test parent membership, and how to store the real shift, is the work in service territories and operating hours. Do that test before you declare the fence finished. A shape nobody has checked against a real offer is a drawing.
The first job of the day
Where the day starts matters as much as the hops in the middle. If the first appointment is on the far side of the territory, every later job inherits that position. Prefer a first job near where that technician actually begins, home or depot, whichever is true. Do not invent a rule that everyone starts from a depot if half the crew leaves from home. The location you store is the location that gets used.
Find out which is true before you standardise it. A crew that leaves from home, stored as if they leave from a depot on the other side of the city, will be given a "near" first job that is near the depot and far from the person. The rest of the day radiates from the wrong point. Store the start you mean. If it changes by roster, store the roster. A single start location for a company with three patterns will pick one pattern and punish the other two.
The last job has a mirror problem. A day that finishes with a job far from where the van must end, home or depot, is a drive you have chosen not to see, because it sits after the appointment and the board looks done. If your operation cares about that return, the end location has to be as real as the start. If you do not track it, do not pretend a map will invent the policy. Decide whether the day ends at the last customer or at the depot, and keep the record consistent with that decision.
Duration and the drive, once
Duration is the other leak. Some organisations hide the drive inside the job duration so the appointment "includes travel." The optimizer also accounts for travel time. Pick one treatment and use it everywhere. Hiding the drive in the duration makes travel look like work, and your utilisation number becomes a fiction. Leaving the drive out of both places makes the day look shorter than the road.
Watch finished days. If the van was moving and the appointment record shows neither travel nor a duration that explains it, the next run will plan the same impossible day. Correct the pattern on the work type, not one heroic appointment. A work type that is short by the same block of minutes on every job is a duration problem. A single job that ran long because a part failed is not. Change the pattern. Leave the freak.
| Where the drive sits | What the scheduler does with it | What the day looks like |
|---|---|---|
| Travel time, which the optimizer already accounts for, and not inside the duration | The road is planned as road | Time on the tools and time in the van can be told apart |
| Inside the duration as well | The road is counted twice | The day overflows, and utilisation looks like time on the tools |
| In neither place | The road is missing | The board shows a shift the van cannot drive |
| Different rules on different work types | The comparison is meaningless | One team looks efficient because their minutes mean something else |
Read a fortnight against this table before you change a territory boundary and claim the road improved. If the before-number and the after-number are not the same kind of minute, you have not measured anything. You have changed the form.
What not to promise
Do not tell a leadership meeting that the optimizer will remove a fifth of the driving, or a third, or any other fraction. You do not know. You know that bad territories and bad durations create avoidable driving, and that fixing them removes whatever waste those particular records were causing. Measure travel the way your technicians record it, before and after the territory change, and report that. If the number does not move, the fence was not the cause. Look at the first job and the duration next.
Say what you changed, in a sentence. "We took this crew off the parent territory and put them on the southern patch." "We stopped hiding the drive inside the install duration." "We set the start location to home for the crew that does not come to the depot." Then look at the recorded travel for that crew. If it moves, the sentence was a cause. If it does not, the sentence was not the cause, and another sentence is next. A programme that changes the fence, the duration, and the map vendor in the same week cannot say which one did anything.
Some long drives are real and should survive the redraw. A specialist with a rare ticket may be the only person who can enter three patches. Their travel is the cost of the skill, and the optimizer is right to account for it. Do not "fix" that by giving the specialist every child territory and then complaining about the road. Give them the patches they are allowed to cover, and keep ordinary work inside the crew that lives there. The absurd hop is the ordinary job that left its patch because membership was lazy. The specialist hop is a named exception. Write the exception down so the fortnight review does not delete it.
A new map will draw the same territory. It will not refuse a membership you stored. It will not move the first job nearer to a start location you recorded in the wrong place. Buy one only when you can name a capability the console and the mobile app still lack, and test it where there is no signal. Until that sentence is true, the travel you want to reduce is still a record.
Read the absurd hops with the person who drove them, not from the board alone. Ask which boundary allowed the offer, and whether the first job of that day was near where they actually started. A hop that looked long on a map and short in the van is a record you do not understand yet. A hop they refuse to repeat is the boundary to change. Do this for one crew before you redraw the company. The second crew may cluster differently. A single national shape, copied because the first redraw felt tidy, will invent a new set of absurd hops next door.
Keep the before-and-after in the same units. If last month's travel was a planned figure and this month's is what the technician typed, a fall in the number may be a change of form. Say which source you used, in the same sentence as the result. Then stop. A second sentence about a percentage you hoped for will be the one the meeting remembers, and it will be the sentence you cannot defend.
The scheduling optimizer is already accounting for travel time, skill, and location. Field Service Lightning is the name people type. Agentforce Field Service and Operations is the name on the help page. Neither name will shrink a fence you drew too wide. The fortnight of absurd hops, read with the dispatcher, is the whole method. Change the boundary that allowed the hop. Then measure the hops you record. Stop there.
