Costo per risoluzione, non costo al minuto: una metodologia per il pricing degli agenti vocali

L'acquirente di un agente vocale siede al tavolo di fronte a un fornitore che quota $0.31 al minuto. Il budget dell'acquirente è espresso in problemi dei clienti risolti, non in minuti. La quotazione del fornitore e il budget dell'acquirente sono in unità diverse, e quasi ogni confronto pubblico tra stack di agenti vocali si allinea all'unità del fornitore, non a quella dell'acquirente. Abbiamo scritto questo articolo perché abbiamo esaurito la pazienza nei confronti di questa asimmetria durante le riunioni di procurement.

La domanda empirica è circoscritta. Dato uno stack di agente vocale con un prezzo al minuto noto, un tempo medio di gestione noto, un tasso di contenimento noto e un costo di fallback noto quando l'agente effettua l'escalation verso un operatore umano, qual è il modo corretto di calcolare il costo di una chiamata risolta? E una volta che quel numero esiste, le classifiche che produce sugli stack pubblici reali coincidono con quelle prodotte dal prezzo al minuto? Se le classifiche concordano, la scelta dell'unità è cosmetica e i team di procurement possono continuare a usare l'unità che i fornitori quotano. Se le classifiche divergono, la scelta dell'unità è di per sé una decisione di procurement, e un acquirente che valuta i fornitori sul prezzo al minuto è esposto a un errore strutturale che il foglio di calcolo non segnala.

Tre osservazioni motivano la domanda. In primo luogo, ogni confronto di pricing tra fornitori che abbiamo esaminato quota tariffe al minuto ^{[14, 15, 16, 17]} senza comporle in una cifra per risoluzione, anche se gli stessi autori riconoscono che è il contenimento a guidare il costo effettivo ^[15]. In secondo luogo, la letteratura sulle operations dei contact center sa da almeno un decennio che il costo per contatto nasconde il costo del rilavoro. Belfiore ha quantificato un divario di 10 punti nella risoluzione alla prima chiamata come $1.2M di costo annuo evitabile su un'operazione da 1M di chiamate ^[2], e l'outsourcing a pagamento per risoluzione è già un formato di procurement con tariffe di listino tra $1 e $7 ^[5]. L'unità ha significato per l'acquirente. In terzo luogo, il benchmark τ-Voice riporta tassi di completamento dei compiti per gli agenti vocali del 31–51% in condizioni pulite e del 26–38% con rumore realistico ^[19], quindi la variabile che determina il costo per risoluzione si muove più di quanto i blog dei fornitori ammettano. La regola di composizione che trasforma questi input in un numero confrontabile non risulta pubblicata.

Un lettore potrebbe ragionevolmente chiedersi perché debba esistere un articolo metodologico su una formula a quattro input. Il motivo è che i quattro input provengono da quattro letterature separate (pagine di pricing dei fornitori, operations dei contact center, benchmarking degli agenti vocali e un costo del lavoro divulgato da un fornitore) e nessuna fonte pubblicata li compone. Le pagine di pricing dei fornitori si fermano alle tariffe al minuto ^{[14, 16, 17]}; la letteratura accademica sul benchmarking degli agenti vocali ^{[18, 19, 20]} riporta il completamento dei compiti come metrica di qualità senza tradurlo in un costo; la letteratura sui contact center definisce il costo per risoluzione concettualmente ^{[4, 7]} ma precede lo stack di costi dell'AI; e i modelli di dimensionamento del personale della gestione delle operations ^{[1, 26]} descrivono il lato umano della sostituzione ma non il lato AI. Ogni pezzo è pubblicato. La composizione no.

I nostri contributi sono: (1) una formula in forma chiusa per il costo per risoluzione che compone prezzo al minuto, tempo di gestione, contenimento e costo per escalation; (2) un esempio applicato a quattro stack reali di agenti vocali (Retell AI, uno stack in stile Vapi decomposto in componenti, uno stack self-hosted best-of-breed e un fornitore enterprise di voice-AI con prezzo minimo) usando prezzi di listino pubblici e intervalli di contenimento da benchmark pubblici; (3) due inversioni di classifica tra gli ordinamenti al minuto e per risoluzione che mostrano come la scelta dell'unità cambi la decisione di procurement; (4) una griglia di sensibilità bidimensionale su variazione di contenimento e costo di escalation che identifica il costo di escalation, e non il prezzo al minuto, come il fattore strutturale dell'ordine di classifica; e (5) una derivazione tramite Erlang C in appendice che ancora il termine di escalation della formula al modello standard di dimensionamento del personale della letteratura sulla gestione delle operations ^{[1, 26]}.

L'articolo è strutturato come segue. La Sezione 2 passa in rassegna le due tradizioni, l'economia unitaria dei contact center e l'economia dell'inferenza degli LLM, che toccano il problema senza risolverlo. La Sezione 3 specifica la formula, i quattro stack, il disegno dell'esempio applicato e gli input mantenuti costanti. La Sezione 4 riporta la tabella dei quattro stack, le due inversioni di classifica e la griglia di sensibilità multivariata. La Sezione 5 discute cosa significhino le inversioni per il procurement, perché il termine di escalation domini e dove la formula si rompe. La Sezione 6 elenca ciò che la metodologia non può concludere. La Sezione 7 chiude. L'Appendice A deriva il termine di escalation da Erlang C.

Il modo in cui gli agenti vocali vengono prezzati oggi eredita due tradizioni: la gestione delle operations dei contact center, dove l'unità di conto è da tempo il contatto, e l'economia dell'inferenza degli LLM, dove l'unità è il token. Nessuna delle due tradizioni produce l'unità che un acquirente di agenti vocali in realtà compra; un problema del cliente risolto. Organizziamo i lavori correlati lungo questi due assi, poi passiamo in rassegna il piccolo corpus di scritti che ha iniziato a spingere verso modelli di costo ancorati alla risoluzione senza però arrivarci.

2.1 Economia unitaria dei contact center

La gestione delle operations tratta il contact center come un sistema di code servito da personale umano da almeno due decenni ^[1]. La rassegna di Akşin, Armony e Mehrotra ^[1] stabilisce la struttura di costo con cui qualsiasi argomentazione sulla sostituzione tramite AI deve confrontarsi: circa due terzi del costo operativo di un contact center è personale, e il personale scala linearmente con il tempo medio di gestione attraverso i modelli standard di dimensionamento Erlang C. Il riferimento per i professionisti della Society of Workforce Planning Professionals ^[26] formalizza la stessa linearità all'interno dello stack software di workforce management. Ereditiamo la linearità del dimensionamento nella nostra metodologia; quando un agente AI contiene una chiamata, accreditiamo la deflessione sottraendola dallo stesso modello Erlang. La derivazione compare nell'Appendice A.

Sopra lo strato di code, l'industria ha convergito sul costo per contatto come metrica operativa di efficienza ^[3]. Lo standard ICMI di Rumburg ^[3] lo definisce come spesa operativa mensile divisa per il volume di contatti in entrata e lo abbina al CSAT come KPI fondamentale. Il costo per contatto ha l'attrattiva analitica di un numeratore misurato direttamente su un denominatore misurato direttamente; la sua debolezza, ben nota all'interno dell'industria ma raramente formalizzata, è che i contatti non sono esiti. Belfiore ^[2] fornisce la quantificazione preesistente più vicina di questo divario traducendo i deficit di risoluzione alla prima chiamata in costo annuo in eccesso: un divario di 10 punti nella FCR su un'operazione da 1M di chiamate produce circa $1.2M di costo evitabile a $8 per chiamata e 1.5 follow-up per problema irrisolto. Il team di CallMiner ^[6] riporta la regola empirica derivata da SQM che ha ancorato la discussione tra i professionisti dalla fine degli anni 2000; un guadagno di un punto nella FCR vale un calo di un punto nel costo operativo.

