La coda: il contenitore del lavoro in attesa
In unified routing una coda (queue) raccoglie gli elementi di lavoro e li distribuisce fra i representative che ne sono membri. Gli elementi di lavoro sono sia record — case, email — sia conversazioni di chat, SMS o voce. Il meccanismo è identico in Dynamics 365 Contact Center e in Dynamics 365 Customer Service: la pagina di riferimento sulle code vale dichiaratamente per entrambi i prodotti, per Contact Center sia embedded sia standalone.
Le code sono classificate per tipo di canale, e il tipo si sceglie alla creazione: Messaging per le conversazioni di live chat, SMS e canali social, Record per record come case ed email, Voice per le chiamate ai numeri di supporto. Il tipo non è un’etichetta cosmetica: serve a evitare assegnazioni incrociate. Quando configuri un workstream o una regola di instradamento, il sistema ti propone solo le code del tipo compatibile; allo stesso modo puoi trasferire una conversazione di chat soltanto verso una coda messaging e un case soltanto verso una coda record.
Il percorso operativo: nel site map del Copilot Service admin center — l’app di amministrazione anche di Dynamics 365 Contact Center — apri Queues dentro Customer support, poi Manage su Advanced queues, poi New. La finestra Create a queue chiede tre cose soltanto: Name, Type e Queue priority. Dopo la creazione aggiungi i membri con Add users e scegli l’Assignment method fra Highest capacity, Advanced round robin, Least active e Create new per un metodo personalizzato. Least active è disponibile solo per le code voice e messaging, ed è la selezione predefinita quando ne crei una.
Su Operation hours colleghi un record di orari già esistente: se non lo imposti, la coda è considerata disponibile in ogni momento. Su Metrics Threshold puoi aggiungere Service Level Threshold e Short Abandoned Threshold, entrambi espressi in secondi. Accanto alle code che crei tu esistono le default queues di sistema — Default entity queue, Default messaging queue, Default voice queue — delle quali puoi modificare solo l’assignment method; la documentazione raccomanda comunque di creare advanced queue e definire la strategia di assegnazione invece di appoggiarti a quelle predefinite.
La priorità sta sulla coda, non sull’elemento
È il punto che separa la risposta giusta da quella sbagliata. Queue priority è un campo della coda, impostato alla creazione e modificabile dopo: non esiste come impostazione del singolo elemento di lavoro in questa schermata. La regola numerica è controintuitiva quanto basta per essere chiesta all’esame: unified routing dà precedenza alla coda con il numero più piccolo. Se vuoi che le conversazioni passino davanti ai case, assegni 1 alle code delle conversazioni e 2 a quelle dei case.
Questa priorità conta solo quando gli stessi representative sono membri di più code: serve a ordinare il lavoro fra code, non dentro una coda. Dentro la singola coda l’ordine predefinito è first-in-first-out, cioè viene assegnato per primo l’elemento più vecchio; per i canali di messaggistica asincroni il “più vecchio” si calcola sull’ultima interazione, non sull’apertura della conversazione. Se ti serve un ordine diverso all’interno della coda devi definire una prioritization ruleset in un assignment method personalizzato, e puoi crearne una sola per coda.
I pareggi hanno regole precise. Due code con lo stesso numero e ordinamento FIFO: viene assegnato l’elemento più vecchio fra tutte. Due code con lo stesso numero ma regole di prioritizzazione personalizzate: le code vengono ordinate alfabeticamente per nome. E se mescoli i due mondi, le code con assignment method predefinito vengono servite prima di quelle con prioritizzazione personalizzata — motivo per cui la documentazione raccomanda priorità distinte per le code con regole personalizzate.
Overflow: due momenti diversi, non uno
L’overflow handling si configura sulla coda con Add condition-action pair, e va letto sapendo che i momenti di valutazione sono due.
Before work items are queued: il controllo avviene dopo le route-to-queue rules e prima che l’elemento entri in coda, una sola volta per elemento. Le condizioni sono Out of operating hours, Work item limit exceeds (un numero fra 1 e 100 di elementi aperti tollerati) e Average wait time, quest’ultima solo per le code voice, con un valore fra 30 secondi e 60 minuti. Le azioni dipendono dal canale: per voice sono Assign to queue anyway, Direct callback, End call, Transfer to a different queue, Transfer to an external number e Voicemail; per live chat e messaggistica sono End conversation, Transfer to a different queue e Assign to queue anyway; per le code record esiste la sola condizione Out of operating hours con Assign to queue anyway o Transfer to a different queue.
Due dettagli da ricordare. Quando associ un record di operating hours alla coda, il sistema aggiunge da solo la condizione Out of operation hours con azione Assign to queue anyway: la condizione non è modificabile, l’azione sì. E se più condizioni risultano vere insieme, viene eseguita per prima l’azione degli orari, poi le altre nell’ordine in cui le hai definite.
When work items are queued: qui la condizione è una sola, Waiting time in queue exceeds, e serve a spostare altrove il lavoro già in attesa. Le durate configurabili sono 1-60 minuti per voice, da 1 minuto a 2 giorni per messaging, da 3 minuti a 2 giorni per i record.
Fallback: la rete che ignora l’overflow
Il fallback queue si imposta sul workstream, non sulla coda, scegliendo Create new o Choose existing. Vi finiscono gli elementi in tre casi: errore durante la classificazione, errore nell’esecuzione di una route-to-queue rule, oppure nessuna regola corrispondente. In tutti e tre le eventuali impostazioni di overflow della coda di fallback vengono ignorate e l’elemento viene assegnato lo stesso. Qualsiasi coda può fare da fallback, comprese le default queues, ma non vale il contrario.
L’esame ti chiederà soprattutto di distinguere questi tre livelli: la priorità decide quale coda serve prima, l’overflow decide cosa succede quando una coda è satura o chiusa, il fallback decide dove finisce il lavoro quando l’instradamento non ha funzionato. Confusione tipica da evitare: se un AI agent è configurato sul workstream, l’overflow viene valutato solo dopo che l’agent ha escalato la conversazione a un representative. Ed evita di citare il customer support swarming come opzione di collaborazione: è deprecato e non più supportato.