30 domande prima di acquistare l'AI vocale

In breve: date a ogni fornitore lo stesso test

Le demo di AI vocale non sono confrontabili. Ogni fornitore sceglie il proprio copione, i propri dati di test puliti e un cliente di prova che si comporta bene. Spesso vince la demo più curata, anche quando non è adatta alle vostre chiamate.

Il rimedio ha tre parti. Mandate a ogni fornitore le stesse domande per iscritto, sottoponete tutti allo stesso scenario di test preso dalla vostra linea e valutate le risposte con pesi concordati prima della prima demo. Questo modello vi dà tutte e tre le cose. Presuppone che abbiate già deciso di acquistare; se non è così, partite dal nostro schema per scegliere tra sviluppo interno e acquisto.

Come dare un punteggio a ogni risposta

Mandate le 30 domande prima del secondo incontro e chiedete una prova per ogni risposta: un documento, un record di esempio, una clausola del contratto o una dimostrazione dal vivo. Fate valutare le risposte a due persone, ciascuna per conto suo, una delle operations e una degli acquisti o dell'IT, e discutete ogni domanda su cui i loro punteggi differiscono di due punti o più.

1. Perimetro e cosa include il prezzo

Due offerte sono confrontabili solo quando coprono lo stesso lavoro. Queste domande trasformano un prezzo in un perimetro.

2. Proprietà dei dati, privacy e uscita

Ogni chiamata produce registrazioni, trascrizioni e campi sui vostri clienti. Chiarite chi li controlla prima del progetto pilota, non al rinnovo. Chiedete controlli testati, non solo dichiarati. La pagina sugli standard di sicurezza di DRING mostra un modo per presentarli.

3. Collegamenti ai sistemi e scrittura dei risultati

Un logo nella pagina delle integrazioni dice che un collegamento è possibile, non quali campi l'agente può leggere o modificare nella vostra versione. Chiedete una mappa dei campi, poi verificatela nello scenario.

4. Passaggio a un operatore e controllo

Il passaggio a un operatore fa parte della progettazione, non è un fallimento. Verificate che il vostro collega possa proseguire senza che il cliente debba ricominciare da capo, e che il vostro team possa fermare l'agente.

5. Test di qualità e rilascio

Una buona prima demo dice poco sulla centesima modifica. Chiedete come il fornitore dimostra che un agente è pronto e che una modifica non ha rotto nulla. DRING descrive passo per passo il suo processo di test: chiedete a ogni fornitore di illustrarvi il proprio.

6. Telefonia, livelli di servizio e guasti

Una demo nel browser salta l'operatore telefonico, l'audio del telefono e il centralino che usate già. Trattate il livello di telefonia come una parte a sé del confronto.

Costruite uno scenario di test a partire dalle vostre chiamate

Le domande mostrano cosa dice un fornitore; lo scenario mostra cosa fa l'agente. Partite da un campione di chiamate recenti, per esempio le ultime 50, e scegliete la richiesta più comune e i momenti che creano problemi. Create record di test in una sandbox del CRM o dell'helpdesk, con gli stessi campi della produzione.

Condividete la traccia con tutti i fornitori nello stesso momento: intenti, sistemi e record di test. Le battute esatte di chi chiama tenetele per voi, così nessun fornitore può adattare l'agente a un copione.

Fate la prova su una vera linea telefonica

• Chiamate un numero reale da un cellulare, non da una scheda del browser, con una persona del vostro team nel ruolo del cliente.
• Registrate la sessione con il consenso e valutatela sulla registrazione, non a memoria.
• Contate quante volte chi chiama ha dovuto ripetere qualcosa, e cronometrate la pausa prima di ogni risposta dell'agente.
• Dopo il primo giro chiedete una modifica, per esempio una nuova regola, e ripetete lo scenario.

Il modo in cui il fornitore testa e rilascia quell'unica modifica risponde alla domanda 23 meglio di qualunque slide. Lo scenario fornisce anche le prove per un 3 alle domande 12, 17, 18 e 28.

Sommate i punteggi con gli stessi pesi

