Predictive customer-to-agent routing in contact centres

Classic skills-based routing sends a contact to the longest-idle agent who has the right skill tag. Predictive routing instead scores each available agent for each waiting contact against a chosen outcome KPI (first-contact resolution, CSAT, conversion, retention, handle time) and picks the best trade-off between outcome, wait time and agent utilisation. Vendors report uplifts, but the effect is workload- and data-dependent and must be proven with a controlled holdout on your own traffic.

Problem & value

• Today: automatic call distribution (ACD) rules use skills, priority, language and idle time. Supervisors tune queues by hand. Agents with the same nominal skill differ widely in results by customer type and topic, but this is rarely exploited.
• AI value: a per-contact decision over outcome models can raise resolution and sales rates and reduce repeat contacts without hiring, because it re-allocates existing capacity. Gains come from heterogeneity: if all agents perform alike on all contact types, there is little to gain.
• Trade-off: matching quality competes with wait time. Waiting for the "best" agent can hurt service levels, so production systems cap the extra wait (queue timeouts) and fall back to standard routing [1][2].
• Evidence caution: published uplift figures come mostly from vendors. Treat them as hypotheses; require an A/B or on/off holdout (Genesys and Afiniti both build this into their rollout) [1][3].

Variants

• Outcome-scored routing (KPI-based): rank agents by predicted KPI per interaction (Genesys Predictive Routing, NICE, Five9, Amazon Connect-based custom).
• Pairing/behavioural matching: pairing models over customer and agent history to select between pairs when several agents and callers are waiting (Afiniti-style); typically run as an overlay on the existing ACD with its own holdout "off" periods.
• Sales/collections/retention desks: objective is conversion, promise-to-pay or save rate.
• Service desks and field dispatch: agent replaced by technician, see OPT-019.
• Digital channels: chat, messaging and email, where agents handle several concurrent sessions and capacity is fractional.
• Private use: not applicable.

How it works

1. contact arrives (voice/chat/email)
2. intent & context (IVR, bot, LANG-012 classifier; customer history from CRM)
3. candidate set (available agents, skills, language, schedule, occupancy)
4. outcome models: P(resolution), P(sale), E[handle time], P(repeat) per agent x contact
5. decision layer: score = weighted outcomes - wait/occupancy penalties; assignment solver
6. routing action (assign / hold up to T seconds / widen pool / overflow)
7. outcome logging
8. retraining + holdout evaluation + fairness checks

• Models: gradient-boosted trees or generalised linear models over agent and contact features are the workhorse; some vendors use deep models. Contextual bandits / RL add exploration so the system keeps learning agent-contact fit instead of only exploiting past routing.
• Assignment: when several contacts and agents are waiting at once, a small assignment problem (Hungarian algorithm or LP/MIP, e.g. Google OR-Tools) maximises total predicted value under constraints such as service-level targets and fairness caps.
• Causal care: historical outcomes are biased by past routing (the best agents got the hard calls). Use randomised exploration, propensity weighting or uplift modelling to avoid learning spurious "star agent" effects.
• Human-in-the-loop: supervisors set KPIs, weights, wait caps and exclusion rules; agents can see the routing rationale policy; a global "predictive off" switch and a holdout group remain.

Data preparation

Routing quality depends on outcome labels and clean agent data. Data typically lives in the CCaaS/ACD (interaction logs, queues, handle times), the CRM (customer tier, history), the quality-management or survey tool (CSAT) and the workforce-management system (skills, schedules).

Typical gaps: skill tags that are outdated or too coarse, outcome labels missing (resolution recorded only as agent free text), CSAT sparse and biased, customer IDs not matched across channels, repeat contacts not linked, and call recordings or transcripts without consistent intent labels.

Preparation steps: 1. Inventory and map sources and gaps (PREP-001, PREP-002). 2. Link interactions to customer IDs and compute first-contact resolution and repeat-contact flags (PREP-020). 3. Define intent categories before modelling (PREP-019) and clean agent skill profiles. 4. Set up a holdout group so effect can be measured against baseline routing (PREP-018). 5. Pseudonymise agent and customer identifiers for modelling (PREP-022) and check purpose and legal basis (PREP-025).