Un filone più recente sostiene che l'unità stessa dovrebbe cambiare. CX Today ^[4] inquadra il costo per risoluzione come costo operativo totale rapportato ai problemi risolti, dove «risolto» richiede nessun contatto ripetuto entro 7-30 giorni e nessuna escalation dopo l'ultimo intervento. Il report di benchmark cross-settoriale di Şimşek ^[7] tabula il costo per ticket da $2.70 (retail) a oltre $40 (sanità complessa) e afferma che per il SaaS la metrica operativa è il costo per risoluzione anziché il costo per ticket; ma si ferma prima di pubblicare benchmark denominati per risoluzione. La prova di esistenza più chiara del fatto che l'unità ha significato per l'acquirente è il procurement: la guida al pricing dell'outsourcing di Mehta ^[5] documenta contratti BPO a pagamento per risoluzione in uso attivo a $1–$7 per problema risolto, con una media di settore riportata intorno a $4. L'unità esiste sul mercato; ciò che non ha avuto finora è una regola di composizione difendibile che dica a un CFO come derivarla dai componenti che i fornitori in realtà quotano.

2.2 Economia dell'inferenza degli LLM

L'altra tradizione che tocca il nostro problema è la letteratura sul costo di servizio per i grandi modelli linguistici. Erdil ^[22] sviluppa un modello teorico del compromesso tra costo per token e token al secondo sotto vincoli aritmetici, di memoria e di rete, e calcola le frontiere di Pareto per gli LLM più diffusi (si veda la Figura 2). La forma della frontiera; convessa con rendimenti marginali decrescenti rispetto al throughput; è la superficie di costo a monte che la nostra metodologia compone con il contenimento a valle per ottenere una cifra per risoluzione. Zhuang et al. ^[23] generalizzano l'impostazione in una «frontiera di produzione dell'inferenza degli LLM» (Figura 3) e identificano tre principi: costo marginale decrescente, rendimenti di scala decrescenti e una zona ottimale di efficienza in termini di costo. Pan et al. ^[21] applicano un framework costi-benefici strettamente correlato alla decisione tra deployment on-premise e commerciale, classificando gli scenari in fasce di rientro (0-6 mesi, 6-24 mesi, oltre 24 mesi). Tutti e tre sono denominati in token; utili perché i token sono l'unità marginale del costo di inferenza, limitanti perché i token non sono ciò che un acquirente di contact center compra. Prendiamo in prestito l'idea di stadiazione da ^[21] e l'impostazione sul costo marginale da ^{[22, 23]} ma riancoriamo il denominatore sui problemi risolti anziché sui token.

2.3 Benchmark e valutazione degli agenti vocali

Un corpus parallelo di lavori misura se gli agenti vocali risolvano affatto i problemi, senza convertirlo in costo. Il τ-bench di Yao et al. ^[18] introduce un benchmark di customer service per retail e compagnie aeree e la metrica di affidabilità pass^k, rilevando che GPT-4o risolve meno del 50% dei compiti ed è notevolmente incoerente tra le esecuzioni. Ray et al. estendono il framework alla voce in τ-Voice ^[19] e riportano tassi di completamento dei compiti del 31–51% in condizioni pulite e del 26–38% con rumore e accenti realistici; sostanzialmente al di sotto dei numeri in modalità testuale; il che informa direttamente l'analisi di sensibilità che eseguiamo sul contenimento (si veda la Figura 1). Ethiraj et al. ^[20] mostrano che il tuning di dominio sposta sensibilmente il completamento dei compiti a parità di calcolo, rafforzando la tesi che il contenimento quotato dai fornitori è condizionato a un carico di lavoro che l'acquirente raramente controlla. La revisione sistematica di Braggaar et al. ^[25] documenta 122 studi di valutazione per il dialogo orientato ai compiti e rileva costrutti eterogenei con operazionalizzazioni poco riportate; parte del motivo per cui una metrica economica a valle stabile non si è cristallizzata. Gao et al. ^[24] rendono operativi i compromessi tra utilità e costo all'interno del ciclo di reinforcement learning dell'agente con il loro framework CMPO; noi trattiamo lo stesso compromesso al livello del procurement con una regola di valutazione in forma chiusa.

2.4 Letteratura dei fornitori e dei professionisti

Gli scritti più letti sul costo degli agenti vocali sono pubblicati da fornitori e professionisti. Il confronto di pricing di Retell AI ^[14] tabula i costi al minuto e per 10K minuti tra Retell, Vapi, Twilio Voice ed Euphonia ($0.07–$0.66/min); l'articolo CloudTalk di Lucido-Balestrieri ^[16] riporta il pricing ibrido di CloudTalk accanto alle tariffe di listino dei concorrenti; Ahmed ^[15] decompone il pricing al minuto attraverso gli strati STT, LLM, TTS, telefonia e piattaforma e osserva che il tipo di chiamata e l'intervallo di contenimento (45–88%) guidano il costo effettivo più delle tariffe di copertina. L'analisi TCO di Dograh ^[17] separa i costi variabili, semi-variabili e fissi su tre fasce d'uso e valorizza il tempo di engineering a $150/ora; l'articolo nota che «i minuti grezzi non catturano l'intera realtà finanziaria» ma si ferma prima di sostituire i minuti con le risoluzioni come unità di conto. La guida agli stack di agenti vocali di Sharma ^[13] e la guida alle metriche di valutazione ^[12] pubblicano formule per la FCR (risolte-alla-prima / totale) e per il contenimento (risolte-da-AI / totale) con un obiettivo di contenimento >70% per la prontezza alla produzione, ma non compongono mai le metriche in un'unità per risoluzione. L'articolo sul ROI dell'automazione di Replicant ^[8] riporta costi per chiamata di $0.62 (AI) contro $7.40 (umano) e il blog sulle metriche di PolyAI ^[11] enumera gli otto KPI che un acquirente di voice-AI dovrebbe monitorare; incluso un avvertimento sul fatto che il contenimento può mascherare i chiamanti ricorrenti; senza arrivare a una metrica composta. Replicant ^[9] e Bucher + Suter ^[10] sostengono in modo indipendente che l'escalation richiede lo stesso rigore ingegneristico dell'automazione; entrambi trattano il costo dell'handoff in modo qualitativo, nessuno dei due lo prezza.

2.5 Sintesi e lacuna

Due cose sono chiare dalla letteratura. In primo luogo, gli input necessari a calcolare il costo per chiamata risolta esistono già in forma pubblica: i prezzi al minuto dei fornitori ^{[14, 15, 16, 17]}, le formule di contenimento ^[12], i tassi di completamento dei compiti misurati ^{[18, 19]}, le tassonomie di progettazione dell'escalation ^{[9, 10]}, i modelli di dimensionamento del personale ^{[1, 26]} e la traduzione storica tra FCR e costo operativo ^{[2, 6]}. In secondo luogo, nessuna fonte pubblicata li assembla. La tradizione dei contact center ^{[1, 3, 4, 5, 6, 7]} ha il denominatore giusto ma precede lo stack di costi dell'AI; la tradizione dell'economia dell'inferenza ^{[21, 22, 23]} ha il giusto rigore nella modellazione dei costi ma il denominatore sbagliato; la tradizione del benchmarking degli agenti vocali ^{[18, 19, 20, 25]} misura la risoluzione come esito di qualità anziché come input di prezzo; e la letteratura dei fornitori ^{[8, 9, 10, 11, 12, 13, 14, 15, 16, 17]} segnala ripetutamente la lacuna senza colmarla. Non siamo a conoscenza di lavori precedenti che definiscano una formula per il costo per chiamata risolta che componga prezzo al minuto, tempo medio di gestione, contenimento e costo di escalation, e che dimostrino con un esempio applicato che le classifiche risultanti differiscono dalle classifiche al minuto sugli stessi stack. Questo è il contributo di questo articolo.

