Contact-Centre Routing with a Bot
This page is the procedure for an endpoint with a bot linked: the bot’s assign to agent element creates the task, and a rule you build sends it to a team. You are here: Contact-Centre Automation explains what every tenant already has and how a chat becomes a task, and you need it first; an endpoint with no bot is the next page.
Step 1: Create the skills and make sure they point at the queue
Unified Contact Center → Configurations → Skill → + ; then Task Router → Router Queue → Default Queue → Skill tab
The outcome: ORDERS and TECH exist and both belong to the default queue.
Create two skills: name Orders, code ORDERS, priority 5; name Technical, code TECH, priority 5. Then open the default queue under Task Router and add both skills on its Skill tab — this is what writes the skill’s queue link, the one the engine reads (a separate queue–skill link table exists, and nothing uses it).
The common failure is skipping the queue step. A skill with no queue falls back to the default queue, which works only while you have one queue.
Step 2: Link each agent to a skill
Configurations → Agents → (agent) → Skill → +
The outcome: the four Orders agents hold ORDERS, the two Technical agents hold TECH.
Open each agent record and add the skill. This writes the agent–skill link the engine reads. Two checks while you are there: the person must hold the Unified Contact Center applet at rank MEMBER (Tenant Admin → Tenant Users → that person’s applets), because the engine filters candidates by that rank; and if you intend to use the “available agent” action, they must be signed in with the desk open, because availability is live browser presence, not a setting.
The most common failure: an agent record exists but the person’s applet link is at a different rank. The engine silently treats them as not there.
Step 3: Create the rule and its condition
Configurations → Rule → + ; then the rule’s Expressions tab → +
The outcome: a parent rule WhatsApp to Technical with one condition.
Rule Type CUSTOM. Automation Rule: SKILL_BASED_TASK_ASSIGNMENT_AUTOMATION_RULE. Rule Name WhatsApp to Technical, Rule Code WA-TECH, Priority 9 (the seeded default’s 10 does not compete — it is reached by name — but among your own rules a higher number wins). Save.
Open the rule and add a condition: Condition Channel, Operator Equal, value WhatsApp from the channel list. Save. This creates a child rule under the parent; without at least one child the parent can never match.
Step 4: Give the rule its action
The rule → Rule Action tab → +
The outcome: the rule assigns to the Technical team.
ASSIGN_TO_TEAM is not one of the four seeded actions: if the list lacks it, create it first on the off-menu Action screen (Routing with No Bot, Step 1). Then choose ASSIGN_TO_TEAM and pick the Technical team (teams are the platform groups you created under Configurations → Teams). Save. Behind the screen this records the team’s table and its guid as the rule’s target — which is exactly what a CUSTOM rule executes.
Step 5: Link the rule to the queue — the step everyone misses
Task Router → Router Queue → Default Queue → Rule tab → +
The outcome: the engine can see your rule.
Add WA-TECH to the default queue. Until this row exists the rule is invisible to the engine: it only ever collects rules linked to the task’s queue. This is the single row that separates a tenant whose routing works from one whose tasks sit in the queue untouched.
Step 6: Send a test message and wait for the poll
Send a WhatsApp message to GSO’s support number from a phone that is not an agent’s, answer the bot far enough to reach the assign to agent element, then open Task Router → Tasks. The task appears at once with status CREATED. Wait — up to fifteen minutes — and refresh. It should now read TEAM_ASSIGNED, and the Team Task Queue of the Technical agents shows it.
What success looks like
Open the test task and read its events from the bottom: TASK_CREATED, then RULE_MATCHED naming WhatsApp to Technical, then TEAM_ASSIGNED. Three lines, in that order, within fifteen minutes of the message. If a RULE_MATCHED line names DEFAULT_RULE_FOR_SKILL_BASED_TASK_ASSIGNMENT, your rule did not match or its action could not run (Steps 3 to 5), and nothing after it means the default found nobody either (Step 2). Only the first line means the poll has not reached the task yet.
Common mistakes
| Symptom | Cause | Fix |
|---|---|---|
Events show RULE_MATCHED for the default rule, never for yours | Your rule is not linked to the queue, or its rule set is not the skill-based one | Step 5; and re-create it under SKILL_BASED_TASK_ASSIGNMENT_AUTOMATION_RULE |
Your rule matches, then a second RULE_MATCHED names the default rule | The action could not be executed — usually ASSIGN_TO_TEAM on a STANDARD rule, or CREATE_ISSUE | Make the rule CUSTOM with ASSIGN_TO_TEAM; do not use CREATE_ISSUE |
| A parent rule with conditions never matches | It has no child condition, or one condition tests a field the task does not carry | Add at least one condition on Channel, Project, Virtual Contact or Skill |
| “Assignment is instant for the team leader but takes ages for the engine” | The poll runs every fifteen minutes; manual assignment from the desk does not wait for it | Expected. KEEP_IN_THE_QUEUE retries in fifteen-minute steps too |
| “Random” assignment always lands on the same person | The random action returns the first candidate | Use least tasks instead |
The two mistakes that apply to both paths are under Contact-Centre Automation › Common mistakes.
Related documentation
- Contact-Centre Automation — the seeded records, how a chat becomes a task, and what a condition can test.
- Contact-Centre Routing with No Bot — the same team rule for an endpoint with no bot linked, which routes at once.
- Unified Contact Center Applet — the routing engine step by step, and the twelve declared action codes.
- A chat came in and nobody got the task — the symptom, on either kind of endpoint.