Il workstream governa l’ingresso
L’unified routing è una catena, e conviene studiarlo nell’ordine in cui il lavoro la attraversa: un work item (una conversation di chat, voice o messaging, oppure un record come un case) entra da un workstream, viene arricchito dalla work classification, instradato da un routing ruleset verso una queue e infine assegnato a un representative.
Nel workstream si definiscono il canale, la modalità di distribuzione (push, che spinge il lavoro al representative e ne richiede l’accettazione, oppure pick, che lo lascia prelevare dalla queue), il tipo di capacity consumata, la presence ammessa e le regole di chiusura automatica. L’errore concettuale più frequente è pensare che il workstream “contenga” il lavoro: non lo contiene. La queue è il luogo dove il lavoro attende e a cui sono associate le persone; il workstream è la porta d’ingresso e il regolamento che si applica mentre il lavoro la varca. In progettazione: un workstream per canale o scenario d’ingresso, più queue per competenza, lingua o linea di servizio.
Work classification: arricchire il work item
La work classification si configura dentro il workstream ed è il punto in cui il work item smette di essere anonimo: le regole impostano attributi (prodotto, lingua, priorità, dati del record collegato) che diventeranno le condizioni delle regole successive, e possono attaccare le skill richieste.
Da qui un criterio ricorrente: se il requisito parla di sapere qualcosa in più sul lavoro, la risposta sta nella classification; se parla di decidere dove mandarlo, sta nei ruleset.
Routing ruleset: scegliere la queue
I routing ruleset di tipo route-to-queue sono liste ordinate di regole valutate dall’alto verso il basso: vince la prima condizione soddisfatta e la valutazione si ferma lì. L’ordine è materia d’esame, non un dettaglio: la regola più specifica deve stare sopra quella generica, altrimenti resta lettera morta. Se nessuna regola corrisponde, il lavoro finisce nella fallback queue del workstream — comportamento previsto per design, quindi trovare tutto lì dentro è sintomo di condizioni scritte male, non di un bug.
Le condizioni leggono gli attributi prodotti dalla classification: un ruleset ben scritto è la conseguenza di una classification ben fatta.
Assegnazione: capacity profile e skills-based routing
Scelta la queue, l’assignment decide la persona. Il metodo può privilegiare chi ha più capacity disponibile, distribuire a rotazione con round robin, oppure seguire un assignment ruleset personalizzato che prima filtra gli utenti idonei e poi li ordina. Il trade-off: round robin distribuisce equamente ma non guarda il carico; il metodo basato sulla capacity guarda il carico ma non l’equità dei turni.
I capacity profile modellano quanto lavoro concorrente una persona regge, per tipo di lavoro: profili distinti permettono a chat e case di consumare budget separati, cosa impossibile con il vecchio conteggio a unità in cui ogni canale erodeva lo stesso totale.
Sullo skills-based routing vanno tenute distinte due cose che l’esame confonde di proposito. Lo skill finder model individua le skill e le attacca al work item in fase di classification: è il “quali competenze servono”. L’algoritmo di skill matching, configurato nell’assegnazione, decide invece quanto rigidamente quelle skill debbano combaciare: un match esatto garantisce la competenza ma può lasciare il lavoro in attesa, mentre un match più permissivo rilassa progressivamente le skill meno rilevanti pur di assegnare il lavoro.
Record routing: la stessa catena per i record
Il record routing porta i record — case, email, tabelle custom — dentro lo stesso meccanismo: tabella abilitata al routing, workstream di tipo record, classification, ruleset, queue, assegnazione. Il valore sta nell’unico modello di governo: stesse condizioni, stesse queue e stessi capacity profile per conversation e record, invece di due sistemi paralleli che divergono nel tempo.
Trappole tipiche d’esame
- I case in francese devono andare a un team dedicato → routing ruleset con condizione sulla lingua: non serve un workstream per lingua; l’ingresso resta uno, cambia la regola che sceglie la queue.
- Chat e case non devono consumare lo stesso budget → capacity profile separati: il conteggio a unità unico non distingue i tipi di lavoro, i profile sì.
- Il lavoro va assegnato comunque, anche senza corrispondenza perfetta di skill → algoritmo di matching permissivo: si rilassano le skill meno rilevanti, non si rimuovono le skill dalla classification.
- Le skill vanno dedotte dal contenuto della richiesta → skill finder model: è classification, non matching; l’algoritmo di matching non attacca skill, le confronta soltanto.
- Tutto finisce nella fallback queue → condizioni troppo strette o ordine sbagliato nel ruleset: la fallback è comportamento atteso, va letta come diagnosi delle regole.
- Assegnare a chi in quel momento è più libero → metodo basato sulla capacity, non round robin: round robin è equità di turno, non bilanciamento del carico reale.