Questo è un articolo metodologico nel senso di paper-research-method: la formula è il contributo, l'esempio applicato esiste per mostrare che la formula produce classifiche utili e non ovvie, e l'analisi di sensibilità esiste per mostrare che la formula recupera una regolarità empirica nota da lavori precedenti. Non abbiamo condotto nuove misurazioni. Abbiamo composto in un'unica regola input che esistono in forma pubblicata, applicato quella regola a quattro stack pubblici reali e sottoposto il risultato a stress test.

3.1 La formula

Sia p il prezzo di listino al minuto di uno stack di agente vocale in dollari, T il tempo medio di gestione di una chiamata contenuta in minuti, c il tasso di contenimento come frazione in [0, 1] ed E il costo per chiamata dell'escalation umana in dollari. Definiamo il costo per risoluzione come

C_res = (p · T) / c + (1 − c) · E

Il primo termine è il prezzo al minuto moltiplicato per il tempo di gestione, diviso per il contenimento. Risponde alla domanda: quando contiamo come risoluzioni solo le chiamate risolte dall'AI, quanto costa ciascuna in spesa di minuti-agente, dato che abbiamo pagato anche i minuti di ogni chiamata che non si è risolta? Il secondo termine è il sovrapprezzo di escalation atteso per ogni chiamata in entrata: con probabilità (1 − c) la chiamata effettua l'escalation, e ogni escalation comporta un costo E. I due termini si sommano in un'unica cifra in dollari per risoluzione.

La costruzione è deliberatamente semplice. Tratta lo stack AI come un servizio a costo marginale fisso pagato al minuto a prescindere dal fatto che la chiamata si risolva, e tratta l'escalation umana come un costo forfettario per chiamata; l'impostazione standard dei contact center in ^{[3, 8]}. Non ammortizza il costo di costruzione, non include soglie di licenza o minimi di piattaforma, e non accredita la deflessione a monte (chiamate che non raggiungono mai l'agente grazie al self-service nell'IVR). Ciascuno di questi punti è citato nel §6 come limitazione.

La formula compone i quattro input che i fornitori quotano in modo incoerente. Il prezzo al minuto p è pubblicato su ogni pagina di pricing dei fornitori ^{[14, 16]}. Il tempo di gestione T è una misurazione lato acquirente disponibile da qualsiasi log storico delle chiamate. Il contenimento c è il rapporto specificato in ^[12] e sottoposto a benchmark end-to-end in ^[19]. Il costo di escalation E è il costo per chiamata dell'instradamento della chiamata a un operatore umano; la cifra che Replicant ha divulgato a $7.40 ^[8] e la cifra che Belfiore ha usato a $8.00 ^[2]. Adottiamo $7.40 come proxy per l'esempio applicato perché è la divulgazione più recente e la fonte pubblica accanto a essa il comparatore per chiamata gestita dall'AI. L'Appendice A mostra che questa cifra è coerente con il modello di dimensionamento Erlang C in ^{[1, 26]} con un costo del lavoro caricato nell'ordine di $50/ora, un'occupazione vicina a 0.85 e un fattore 1.5× per le chiamate di follow-up.

3.2 I quattro stack

Abbiamo applicato la formula a quattro stack di agenti vocali scelti per coprire la forma del mercato pubblico, dalla configurazione self-hosted più economica al livello enterprise dal prezzo più alto.

Stack A, Retell AI, è una piattaforma gestita di agente vocale end-to-end prezzata a una singola tariffa al minuto che include STT, LLM, TTS e telefonia. Abbiamo usato $0.31/minuto, la tariffa che Retell pubblica accanto al suo confronto con i concorrenti ^[14].

Stack B, in stile Vapi decomposto, è un orchestratore gestito che espone i componenti sottostanti e li fattura separatamente. Seguendo la disciplina di decomposizione pubblicata da Ahmed ^[15], abbiamo composto STT a $0.05/min, LLM a $0.06/min per un modello di classe OpenAI, TTS a $0.07/min per una voce di classe ElevenLabs, telefonia a $0.013/min per la tariffa PSTN di Twilio e piattaforma a $0.05/min, per un totale di $0.243/min.

Stack C, self-hosted best-of-breed, è la configurazione pubblica a costo più basso: Pipecat come orchestratore, Deepgram per lo STT in streaming, Claude Haiku 4.5 come LLM, ElevenLabs Flash come TTS e Twilio come telefonia. Abbiamo preso tariffe pubbliche per componente con stima approssimativa e le abbiamo composte a circa $0.105/min. Il numero al minuto dello Stack C è il più esposto alle ipotesi; lo trattiamo come una stima difendibile del limite superiore del costo variabile self-hosted e lo dichiariamo come tale.

Stack D, fornitore enterprise di voice-AI, modella il livello a prezzo minimo di una grande piattaforma di contact center; NICE, Genesys Cloud, Verint o simili; composto da minuti di voice-AI più commissioni di piattaforma, tuning di servizi professionali e una spesa minima garantita ad alto volume. Il pricing di voice-AI pubblicato da CloudTalk di $0.50/min PAYG e $350/mese per 1.000 minuti ^[16] e il confronto tra fornitori di Retell ^[14] riportano entrambi tariffe di livello enterprise nell'intervallo $0.45–$0.66/min con le commissioni di piattaforma ammortizzate. Adottiamo $0.50/min come prezzo minimo per l'esempio applicato e lo abbiniamo a un impegno di contenimento di 0.55, vicino all'estremo superiore dell'intervallo pulito di τ-Voice ^[19], partendo dal presupposto che i fornitori enterprise tipicamente includono un team di tuning dedicato e SLA garantiti che elevano il contenimento al di sopra dell'intervallo di cold-start. Lo Stack D quindi sottopone a stress test la formula all'estremo superiore del prezzo abbinato all'estremo superiore del contenimento garantito; lo scenario di procurement in cui l'acquirente paga esplicitamente per una garanzia di contenimento.

Per i valori di contenimento negli stack A-C, abbiamo ancorato l'esempio applicato agli intervalli di completamento dei compiti riportati da τ-Voice ^[19]: 31–51% in condizioni pulite e 26–38% con rumore realistico. Abbiamo scelto un punto medio difendibile per ogni stack con giustificazione esplicita anziché i numeri pubblicati dai fornitori, perché il contenimento pubblicato dai fornitori è condizionato a carichi di lavoro che l'acquirente non controlla ^[20] e non è direttamente confrontabile tra fornitori. Retell ha ricevuto un contenimento di 0.45, vicino all'estremo superiore dell'intervallo pulito di τ-Voice, giustificato dal tuning della piattaforma verso i flussi di customer service più comuni. Vapi ha ricevuto 0.38, al confine tra gli intervalli pulito e rumoroso di τ-Voice, giustificato dal fatto che Vapi è uno strato di orchestrazione più sottile che trasferisce all'acquirente una maggiore responsabilità di tuning dello stack; in uno scenario di procurement a cold-start il contenimento effettivo è più vicino all'intervallo rumoroso. Self-hosted ha ricevuto 0.42, tra Retell e Vapi, giustificato dal fatto che i componenti best-of-breed offrono in media qualità ma l'assenza di tuning lato piattaforma deprime la cifra rispetto a uno stack gestito. Stack D ha ricevuto 0.55, giustificato dal team di tuning dedicato e dall'impegno SLA che il contratto a prezzo minimo di solito comporta.

