How to optimize technician routing with Field Service Lightning

A Tuesday board can look settled at dawn and impossible by mid-morning. Three customers are waiting. The fourth job has not started. Every appointment was stored as forty-five minutes. The work took those forty-five minutes, plus the induction at the gate, the walk from the street, and the time to pack the van. Nobody typed those minutes. The scheduling optimizer built the day from the number it was given.

People still search for Field Service Lightning. The name on the help page has changed. "Field Service is now Agentforce Field Service and Operations. In some cases, we still use Field Service to refer to this product area in Salesforce applications and documentation."

Routing is not a map problem. Salesforce describes the scheduler in one sentence: "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." That is the published account. This page will not invent the rest of the algorithm.

#The product will still produce a day

That is the trap. An obedient optimizer with bad inputs looks like a product fault. The day is neat. The pins line up. The travel between them looks short on a screen. Then the technician rings in late, and the organisation goes shopping for a map.

The map was not the missing fact. The duration was a guess. The required skill was blank, or it was a word the whole crew holds. The territory still listed a region the person left last year. Any one of those is enough to make the efficient appointment efficiently wrong. All three together make a week of complaints that sound like routing, and are records.

Agentforce Field Service and Operations, formerly Field Service, will keep doing this until the records change. Field Service Lightning is the name on the old training slides. The behaviour is the same under either name. The scheduler allocates. It does not audit the number you typed, the skill you forgot, or the membership you left in place. Phone rebuilds of the day do not teach the next run. Tomorrow uses the same records.

#What the optimizer can use

It can use worker skill level, travel time, location, and other factors you have stored. The phrase "other factors" is Salesforce's, and the help page does not list them. A guide that publishes a secret weighting is making it up. A slide that shows a formula inside the optimizer is making it up too. Do not operate on a weighting you have not been shown.

Travel time and location are already in the sentence. They are not a feature you add later with a second product. They are also not a substitute for duration, skill, and territory. A correct pin on a bad duration still stacks a day that cannot happen. A correct drive into a territory the technician must not enter is still a bad offer. Closeness is one input. It is not permission. How a skill level is scored against a minute of travel is not published. Argue with the records you can see.

#How a short duration stacks

Watch a fortnight of finished work. Put the duration you booked beside the time the technician was actually there. Do it by work type, not by the one job a supervisor remembers. If the booked hour is a fiction, the optimizer will stack more appointments than the shift can hold. It is using the number you typed.

The minutes people leave off are predictable, which is why they keep being left off. Induction at a site that always takes it. Walking from a van that cannot park at the door. Waiting for the person who has the keys. A second trip to the van for a part that was listed and not in the first bag. Packing up. The notes that have to be written before the next customer will let you leave. None of these feel like "the job" when someone is asked, in a workshop, how long the job takes. All of them consume the shift.

A workshop produces round numbers. Forty-five minutes. An hour. Half a day. The lived job is rarely that round. Correct the work types whose durations are systematically short, and correct them from watched jobs. One appointment edited by hand will be overwritten the next time that work type is used. The pattern lives on the work type. The appointment only shows it.

Separate a bad day from a bad work type. One job runs long because a part failed in a way you had not seen. That is an exception. Leave it on the appointment. Ten jobs of the same type run long by the same block of minutes. That is the work type. Change the work type, or the next fortnight will repeat the stack.

The shape of the failure is the same in a city and on a long regional run. The morning holds. The late jobs fall off. People then blame traffic, or the technician, or the product. Traffic may be real. It is not what put a fifth visit on a shift that could hold four. The duration did that before the van moved.

Write down what the duration includes, in one sentence the crew can repeat. Time on site, from arrival to leaving, including the notes. Travel stays with the optimizer, which already accounts for travel time. If you also hide the drive inside the duration, you count the road twice. Pick one place for the drive and use it on every work type.

#Skills that do not filter

Then look at the jobs where the wrong person arrived. Either the work order had no required skill, or the skill was so broad that everyone held it. "Technician" and "field" fail that test. Add the specific skill. Stop requiring a skill the whole crew has. A requirement nobody can fail does not route.

The skills that earn a place are the ones your organisation will not waive. A height ticket. An electrical isolation. A licence the site checks at the gate. A product family a generalist cannot finish, so the first visit becomes a second visit by somebody else. If you cannot name the person who would be turned away, you do not yet have a required skill. You have a label.

