Il call flow come catena di oggetti

Un centralino in Teams Phone non è un oggetto unico ma una catena: numero PSTN → resource account → voice application → destinazione finale (persona, altra voice application, numero esterno, voicemail condivisa). Il criterio di progetto è separare due responsabilità distinte. L’auto attendant decide dove va la chiamata: accoglie, presenta le opzioni, applica orari e festività. La call queue decide chi la prende: tiene gli agenti, la coda di attesa e le regole di distribuzione. Quasi ogni impianto reale li combina — un’auto attendant in ingresso che smista verso più code per reparto — e l’esame descrive esattamente scenari di questo tipo, chiedendo quale dei due oggetti va toccato per ottenere un certo comportamento.

Auto attendant: accoglienza, menu, calendario

L’auto attendant fornisce il messaggio di benvenuto (testo sintetizzato o file audio) e il menu di scelta, che accetta sia input a tasti (DTMF) sia comandi vocali. Ogni voce di menu punta a una destinazione: un operatore, un utente del tenant, un’altra voice application, un numero esterno, la voicemail. Sono disponibili anche la ricerca a rubrica per nome e l’inoltro per interno, con la possibilità di limitare l’ambito di ricerca tramite gruppi, scelta rilevante quando la directory non deve essere interamente esposta a chi chiama.

La parte che distingue l’auto attendant da qualsiasi altro oggetto è la gestione del tempo: call handling separato per orario di apertura, fuori orario e giorni di holiday, ciascuno con il proprio greeting e la propria destinazione. Se il requisito parla di calendari, festività o comportamento diverso di notte, la risposta è auto attendant — non call queue.

Call queue: agenti, distribuzione, uscite di sicurezza

La call queue gestisce l’attesa e la consegna. Configuri il greeting, la music on hold, l’elenco degli agenti (utenti singoli, gruppi o team) e il metodo di distribuzione: attendant routing verso tutti contemporaneamente, serial in ordine fisso, round robin per bilanciare, longest idle per dare la chiamata a chi è fermo da più tempo. Si aggiungono il presence-based routing (chi non è disponibile viene saltato), la possibilità per l’agente di fare opt-out, e la conference mode che riduce il ritardo di connessione con i client supportati.

Le uscite di sicurezza sono tre e vanno distinte: overflow quando si supera il numero massimo di chiamate accodate, timeout quando si supera il tempo massimo di attesa, gestione no agents available quando nessun agente è raggiungibile. Ognuna può rimandare la chiamata a voicemail, a un’altra voice application o a un numero esterno. In più esistono la priorità della chiamata, per far scavalcare la coda a certi flussi, e il callback: il chiamante lascia la posizione in coda e viene richiamato quando arriva il suo turno, opzione che si sceglie quando il problema da risolvere è l’abbandono su attese lunghe, non la carenza di agenti.

Resource account, licenza e service number

Qui sta il punto che l’esame verifica quasi sempre. Né l’auto attendant né la call queue hanno un’identità propria in Microsoft Entra ID: non possono essere chiamate direttamente. Entrambe rispondono attraverso un resource account, un oggetto disabilitato all’accesso che va creato, licenziato con la licenza dedicata ai resource account e infine associato alla voice application. Un resource account senza associazione non fa nulla; una voice application senza resource account non è raggiungibile.

Se poi il flusso deve essere raggiungibile dall’esterno, quel resource account ha bisogno anche di connettività PSTN: piano/abilitazione coerente con il modello adottato (Microsoft Calling Plan, Operator Connect, Direct Routing) e di un service number, cioè un numero di servizio dimensionato per chiamate concorrenti, diverso dal subscriber number di un utente. Le voice application annidate — un’auto attendant che passa a una coda che passa a un’altra coda — hanno ciascuna il proprio resource account, ma solo quella esposta al pubblico deve avere il numero.

Per la gestione quotidiana c’è la Queues app nel client Teams: dà a lead e supervisori la vista sulle code, la possibilità di intervenire sulle chiamate e i dati di andamento senza passare dal Teams admin center. È una capacità premium: verifica i requisiti di licenza sulla documentazione ufficiale prima di prometterla in un progetto.

Trappole tipiche d’esame

  • Il numero pubblico dell’azienda deve arrivare all’auto attendant → resource account licenziato con service number: non si assegna il numero alla voice application né a un utente “centralinista”. Senza licenza sul resource account l’assegnazione del numero fallisce.
  • Serve un messaggio diverso a Natale e nei weekend → auto attendant, non call queue: la coda conosce solo overflow, timeout e assenza di agenti; orari, holiday e greeting stagionali esistono unicamente nell’auto attendant.
  • Chi chiama riattacca dopo minuti di attesa → callback, non nuovi agenti né timeout più lungo: il callback preserva la posizione in coda; alzare il tempo massimo di attesa peggiora solo l’esperienza.
  • Le chiamate devono andare a chi è libero da più tempo → longest idle, non round robin: il round robin distribuisce in modo ciclico a prescindere dall’inattività; attendant routing squilla invece a tutti insieme.
  • Menu che smista verso tre reparti diversi → tre call queue, ciascuna con il proprio resource account: le voice application concatenate richiedono un resource account ognuna, anche quando non sono esposte al PSTN.
  • Molti utenti devono chiamare in uscita con un solo numero aziendale → Shared Calling, non call queue: Shared Calling condivide numero e piano tramite un resource account, ma non accoda né distribuisce chiamate in ingresso agli agenti.