Per il tempo medio di gestione abbiamo usato come riferimento i 4 minuti tipici del settore ^[3], e abbiamo eseguito la sensibilità a 2.5, 4 e 6 minuti per coprire l'arco realistico tra le semplici chiamate in stile FAQ e le chiamate di servizio più lunghe e multi-fase.

Per il costo di escalation abbiamo usato $7.40 per chiamata ^[8]. La cifra è una divulgazione di un fornitore ed è stata pubblicata come comparatore con l'operatore umano per lo stack AI che il fornitore vende; lo stesso articolo la tratta come il costo operativo per chiamata della gestione umana, che è il ruolo in cui la collochiamo. Abbiamo inoltre eseguito la griglia multivariata nel §4.4 su E ∈ {$5, $7.40, $10, $15} per coprire i mercati del lavoro dai contesti outsourced a basso costo fino ai settori regolamentati ad alto costo dove le escalation comportano penalità di trasferimento a freddo ^[10].

3.3 Il disegno dell'esempio applicato

Ci siamo impegnati in anticipo su cinque analisi prima di calcolare qualsiasi numero. Primo, la tabella dei quattro stack agli input di riferimento: T = 4, contenimento secondo il §3.2, E = 7.40. Secondo, il confronto di classifica tra gli ordinamenti al minuto e per risoluzione dei quattro stack. Terzo, un'analisi di sensibilità una variabile alla volta su Retell come stack di riferimento: contenimento a c ± 0.10, tempo di gestione a T × {0.625, 1.5} (cioè 2.5 e 6 minuti) e costo di escalation a 2E. Quarto, una sensibilità sul solo contenimento su Vapi per testare la robustezza dell'inversione di classifica; nello specifico, il contenimento al quale il costo per risoluzione di Vapi incrocia quello di Retell. Quinto, una griglia bidimensionale su variazione di contenimento Δc ∈ {−0.10, −0.05, 0, +0.05, +0.10} (applicata uniformemente al c di riferimento di ogni stack) e costo di escalation E ∈ {$5, $7.40, $10, $15}, riportando l'ordine di classifica in ciascuna cella. Ci siamo impegnati in anticipo a riportare qualsiasi inversione di classifica come risultato reale solo se sopravvive a una perturbazione di ±0.05 sul contenimento rilevante, perché un'inversione che scompare con un errore di ipotesi di mezzo punto percentuale non è robusta.

3.4 Cosa la metodologia non include

Abbiamo deliberatamente escluso quattro cose. Il costo di costruzione. Gli stack self-hosted comportano un capex di engineering che gli stack gestiti non hanno ^[17]; includerlo richiede una regola di ammortamento che dipende dal volume di chiamate e dalla durata del progetto, entrambi specifici dell'acquirente. Lo trattiamo come una fase separata della decisione di procurement e lo discutiamo qualitativamente nel §5. Soglie e minimi di licenza. Diverse quotazioni dei fornitori includono minimi mensili o licenze per postazione ^[16] che piegano la tariffa al minuto a basso volume. Abbiamo modellato il regime ad alto volume in cui questi sono ammortizzati. Chiamanti ricorrenti. Il contenimento può mascherare i pattern dei chiamanti ricorrenti ^[11]; il nostro c è il contenimento alla singola chiamata, non al netto delle ripetizioni. Risoluzione corretta per la qualità. Una chiamata risolta con basso CSAT è comunque una risoluzione nella formula; ponderare per la soddisfazione è un aggiustamento a valle che non abbiamo effettuato. Ciascuno di questi punti è citato di nuovo nel §6.

3.5 Riproducibilità

La formula e gli input sono completamente specificati sopra. Un lettore può rieseguire l'esempio applicato in un foglio di calcolo in meno di cinque minuti. Le quattro righe di input dei fornitori risalgono alle voci bibliografiche ^[14], ^[15], ^[16] e a una composizione approssimativa di componenti pubblici per lo Stack C; gli intervalli di contenimento risalgono a ^[19]; il costo di escalation risale a ^[8]. Non abbiamo condotto nuove misurazioni, e non ci sono seed casuali, specifiche hardware o protocolli di prova da divulgare. L'onere di riproducibilità di un articolo metodologico è la specifica della formula, che si trova nel §3.1, e la tabella esplicita degli input nel §4.1.

3.6 Perché un quarto stack conta

L'esempio applicato originario a tre stack copriva la forma del mercato pubblico; completamente gestito, gestito decomposto e self-hosted; ma si fermava prima del regime che i team di procurement incontrano più spesso nei settori regolamentati: il fornitore enterprise di voice-AI prezzato a un prezzo minimo con minimi garantiti. Lo Stack D colma quella lacuna. Testa la formula nel regime in cui il prezzo al minuto è più alto e anche il contenimento è più alto, perché il prezzo minimo finanzia il team di tuning dedicato che eleva il contenimento. Questo è lo scenario di procurement in cui un CFO sospetta più spesso di pagare troppo; la tariffa al minuto è da due a cinque volte le alternative più economiche, ma il fornitore sostiene che il prezzo è giustificato da un impegno di contenimento che le alternative più economiche non offrono. La formula è la regola decisionale che permette al CFO di verificare se l'argomentazione regga. Senza lo Stack D, l'esempio applicato copre solo il regime in cui un prezzo più alto si accompagna a un contenimento marginalmente più alto; con lo Stack D, l'esempio applicato copre il regime in cui un prezzo più alto si accompagna a un contenimento materialmente più alto, che è strutturalmente diverso. La Sezione 4.4 mostra il punto di incrocio: per ogni costo di escalation superiore a $8.80, lo Stack D batte Retell sul costo per risoluzione nonostante costi 1.6× di più al minuto; per ogni costo di escalation superiore a $6.34, lo Stack D batte Vapi nonostante costi 2.1× di più al minuto. La domanda di procurement smette di essere se il fornitore enterprise a prezzo minimo sia troppo caro e diventa se il costo di escalation dell'acquirente si collochi al di sopra o al di sotto del punto di incrocio.

4.1 Riferimento a quattro stack

La Tabella 1 riporta l'output della formula agli input di riferimento. La colonna più a destra è la cifra del costo per risoluzione che l'articolo sostiene dovrebbe sostituire il prezzo al minuto come dato principale del procurement.

Il costo per risoluzione variava da $5.29 a $7.15 nei quattro stack, un divario di circa il 35%. Il divario al minuto sugli stessi stack era del 376% (da $0.105 a $0.50). La scelta dell'unità comprime il divario apparente tra i fornitori di oltre 10×, il che è di per sé il segnale per il procurement: le differenze al minuto lusingano in modo drammatico finché non vengono convertite nell'unità che l'acquirente paga.

Il termine di escalation (1 − c) · E ha sostenuto la maggior parte della cifra del costo per risoluzione per ogni stack tranne lo Stack D; 60% per Retell, 64% per Vapi, 81% per il self-hosted e 48% per il livello enterprise. Questo è il risultato strutturale che motiva il §5: il costo per risoluzione è una metrica dominata dal costo di escalation per qualsiasi stack di agente vocale attuale con un contenimento inferiore a circa 0.5, e l'ordine di classifica è quindi determinato dal contenimento anziché dal prezzo al minuto. Lo Stack D è l'unico stack dell'esempio a scendere sotto il 50% di quota di escalation, e lo fa perché il suo contenimento garantito di 0.55 riduce la quota di chiamate che trascina il sovrapprezzo di escalation di $7.40 su ogni risoluzione.

