# How to reduce technician travel time using FSL optimization The scheduling optimizer already accounts for travel. The levers you have are the shape of the territory, the first job of the day, and durations that include the real drive. **Published:** 2025-12-04 **Canonical:** https://synconai.com/reduce-technician-travel-time-field-service **Author:** SynconAI Architecture Team ## In short The scheduling optimizer already accounts for travel time, along with skill, location, and other factors. Shorter days come from the territory a technician may enter, a sensible first job, and durations that include the real drive. This page does not promise a percentage. The product is Agentforce Field Service and Operations. ## Sources - **Agentforce Field Service and Operations** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=service.fs_overview.htm&type=5 > 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. - **Agentforce Field Service and Operations** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=service.fs_overview.htm&type=5 > Set up multilevel service territories that represent the regions where mobile workers can provide services. ## What to take away - Travel is already an input. A second map does not add a fact the optimizer was missing. - Territory shape decides which jobs a person is even allowed to be offered. A sales-region shape makes long drives look legitimate. - The first job of the day should sit near where that person starts. A first job across the city sets the tone for every hop after it. - If the duration quietly includes a drive, and the optimizer also adds travel, you are counting the same road twice. Pick one place for it. ## The guide 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](/service-territories-operating-hours-field-service). 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. ::: note The first job is an ordinary appointment the optimizer can be pointed at by the locations and territories you stored. It is not a slogan about "starting smart." If the stored start is wrong, the smart start is wrong, and every hop after it inherits the error. ::: ## 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. ::: warn A promised percentage is a guess with a meeting attached. Salesforce did not publish a saving. This page will not invent one. Report the travel you actually record, after you have changed a fence you can name. ::: 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. ## Questions ### Does Field Service optimization already include travel time? Yes. Salesforce says the scheduling optimizer accounts for worker skill level, travel time, location, and other factors. Travel is already an input. The work is to make the territory and the durations honest, not to add travel as if it were missing. A second map does not insert a fact the optimizer lacked. If the drives are absurd, read the territory membership and where the day is allowed to start; those are the records that made the long hop legal. ### How much travel time will we save? Nobody honest can say a percentage in advance. Salesforce did not publish one, and this page will not invent one. Measure the travel you actually record, change the territory shape, the first job, and the place you store the drive, and report what moved. Keep the before and after in the same units, or a drop in the number is just a change of form. If the number does not move, the fence was not the cause. Look at the first job and the duration next. ### Should the drive sit inside the job duration? Put it in one place only. The optimizer already accounts for travel time. Also folding the drive into every duration double-counts the road and makes utilisation look like time on the tools. Leaving the drive out of both places makes the day look shorter than the road. Use the same treatment on every work type, or the fortnight comparison is meaningless. Correct the pattern on the work type; a single appointment edited by hand will not teach the next run. ### How do multilevel territories affect driving? They represent the regions where mobile workers can provide services. A technician on a parent territory that covers too much ground can be offered jobs that force long drives, and the optimizer will take the offer when the skill matches. Membership should match the patch they are meant to work. Keep the parent for reporting if you need it, and test whether parent membership also schedules. A specialist with a rare ticket may cover several patches on purpose. That is a named exception, not a reason to put the whole crew on the parent. ### What does FSL mean here? Field Service Lightning, the name people still search for. FSL optimization in the title is that older phrase. The product is Agentforce Field Service and Operations, formerly Field Service. The help page still describes a scheduling optimizer that accounts for travel time. The rename does not add a savings figure. Shorter days, if you get them, come from the fence, the first job, and durations that do not hide or double-count the drive. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Field Service (https://synconai.com/salesforce-field-service).