Per creare le nostre soluzioni cloud, sviluppiamo proprie applicazioni aziendali. Questa padronanza in materia di software rafforza la nostra indipendenza e fornisce strumenti efficaci ai nostri collaboratori. Di recente, un team ha avuto carta bianca per sottoporre a ulteriori sviluppi gli strumenti utilizzati dagli operatori del servizio di assistenza di Infomaniak. Vi raccontiamo questo progetto attraverso gli occhi dei nostri sviluppatori.

Il nostro servizio di assistenza ci sta a cuore almeno quanto a te

Gli operatori del servizio di assistenza realizzano il trait d’union tra il nostro intero operato e gli utenti. Sono loro a riferirci i tuoi suggerimenti e i tuoi problemi e a consentire quindi di ottimizzare i nostri prodotti in base alle tue priorità. Senza il suo servizio di assistenza, Infomaniak non sarebbe Infomaniak.

Ascoltare. Individuare. Prioritizzare. Codificare. Adeguare.

Per migliorare i nostri strumenti, gli sviluppatori hanno lavorato con i loro colleghi del servizio di assistenza organizzandosi in un comitato ristretto e senza intermediari. Tutto ha avuto inizio con una riunione tra il servizio di assistenza, gli sviluppatori e gli ingegneri di sistema. Il team ha individuato innumerevoli punti da migliorare per ottimizzare:

  • la soddisfazione dei clienti
  • la gestione interna del servizio
  • l’efficacia dei processi
  • il comfort di lavoro e la soddisfazione degli operatori

L’obiettivo iniziale era trovare l’equilibrio tra ciò che era fattibile e la visione ideale immaginata insieme. Ogni sviluppo di funzionalità è stato presentato agli utenti finali per raccogliere le loro impressioni e i loro feedback utili ad apportare gli adeguamenti finali.

Rispondere alle specifiche problematiche del servizio di assistenza

Abbiamo chiesto agli sviluppatori di parlarci delle nuove funzionalità che hanno realizzato per il servizio di assistenza:

1 – Fluidità delle code d’attesa

Per abbreviare l’attesa in caso di indisponibilità in determinate code, un sistema di “fallback” inoltra la chiamata del cliente verso il primo operatore disponibile nella sua lingua. Gli orari di ogni coda d’attesa sono gestiti individualmente per ciascun giorno della settimana in base agli specialisti o alle lingue disponibili. Per informare i clienti al più presto, i nostri operatori possono creare messaggi audio dinamici da trasmettere in base a queste condizioni: coda d’attesa, problema tecnico per prodotto, lingua.

2 – Analisi e ottimizzazione della produttività

Abbiamo implementato statistiche e nuovi indicatori chiave di prestazione (KPI) per ottenere una panoramica sullo stato del servizio di assistenza in determinati periodi. Gli operatori del servizio di assistenza possono quindi:

  • identificare i problemi più rapidamente
  • essere più in linea con le attese dei clienti
  • aiutarsi a vicenda nei momenti di picco per rispondere più rapidamente ai clienti

3 – Gestione dinamica della centrale del servizio di assistenza

I responsabili possono aggiungere/rimuovere gli operatori alle/dalle code d’attesa, designare e modificare il loro ruolo, visualizzare il loro stato e definire un numero interno (cosa che prima non era possibile). Essi possono inoltre definire una musica di attesa, modificare le varie soglie di allerta e configurare i lassi di tempo:

  • prima di segnalare la chiamata a un altro operatore
  • tra una chiamata e l’altra
  • di attivazione del «rush time» e del «fallback»

Adesso, le chiamate possono essere inoltrate automaticamente verso i telefoni cellulari per trattare le richieste, anche se un operatore non è in postazione (periodi di permanenza).

Al centro dello sviluppo

Quando si parla di servizio di assistenza, ogni dettaglio contribuisce all’esperienza finale dei clienti. L’intero progetto si è quindi svolto internamente, secondo i nostri canoni tecnologici e obiettivi futuri.