4.2 Inversioni di classifica

La Tabella 2 contrappone la classifica al minuto alla classifica per risoluzione.

Al riferimento emergono due inversioni di classifica. La prima, tra Retell e Vapi, è l'inversione già presente nella versione a tre stack dell'analisi: il contenimento più alto di Retell (0.45 contro 0.38) riduce la quota di chiamate che incorrono nel costo di escalation di $7.40 quanto basta per superare il divario di prezzo di $0.067/min sui minuti-agente stessi. La seconda inversione, più marcata, è lo Stack D, che costa 1.6× Retell al minuto e 2.1× Vapi al minuto ma è più economico per risoluzione di Vapi di $0.18 (2.5%). Il meccanismo è lo stesso della prima inversione ma più pronunciato: il contenimento garantito di 0.55 dello Stack D riduce la quota di escalation del costo dal 64% (Vapi) al 48%, e il sovrapprezzo di escalation assoluto da $4.59 a $3.33. La riduzione del 17% del costo di escalation per chiamata fa ottenere all'acquirente uno stack che costa di più al minuto e di meno per risoluzione, che è strutturalmente l'argomentazione di procurement che fanno i fornitori enterprise di voice-AI.

Vapi scende dal secondo posto al minuto all'ultimo per risoluzione. Questo è il più grande errore di classifica che la formula identifica nell'esempio applicato, e quello in cui una decisione di procurement ancorata al minuto produrrebbe l'esito peggiore.

4.3 Sensibilità a una variabile

Ci siamo impegnati in anticipo a perturbare una variabile alla volta sul riferimento di Retell e a una perturbazione del solo contenimento su Vapi. La Tabella 3 riporta le quattro perturbazioni.

Dalla Tabella 3 emergono tre osservazioni. Primo, il contenimento ha mosso il costo per risoluzione di circa il 20% ogni 10 punti percentuali attorno al riferimento, un'elasticità vicina a 1:1 che recupera la regola empirica di SQM citata da ^[6]: un guadagno di un punto nella risoluzione alla prima chiamata produce un calo di un punto nel costo operativo. La nostra metodologia non era stata progettata per riprodurre questa regolarità, e il fatto che lo faccia è un segno che la regola di composizione non è patologica. Secondo, il costo di escalation è stato la variabile a maggiore impatto: raddoppiare E ha aumentato il costo per risoluzione di Retell del 60%, più di tre volte la variazione di un cambio di 10 punti nel contenimento. Terzo, l'inversione di classifica tra Retell e Vapi è sopravvissuta al controllo di robustezza pre-registrato. Una perturbazione al rialzo di 5 punti sul contenimento di Vapi (a 0.43) ha portato il suo costo per risoluzione a $6.48, al di sotto del riferimento di Retell di $6.83. L'inversione si capovolge se il contenimento reale di Vapi è mezzo punto sopra quello di Retell. Trattiamo l'inversione di classifica come un risultato reale sotto gli input che abbiamo usato, non come uno robusto rispetto a tutti gli input plausibili; che è il punto dell'articolo. La scelta dell'unità cambia la classifica, e la classifica è sensibile a una variabile che i fornitori non sottopongono a benchmark in modo coerente.

4.4 Sensibilità multivariata: una griglia (Δc, E)

La sensibilità a una variabile nel §4.3 tiene fisse tre variabili e muove la quarta. I team di procurement raramente affrontano quel quadro. Le decisioni di procurement reali fanno covariare contenimento e costo di escalation: un acquirente di fascia alta dei servizi finanziari affronta sia un costo di escalation più elevato (lavoro caricato, handoff regolamentato) sia un contenimento inferiore al riferimento (filtraggio PII, traffico multilingue). Un acquirente del retail affronta l'opposto (basso costo di escalation, alto contenimento). Per rendere la formula utile al livello del procurement, abbiamo eseguito una griglia bidimensionale su variazione di contenimento e costo di escalation, tenendo fisso il tempo di gestione a 4 minuti e il prezzo al minuto fisso al riferimento di ciascuno stack.

La variazione Δc è applicata uniformemente al c di riferimento di ogni stack dal §3.2; per esempio, a Δc = −0.05, il contenimento effettivo di Retell è 0.40, quello di Vapi è 0.33, quello del Self-hosted è 0.37 e quello dello Stack D è 0.50. Questo tratta Δc come un modificatore di dominio dell'acquirente; un riflesso di quanto il mix di chiamate dell'acquirente si discosti dal riferimento di τ-Voice, anziché una perturbazione di prestazione per stack. La Tabella 4 riporta l'ordine di classifica in ciascuna cella.

La griglia produce un risultato strutturale sorprendente: l'ordine di classifica è determinato quasi interamente da E, non da Δc. Leggendo lungo qualsiasi colonna, la classifica è identica a ogni variazione di contenimento. Leggendo lungo qualsiasi riga, la classifica si sposta man mano che il costo di escalation aumenta. I punti di incrocio sono netti:

• A E = $5 (lavoro outsourced a basso costo, traffico retail monolingue), il prezzo al minuto vince ancora. Lo Stack D, il più costoso al minuto, è il più costoso per risoluzione.
• A E = $7.40 (il riferimento da divulgazione pubblica ^[8]), lo Stack D passa alla posizione 3; battendo Vapi, il secondo più economico al minuto, nonostante costi 2.1× di più al minuto.
• A E ≥ $10 (settori regolamentati, lavoro enterprise caricato), lo Stack D passa alla posizione 2, battendo anche Retell. Il prezzo minimo enterprise è la seconda migliore scelta per risoluzione in ogni cella con E ≥ $10.

I punti di incrocio sono calcolabili direttamente dalla formula. Ponendo Cres(D) = Cres(Retell) e risolvendo: E = (pD · T / cD − pR · T / cR) / (cD − cR) = ($3.636 − $2.756) / 0.10 = $8.80. Al di sotto di E = $8.80, Retell è più economico per risoluzione; al di sopra, lo Stack D è più economico. La stessa algebra colloca il punto di incrocio tra lo Stack D e Vapi a E = $6.34, motivo per cui lo Stack D batte già Vapi al riferimento divulgato di $7.40. Queste soglie di incrocio sono i numeri operativi che un team di procurement dovrebbe calcolare rispetto al proprio costo di escalation caricato, perché riducono il confronto a quattro stack a una regola decisionale in una sola riga.

La robustezza della classifica rispetto alle perturbazioni di Δc riflette una caratteristica strutturale della formula: l'ordine di classifica è determinato dal divario di contenimento tra gli stack, non dal livello assoluto. Spostare il contenimento di ogni stack della stessa quantità preserva il divario, quindi la classifica non cambia. Questo è un risultato significativo per il procurement perché il divario tra gli stack (l'impegno di contenimento dello Stack D meno il contenimento a cold-start degli stack più economici) è la variabile che un fornitore controlla, mentre il livello assoluto è una funzione del mix di chiamate dell'acquirente, che il fornitore non controlla. La formula isola il segnale rilevante per il procurement dal rumore specifico dell'acquirente.

Il risultato che ci ha sorpreso nell'esempio applicato originario a tre stack non era l'inversione di classifica in sé ma quanto fosse esiguo il margine. La versione a quattro stack rende la sorpresa più netta. Lo Stack D, il più costoso al minuto, è il secondo più economico per risoluzione al costo di escalation di riferimento divulgato e il secondo più economico per risoluzione a ogni costo di escalation più alto. L'argomentazione di procurement che fanno i fornitori enterprise di voice-AI; che il prezzo minimo compri un impegno di contenimento che si ripaga da sé ad alto costo di escalation; è, in questo esercizio, strutturalmente corretta. La formula fornisce al team di procurement la soglia oltre la quale l'argomentazione diventa corretta (E ≥ $8.80 contro Retell, E ≥ $6.34 contro Vapi), che è la conversazione che il team di procurement deve avere con il fornitore.

