Sviluppo su misura, non connettori a catalogo
Il centralino sa chi chiama. Il gestionale anche. Non se lo dicono
Scriviamo il livello di mezzo che manca: un middleware che interroga i vostri sistemi mentre la chiamata è ancora in IVR, e decide dove mandarla e cosa mostrare a chi risponde.
-
Squilla il centralino
Arriva una chiamata. Per ora è soltanto un numero: nessuno sa ancora chi stia chiamando, né perché.
-
Il middleware parte a cercare
Mentre il chiamante ascolta il messaggio di benvenuto, il livello di mezzo prende quel numero e interroga i vostri sistemi.
-
Il gestionale risponde
Chi è, quale pratica ha aperta, chi la segue. Due secondi al massimo: oltre quella soglia la chiamata prosegue comunque, senza dati.
-
Se il cliente parla un'altra lingua
Il chiamante ha scelto la lingua da un menu vocale e la conversazione viene tradotta mentre avviene, in entrambe le direzioni: voce, non sottotitoli, con circa un secondo di scarto per frase.
-
Arriva alla persona giusta
All'interno di chi segue quella pratica, non alla coda generale. E la scheda del cliente è già aperta sul monitor prima che sollevi la cornetta.
-
Il supervisore guarda
La coda si aggiorna ogni cinque secondi su un wallboard, con avviso visivo quando una coda va sotto stress.
-
L'operatore classifica
A chiusura, il motivo del contatto viene registrato in pochi passaggi guidati: serve a sapere non quante chiamate arrivano, ma di cosa parlano.
-
La registrazione va in archivio
Ricercabile per data, operatore, coda, direzione e durata, con accessi distinti per ruolo e registro di chi ha ascoltato cosa.
-
E se non rispondesse nessuno?
La chiamata persa entra in lista e il richiamo parte da solo, ma soltanto quando un operatore è connesso, in coda e davvero disponibile.
1 di 9
Tutto questo accade nei secondi in cui il telefono squilla. Se un sistema non risponde in tempo, la chiamata prosegue comunque sul percorso ordinario: l'integrazione aggiunge intelligenza, non introduce un punto di rottura.
Cosa deve poter fare il vostro gestionale
È la prima cosa che verifichiamo, perché determina se il progetto è fattibile e quanto costa. Ve lo diciamo prima di preventivare, non dopo.
-
Un modo per interrogarlo dall'esterno
Nell'ordine di preferenza: API REST documentate, un web service anche datato, un accesso in sola lettura al database. Una di queste tre basta. Se non c'è nessuna, l'integrazione va costruita in altro modo e il discorso cambia.
-
Tempi di risposta compatibili con una telefonata
La query deve rientrare entro un paio di secondi, perché avviene mentre il chiamante ascolta il messaggio di benvenuto. Quando il sistema è più lento lavoriamo con una cache locale delle anagrafiche, aggiornata a intervalli.
-
I numeri di telefono scritti in modo trattabile
È il punto che fa fallire più integrazioni di quanto si creda. Anagrafiche con numeri in dieci formati diversi, spazi, prefissi internazionali a volte sì e a volte no. Prima di collegare qualsiasi cosa serve una normalizzazione, e spesso una bonifica.
-
Un legame chiaro fra pratica e persona
Per instradare la chiamata a chi segue davvero il cliente serve che quel legame esista a sistema e sia aggiornato. Se la pratica non ha un titolare, nessun software può inventarlo: si torna alla coda, e va benissimo, ma è meglio saperlo prima.
-
Un posto dove scrivere l'esito
L'integrazione ha senso se è a doppio senso: la telefonata deve tornare nel gestionale come attività, con durata, esito e note. Serve quindi anche un'API o una tabella in scrittura, non solo in lettura.
Non partiamo da zero ogni volta
Le integrazioni CTI hanno una parte specifica del cliente e una parte che si ripete in ogni progetto: raccogliere le chiamate perse e richiamarle, mostrare a un supervisore cosa sta succedendo nelle code, archiviare le registrazioni, far classificare all'operatore il motivo del contatto.
Quella parte l'abbiamo già scritta e gira in produzione. Su un nuovo progetto viene adattata invece che sviluppata, e questo si vede sui tempi e sul preventivo. Quello che resta da costruire è il pezzo che riguarda davvero voi: il dialogo con i vostri sistemi.
Oggi i componenti pronti sono nove: richiamata delle chiamate perse, monitoraggio delle code in tempo reale, classificazione dei contatti, registrazioni, reperibilità in due versioni, allarmi da impianti antincendio e traduzione simultanea delle telefonate. Li trovate tutti nella pagina prodotti.
Siamo 3CX Titanium Partner e VoIP provider certificato 3CX: sull'integrazione lavoriamo sullo stesso centralino di cui forniamo anche le linee, e questo toglie di mezzo buona parte dei rimpalli.
Sviluppiamo in PHP su MariaDB o MySQL, con server Debian in cloud o presso di voi. Il resto dei nostri servizi è su infoset.it.
Come conduciamo un progetto
Il primo passo non è scrivere codice, ed è quello che evita i progetti che si arenano a metà.
-
Analisi di fattibilità, requisito per requisito
Prendiamo l'elenco di quello che volete ottenere e per ogni voce diciamo se è fattibile, con quale approccio tecnico e da cosa dipende. Il documento che ne esce elenca anche le dipendenze critiche, cioè i punti in cui il risultato dipende da sistemi che non controlliamo noi.
-
Verifica sul campo delle interfacce
Prima di quotare lo sviluppo proviamo davvero le API o l'accesso ai dati: cosa restituiscono, in quanto tempo, cosa succede quando il sistema è sotto carico. È il momento in cui emergono le sorprese, ed è meglio che emergano adesso.
-
Sviluppo a blocchi verificabili
Ogni funzione viene consegnata e provata per conto suo: prima il riconoscimento del chiamante, poi l'instradamento, poi la scheda a video, poi la scrittura degli esiti. Si vede il progetto avanzare invece di aspettare la consegna finale.
-
Collaudo con traffico reale
Le integrazioni si rompono sui casi limite: il numero non trovato, la pratica con due titolari, il gestionale in manutenzione. Il collaudo serve a decidere insieme cosa deve succedere in ognuno di quei casi.
-
Manutenzione dichiarata
Le API cambiano, i gestionali si aggiornano. Chi mantiene l'integrazione e con quali tempi di intervento è scritto in contratto fin dall'inizio, non lasciato al buon senso.
Le domande dei tecnici
Il nostro gestionale è su misura, non un prodotto di mercato. È un problema?
Al contrario, spesso è più semplice. Un gestionale interno ha di norma un database accessibile e uno sviluppatore raggiungibile, mentre un prodotto commerciale può avere API limitate e nessuno con cui parlare. Quello che conta non è il nome del software, ma se espone i dati e a quali condizioni.
Dobbiamo cambiare centralino per fare questo?
Lavoriamo su 3CX, dove abbiamo la profondità maggiore. Se avete un altro centralino la fattibilità dipende da cosa espone: eventi di chiamata, API di controllo, possibilità di intervenire sul flusso IVR. Lo verifichiamo prima di proporvi qualsiasi sostituzione, che è una spesa e va giustificata.
Cosa succede se il gestionale non risponde?
È una decisione di progetto, non un caso da gestire all'ultimo. Di norma il middleware ha un tempo massimo di attesa oltre il quale la chiamata prosegue sul percorso ordinario, verso la coda generale. Meglio una chiamata gestita senza dati che una chiamata persa.
Le registrazioni e i dati delle chiamate, con il GDPR come si gestiscono?
Registrare le telefonate è lecito a condizioni precise: informativa a chi chiama, base giuridica individuata, accesso limitato per ruolo, tempi di conservazione definiti e rispettati, log degli accessi. Sono cose che vanno impostate all'inizio, insieme al vostro responsabile privacy: sono requisiti di progetto quanto le funzioni.
Quanto dura un progetto di questo tipo?
Dipende quasi solo da due fattori: quanto sono accessibili i vostri sistemi e quanto è pulita l'anagrafica dei numeri. L'analisi di fattibilità serve proprio a rispondere a questa domanda con dei numeri invece che con un'impressione, e si fa prima di impegnarsi sullo sviluppo.
Parliamo del vostro caso
Utile sapere già in partenza: che centralino avete, che gestionale usate e se espone API. Con queste tre informazioni la prima risposta è già concreta.