Your customer, Charlie, called in yesterday and spoke with an agent, Ricky. She had a good experience with Ricky, and said so yesterday. Today, Charlie is calling back in to follow up.
In many contact centers, Charlie might end up speaking to a new agent. This means she spends time discussing her issue once again, and telling the new agent about her call with Ricky. With Known Agent Routing, however, you can provide Ricky's Worker SID and attempt to match Charlie with Ricky again. Both Charlie and Ricky are able to pick up where they left off, and get her issue solved.
Use cases where Known Agent Routing can be used include 'last agent routing' or 'preferred agent routing', and the feature can also be leveraged to support extension dialing use cases. All of these use cases have in common that the agent who should be targeted first is already known.
Known Agent Routing offers significant performance improvements over the general evaluation logic in those use cases. To prevent latencies e.g. during times when there is a spike in Task volume, we recommend that you always utilize Known Agent Routing when implementing such use cases, and update your existing Workflows to leverage Known Agent Routing as well.
You can choose one of two fields to designate an agent as the target of the Workflow.
To identify the known agent based on Worker SID:
"known_worker_sid": "task.agent_sid"
To identify the known agent based on Worker friendly name:
"known_worker_friendly_name": "task.agent_friendly_name"
You can use the known_worker_sid
OR the known_worker_friendly_name
as a key. The value should be an attribute in the Task attributes that references the appropriate agent information.
For example, the preceding snippets might use the following process:
known_worker_sid
in the Workflow Target. This pattern is also used for the Worker friendly name, which is required when
known_worker_friendly_name
is used in the Workflow Target instead.
Events created using Known Agent routing will contain a known_worker_sid
, which you can use to infer that Taskrouter used Known Agent Routing for handling a given Task.
1{2"filters": [3{4"filter_friendly_name": "sample workflow filter”,5"expression": "category == ‘some_category'",6"targets": [7{8"queue": "WQ00000000000000000000000000000001",9"priority": "100",10"timeout": "10",11"known_worker_sid": "task.agent_sid",12"expression": "worker.activity_name in ['Generally Available', 'High Value Tasks']"13},14{15"queue":16"WQ00000000000000000000000000000002",17"priority": "20",1819"expression": "worker.activity_name in ['Generally Available']"20}21]22}23]24}25}
In the best-case scenario, the agent will be in the Task Queue and will be available. But if either of these conditions isn't true, you can use additional Workflow Target fields - like timeout, priority, and expression - to ensure that your customer is helped in a timely manner. TaskRouter will evaluate the general worker expression in addition to the Known Agent Routing field, but the use of a general worker expression or workflow fields is optional.
Note that if the known agent is not part of the specified TaskQueue OR the inherited TaskQueue in the Workflow Target, you will receive a debugger error (Error 40152 - Invalid Queue for Known Worker).
Example JSON
1{2"task_routing": {3"filters": [4{5"filter_friendly_name": "Attempt 1",6"expression": "1==1",7"targets": [8{9"queue": "WQf4b9e3942acb4b62fdda09e84971e98e",10"timeout": 10,11"known_worker_sid": "task.agent_sid"12},13{14"queue": "WQf4b9e3942acb4b62fdda09e84971e98e"15}16]17}18],19"default_filter": {20"queue": "WQf4b9e3942acb4b62fdda09e84971e98e"21}22}23}24
You can specify known worker logic in the Twilio Console. The field is optional, and can either be known_worker_sid
or known_worker_friendly_name
, but not both. When known_worker_sid
or known_worker_friendly_name
is selected, you can enter a string that corresponds to a field on the task as your value (e.g., task.agent_sid
or task.agent_friendly_name
). If the chosen worker key holds an incorrect value, TaskRouter will emit a debugger error message.
For those tasks without an actual known worker reference, you can use the null
value assigned to the Known Worker field on the task to avoid debugger log messages:
1{2"agent_sid": null3}4
Do not wrap the known worker null
value in quotation marks.
A task that flows through a known worker filter target will, even if the known worker key is null or incorrect, stay in that target until any of the following conditions is satisfied:
skip_if
condition is met
For more information, see Lifecycle of a Task: Workflows and Assignment.