Esso rappresenta un esempio emblematico della realtà quotidiana dei nostri sviluppatori. Confronta e sfida le scelte tecnologiche in relazione ai miglioramenti concreti che vogliamo apportare a favore dell’utente, offrendo al tempo stesso grande libertà in tutte le varie fasi di realizzazione. Julien Viard, VP of Engineering presso Infomaniak

Il front-end

Lo sviluppo dell’interfaccia di amministrazione e delle interfacce di assistenza live (schermate di controllo della centrale in tempo reale) è stato realizzato con il framework AngularJS. È la tecnologia storica dell’applicazione alla quale si sono agganciati i nostri sviluppatori.

Per semplificarne l’utilizzo, diversi componenti sono stati realizzati su misura, ad esempio:

  • la selezione degli utenti per essere assegnati alle code
  • il passaggio all’interfaccia dell’account del cliente
  • lo scorrimento automatico sulle interfacce di assistenza live

Per l’assistenza live è stato necessario fare una scelta: implementare dei socket (IPS) o utilizzare il pooling facendo un call backend ogni 3/4 secondi. Per motivi di eco-concezione e facilità di implementazione si è optato per la seconda soluzione. Anziché tenere un canale sempre aperto tra il front-end e il back-end per aggiornare i dati, gestiamo i calcoli sul lato server. L’interfaccia front-end attinge le informazioni dalla cache disponibile a intervalli di 3 secondi (invece di 1) per limitare le chiamate del server e i calcoli ridondanti. Per fornire una visualizzazione fluida e piacevole agli operatori del servizio di assistenza, viene simulato un aggiornamento in tempo reale con incrementi visivi ogni secondo.

Le statistiche (KPI) hanno richiesto l’implementazione di varie grafiche e tabelle che possono essere visualizzate su scale temporali più o meno lunghe. Se riferite a un giorno, le statistiche vengono visualizzate per ora, se riferite a un mese per giorno.

Il back-end

La tecnologia storica della centrale del servizio di assistenza è Asterisk (protocollo SIP), mentre AngularJS lo è per gli strumenti preesistenti. È stato necessario agganciarsi al database di Asterisk per recuperare determinate informazioni al volo, gestire gli operatori e creare tutte le funzionalità correlate. Nel quadro di questi strumenti, procediamo soltanto con route API (REST) che vengono richiamate dall’interfaccia.

In generale, questo progetto ha lasciato molto spazio alla creatività. Con Asterisk e un DB in real time è stato possibile fare un po’ tutto ciò che volevamo. Una funzionalità interessante è poter passare un operatore su un’altra coda (ad es. di un altro reparto o altra lingua) con un semplice clic per rispondere a una sola chiamata. A tale scopo, basta aggiungere l’operatore alla coda in modo dinamico, quindi rimuoverlo da essa intercettando la sua prossima chiamata ricevuta (tramite il sistema di gestione degli eventi).

Abbiamo implementato un sistema di gestione degli eventi: il server telefonico effettua chiamate API con determinate impostazioni ed esegue azioni correlate sul lato back-end. È con l’aiuto di questo tipo di evento che è possibile vedere apparire l’account del cliente (in base al numero del chiamante) nell’interfaccia, al momento della risposta alla chiamata. Questo sistema recupera i dati archiviati nella richiesta, quindi invia i processi affinché la risposta dell’API sia molto rapida e non ritardi la risposta alla chiamata stessa.

Per la gestione dei messaggi dinamici, il testo viene trascritto in voce e quindi distribuito direttamente su un repository Git: la centrale si aggancia a quest’ultimo e può accedere ai messaggi in tempo reale. È una funzionalità che è stata molto piacevole da sviluppare in quanto è possibile creare rapidamente un piccolo repository di messaggi vocali e accedervi dall’interfaccia dedicata per ascoltarli / modificarli.

