How to use Agentforce to triage inbound field service requests

A customer says the cooler is down at the back dock and asks if someone can be there at 2pm. The agent creates a work order, leaves the skill blank, and replies that a technician will arrive at 2pm. The scheduling optimizer had no capacity at 2pm, and it had no skill to allocate against. Dispatch spends the afternoon apologising, then sends whoever is nearest. The nearest person does not have the skill. The job returns. Two failures, one sentence, and the sentence sounded helpful.

An inbound field request is usually a sentence. It is not yet a work order. Someone has to decide the work type, the skill the job needs, and how urgent it is, then stop. That classification is the agent's job. Choosing the technician and the time is not.

The documented product name is Agentforce Field Service and Operations. Salesforce still uses Field Service in places, and so will your dispatchers. Say both while the org still says both. Field Service Lightning is the older label for this same area, not a second product you run beside it.

#What triage is allowed to decide

The agent reads the sentence and fills the classification: work type, required skill, and urgency, using the values your org already defined. It does not invent a skill name that is not in the catalogue. "Cooling" is not a skill if the catalogue says refrigeration, and a near-synonym the model prefers is a skill the optimizer cannot match. If the sentence is too thin to choose, the agent asks one question or it hands off. It does not guess "general" so the record will save. A placeholder skill is how a vague message becomes a van roll.

One question means one question. Ask for the fact that chooses between two real skills, or for the site if the site is missing. Do not interview the customer through a troubleshooting tree the work type does not require. The tree is a temptation, because it makes the channel feel thorough. It also creates a second description of the fault that disagrees with the work order, and the technician will meet both.

Urgency is operational. If a phrase must page a dispatcher, encode that in a Flow and let the agent call it. The Flow sets the priority. Two writers on urgency will disagree, and the optimizer will inherit whichever write landed last. Tone is not the phrase. "This is urgent" from a customer who says it about every visit is not the same input as the words your Flow treats as a page. A warm confirmation that never wrote work type and skill is a failed triage, because nothing downstream can see it. The customer heard a promise. The board received a blank.

This is the same split as any other workflow that already has a right answer. The Flow owns the page. The agent recognises the sentence and calls the Flow. Known-answer steps stay in Flow or Apex. A safety phrase is that kind of step. Leaving it in the instruction, as "treat dangerous wording carefully", is how the dangerous case looks routine.

#Pass a complete work order

Salesforce's field service model schedules work orders and records required skills, worker preferences, and parts. A complete handoff from triage includes the work type, the required skills from that catalogue, the site, access notes the customer actually gave, and parts if the request named them. Blank skill is an incomplete order. The optimizer cannot honestly allocate a skill you did not pass. It can only fall through to whatever your org does with a blank, which is usually a person guessing under time pressure.

Access notes are the words the customer used. A gate code, a dock that is closed after four, a request to call ahead. Do not improve them into a cleaner sentence that drops the constraint. Parts are included when the customer named them, not when the agent thinks a job of this type usually needs a part. An invented part becomes a van that loads the wrong thing, or a delay while someone checks a suggestion that was never a fact.

How those skills should be structured is a separate discipline. Use skill-based routing for field service when you design the catalogue. This agent should consume that catalogue, not freelance a new one in the instructions. If the catalogue is wrong, fix the catalogue. An instruction that lists unofficial skill names creates a second catalogue the optimizer does not share, and the two will drift the first time someone renames a skill in the org and forgets the prompt.

Then stop. Create one work order. Do not create a second because the first reply felt short, or because the plan searched again to be sure. Duplicates dispatch two people to one fault. Both work orders can look reasonable. Both can carry the same site. The board now has two claims on capacity, and the customer will meet whoever arrives first, then have to explain the second van.

The last column is the whole customer promise. If a sentence in the reply is not in that column, it is a commitment the optimizer has not made.

#The optimizer is not the agent

Agentforce Field Service and Operations includes a scheduling optimizer that allocates resources using worker skill, travel time, location, and related constraints. That is the owner of who goes and when. The agent does not offer an arrival window, name a technician, or reorder the board because the customer asked nicely. A preference is not a constraint the agent can satisfy from a sentence. The optimizer is where preferences, skills, and travel meet the capacity you actually have.

If the person wants a promise, the agent says the request is logged and a dispatcher or the schedule will confirm. A fabricated window fights the optimizer, which may have a required break, a missing part, or a territory the agent never loaded. The apology then belongs to dispatch, who did not make the promise and cannot see it in the work order if the agent only said it in the chat. Put nothing in the reply that is not on the work order.

When the request falls outside the actions you defined, escalate to a person. An unknown site, a missing skill, or a safety concern is beyond this scope. Salesforce's line is that agents escalate when the issue is beyond their scope. Here the scope is the catalogue and the Flow you wrote down. A fault that matches neither is not an invitation to pick the nearest skill so the channel can end. A person takes it. Emergency work has its own path, and triage should call that path rather than file a dangerous sentence in the ordinary queue with a high urgency and a blank skill.

#How triage fails

The 2pm promise is the loud failure. The optimizer had no capacity at 2pm. The customer quotes the chat. The work order does not contain 2pm, so the dispatcher cannot even see the commitment they are apologising for. Stop the topic that is offering times, the same day. Do not soften the phrasing to "around 2pm". Around is still a promise.

The blank skill is the quiet failure. The work order exists, the board looks staffed, and the return visit shows up next week as a parts or skills problem rather than as a triage problem. Count return visits on work orders whose required skill was blank at create. That count is the triage metric. A short handle time in the channel is not.

The duplicate is the failure of a missing stop. The plan created a work order, did not treat the Id as the finish, and created another. Two vans move. The stop is the Id plus the required fields filled, not a feeling that the customer has been reassured. If the required skill is still blank, the correct finish is a handoff, not a second create that hopes the skill will appear.

The safety phrase filed as ordinary urgency is the failure that does not look like a bad reply. The words that should have paged a person were classified as "high" and left in the queue. Classification without the Flow is how the dangerous case looks routine. Test the phrase your operation already treats as a page, and read the trace. The pass is a call to that Flow, not a priority value the agent typed because the sentence sounded serious.

Dispatcher language and agent language will diverge if you let them. Dispatchers say Field Service. The documented name is Agentforce Field Service and Operations. The work order does not care which name the channel uses, and the customer should hear neither product name. They should hear that the request is logged. Internal notes can use the name your dispatchers already say, so a person reading the handoff does not have to translate. Do not maintain a glossary in the instruction. The glossary will be wrong the next time a skill is renamed, and the instruction is the wrong system of record for a catalogue.

A return visit is the feedback the channel will not give you. The customer may not call back through the same door. The technician will close the work order with a reason, or open another. Tie those outcomes back to work orders the topic created, and look for a blank skill at create, a promised time that existed only in the transcript, and a second work order on the same site inside the window your operation already uses for repeats. That window is the one dispatch already argues about. Do not invent a shorter one so triage looks cleaner.

Test with three messages, and keep them. A clear fault that maps to one skill: one work order, that skill, no arrival time. A vague fault: one question or a handoff, and no placeholder skill. A message that must page a person: the Flow runs, and the reply does not assess the danger in its own words. Re-run the three when the catalogue changes or the instruction grows. An instruction that has started to name technicians "as examples" has started to do the optimizer's job. Take the examples out.