ChatGPT
Claude
Google AI
Copilot
The branch starts at 7:00 and finishes at 15:30. The operating hours said 9:00 to 17:00, because that was in the project template. For a month the first two hours of the real day looked empty, and the last two hours were full of appointments nobody attended. Customers had windows. The yard was shut. The scheduling optimizer was blamed for ignoring the roster. It had not ignored anything. The roster it could see was the template.
People still search for service territories and operating hours in FSL. FSL is Field Service Lightning. The product is Agentforce Field Service and Operations, formerly Field Service. The help page is direct about territories, and direct about what the scheduler is allowed to consider.
"Set up multilevel service territories that represent the regions where mobile workers can provide services." Levels exist so a region can contain smaller regions. They are not a decoration on an org chart. "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." Hours are how you tell it when those people exist. Store a fantasy shift and the efficient day will be a fantasy.
What each level means
Decide what each level means before you create records. A pattern that stays honest: the parent is the area you report, the child is the patch a person may be sent into. Name them in the dispatcher's language, not in a project code. If a dispatcher cannot point at the territory on a real map and say who works it, the level is abstract and it will be mis-assigned.
Write one sentence per level and pin it where the people who add members will see it. "Parent: reporting only. Do not add technicians here." "Child: the patch they may enter this month." If the sentence is missing, every new hire will be added wherever the last person was added, and the last person was added to the parent because it was quicker. The quicker path becomes the territory model, whatever the diagram said.
Membership is the control. A technician who should work one child patch should be a member of that patch. Before you add everyone to the parent "so reporting works," find out whether parent membership also makes them schedulable everywhere underneath. Do not assume. Create one test person, put them only on the parent, and see which appointments they are offered. Then put them only on one child and look again. The difference is the fact. Reporting can roll up without giving the optimizer a licence to send them across every child.
Contractors get the child patch they cover, not the employee's territory "for now." Their agreement is the patch. Revisit membership when a patch changes hands. Old membership is how last year's contractor keeps receiving this year's work. The optimizer will offer it. Travel and skill will look fine. The commercial arrangement is what you forgot. End the hours on the same day. A member with no hours should not be offered work. Check that the offer actually stops, with one appointment you expect not to see.
Operating hours are the shift
Write the hours people work. A branch that runs 7:00 to 15:30 should not be stored as 9:00 to 17:00 because that is what the project template said. The last two hours of offered work will be a lie, and the first two hours of the real day will look empty. Dispatchers will drag work forward by hand. The hand move will not correct the hours, and tomorrow's run will build the lie again.
Contractors often do not share that shift. A three-day week, a night roster, a summer pattern: store that pattern on them. One operating-hours record for the whole company is how you schedule people who are not there, then hold a meeting about no-shows. The meeting feels like discipline. It is a data fix you postponed. Put the pattern on the person. Include the days the contract does not cover, as absence of hours, not as a note.
If the branch is shut on a public holiday, that day should say so. Leaving it open means the optimizer can place work on a day nobody will attend. Customers will get a window. The van will not come. That is an hours problem, not a routing mystery. The same is true of a local show day, a shutdown, a depot that closes at noon on Friday. If you cannot attend, the hours should say you cannot attend. A reminder sent against that window will promise a visit you have already made impossible. Appointment Assistant should not be asked to defend it.
Relievers and on-call need a decision too. If they are only available after a call-out, do not give them a full ordinary shift or they will be planned into the normal day and be unavailable when you actually need them. Model the hours you can promise. If you cannot promise any until the phone rings, they are not ordinary capacity. Keep them out of the ordinary run. An emergency policy can still call them. The planned board should not assume they exist from 9:00 to 17:00.
When the offer looks absurd
Pull one bad day with the dispatcher. For the person who was given an absurd appointment, read three things: their territories, their hours that day, and the required skill on the work order. The offer will match those records more often than it matches your intention. Change the record. Run again.
The absurd hop is often the parent territory, not the road. A person eligible for every child will be offered the job that fits the skill and the travel inside that huge fence. Shrink the membership and the hop disappears, without any change to how travel time is calculated. The optimizer was already accounting for travel. It was accounting for it inside a permission you did not mean. The longer version of that fence problem, including why no percentage saving is promised, sits in reducing technician travel time. Read the membership first. The road is the second conversation.
Do not add a territory level to escape a bad membership, and do not add another hours record to escape a bad one. Extra records hide the contradiction. The scheduler will still pick a legal combination you did not mean, and now two people have to remember which record is the real one. Fix the record that is wrong. Delete the decoy. A depot with four overlapping hour records will schedule from the one nobody thinks is active.
| What you meant | What to store | What the test shows you |
|---|---|---|
| A region for reports | A parent you do not use as a scheduling membership, unless the test says that is safe | A person on the parent alone is not offered every child |
| A patch someone may enter | Membership of that child | They are offered inside it, and not in the next patch |
| The branch shift | Operating hours from open to shut, including the early start | No appointments in the hours the yard is closed |
| A contractor's week | Their days only | No offers on the days they are not engaged |
| A shut day | Hours that exclude it | No window, and no reminder, for a van that will not come |
| On-call, not a normal shift | Hours you can actually promise, or none on the ordinary board | They are not planned into the normal day |
When the organisation changes
Review membership and hours when something real changes: a depot opens, a contractor ends, a shift moves, a patch is handed over. Territories and hours are operational data. They go stale as fast as a roster. A quarterly governance meeting that does not look at a single offer will not catch it. The check is the same test as go-live. One person, the appointments they are offered, the hours on the day the yard is shut.
New starters inherit whatever the last starter was given. If the last one was dumped on the parent with company hours, the new one will be too. Make the default the child patch and the real shift. A default is a decision you will live with on the busy week, when nobody has time to correct it. The busy week is when the optimizer will use the default without mercy.
A depot move is the moment both records go stale together. The child patches that were drawn around the old yard no longer match where people start, and the hours often change because the drive to the new yard ate the start of the shift. Update membership and hours in the same change, before the first customer window is sent from the new place. Leaving either one behind produces a week of offers that look efficient against a map you have left. The start location, if you store one, moves with them. A crew that now leaves from home, still stored as the old depot, will be given a first job near a building they do not visit.
Tell the dispatchers the day the records change. They will otherwise "correct" the board by hand and leave the hours and the membership for later. Later is the next optimizer run, which will undo the hand correction and restore the old yard. The run is right. The records are what you forgot to move. Do the parent-membership test again after the move. A redraw is when someone adds the whole crew to the new parent so the report does not look empty, and the statewide offer comes back on day one.
Field Service Lightning is the search phrase. The product is Agentforce Field Service and Operations, formerly Field Service. It will allocate by skill, travel time, and location inside the territories and hours you stored. Those two setups are the job. A fantasy shift and a parent membership you did not test will keep producing a day that looks efficient and cannot be worked. Change the record the offer is obeying.
