Best practices for dispatching emergency work orders in Field Service Lightning

The leak was logged at 7:10. The planned service on the next street was logged at 6:40. Both work orders carried the same priority. The scheduling optimizer built the efficient day, and the efficient day did the planned service first. The leak waited until a dispatcher noticed and started moving pins by hand. By then the nearest qualified person was already inside a job that could have moved.

People still search for Field Service Lightning. The product is Agentforce Field Service and Operations, formerly Field Service. Emergency dispatch is a policy on top of two documented pieces, not a secret button.

Salesforce describes "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." It also says you can "Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts." The optimizer is trying to build an efficient day. An emergency is a decision that this job may wreck that day. If you do not write the decision down, the efficient day wins, and the leak waits.

#A leak is not a planned service

If both work orders carry the same priority, you have told the system they are the same kind of claim on the day. Planned maintenance can wait a week. A leak cannot. Use a priority, or a field your organisation treats as policy, that only emergencies get. Do not spend that value on "the customer shouted." Once everything is urgent, nothing is.

The failure is quiet at first. Dispatchers still know a leak when they hear one. They override. The override is not in the record, so the next run does not learn, and a new dispatcher on the weekend does not see the rule. They see two work orders with the same priority and a board the optimizer has already filled. They trust the board. The leak waits again.

Say what qualifies. Safety. A stopped production line you have contracted to attend. A legal time limit. Write the examples in the dispatcher's language, with two or three that count and two or three that do not. "The customer is angry" does not count. "Water is entering a switchroom" does. A policy that says "use judgement" will be used differently on every shift, and the optimizer will be blamed for the difference.

Write the examples where the person taking the call can see them. A definition that lives in a procedure nobody opens will not be applied at 7:10. The work order should show the emergency class without a treasure hunt through related lists. If the class is a priority value, that value means one thing. Do not reuse it for VIP customers, for jobs a salesperson promised, or for work that is merely late. Those are real pressures. They are not this class.

#The work order still needs the facts

Required skills, parts if you know them, and the customer preferences that matter even in a hurry. A site induction that takes forty minutes is still forty minutes. Leaving those blank to "save time" sends the nearest person, who may not be allowed to do the job.

Speed is how the blanks get justified. The call-taker does not know the skill. They type a subject line and a suburb. The optimizer then accounts for travel time and location, because those are all it has, and offers the closest available resource. Skill level cannot be accounted for when no skill is required. The closest person is a coherent answer to an incomplete question.

Put the skill on the work type for that class of emergency, so the call-taker does not have to remember it. A leak on a particular plant needs the ticket that plant always needs. The template or the work type is the memory. The phone call is a bad place to invent it. Parts you already know belong there too. Parts you cannot know yet should be left unknown, not filled with a guess that stocks the wrong van.

Preferences survive emergencies. A gate code, an induction, a site that will not admit a person without the right card: none of these become optional because the job is serious. They become more important. A refused entry wastes the person you pulled off planned work, and now two jobs are late.

Duration is the other fact people skip. Emergencies get booked as half an hour because the field was mandatory and the truth was unknown. The visit consumes a morning. The rest of that person's day, which the optimizer had built from travel time and the remaining appointments, is now fiction. When the emergency is done, compare the duration you stored with the time it took. Correct the work type. Emergencies poison the next plan when they are stored short. The next run will believe you.

#Someone is allowed to break the day

Someone has to be permitted to override the plan. Name them. A dispatcher on shift, not a committee that meets Thursday. The override is a normal act, not a favour and not a failure of the optimizer.

The name matters because an unnamed permission becomes a contest. The technician wants to finish the job they have started. The planner wants the board to stay as the optimizer drew it. The customer with the leak wants a person now. Without a named role, the loudest of those three wins, and the reason is not written down. With a named role, the dispatcher can move one job and the organisation can review the move later without treating it as insubordination.

Write what moves. The usual rule is simple. Bump the planned appointment the customer can move, with the most slack, that does not itself create a safety issue. Call that customer. Do not bump five jobs a little and hope. One clear move is a policy. Five quiet slips is chaos, and the travel the optimizer accounted for is now wrong for the rest of the day.

Re-read the rest of that person's day after the move. The hops were calculated from the old order. Inserting an emergency on the far side of the territory can make every later hop longer, even when each one looked fine this morning. You may need to move a second planned job, on purpose, rather than discover it at 3pm. That second move should follow the same rule. It should not be a new invention made under pressure.

Skill and territory still apply. The nearest van is not the right van if the person lacks the ticket or is not a member of that territory. The optimizer accounts for those factors on ordinary work. An emergency policy that ignores them will put an unqualified person on a dangerous job because the pin was close. Closeness is one input. It is not the only one. How those records poison an ordinary day is the subject of technician routing. An emergency does not repeal them.

#What good looks like on the board

Keep emergency and planned work distinguishable in the queue. A single list sorted by created date hides the leak under a planned service that was logged earlier. The dispatcher should see the emergency class without opening every record. If they have to open the record to know it is a leak, the board is sorted for data entry, not for dispatch.

#After the call

Review the bumps weekly, with the dispatcher who made them, not as a verdict. Which planned jobs moved, and did the rule match what people actually did? If dispatchers invent a new rule every Friday night, the written one is wrong. Change the rule. Do not add another priority value to paper over the argument.

Look for two patterns. The first is emergencies that were not emergencies. The customer shouted, the priority was spent, and a planned job moved for no safety reason. Tighten the examples. The second is real emergencies that sat in the ordinary queue because the call-taker was afraid to use the flag, or did not know it existed. That is a training and a screen problem. The flag has to be easier to set than to avoid.

Tell the bumped customer the new window yourself. A reminder that still offers the old time will create the angry call, and it will arrive while the technician is on the leak. Appointment Assistant is the named tool for that message, and it should carry the window you are now willing to keep. Do not describe the other tools on that help page here. The point is narrower. The old message is wrong the moment the job moves. Send the change.

Count the emergencies that stole a person who lacked the skill. If that count is not zero, the policy is skipping the requirement under pressure. Put the skill back on the work type and refuse the offer. A late qualified person is a better outcome than a fast unqualified one who is turned away at the gate, or worse, not turned away.

One more record belongs in the weekly review: the emergency that was attended by a person from the wrong territory because membership was stale and the pin was close. That is not an emergency exception. It is the ordinary poison, showing up on a day when people are most willing to ignore it. Remove the membership. The leak can still break the plan. It cannot conscript someone the territory says must not enter.

The scheduling optimizer is not the obstacle. It is doing what it was built to do with the priorities, skills, travel, and territories you stored. An emergency policy is the permission to break that day on purpose, written so every shift breaks it the same way. Without the writing, you do not have a practice. You have a series of phone calls, and the leak is still waiting on the efficient appointment.