Determinate route API vengono consumate direttamente dagli script dei nostri amministratori di sistema. Le impostazioni differiscono un po’ da quelle utilizzate dalla nostra interfaccia poiché le funzioni non sono uguali al 100%. In una riga di comando è possibile visualizzare lo stato di un inoltro e modificarlo indicando soltanto il numero interno ed esterno da utilizzare. Ciò consente di gestire automaticamente gli inoltri legati alle penalità di mora.

Lo sviluppo interno: una sfida e una leva

È cosa rara avere così tanta libertà nella realizzazione di un progetto. L’avvicinamento agli utenti finali ha consentito di creare un’emulsione di produttività per fare le cose in tempi rapidi, bene e in modo pertinente. Florian Grenier, Frontend developer

Il fulcro e anche l’interesse di questo progetto è la sua ala leggera che consente la massima autonomia ed efficacia. Gli utenti finali sono i nostri stessi colleghi e questo ci consente di definire standard diversi. Il team volontariamente minimalista è progredito in un comitato ristretto per 2 mesi. Abbiamo fatto integrazione continua (CI) con un server di staging 1 per 1 server di produzione, mentre il deployment automatico su un server di test viene inviato tramite script interno.

Creare nuove prestazioni da un framework obsoleto

Sebbene esista già un’API integrata nel server Asterisk, abbiamo scelto di non utilizzarla. Essa non rispondeva alle nostre esigenze e non era possibile modificarne il comportamento. Abbiamo quindi sviluppato proprie API.

La sfida tecnica di questo progetto è stata quella di giostrarsi tra le funzionalità disponibili, il già esistente e gli sviluppi specifici offrendo tempi di messa in produzione molto brevi e una qualità notevole.

Gli adeguamenti necessari

È stato difficile lanciare dei test nelle reali condizioni di produzione: molte più chiamate contemporaneamente / chiamate che durano più a lungo / tempi di attesa più importanti. Tutto questo ha relegato il team di sviluppo in condizioni mai presentatesi in passato e che hanno richiesto piccole correzioni, ad esempio a livello delle visualizzazioni in tempo reale.

Uno dei problemi maggiori non si è presentato subito. Si è dovuto attendere più settimane per rendersi conto dell’elevato numero di log creati dalla centrale. Ciò tendeva a rallentare la creazione delle statistiche e le varie azioni. È stato quindi implementato un sistema di flush automatico affiancato da un sistema di cache per evitare il ricalcolo dei dati che non devono essere aggiornati con la stessa frequenza.

Gli sviluppatori del progetto

Florian Grenier, sviluppatore Frontend: sono entrato in Infomaniak due anni fa in qualità di sviluppatore Frontend. Il mio background è piuttosto ampio: sviluppatore PHP, poi c#, breve passaggio sull’app mobile Ionic, project manager junior, poi sviluppatore java. Sono diplomato bac+5 alla scuola francese Y-NOV dal 2016 dove ho realizzato numerosi progetti e concorsi di sviluppo, anche extra-scolastici. Per quando riguarda le risorse, traggo spunti interessanti navigando molto spesso in questo sito. Mi piace seguire i tutorial di Grafikart su YouTube.

Può essere frustante avere a che fare con tecnologie obsolete (debito tecnico). La realtà di uno sviluppatore è confrontarsi con la situazione esistente, sulle prime battute non sempre attraente, per poi fornire alla fine una soluzione di qualità con effetto reale sulla velocità delle attività aziendali.

Noé Fleury, sviluppatore Backend: sono sviluppatore Backend in Infomaniak da circa 1 anno. Ho iniziato formandomi su più linguaggi (PHP, C, Python, SQL, ecc.) come autodidatta e 2 anni fa ho suggellato le mie conoscenze con una laurea in informatica presso un istituto di ingegneria (HES).

Questo progetto è la dimostrazione che siamo in grado di sviluppare strumenti molto efficaci senza dover ricorrere a soluzioni esterne meno flessibili. Dato che l’interfaccia è dedicata solo ed esclusivamente all’uso interno, è stato possibile aggiungere piccole funzionalità non previste, ma che alla fine si sono rivelate molto utili per lo svolgimento delle attività quotidiane.