Question
Closed · Answered

Can enquiries be routed by language and department before round-robin assignment?

Wenke Li

One contact form may receive Chinese sales enquiries, English support requests, and billing questions. A single round-robin list could assign a request to someone who doesn't cover its language or department.

For a Busabase queue, would a separate staff Base with languages, department, and availability be a useful setup before an agent or external workflow assigns requests? Enquiries with no suitable assignee should remain unassigned with a reason so a person can pick them up.

Report
Kelly
Team

Yes. Keep who can take work separate from which ticket goes where, narrow candidates by language → department → availability, and only then round-robin inside that pool—do not force work through one global rotation list.

(Diagram: match first, then rotate; empty pool → pending with a reason.)

Suggested tables

1. People (skills / coverage)

One row per person, for example:

  • Name, contact
  • Languages (multi-select: English, 中文, …)
  • Department / skills (Sales, Support, Finance, …)
  • Available to take work (toggle; turn off when on leave or at capacity)
  • Current load (optional number; prefer lower load when rotating)

2. Enquiries / tickets

One row per incoming enquiry:

  • Source (form, WhatsApp, email, …)
  • Detected or stated language, issue type / department
  • Assignment status: pending match / assigned / needs human
  • Assignee (link to People)
  • Unmatched reason (no language match, nobody available in that dept, all at capacity, …)
  • First assigned at / last reassigned at (for later review)

People holds capability and availability; the enquiry holds the outcome of *this* ticket. One person can sit on many tickets; each ticket keeps its own status.

(Local demo: Base design — split language, department, and status into real fields so filters and agents can write them cleanly.)

Flow when a new enquiry arrives

  1. Create the enquiry row with language, department, and source filled (from the form or an agent). Start as “pending match.”
  2. Filter people: language contains the enquiry language and department matches and available = on.
  3. Someone matches: round-robin (or pick lowest load) inside that pool, set assignee, mark assigned, notify them.
  4. Nobody matches: do not force-assign someone who cannot cover the language or the function. Mark “needs human / pending,” write the unmatched reason, and let a duty owner pick it up.

An external flow (e.g. n8n) or an agent can follow the same rules—keep the logic in one place so forms, bots, and manual reassignment do not diverge.

How to verify it worked

  • Open Enquiries, filter “created today”: assigned rows should have an owner; pending rows should show an unmatched reason.
  • Spot-check one assigned row: open the linked person and confirm their languages, department, and availability actually cover that ticket.
  • If your space uses reviews: flip assignee / status via a change request so Inbox shows who reassigned what and when.

Edge cases

  • One global round-robin list often misroutes (e.g. a Japanese enquiry to someone who only speaks English). Match first, then rotate, so “nobody available” stays visible separately from “already assigned.”
  • Several open threads for one customer: put assignment on the enquiry, not only a default owner on the customer profile.
  • Mid-flight reassignment: update assignee + reassigned-at; optionally note the handoff to the previous owner.
  • Bad language detection: let a human correct the language field and re-run matching; keep a short note why.

With this split, multilingual + multi-department intake stays auditable, and adding another filter (e.g. region) later is just one more field in the same gate.

Report

Your reply

Sign in to join the discussion. Reading is always open; you only need an account to post.

Sign in