Tools: CCaaS exports or streaming APIs, a data warehouse and a notebook environment. Expect about half of the effort in data work, particularly label creation and identity matching.

Implementation paths

Which path for whom

• enterprise (A): predictive routing is a built-in module of the major contact-centre platforms, which hold the real-time queue and agent state; building your own router rarely pays off.
• developer (B): for custom routing on top of an ACD, score agents with your own model via cloud APIs and the platform's routing hooks, with EU-hosted components.

Path A — Buy (recommended)

• CCaaS with built-in predictive routing: Genesys Cloud CX (Predictive Routing, with KPI setup, benefit assessment and comparison test before activation), NICE CXone (incl. Enlighten AI), Five9, Talkdesk, Avaya/Alvaria, Cisco Webex Contact Center, Salesforce Service Cloud Omni-Channel, Amazon Connect (routing profiles, proficiencies, predictive rules).
• Overlay vendors: Afiniti (pairing overlay on existing ACDs); check data-sharing terms.
• EU/European options: Genesys and NICE offer EU regions; European CCaaS vendors include Sinch Contact Pro, Enghouse Interactive, Content Guru (UK), Daktela (CZ) and Dixa (DK), with differing depth of predictive features. Verify EU data residency and subprocessors.
• Choose A when: you already run a major CCaaS with several hundred seats and enough history; building from scratch rarely pays below that.

Path B — Build on cloud APIs

• Use the CCaaS routing APIs (Genesys Cloud routing/analytics APIs, Amazon Connect contact attributes and routing profiles, Twilio TaskRouter) to call an external scoring service.
• Train models on managed ML (Azure ML, Vertex AI, SageMaker, EU regions); feature store fed by CRM and interaction data. LLMs help only upstream: intent and sentiment extraction from the first utterance or message, not the assignment decision itself.
• Choose B when: specific business objectives (margin, retention value) need custom scoring.

Path C — Self-host (open source)

• scikit-learn, LightGBM/XGBoost, Vowpal Wabbit (contextual bandits), OR-Tools or HiGHS for assignment, Kafka/Redis for streaming state; Asterisk, FreeSWITCH or Jambonz-based stacks for telephony. CPU suffices (HW1); open-weight small LLMs only for intent extraction.
• Ops effort is mainly telephony integration and monitoring, not compute.

Path D — Custom training

Worthwhile for large operations (thousands of seats) with unique KPIs: train per-queue outcome models, bandit policies and uplift models from at least months of interaction logs with reliable outcome labels; plan offline policy evaluation (inverse propensity scoring) before live tests.

State of the art (2026)

• Practice: predictive routing is production-grade in mainstream CCaaS, activated per queue after a benefit assessment on historical data and a live comparison test [1][2].
• Trend: CCaaS vendors bundle routing with AI agents/voicebots (CONV-002) and agent assist (CONV-007); routing now also decides human versus AI handling and escalation.
• Techniques: contextual bandits, uplift modelling and constrained assignment replace pure prediction; fairness-aware allocation is increasingly requested by works councils.
• Limits/failure modes: selection bias in training data; small queues with too little data; gaming by agents; metric conflicts (shorter handle time vs resolution); feedback loops that overload top agents and cause burnout; drift when products or processes change; weak evidence beyond vendor-reported results.

Shared resources & combinations

• Upstream: LANG-012 (intent classification), CONV-002 (voicebot triage), SPEECH-002 (call outcome labels and QA scores used as training targets).
• Staffing: OPT-003 (shift planning) and PRED-011 forecasting set capacity; routing optimises inside that capacity.
• Downstream: CONV-007 (agent assist), PRED-003 (churn score as a routing feature).
• Shares tabular-ml, optimization-solver and streaming stacks with OPT-019 and OPT-028.

Effort, cost & KPIs