Il risultato strutturale, cioè che il termine di escalation (1 − c) · E domina il costo per risoluzione per qualsiasi stack con contenimento inferiore a circa 0.5, non è nuovo per la letteratura sui contact center ^{[2, 6]} ma è largamente assente dalla letteratura dei fornitori di agenti vocali. Il contenimento domina perché ogni chiamata irrisolta trascina sul registro dell'AI il costo intero di una chiamata gestita da umano, e le chiamate gestite da umano sono di un ordine di grandezza più costose di quelle gestite dall'AI ^[8]. Questo è il motivo per cui l'obiettivo di prontezza alla produzione del contenimento >70% di Sharma ^[12] ha la forma giusta, anche se la soglia specifica è una convenzione anziché una derivazione. Al di sotto del 70%, l'agente AI si ripaga da sé ma lascia comunque la maggior parte del costo operativo sul lato umano; al di sopra del 70%, la sostituzione inizia a dominare. Lo Stack D nel nostro esempio applicato si colloca a 0.55, motivo per cui la sua quota di escalation è la più bassa nella Tabella 1 (48%) eppure rappresenta comunque quasi metà del costo totale.

Riteniamo che i fornitori non quotino in unità di risoluzione per due ragioni. La prima è meccanica: il contenimento non è una proprietà del solo stack del fornitore; dipende dal mix di chiamate dell'acquirente, dalla copertura linguistica e dallo sforzo di tuning, tutti elementi su cui il fornitore non può impegnarsi in anticipo. Quotare in unità di risoluzione costringerebbe i fornitori ad assumersi un rischio di carico di lavoro che attualmente non prezzano. Il mercato dell'outsourcing a pagamento per risoluzione in ^[5] è la prova di esistenza del fatto che un fornitore può assumersi un rischio di carico di lavoro se il modello di pricing è progettato per questo; i fornitori di voice-AI non hanno ancora costruito quel modello di pricing. La seconda è commerciale: il pricing al minuto drammatizza il margine tra i fornitori. Retell a $0.31 contro Vapi a $0.243 sembra una differenza significativa; $6.83 contro $7.15 sembra rumore. Lo Stack D a $0.50/min contro Retell a $0.31/min sembra un sovrapprezzo del 60%; $6.97 contro $6.83 è un sovrapprezzo del 2%. I fornitori che quotano al minuto mantengono la conversazione di procurement in un divario che li lusinga. La traduzione in unità di risoluzione riporta la conversazione al divario che l'acquirente effettivamente paga.

Cosa dovrebbero fare diversamente i team di procurement dopo aver letto questo articolo? Tre cose, in ordine. Primo, chiedere a ogni fornitore di agenti vocali un impegno di contenimento, o almeno il contenimento che ha osservato su carichi di lavoro simili al vostro, con il carico di lavoro definito in modo abbastanza preciso da poter falsificare il numero. Il mercato dell'outsourcing a pagamento per risoluzione documentato in ^[5] dimostra che questa conversazione è possibile. Secondo, eseguire la formula del §3.1 rispetto al vostro tempo di gestione e al vostro costo di escalation caricato anziché alle cifre di questo articolo. Entrambi sono fatti lato acquirente e di solito sono disponibili dal log storico delle chiamate. Terzo, calcolare le soglie di incrocio nella forma del §4.4: a quale costo di escalation ciascuna coppia di stack pareggia sul costo per risoluzione? La soglia di incrocio riduce un confronto a quattro stack a una regola decisionale in una sola riga rispetto al costo del lavoro dell'acquirente. Il calcolatore per agenti vocali su /resources/tools/voice-agent-cost-calculator espone questa composizione per i numeri lato acquirente che un team di procurement ha più probabilmente a portata di mano.

Una nota sugli stack self-hosted. Lo Stack C ha prodotto il costo per risoluzione più basso nel nostro riferimento, ma la metodologia ha deliberatamente escluso il costo di costruzione. Gli stack self-hosted comportano un capex di engineering che l'analisi TCO di Dograh prezza a $150/ora ^[17] e che gli autori notano rientra in pochi mesi ad alto volume ma non a basso volume. Il modo corretto di incorporare il costo di costruzione è come ammortamento per risoluzione sulla durata del progetto, (costo_di_costruzione) / (risoluzioni_totali_attese), aggiunto a Cres. Lo abbiamo lasciato come aggiustamento di seconda fase perché è specifico dell'acquirente e il contributo dell'articolo è la regola di composizione del costo variabile. Un acquirente a 1.000 minuti mensili concluderà diversamente da un acquirente a 100.000 minuti mensili, ed entrambe le conclusioni dovrebbero discendere dalla stessa regola di composizione applicata con il volume di ciascun acquirente.

5.1 Quando la formula si rompe

La formula compone quattro input in un unico numero e produce classifiche pulite in un'ampia gamma di input plausibili. Ci sono tre regimi in cui produce numeri fuorvianti, e un team di procurement dovrebbe riconoscerli prima di applicare la regola.

Contenimento estremamente alto (c ≥ 0.85). Man mano che c si avvicina a 1, il termine di escalation (1 − c) · E si avvicina a zero e il termine di costo AI (p · T) / c si avvicina a p · T. Il costo per risoluzione converge sulla spesa al minuto di una chiamata contenuta. In questo regime, la formula si riduce al prezzo al minuto scalato per il tempo di gestione, e l'ordine di classifica coincide con la classifica al minuto. Questo è coerente con l'intuizione; una volta che l'AI gestisce essenzialmente ogni chiamata senza escalation, la decisione di procurement riguarda il costo dei minuti-agente e nient'altro; ma significa che la formula perde il suo potere discriminante proprio nel regime che la letteratura dei fornitori ^[12] dichiara pronto alla produzione. Un acquirente che confronta due stack entrambi impegnati a un contenimento del 90%+ non dovrebbe aspettarsi che la formula identifichi un vincitore strutturale; la differenza a quel livello è dominata dal prezzo al minuto e dall'aggiustamento per il costo di costruzione che il §5 lascia come considerazione di seconda fase.

Contenimento estremamente basso (c ≤ 0.20). Man mano che c si avvicina a zero, il termine di costo AI (p · T) / c esplode e il termine di escalation si avvicina a E. Il costo per risoluzione diventa patologico perché quasi ogni chiamata effettua l'escalation e l'AI viene pagata per minuti che non ha contenuto. Questo regime è degenere per qualsiasi stack di produzione; un acquirente non effettuerebbe il deployment al 20% di contenimento in produzione; ma compare nella valutazione pre-tuning, quando un acquirente sottopone a benchmark un fornitore sul traffico a cold-start prima che sia stato fatto il lavoro di tuning dedicato. Una misurazione pre-tuning di c = 0.15 produce una cifra Cres che sovrastima drammaticamente il costo, perché la maggior parte del costo è il termine dei minuti-agente diviso per un piccolo denominatore. Un team di procurement che esegue la formula su dati pilota dovrebbe correggere per questo riportando la cifra del costo per risoluzione accanto alla traiettoria del contenimento, non come un singolo numero.

