Contact-Centre Automation

You look after the Unified Contact Center and are tired of a supervisor dragging every WhatsApp conversation onto somebody’s desk by hand. This guide builds the one rule most contact centres need — these chats go to that team — in a way the routing engine will actually run, and shows what BigLedger does with a new conversation before you do (less than you think). Building it takes about twenty minutes; seeing it fire takes up to fifteen more.

The procedure at a glance. It is for an endpoint with a bot linked; on an endpoint with no bot, a different rule set routes the task the moment it is created (the warning under How a chat becomes a task).

1. Create the skills and add them to the default queue (Step 1).
2. Link each agent to a skill, and check they hold the applet at rank MEMBER (Step 2).
3. Create a CUSTOM rule under SKILL_BASED_TASK_ASSIGNMENT_AUTOMATION_RULE, with one condition (Step 3).
4. Give it the ASSIGN_TO_TEAM action and the team (Step 4).
5. Link the rule to the queue — the step everyone misses (Step 5).
6. Send a test message and wait up to fifteen minutes for the poll (Step 6).

Meet GadgetSphere

GadgetSphere Online Sdn Bhd (GSO) answers customers on WhatsApp and web chat from 9 to 9, with six agents in two teams: Orders (four people — where is my parcel) and Technical (two — the laptop will not boot). About 250 conversations arrive a day, 900 on a launch day, and today a team leader hands every one out by hand.

What every tenant already has

The contact-centre tables are populated by the platform’s database migrations, so your tenant has routing configuration before anyone opens the applet. Unless somebody here has already been in and changed it, this is exactly what you will find:

So out of the box the intent is: every task goes to whichever agent has had the fewest tasks today. Read on for why, out of the box, that never happens.

How a chat becomes a task on someone’s desk

    flowchart LR
  AR[Automation rule set]
  R[Parent rule]
  RC[Child rule = one condition]
  RA[Rule action]
  A[Action]
  Q[Queue]
  QR[Queue–rule link]
  SK[Skill]
  LS[Agent–skill link]
  U[Agent login]
  T[Task]
  TQ[Assignment]
  G[Team]
  R --> AR
  RC --> R
  RA --> R
  RA --> A
  QR --> Q
  QR --> R
  SK --> Q
  LS --> SK
  LS --> U
  T --> Q
  TQ --> T
  TQ --> U
  TQ --> G
  

Every arrow is a link between records. Read it left to right with a conversation in hand:

1. The chat-flow creates the task. This guide is about endpoints with a bot linked; a task from an endpoint with no bot is routed differently (the warning below). The bot flow that answers the customer has an element — assign to agent or invoke automation rule — and when the conversation reaches it, a task is created carrying the element’s skill and a bag of facts about the conversation: the channel code, the endpoint, the virtual contact, the project, the skill.
2. The skill decides the queue. The task’s queue is the skill’s queue; a skill with no queue → the default queue. No skill on the element → no task at all.
3. The task waits for the poll. Creating the task drops a row on a processing queue. A scheduled job reads that queue every fifteen minutes, ten tasks at a time. This is the latency: a task created at 10:01 is looked at around 10:15, later behind a backlog. The interval is a Scheduler clock.
4. The engine picks a rule. It collects the rules linked to the task’s queue (the Rule tab on the queue, under Task Router), keeps the parent rules in the rule set the task carries, sorts by priority — highest number first — and takes the first whose conditions all hold. A parent rule with no conditions never holds; the seeded default rule is reached only by name, when no linked rule matched.
5. The rule’s action runs. For a STANDARD rule the engine reads the action code and does that. For a CUSTOM rule it ignores the action code and reads the target: a team, or one person.
6. Who counts as an agent. For the “assign to agent” actions the candidates are the people linked to a skill on the task’s queue (Configurations → Agents → Skill) who also hold the applet at rank MEMBER. Nobody linked → the action fails → the default rule is tried with the same empty list → the task stays CREATED, on no queue: only Task Router → Tasks shows it.
7. The assignment is written: the task’s status becomes AGENT_ASSIGNED or TEAM_ASSIGNED, and its events record which rule matched (RULE_MATCHED) and what happened.

Point 6 is where a fresh tenant stops. The seeding links no agent to a skill and no rule to the queue, so the engine finds no candidates and leaves the task where it was, with no error. Step 5 fixes that for your team rule, which needs no agent links; Step 2 is the safety net for every task your rule does not match.

What a condition can test, and what an action can do

A condition is a child rule: a field, an operator, a value. The screen offers four fields — Channel, Project, Virtual Contact and Skill — and six operators: equal, not equal, less than, less than or equal, greater than, greater than or equal. For these four fields only equal and not equal make sense. All conditions on one rule must hold together (AND). There is no “contains”, no “or”, and no condition on the message text.

An action is what a matched rule does, and the two places that offer one do not agree. The four seeded actions run through a STANDARD rule; the Action screen is off the menu, so they are all you have unless someone created more. “At random” always picks the first candidate.

The Rule Action drop-down lists the same action records, and gives ASSIGN_TO_TEAM a team picker. ASSIGN_TO_TEAM works only on a CUSTOM rule, where the engine reads the team you picked; on a STANDARD rule the rule fails over to the default. CREATE_ISSUE never runs (LB8-P05). Which codes the engine handles is on Core concepts.

So the rule you want — WhatsApp goes to Technical — is a CUSTOM rule with a Channel condition and an ASSIGN_TO_TEAM action, linked to the default queue. That is the procedure.

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 (Unified Contact Center). 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

Related documentation

• Unified Contact Center Applet — the reference page: menus, permissions, endpoints, task statuses, the full processor list and the twelve declared action codes.
• A chat came in and nobody got the task — the symptom, on either kind of endpoint.
• Contact Keys — how the customer on the other end of the chat resolves to an entity and a contact.
• Tenant Admin Applet — applet ranks per user, which the engine reads.
• Digital CRM Module — where this applet sits among the customer-facing ones.