ChatGPT
Claude
Google AI
Copilot
The board was empty on Tuesday, so someone encoded "morning" as a skill called Morning and required it on every job booked before noon. The eligible crew shrank to the three people who had been given that skill by accident. The rest of the qualified technicians sat unused. By Thursday the skills had been stripped off again so the board would fill, and the person who arrived lacked the isolation ticket. Both weeks were the same mistake. A requirement was used for something other than who may do the job.
People still search for skill-based routing in FSL. FSL is Field Service Lightning. The product is Agentforce Field Service and Operations, formerly Field Service. Routing by skill is two documented facts, not a scoring model we are free to invent.
"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." Skill level is in the sentence. The help page does not publish how levels are weighted against travel. Do not pretend you know. "Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts." Required skills are a detail on the work order. If they are not there, the optimizer is not being difficult. It has nothing to match.
What earns a required skill
A required skill should change who is allowed to do the job. Legal and safety first: the licence, the isolation ticket, the height ticket, the confined-space ticket, whatever your organisation is not willing to waive. Then the trade skill that prevents a second visit, if a generalist genuinely cannot finish the work.
Stop there and run it. If almost every appointment schedules, and the wrong trade is rare, you are done. If nothing schedules, you have required a combination nobody holds. Split the job, or drop the skill that was taste rather than a limit. If the wrong person still arrives, you are missing a skill, or you required one so common it does not filter.
"Technician," "field," and "general" fail that test. Everyone has them, so they never change the result. Delete them as requirements. Do not make the optimizer pretend they matter. A catalogue of soft labels, added because a stakeholder wanted their discipline named, has the same effect if every person in the territory holds them. The label can exist on the person for reporting. It should not be required on the job unless lacking it would turn someone away.
Write the refusal in a sentence before you create the skill. "We will not send a person without the isolation ticket onto this plant." If you cannot write the refusal, you do not have a requirement. You have a wish. Wishes belong in preferences, or nowhere. They do not belong in the list that empties the board or, worse, gets deleted under pressure so that anyone can go.
Work type, then the work order
The work type is where the standard lives, so every job of that kind asks for the same skills, parts, and duration. The work order is where Salesforce says the required skills are recorded for the job you are scheduling. Get both right. A beautiful work type that does not land on the work order will not help the appointment in front of the dispatcher. The optimizer matches the job it can see. A skill that exists only on a design document is invisible.
A work order someone edited by hand, with the skill removed "just this once," becomes the new standard by accident. The next job is cloned from it. A dispatcher learns that skills are optional when the day is tight. Put the requirement back on the work type, and check a sample of new work orders after go-live. The required skills should be the ones you agreed. If they are blank, the path from work type to work order is not finished, whatever the design document claimed. Fix that path before you add more skills.
Check the sample with a dispatcher, on jobs raised the way they are really raised: by phone, by a customer portal, by a maintenance plan, by a feed. Each path can forget the skill in a different place. A path that works in a demo and drops the skill on the portal is the path your customers will use. Read those work orders. Blank means the optimizer will account for travel time and location only, and the nearest person will look correct.
Preferences sit beside skills on the work order, and they are not the same thing. A preference is the customer or the worker: morning only, this site contact, do not send the person the customer refused. It does not qualify anyone. Do not encode "morning" as a skill called Morning, or you will shrink the eligible crew for no safety reason and then wonder why the board is empty. A refused person is a preference or a scheduling constraint you can name. It is not a missing licence.
Parts, levels, and the empty board
Parts are the third detail on the work order. A skill match with the wrong part still fails on site. Do not bury the part inside the skill name. "Fibre-with-kit" is not a skill. Require the skill, list the part, and keep duration honest. A duration that is a guess will poison the day even when the skill is perfect. The optimizer will stack from the number. The qualified person will still be late, and the skill programme will be blamed for a clock problem.
Skill level is in the published sentence. A weighting of level against minutes of travel is not. Do not invent one in a workshop and then configure towards it. If you use levels, say what a level means in the yard: this person may do the work unsupervised, this person may do it only with another, this person may not. If you cannot say that, a number in a field is decoration. Decoration that the optimizer treats as real will change who is offered the job, and you will not be able to explain the offer.
When the board is empty, read one unscheduled job with the dispatcher. Which required skill does nobody in that territory hold today? That is the answer. It is either a real shortage, or a requirement you should not have set. Add a person with the skill, or remove the requirement. Do not lower every level in a panic so that Tuesday fills up. You will get the wrong person.
Territory still bounds the offer. A person with the skill, outside the territory they are allowed to enter, should not be made eligible by deleting the territory rule "just for skills to work." Membership is permission. The skill is permission of a different kind. Both have to pass. How bad durations and bad memberships make an efficient day wrong, even with a perfect skill, is the subject of technician routing. Fix the skill list here. Do not use it to paper over the fence.
What the symptom usually is
| What you see | What to read | What to change |
|---|---|---|
| The wrong person arrives | Required skills on that work order | Add the ticket or trade that would have turned them away. Remove "technician" if that was the only requirement |
| Nothing schedules | The full set of required skills, against who is in the territory today | Split the job, or drop the requirement that is taste rather than a limit |
| The board emptied after a tidy-up | Skills that encode time of day, region, or a customer's mood | Put those back in preferences. Leave the legal and safety skills required |
| Skills look right on the work type and blank on the job | The path that created the work order | Fix that path. The optimizer cannot match a blank |
| A qualified person is never offered | Their territory membership and their hours, not only their skills | Restore the membership or the shift. Do not copy their skill onto everyone |
Run this table on real jobs for a fortnight after go-live. Bring the refusals the sites actually made: turned away for a ticket, a second visit because the trade was wrong, a job that sat unscheduled while a qualified person was in the next patch and not a member of this one. Each refusal is either a missing requirement, an extra requirement, or a territory. Write which. Change that record. Do not add a sixth category of skill because the fortnight was uncomfortable.
Contractors belong in the same fortnight. Their skills are the tickets they hold, on their user, not a skill called contractor. If they are missing from the offers, read their hours and their child territory before you conclude the skill model is wrong. A three-day contractor on a five-day shift, or on the parent territory, will distort every reading you take of the skill list.
After the fortnight, freeze the list for a quarter unless a real refusal shows a hole. A weekly edit to required skills makes the empty-board symptom impossible to read, because you cannot tell a shortage from a rule that changed on Monday. New work types can still be added. The skills already in use should stay stable long enough for dispatchers to trust that a blank board means what it meant last week. Tell them when you do change one, in a sentence: which job, which skill, why. A silent change is how "just this once" returns.
Levels, if you use them, get the same freeze. A level changed to fill a day is the panic move. Put it back. The person who may not work unsupervised did not become qualified because Tuesday was thin. Travel can prefer a closer qualified person. It cannot promote an unqualified one without you deciding to waive the ticket, and a waiver is a named decision, not a field edit at 7:40.
Agentforce Field Service and Operations will account for worker skill level when you have recorded it on the person and required it on the job. Field Service Lightning is the older search. The help page will not tell you the weighting against travel. Your job is the refusal sentence, the work type, and the work order that still carries it on Tuesday afternoon when someone wants the board to look full.