Chiamate di follow-up al di fuori del contenimento alla singola chiamata. La formula tratta la chiamata gestita da umano come l'evento terminale in una traiettoria irrisolta. In pratica, una chiamata in escalation può a sua volta produrre contatti di follow-up entro la finestra di risoluzione, e una chiamata contenuta può produrre contatti di follow-up se la risoluzione dell'AI non ha effettivamente risolto il problema sottostante. Belfiore ^[2] usa un fattore 1.5× per convertire le chiamate irrisolte in costo di follow-up, e PolyAI ^[11] avverte specificamente che il contenimento può mascherare i chiamanti ricorrenti. La E della formula dovrebbe essere letta come il costo caricato dell'intera traiettoria in escalation, non solo della prima chiamata gestita da umano; un acquirente che usa un proxy basato solo sul costo del lavoro per E sottostimerà il sovrapprezzo di escalation del 30–50%. La derivazione tramite Erlang C nell'Appendice A lo rende esplicito: l'equivalente in costo del personale che produce la nostra cifra di riferimento di $7.40 include già il fattore 1.5× per il volume di follow-up.

Una quarta modalità di fallimento meno comune merita di essere segnalata: quando il modello di pricing dell'acquirente include minimi di piattaforma o licenze per postazione che piegano la tariffa al minuto a basso volume ^[16]. La nostra formula modella il regime ad alto volume in cui questi sono ammortizzati; a basso volume, la tariffa al minuto effettiva è più alta di quella pubblicata e l'ordine di classifica può spostarsi. Un acquirente con meno di 1.000 minuti mensili dovrebbe eseguire la formula rispetto alla tariffa al minuto effettiva dell'acquirente (spesa mensile totale divisa per i minuti), non rispetto al dato di copertina al minuto del fornitore.

La metodologia è una regola di composizione, e una regola di composizione è onesta solo quanto gli input che compone. Citiamo le cose specifiche che questo articolo non può concludere.

I prezzi dei fornitori sono prezzi di listino, non tariffe negoziate. Retell a $0.31, la decomposizione in stile Vapi a $0.243 e il prezzo minimo dello Stack D a $0.50 sono le tariffe che un acquirente pagherebbe in self-service o come prezzo minimo pubblicato; il procurement enterprise produce regolarmente sconti del 30–50% sulle fasce di volume superiori a 100.000 minuti mensili, e non avevamo accesso a quotazioni negoziate. L'ordine di classifica nella Tabella 2 potrebbe spostarsi con un pricing enterprise realistico.

Il prezzo al minuto dello Stack D è l'input a minore affidabilità nell'esempio applicato. Il pricing della voice-AI enterprise è genuinamente opaco: prezzi minimi, pacchetti di servizi professionali, sconti per spesa garantita e commissioni di piattaforma si combinano in un equivalente al minuto che il fornitore raramente pubblica. I nostri $0.50/min provengono dalla tariffa di voice-AI pubblicata da CloudTalk ^[16] e sono corroborati dal limite superiore del confronto tra fornitori di Retell ^[14], ma un acquirente che firma un contratto di classe Stack D negozierà rispetto alla quotazione effettiva del fornitore, non rispetto a un prezzo minimo pubblicato. L'inversione di classifica che riportiamo a E ≥ $8.80 (lo Stack D che batte Retell) è robusta a una perturbazione del ±15% sulla tariffa al minuto dello Stack D, ma un acquirente dovrebbe rieseguire la griglia del §4.4 rispetto alla tariffa negoziata prima di trarre una conclusione di procurement.

I valori di contenimento sono proxy da benchmark, non misurazioni del dominio dell'acquirente. τ-Voice ^[19] riporta il completamento dei compiti su compiti ancorati al retail e alle compagnie aeree, che è più vicino a un riferimento pre-tuning che al contenimento post-tuning che un acquirente reale sperimenta dopo tre-sei mesi di iterazione. Un acquirente con un caso d'uso pulito e ben delimitato può superare i nostri input di 10-20 punti; un acquirente con traffico multilingue, rumoroso o ricco di PII può collocarsi al di sotto. Il contenimento di 0.55 dello Stack D è il più lontano dall'ancora di τ-Voice ed è l'input più esposto al bias delle dichiarazioni dei fornitori; un team di procurement dovrebbe richiedere al fornitore di quotare un impegno di contenimento rispetto a un carico di lavoro definito anziché accettare la cifra del prezzo minimo sulla fiducia.

Il costo di escalation è una divulgazione su un singolo dato. $7.40/chiamata proviene dal confronto pubblicato di un solo fornitore ^[8] ed è calibrato su uno specifico mix di chiamate e uno specifico mercato del lavoro. Gli $8.00 di Belfiore ^[2] si collocano entro l'8% da esso, il che è una qualche triangolazione, ma nessuno dei due è una meta-analisi. Un acquirente in un mercato dove il lavoro caricato di customer service è la metà o il doppio dell'intervallo divulgato calcolerebbe numeri di costo per risoluzione diversi, e l'ordine di classifica nella Tabella 2 è sensibile a questo. La griglia del §4.4 copre l'intervallo realistico $5–$15.

Il prezzo al minuto dello Stack C è una composizione approssimativa. Il costo variabile self-hosted dipende dalla fascia di volume di Deepgram, dal fatto che ElevenLabs Flash sia impegnato su base mensile o pagato a consumo, dalla tariffa regionale di Twilio e dal mix di token di input/output di Claude Haiku per chiamata. Abbiamo composto tariffe plausibili di fascia media; un acquirente attento sostituirebbe i nostri $0.105 con la propria cifra basata su quotazione prima di trarre una conclusione di procurement.

La griglia multivariata del §4.4 è un campione 5×4 di una superficie continua. Una griglia più fine o un grafico di contorno rivelerebbe le soglie di incrocio in modo più preciso; riportiamo le soglie di incrocio analitiche nel §4.4 come numeri operativi e trattiamo la griglia discreta come un'illustrazione della stabilità di classifica nei diversi contesti di dominio dell'acquirente. La griglia non fa variare il tempo di gestione né il prezzo al minuto, entrambi i quali sposterebbero i punti di incrocio.

La formula non accredita la deflessione a monte. Le chiamate deflesse dall'IVR o dal self-service prima di raggiungere l'agente vocale non entrano mai nel denominatore. Uno stack che si integra bene con l'IVR esistente dell'acquirente può mostrare un costo per risoluzione peggiore pur riducendo il costo operativo totale. La metrica è un confronto interno all'agente vocale, non un conto economico del contact center.

Il contenimento è una definizione alla singola chiamata. Abbiamo usato il contenimento come rapporto tra le chiamate che l'AI ha risolto senza escalation su una singola chiamata. PolyAI ^[11] nota che questo può mascherare i pattern dei chiamanti ricorrenti in cui lo stesso problema riemerge entro sette giorni. Un contenimento al netto delle ripetizioni abbasserebbe ogni valore nella Tabella 1; non lo abbiamo modellato.

La risoluzione non è ponderata per la qualità. Una risoluzione che produce un basso CSAT è conteggiata come una risoluzione. La letteratura sulle metriche di risoluzione ponderate per la qualità ^{[4, 7]} supporta un aggiustamento a valle, e un acquirente con una soglia rigida di CSAT vorrebbe applicarne uno.

L'esempio applicato è di quattro stack. Quattro stack coprono la forma del mercato pubblico (completamente gestito, gestito decomposto, self-hosted, prezzo minimo enterprise) ma non sono esaustivi. Una soluzione costruita internamente presso una grande banca, un fornitore verticale specializzato nella sanità o un BPO offshore a basso costo con operatori potenziati dall'AI sposterebbero ciascuno il quadro; non avevamo divulgazioni di prezzo pubbliche per quei casi.