Concordate i pesi prima della prima demo, così nessuno li aggiusta per favorire il proprio preferito. La ripartizione qui sotto è un esempio: spostate punti verso le aree in cui un errore farebbe più danni alla vostra operatività.

Punteggio dell'area = (punti nell'area / 15) × peso dell'area. Quindici è il massimo per area: cinque domande da 3 punti ciascuna. I sei punteggi di area sommati danno un totale su 100.

Prima di assegnare i punteggi, segnate da tre a cinque domande vincolanti, per esempio la 6, la 13 e la 17. Un fornitore che prende 0 o 1 su una qualsiasi domanda vincolante è escluso, qualunque sia il suo totale.

Un esempio svolto

I punteggi qui sotto sono inventati per mostrare il calcolo. Il fornitore A ha fatto la demo più fluida; il fornitore B sembrava meno brillante, ma nello scenario ha mostrato la scrittura dei risultati e il suo processo di test.

Il fornitore A ha preso anche 1 alla domanda 13, che è vincolante, quindi è escluso qualunque sia il suo totale. La sua demo era forte sulla conversazione e debole su ciò che viene dopo: il record, il percorso in caso di errore e la release successiva.

Campanelli d'allarme nelle risposte

• «Ci integriamo con tutto», senza una mappa a livello di campo per i vostri sistemi.
• Nessuna risposta a «cosa sente chi chiama quando il vostro sistema è fuori uso?»
• Il passaggio a un operatore si riduce a inoltrare la chiamata a un numero, senza contesto per il vostro collega.
• Risultati dei test riportati come un'unica percentuale complessiva, senza metodo né dimensione del campione.
• Modifiche o aggiornamenti del modello che vanno in produzione senza la vostra approvazione o senza preavviso.
• Condizioni di uscita secondo cui i dati «possono essere resi disponibili», senza formato né scadenza.

Un campanello d'allarme è un motivo per chiedere di nuovo, per iscritto. Se ne suonano diversi nella stessa area, vi mostrano dove il lavoro vero finirebbe sulle spalle del vostro team.

Come risponde DRING a queste domande

Usate lo stesso modello anche con DRING. Alcune risposte possiamo già darle per iscritto:

• Domanda 21: ogni agente DRING affronta da 1.000 a 10.000 conversazioni simulate, costruite per la vostra azienda, prima della prima chiamata reale. Sono generate a partire dal vostro processo, dai vostri documenti e dalle vostre registrazioni, non da un set di benchmark generico.
• Domande 11 e 12: HubSpot è l'implementazione di riferimento documentata per scegliere chi chiamare, eseguire la chiamata e riportare il risultato nel CRM. Connect collega Salesforce, Freshdesk e gli altri CRM e helpdesk più diffusi alle stesse condizioni; il dettaglio di oggetti, permessi, campi personalizzati e azioni si conferma in fase di onboarding. Si possono definire campi di analisi aggiuntivi, che tornano allo stesso modo tramite API, CRM, dashboard e report.
• Domanda 14: i servizi per avviare una chiamata, controllarne lo stato e interrogarne il risultato, più i webhook sul ciclo di vita e sui risultati, sono standard per il processo concordato.
• Domande 1 e 27: DRING consiglia il pacchetto in base a utilizzo previsto, capacità di chiamate simultanee, numero di tipi di agente, canali, necessità di trasferimento in linea, livello di assistenza e profondità delle integrazioni. Sulle lingue: 62 lingue disponibili, 10 già in produzione; la vostra viene validata prima del lancio.

Dove DRING può partire con un punteggio più basso: un CRM di nicchia o molto personalizzato viene valutato a parte prima di mettere a preventivo qualsiasi sviluppo non standard. Finché quella valutazione non è fatta, la domanda 11 può restare a 2. Una lingua fuori dall'insieme già in produzione va considerata non dimostrata per la vostra linea, finché il vostro scenario non è stato eseguito in quella lingua.

Tenete la griglia anche dopo la firma

Le risposte che hanno ottenuto un 3 diventano i criteri di accettazione del progetto pilota. Lo scenario in sei momenti diventa il primo test di regressione, così ogni modifica successiva si verifica sulle chiamate che hanno deciso l'acquisto.