• Path A: weeks to configure plus a multi-week test period; licence often per seat or per AI token/usage, check holdout-based or outcome-based pricing terms.
• Path B/C: 4-9 months incl. telephony integration, data engineering and test design.
• Path D: quarters; data science team.
• KPIs: first-contact resolution, repeat-contact rate, CSAT/NPS, conversion or save rate, average handle time, average speed of answer, service level, abandonment, occupancy spread across agents, uplift versus holdout with confidence intervals.

People & change

Agents are directly affected, so involve them from the start. Sponsors are management and the head of customer service; HR, IT and the owners of ACD and CRM data join early. Pick one team as pilot group with a holdout, and share routing logic and results openly. Supervisors keep the ability to override routing and to exclude contact types.

Works council: yes. Scoring agents per contact and optimising by individual outcomes is suited to monitor behaviour and performance, so co-determination under section 87(1) no. 6 BetrVG applies in practice; section 90(1) no. 3 adds the information duty. Engage an AI expert under section 80(3) if needed. Agree on rules: no individual rankings for disciplinary use, fairness and workload monitoring, and retention limits. Public bodies: staff council.

Data protection: agent and customer data are personal. Involve the DPO, run a DPIA (systematic evaluation of employees), sign an AVV with the platform vendor and document the legal basis (section 26 BDSG). Check against Annex III (employment, task allocation based on individual behaviour), which brings high-risk duties from 2 Dec 2027.

AI literacy: support agents and supervisors with training on how routing works (GUIDE-006). Typical concern: surveillance and unfair assignment of hard calls; address it with transparency and fairness dashboards (GUIDE-008). See GUIDE-004 and GUIDE-005.

Risks, regulation & compliance

• EU AI Act: usually not high-risk when routing only customers. Caution: if the system allocates tasks based on individual behaviour or personal traits of agents, or monitors and evaluates their performance, it falls under Annex III point 4(b) (employment, worker management) and is high-risk [4]. Never infer agents' or customers' emotions from voice or biometrics in a workplace: emotion recognition in the workplace is prohibited under Art. 5(1)(f) (safety/medical exceptions only) [4][5]. Art. 50 transparency applies if bots are in the loop.
• GDPR: customer history is personal data; define purpose and legal basis (legitimate interest with balancing test); minimise features; avoid special-category inference (health, ethnicity) from call content. Art. 22 limits solely automated decisions with legal or similarly significant effects on individuals; routing normally does not meet that bar, but denial of service or worse treatment by customer value tier needs review [6]. Agent data: employee data protection (e.g. §26 BDSG), works council co-determination (§87 BetrVG in Germany), DPIA likely.
• Fairness: customers must not be systematically routed to worse service based on protected characteristics or proxies (language, postcode); test disparate impact.
• Mitigations: wait caps, holdout group, explainable policy documentation, audit logs of routing decisions, agent-side transparency, regular bias and workload reviews.

Getting started

1. Define one primary KPI per queue and the maximum acceptable extra wait; fix baseline metrics.
2. Check data: at least several months of interactions with reliable outcome labels and agent IDs.
3. Involve works council and DPO early; run a DPIA and classify against Annex III.
4. Pilot on one queue with a randomised holdout (predictive on/off) for several weeks.
5. Review uplift, wait times, fairness and agent workload before scaling.

Sources

1. Genesys Cloud Resource Center — About predictive routing — https://help.genesys.cloud/articles/about-predictive-routing/
2. Genesys Cloud Resource Center — Get started with predictive routing — https://help.genesys.cloud/articles/get-started-with-predictive-routing/
3. Afiniti — company and product information — https://www.afiniti.com/
4. Regulation (EU) 2024/1689 (AI Act), Art. 5 and Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. European Commission — Guidelines on prohibited AI practices — https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-prohibited-artificial-intelligence-ai-practices-defined-ai-act
6. Regulation (EU) 2016/679 (GDPR), Art. 22 — https://eur-lex.europa.eu/eli/reg/2016/679/oj
7. Amazon Connect — Routing profiles and proficiencies — https://docs.aws.amazon.com/connect/latest/adminguide/routing-profiles.html
8. Google OR-Tools — https://github.com/google/or-tools