Abbiamo definito una formula in forma chiusa per il costo per risoluzione degli agenti vocali, l'abbiamo applicata a quattro stack pubblici reali agli input di riferimento tratti dalle pagine di pricing dei fornitori e da un benchmark pubblico, e abbiamo riportato due inversioni di classifica in cui gli ordinamenti al minuto e per risoluzione di quegli stack divergevano. Le cifre del costo per risoluzione variavano da $5.29 a $7.15; un divario del 35% su stack le cui tariffe al minuto coprivano il 376%. Una griglia di sensibilità bidimensionale ha mostrato che l'ordine di classifica è determinato dal costo di escalation, non dalla variazione di contenimento; le soglie di incrocio analitiche (lo Stack D batte Retell a E ≥ $8.80, batte Vapi a E ≥ $6.34) riducono il confronto a quattro stack a una regola decisionale in una sola riga rispetto al costo del lavoro dell'acquirente. Il contenimento ha dominato la metrica e ha recuperato la regola 1:1 dei call center tra guadagni di risoluzione alla prima chiamata e riduzioni del costo operativo, e l'Appendice A mostra che il termine di escalation della formula si riconduce al modello standard di dimensionamento Erlang C della letteratura sulla gestione delle operations. La regola di composizione è il contributo. I team di procurement che valutano i fornitori di agenti vocali sull'unità che i fornitori quotano stanno ottimizzando il numero sbagliato; la formula del §3.1 fornisce loro l'unità in cui effettivamente pagano.

Il costo di escalation E nel §3.1 è il costo per chiamata della gestione umana. Abbiamo adottato $7.40 da una divulgazione pubblica di un fornitore ^[8] e abbiamo notato che gli $8.00 di Belfiore ^[2] si collocano entro l'8% da esso. Questa appendice mostra che la cifra divulgata è coerente con il modello di dimensionamento Erlang C usato nel software di workforce management ^{[1, 26]}, ancorando il braccio di escalation della formula alla tradizione della gestione delle operations.

A.1 Dimensionamento Erlang C

In un contact center servito da personale umano, il modello Erlang C fornisce la probabilità che una chiamata in arrivo si metta in coda anziché essere risposta immediatamente, in funzione del tasso di arrivo λ (chiamate all'ora), del tempo medio di gestione Th (ore per chiamata) e del numero di operatori N ^[1]. La decisione di dimensionamento è il più piccolo N tale che la probabilità di coda scenda al di sotto di una soglia obiettivo di livello di servizio (tipicamente P(attesa > 20s) ≤ 0.20).

Per un call center che opera a un'occupazione ρ = λ · Th / N, il costo del lavoro caricato per chiamata servita è

Cper_call = (Wloaded · Th) / ρ

dove Wloaded è il salario orario caricato di un operatore (stipendio base più benefit, overhead di supervisione, strutture e strumenti, tipicamente 1.4–1.6× la base ^[1]). Th è il tempo medio di gestione incluso il lavoro post-chiamata. L'occupazione ρ raramente supera 0.85 nella pratica perché un'occupazione più alta degrada il livello di servizio ^[26].

Esempio applicato. Con Wloaded = $52.50/ora (tariffa caricata statunitense rappresentativa per il customer service in entrata, metà anni 2020), Th = 4 minuti = 1/15 ora e ρ = 0.85:

Cper_call = ($52.50 · (1/15)) / 0.85 = $3.50 / 0.85 = $4.12 per chiamata servita

A.2 Aggiunta del fattore di follow-up

Belfiore ^[2] riporta che le chiamate irrisolte producono in media 1.5 contatti di follow-up nella finestra di risoluzione. Ogni contatto di follow-up comporta lo stesso Cper_call più il costo di esperienza cliente del rilavoro. Trattando i follow-up come un'aggiunta di 1.5× del costo per chiamata; la lettura conservativa di Belfiore; il costo caricato di una traiettoria in escalation diventa

E = Cper_call · (1 + f) = $4.12 · 1.5 = $6.18

dove f = 0.5 è il moltiplicatore frazionario di follow-up sulla chiamata iniziale gestita da umano (0.5 perché una chiamata iniziale più 0.5 di follow-up attesi equivale agli 1.5 contatti che Belfiore documenta). La cifra di $6.18 è circa il 17% al di sotto del riferimento di $7.40 divulgato da ^[8]. Aggiungendo il 15–20% per la penalità di trasferimento a freddo ^[10]; il costo della perdita di contesto quando la chiamata passa dall'AI all'umano; si colma il divario rispetto alla cifra divulgata entro l'arrotondamento.

I $7.40 divulgati da ^[8] corrispondono quindi a un costo del lavoro caricato nell'intervallo $50–60/ora, a un'occupazione vicina al soffitto standard di 0.85 e a un fattore di follow-up nell'intervallo di Belfiore. Ciascuno di questi input è pubblicato in modo indipendente, e la cifra divulgata è coerente con tutti e tre.

A.3 Il credito di sostituzione

Quando un agente AI contiene una frazione c delle chiamate in entrata, il fabbisogno di personale lato umano cala in proporzione. Con un tasso di arrivo λ di chiamate totali all'ora, il tasso di arrivo lato umano diventa (1 − c) · λ, e il fabbisogno di personale Erlang C scala approssimativamente in modo lineare con il tasso di arrivo a livello di servizio fisso, quindi il costo del personale lato umano per chiamata in entrata cala da Cper_call a (1 − c) · Cper_call. Includendo il fattore di follow-up, il costo lato umano per chiamata in entrata è (1 − c) · E, che è esattamente il secondo termine della formula del §3.1.

Il primo termine (p · T) / c è il costo lato AI caricato su ogni chiamata risolta: l'acquirente paga p · T in minuti-agente per chiamata in entrata, e le risoluzioni dell'acquirente sono c per chiamata in entrata, quindi ogni risoluzione porta con sé (p · T) / c di spesa in minuti-agente.

Sommando i due termini si ottiene il costo per risoluzione di una chiamata in entrata elaborata end-to-end: la spesa lato AI per risoluzione più il costo lato umano atteso per chiamata in entrata. Questa è la formula. Il suo braccio di escalation non è un proxy ad hoc ma una riduzione del costo di dimensionamento Erlang C sotto sostituzione proporzionale, che è l'assunzione di linearità documentata dal riferimento SWPP ^[26] e passata in rassegna da Akşin et al. ^[1].

A.4 Dove l'assunzione di linearità si rompe

Vale la pena segnalare due regimi. Primo, il dimensionamento Erlang C è non lineare vicino alla soglia di livello di servizio: un piccolo calo del tasso di arrivo può non ridurre il personale necessario nella stessa proporzione, perché la soglia opera sul numero intero di operatori. Nei contact center piccoli (meno di ~30 operatori), il credito di sostituzione è sovrastimato dalla regola proporzionale; il risparmio reale è a gradini. Secondo, l'assunzione di linearità richiede che le chiamate contenute dall'AI e le chiamate gestite da umano abbiano distribuzioni di tempo di gestione simili. Se l'AI contiene prevalentemente chiamate facili (tempo di gestione breve) ed effettua l'escalation prevalentemente di chiamate difficili (tempo di gestione lungo); un pattern comune, dato che gli agenti AI faticano sulla coda difficile; allora il tempo di gestione lato umano sulle chiamate in escalation è più lungo della media Th, e il costo lato umano per chiamata in entrata è più alto di (1 − c) · E. Un team di procurement in un dominio dove il tempo di gestione delle chiamate contenute dall'AI è chiaramente più breve della media complessiva dell'operazione dovrebbe trattare E come un limite inferiore e considerare un moltiplicatore esplicito del tempo di gestione sulle escalation. La limitazione del §6 sulla risoluzione corretta per la qualità cattura la stessa preoccupazione da un'angolazione diversa.