Record it on the person and require it on the job. The optimizer accounts for worker skill level only when both sides exist. A skill that lives in a spreadsheet, or in a supervisor's memory, is not a skill the scheduler can see. The wrong person will look efficient. They are close, they are free, and nothing on the work order says they must not go.

Too many requirements is the opposite failure, and it shows up in the same fortnight. If nothing schedules, read one unscheduled job and ask which required skill nobody in that territory holds today. That is either a real shortage or a requirement you should not have set. Do not respond by deleting every skill so the board fills. You will get the wrong person, which is the failure the skills were meant to prevent.

A hand edit that removes a skill "just this once" becomes the new standard by accident. Put the requirement on the work type, and check that it is still on the work order the dispatcher is holding.

#Territory membership is permission

Then read territory membership with the dispatcher. A technician left on last year's region will be offered that region's work whenever the travel looks short. The optimizer is obedient. The membership is the mistake.

Contractors belong in this check. If they are members of a territory they should not enter, they will be sent there. If they are members of a parent region because that was faster to load, find out whether that membership makes them eligible for every child underneath. Do not assume a parent is only a reporting label. Membership is permission to enter. Reporting can roll up without granting that permission.

Old membership does not expire because a contract ended or a depot moved. It expires when somebody removes it. Until then the travel can look good and the skill can match, and the offer is still wrong. The commercial arrangement is not an input the optimizer will infer from a contract stored somewhere else.

Operating hours sit beside membership. A person on the right territory, with hours that say Monday to Friday when they work Tuesday to Thursday, will be offered Monday. That offer matches the record. It is not a routing mystery. Hours are how you tell the scheduler when the person exists. A fantasy shift produces a fantasy day that still looks efficient.

The place to set the levels, and to test what parent membership actually offers, is service territories and operating hours. Fix membership there. Then come back and read one appointment against it. A route cannot be cleaner than the permission you stored.

#Read one appointment out loud

Run the optimizer after the durations, the skills, and the membership are corrected. Then argue with one appointment, not with the whole board. Name the duration, the skill, or the territory that made that person the efficient choice. If you cannot name it, you are not finished with the data. Change the record and run it again.

Sit with the dispatcher for that one job. Say the work type, the minutes stored, the skill required, the territories the person belongs to, and the hours that day. The offer should be explainable from those lines. When it is not, one of the lines is stale. Fix the line. A comment that says "do not send" is not a constraint the optimizer has to obey. A skill, a territory, and a duration are. Read a job that looked fine as well. Cancellations hide a short duration. A quiet fortnight can still be a lying work type.

#What the records look like when they are wrong

Read down the last column before you brief a vendor. Almost none of it is a basemap. The optimizer is already accounting for travel time and location. It is accounting for them inside the fence and the clock you stored.

#Why a new map feels like the fix

The complaint arrives as geography. The van was in the wrong suburb. The pins look far apart. Someone asks for a better map, and a project starts. A new map draws the same pins on a cleaner background. It does not know the height ticket, the locked gate, or the suburb that person is forbidden to enter.

The locked gate is a duration and a preference, not a tile. Minutes at a buzzer belong in the duration, or in a preference the dispatcher can see before they promise a window. The forbidden suburb is membership. Remove the membership. The pin can stay where it is.

Buy another map only when these inputs are dull and true, and only when you can finish this sentence: our dispatchers or technicians cannot do this, and neither the console nor the mobile app does it. If the sentence ends with "a nicer map," you are not finished with the data. Until then the route is a data problem, and the data is yours.

#What to do with the next fortnight

Start with finished work, not with a design workshop. Export or read a fortnight of appointments. Group them by work type. Where the booked duration is always short of the time on site, change the work type once. Leave the freak job alone.

Then list the appointments where the customer, or the technician, said the wrong person arrived. For each one, write the skill that should have stopped it. Add that skill to the person who holds it and to the work type. Delete requirements that everybody passes.

Then sit with the dispatcher and read membership for the people who were sent somewhere they should not have been. Include contractors. Remove the old region. Confirm the hours match the days they work. Run the optimizer. Pick one appointment and name the record that made it the efficient choice.

If you cannot name it, do not book a map demo. Change the record that is still a guess, and run the day again. The optimizer will follow you. That is the whole mechanism, and it is already described on the help page. The rest of the work is making the description true of your data.