How Lucidchart’s Support Team Drives Revenue by Helping Customers Help Themselves
Lucidchart, di Lucid Software, è una piattaforma di produttività visiva che aiuta le persone a condividere idee, informazioni e processi con chiarezza. Attraverso un robusto centro assistenza, una comunità online e assistenza uno a uno, il team di supporto di Lucidchart serve oltre 15 milioni di utenti soddisfatti, mantenendo nel contempo il numero del team e il volume dei ticket stabili. Ci siamo seduti con Keyvan Sadigh, Senior Director of Customer Operations di Lucidchart, per scoprire come il suo team ha scalato le proprie capacità di supporto e aumentato i ricavi senza espandere il proprio team.

Grazie per esserti unito a noi, Keyvan! Puoi raccontarci il tuo background e fornire un po' di contesto su come sei diventato Senior Director of Customer Operations di Lucidchart?
Certo! Ho avuto una lunga carriera con molti colpi di scena. Mi sono laureato a Cornell con una laurea in biologia e pensavo di voler ottenere il dottorato in genetica. Ho lavorato per due anni in un laboratorio biomedico a Boston facendo ricerche genetiche, e poi ho deciso che quella vita non faceva per me. Ero un po' confuso su cosa volessi fare perché avevo studiato scienza per tutta la vita, e ora non volevo più seguire il percorso della ricerca.
Quindi, invece, ho fatto Teach for America a Philadelphia, dove ho insegnato matematica alle scuole superiori a studenti di prima e terza per due anni. Pensavo potesse offririmi una buona opportunità per riflettere e prendere un passo indietro da tutto ciò che avevo fatto. Alla fine del mio tempo lì ho iniziato a cercare lavoro e ho contattato un mio amico che lavorava in Google e mi ha incoraggiato a candidarmi per un ruolo. Sono entrato in Google in un momento in cui erano molto concentrati sulla creazione dei loro centri assistenza. Gmail era un prodotto relativamente nuovo, ma la sua base di utenti stava crescendo molto rapidamente. Google non aveva un numero di telefono da chiamare o un'email per il supporto, quindi lavoravamo su una strategia per costruire un centro di aiuto dove gli utenti potessero aiutare se stessi e aiutarsi a vicenda.
L'ho fatto per circa quattro anni in diverse funzioni, poi ho voluto provare a gestire persone, così sono stato trasferito nell'ufficio di Google a Dublino, in Irlanda, dove ho aiutato a lanciare la loro strategia comunitaria in diversi mercati europei. Così, di nuovo, il pensiero era che se potessimo fornire una piattaforma per gli utenti per aiutarsi a vicenda, allora sarebbero stati in grado di ottenere una risposta di alta qualità molto più rapidamente di quanto altrimenti avrebbero potuto.
Avrei dovuto essere a Dublino per un anno, ma alla fine ci sono rimasto per quasi quattro anni. Mi è piaciuto, è stato un ottimo periodo. Sono riuscito a gestire persone di diverse culture, che è stata un'esperienza molto nuova per me e davvero grandiosa. Verso la fine del mio periodo lì, sentivo che l'azienda era una macchina molto ben gestita di cui facevo solo una piccola parte, e cominciavo a sentire nostalgia per la frenesia dei primi giorni in Google, dove potevo avere esposizione a molti tipi diversi di compiti ed era più una filosofia di tutti sulle spalle.
Ho iniziato a cercare aziende molto più piccole e volevo qualcosa con una cultura simile a quella di Google, così ho guardato il sito di Google Ventures per trovare aziende in cui Google stava investendo e Lucid era una di queste. Il nostro CEO Karl Sun è in realtà un ex dipendente di Google, e ciò che mi è piaciuto della mia conversazione con lui è stato #1, il suo enfasi sulle persone e nel costruire una cultura che permette alle persone di fare grandi cose; e #2 costruire una piattaforma, Lucidchart, che consente alle persone di comunicare visivamente attraverso il software.
Era un concetto nuovo per me. Siamo tutti consapevoli di cosa significhi comunicare visivamente, ma tradizionalmente ci siamo affidati a cose come riunioni, note o fogli di lavoro per comunicare tra di noi. Lucid ha iniziato a spingere i confini di ciò che le persone possono fare in un browser e mira a permetterci di pensare in modo visivo in modo più collaborativo. Quindi ero davvero convinto della missione dell'azienda.
Quando sono entrato, il team di supporto era composto solo da quattro persone e si concentrava davvero sul supporto tramite email. Il compito che mi è stato assegnato era che la nostra base utenti stava crescendo estremamente rapidamente - era raddoppiata ogni anno per quattro o cinque anni consecutivi - ma eravamo certi che la strategia giusta fosse consentire ai nostri utenti di ottenere la propria risposta nel modo migliore e più veloce aiutando se stessi. Ecco perché mi hanno coinvolto in questo.
Wow, sembra che tu abbia davvero ottenuto quella frenesia che cercavi passando da un team di supporto di dimensioni Google a un team di quattro persone in Lucidchart!
Assolutamente.
Quindi ora che sei aumentato in Lucidchart, ho sentito che hai mantenuto il tuo team di supporto stabile a 10 persone e il volume dei ticket piatto negli ultimi anni. Quale ruolo gioca avere un team piccolo nella tua strategia di supporto?
La mia strategia è realmente focalizzata nel fornire contenuti ricchi che il nostro team può misurare per permettere agli utenti di aiutarsi a trovare quello che cercano. Uso sempre l'esempio di un bancomat per illustrare questo: quando vai in una banca durante le normali ore d'ufficio, ti trovi di fronte a questa domanda: voglio entrare in banca, aspettare in fila e chiedere la mia domanda? Oppure voglio aiutarmi al bancomat? Di solito, è il bancomat. E se prendiamo quell'analogia e la applichiamo al mondo tech, in Lucidchart pensiamo che un articolo del centro assistenza ben scritto non solo sia sufficiente, ma sia effettivamente preferibile per il 90% di ciò che i nostri utenti stanno cercando di fare.
In aggiunta, il centro assistenza è davvero un ottimo modo per misurare la domanda per molte cose diverse. Se puoi dimostrare che decine di migliaia di persone stanno visitando un articolo su un certo argomento, allora puoi portare tali informazioni all'ingegneria e chiedere modifiche supportate da dati reali dei clienti. Mentre quando gli utenti inviano email al nostro team di supporto, il volume tende ad essere molto più basso e quindi i dati sono meno utilizzabili quando li presentiamo al nostro team di ingegneria. È stato fantastico per noi poter dimostrare che anche se solo 15 utenti hanno inviato un'email chiedendo una funzionalità, migliaia di utenti hanno visitato articoli del centro assistenza anche correlati a tale funzionalità.
Il secondo pezzo è che il nostro contenuto del centro assistenza è ora localizzato in sei lingue diverse, quindi ci sono dei costi intrinseci nell'avere contenuti di alta qualità scritti dal tuo team. Quindi, per contenuti più marginali, offriamo una comunità dove gli utenti possono andare a inviare i propri contenuti e altri utenti possono beneficiarne. L'esempio che mi piace usare per questo concetto è che abbiamo un'app per Android per Lucidchart, e ci sono letteralmente migliaia di diversi telefoni Android, quindi se un utente ha un problema con il proprio telefono specifico e come interagisce con il nostro software, le possibilità che riusciamo effettivamente a entrare in possesso di quel particolare telefono sono piuttosto basse. Ma uno dei nostri 15 milioni di utenti probabilmente ha quel telefono e potrebbe aver persino affrontato esattamente quel problema. Quindi, a volte il nostro ruolo è connettere i nostri utenti tra loro in modo che possano aiutarsi a vicenda.
Ed è stato davvero fantastico vedere che quando guardiamo il traffico per il nostro centro assistenza e la comunità, ha effettivamente superato la crescita della base utenti. E poi, a proposito, quando guardiamo il volume dei ticket di supporto per il prodotto negli ultimi tre anni, è rimasto essenzialmente piatto. Il che per me implica che gli utenti realmente apprezzano e si stanno avvicinando a questo modello di auto-aiuto.
Quando si tratta della tua comunità online, hai qualche idea di che tipo di persone stanno contribuendo conoscenze e aiutando altri utenti? È un concetto interessante pensare a qualcuno che trascorre il proprio tempo personale a parlare del tuo prodotto per aiutare persone che non conosce.
La nostra comunità è ancora un lavoro in corso - molte volte gli utenti faranno domande e siamo noi a rispondergli nella comunità, ma poi altri utenti possono comunque beneficiare di quella risposta. Sempre più, tuttavia, stiamo vedendo che altri utenti stanno entrando e fornendo la risposta, che è il miglior scenario per i nostri scopi.
Per rispondere alla tua domanda sul perché, ci sono davvero pochi prodotti al mondo di cui gli utenti siano molto appassionati, ma sono stato abbastanza fortunato da lavorare su uno come Lucidchart che sicuramente rientra in quella categoria. Perché anche quando il nostro prodotto non corrisponde esattamente ai bisogni di un utente, e devono affrontare a volte delle soluzioni alternative per continuare ad usarlo, scelgono di farlo.
Un esempio di questa passione è un utente che ha effettivamente impostato l'app per iPhone di Lucidchart come il proprio calendario giornaliero. Questo è un caso d'uso che il nostro team non avrebbe mai immaginato per il prodotto, ma per qualche motivo questo utente ha deciso che la nostra soluzione era in realtà migliore dei calendari di Google e Apple, e nonostante il fatto che non ci proponiamo affatto per quel caso d'uso, sono andati oltre e hanno fatto in modo che funzionasse con il loro caso d'uso.
Quindi, se pensiamo a quella mentalità, molto di ciò che gli utenti cercano di fare è spingere i confini di ciò che il nostro prodotto può fare. E aiutando gli altri e condividendo i loro casi d'uso, alimentano la loro passione. Amano questo prodotto e vogliono condividere quella passione con gli altri.
È fantastico. Come fa il tuo team a tenere il passo con queste idee e invii degli utenti?
All'interno della nostra comunità abbiamo una sezione chiamata condividi i tuoi diagrammi; vogliamo sentire dagli utenti i modi nuovi in cui stanno usando il nostro prodotto. Quindi questo è un modo in cui sentiamo parlare di alcuni di questi casi d'uso. Il modo più prevalente è che il nostro team è ancora molto coinvolto nel rispondere alle email. Anche se il volume dei ticket è stabile, riceviamo ancora circa 600 email di supporto relative al prodotto a settimana. E così un utente ci contatterà e dirà: "Questo è ciò che sto cercando di fare ma ho incontrato questo ostacolo. Potresti dare un'occhiata al mio documento e aiutarmi a risolvere questo problema?" Spesso i documenti di cui vogliono aiuto sono usi abbastanza diretti dei nostri template, ma altre volte vediamo alcuni casi d'uso veramente innovativi del nostro prodotto e in quei casi spesso chiediamo loro se non vogliono pubblicarli nella comunità in modo che anche altri utenti possano beneficiarne.
Le idee innovative che arrivano in quel modo arrivano mai nel tuo prodotto? Come condividi quel lavoro internamente?
Collaboriamo con i nostri team di Customer Success e Solutions Engineering per mettere insieme un rapporto sulla Voce del Cliente che compila le richieste di funzionalità provenienti da tutti i nostri clienti. E nel caso delle richieste di template, abbiamo un team di template di prodotto al quale inviamo nuove idee generate dagli utenti. Quel team fa le proprie ricerche sulle proposte e valuta la possibilità di aggiungere un template ufficiale al prodotto. Abbiamo anche una galleria di template all'interno del nostro centro assistenza, e alcuni dei nostri contenuti creati dagli utenti finiscono lì e sono scoperti in questo modo.
Penso che la nostra visione a lungo termine sia che il centro assistenza e la comunità combinati siano molto più un luogo di ispirazione e aiuto proattivo, piuttosto che un luogo dove gli utenti vanno solo quando qualcosa si rompe. Vogliamo portare le persone oltre quella percezione che è ancora lo standard generale del settore.
Sembra che tu stia immaginando una strada a doppio senso tra la tua azienda e i tuoi clienti.
Assolutamente.
Questo mi ricorda i valori fondamentali di Lucid: Collaborazione oltre l'ego; innovazione in tutto ciò che facciamo; empowerment individuale, iniziativa e proprietà; e passione ed eccellenza in ogni area. Creare una strada a doppio senso rispecchia così tanti di questi valori. Come altro incarna questi valori fondamentali nel tuo approccio alla CX?
È interessante perché questi valori fondamentali sono stabiliti a livello aziendale e sono particolarmente veri per noi perché siamo dalla parte aziendale a contatto diretto con i clienti. Oltre a ciò, questi valori fondamentali sono qualcosa che enfatizziamo in ogni kickoff aziendale e in ogni aggiornamento aziendale. E una volta all'anno abbiamo un ritiro aziendale dove prendiamo tre giorni di pausa per andare a Zion National Park o Bear Lake per costruire il team e concentrarci sulla nostra strategia per l'anno successivo e anche ribadire i nostri valori fondamentali a tutte le nuove persone che partecipano al loro primo ritiro.
È fantastico sentirlo. Cerchiamo di incarnare i nostri valori fondamentali in tutto ciò che facciamo su Guru.
Quindi come fa il tuo team ad affrontare l'istruzione proattiva dei clienti? Qual è la suddivisione tra la parte proattiva e quella reattiva dell'essere un team CX?
Iniziamo dalla parte reattiva, che è qualcosa che penso attualmente facciamo molto bene. Se un utente sa cosa sta cercando di fare nel prodotto e viene al nostro centro assistenza o comunità cercando di capire come farlo, forniremo il contenuto di cui hanno bisogno e spesso lo completeremo con video e screenshot per assicurarci che siano pronti per il successo.
Penso che il modello verso cui stiamo cercando di muoverci, che è il modello proattivo, non sia solo dirti come fare qualcosa, ma dirti perché farlo in quel modo. Immagina che un utente venga al nostro centro assistenza e attraverso altri mezzi e segnali sappiamo che sono un insegnante di biologia. Vogliamo portare quell'insegnante a contenuti personalizzati che non solo mostrano loro le istruzioni passo-passo su come fare quello che stanno cercando di fare, ma mostrano anche quale template utilizzare per farlo. I nostri team specializzati - in questo esempio, il team educativo - stanno lavorando per fornire casi d'uso migliori e più informativi .]
Quindi se un cliente sta leggendo su come utilizzare una certa funzionalità, possiamo catturare alcuni dei segnali di prodotto di altri utenti che hanno utilizzato quella funzionalità e servire quelle informazioni al cliente, insieme ad altre funzionalità che utenti simili hanno utilizzato. Quindi poi prendiamo quel concetto per il centro assistenza e diciamo: "Ok, hai appena letto un articolo sulle presentazioni. Ora dovresti leggere questo articolo sui livelli e su come mostrare e nascondere diversi livelli, perché sappiamo che queste due funzionalità vanno a braccetto nel prodotto." Questo è un po' di ciò che stiamo cercando di ottenere.
Come formalizzi questa strategia in obiettivi? Sembra che i tuoi obiettivi vadano oltre il semplice mantenere stabili i volumi di ticket e ridurre i tempi di risposta iniziali.
Il nostro "Santo Graal" per le metriche di supporto è collegare ciò che un utente fa nel centro assistenza a ciò che poi fa nel prodotto. Quando guardiamo un particolare articolo, diciamo su collegamenti di dati, vogliamo avere un obiettivo del tipo: su ogni 1000 utenti che leggono quell'articolo, 700 di loro poi vanno nel prodotto e utilizzano la funzionalità di collegamento di dati. E recentemente, siamo riusciti a collegare l'uso del centro assistenza all'uso del prodotto. E così possiamo quindi estrapolare da lì e trovare correlazioni tra l'uso del centro assistenza e l'uso del prodotto.
Quello che penso sia davvero il cuore di ciò che stiamo cercando di fare: aumentare l'uso del nostro prodotto. E poi essere in grado di attribuire un valore alla ritenzione degli utenti. Possiamo quindi dire che se confrontiamo 1000 utenti che hanno visitato il centro assistenza con 1000 che non lo hanno fatto, i nostri tassi di ritenzione sono aumentati di questa percentuale perché abbiamo insegnato loro qualcosa di valore. O addirittura andare oltre la ritenzione e vedere se i loro tassi di coinvolgimento sono aumentati.
Adoro questo. Recentemente ho parlato con diversi leader del CX e il tema che il supporto sia un generatore di entrate piuttosto che un centro di costo continua a emergere. Sembri iscriverti a quel modello in cui il supporto può generare entrate piuttosto che solo generare costi?
Assolutamente, ma il nostro team va ancora oltre. Molto spesso, un utente ci contatta e dice: “Ehi, ci piace usare Lucidchart, ma stiamo avendo un problema con un'importazione di documento. I nostri documenti importati sembrano strani. Se fossimo in grado di risolvere questo problema allora potremmo espandere l'utilizzo di Lucidchart nella nostra azienda.” Quindi ci occuperemo del problema di supporto e poi lo passeremo al nostro team vendite.
“Nell'ultimo anno, il supporto è stato in realtà la terza fonte più grande di lead di vendita in azienda. Se guardi l'ammontare di entrate che arrivano tramite questo canale di supporto, supera di gran lunga gli stipendi di quanto il team viene pagato. Quindi in realtà NON siamo affatto un centro di costo.”
È estremamente impressionante! Quali altri metriche traccia il tuo team? E quali metriche consiglieresti ad altri leader di supporto che ammirano il tuo modello?
Una delle cose di cui andiamo fieri è quanto velocemente crescono il centro assistenza e i siti della community - ciò che chiamiamo supporto scalato - rispetto al supporto uno a uno, che comprende email, telefonate e supporto chat.
Un modo per misurare la crescita del supporto uno a uno è guardare il numero di email per base utenti. Quindi monitoriamo quanto velocemente sta crescendo la nostra base utenti e quanto velocemente stanno crescendo le nostre piattaforme di supporto, poi normalizziamo l'uno rispetto all'altro per scoprire il numero di email inviate per 10.000 utenti attivi del prodotto. E in confronto, quante visualizzazioni di pagina del centro assistenza stiamo ricevendo per ogni 10.000 utenti attivi del prodotto?
Se guardo il lato del supporto uno a uno, è piuttosto tradizionale: guardiamo cose come il tempo di prima risposta, la soddisfazione dei clienti e ciò che chiamiamo tempo di attesa degli utenti, che è il tempo che intercorre dal momento in cui un ticket viene inviato e il momento in cui viene risolto, sottraendo qualsiasi tempo in cui siamo in attesa che il cliente ci contatti con ulteriori informazioni.
Quando guardiamo il supporto scalato, è un po' diverso rispetto al supporto uno a uno. Quindi, di quegli utenti che stavano utilizzando il supporto scalato - sia esso il centro assistenza o la community - cosa stanno facendo nel prodotto? Qual è il loro tasso di retention a sette giorni rispetto a quello di trenta giorni rispetto al tasso di retention delle persone che non stanno usando il centro assistenza? E poi possiamo anche collegarlo alle entrate. Le persone che visitano il centro assistenza, tendono ad aggiornare di più? Tendono ad espandere il numero di utenti nel proprio account? Direi che queste sono le principali metriche che abbiamo monitorato anche se questo rimane molto un lavoro in corso.
Hai detto qualcosa in precedenza riguardo a scavare su quanto spesso viene utilizzato un certo articolo nel tuo centro assistenza e che i dati informano le decisioni sui futuri prodotti. Questo si ricollega un po' a ciò che facciamo noi in Guru in termini di conoscenza, quindi come pensi ai dati e alla conoscenza che raccogli attraverso il tuo centro assistenza nel giocare una parte nella tua strategia?
È una grande domanda. Ci piace sempre dire che il nostro supporto uno a uno informa il nostro supporto scalato. Quindi se vediamo un problema che sta decollando nella community, come se un utente pubblica qualcosa nella community e vogliono sapere come fare qualcosa e vediamo che riceve molte visualizzazioni di pagina, allora lo trasformeremo in un articolo del centro assistenza e lo localizzeremo per attirare ancora più traffico. E poi, se guardo i volumi dei ticket, si può dire lo stesso. Se riceviamo molte email su come fare qualcosa nel prodotto, allora guarderemo quelle email e penseremo: “Ok, ha senso meglio come post comunitario o come articolo del centro assistenza?” Quindi c'è in un certo senso questo processo di graduazione dove se vediamo molte email su qualcosa, allora passa a un post della community. Se poi quel post riceve molto traffico, passa a un articolo del centro assistenza.
E poi possiamo misurare il successo di ciò che stiamo facendo. Una volta creato questo articolo del centro assistenza, possiamo poi tornare e vedere se abbiamo avuto una diminuzione di quel tipo di ticket perché ora stiamo attirando più traffico sul supporto scalato.
L'ultimo aspetto riguarda le visualizzazioni di pagina. Le visualizzazioni di pagina per noi possono spesso sostituire il volume delle email. Se otteniamo un post della community che è una richiesta di funzionalità, possiamo mostrare il coinvolgimento e le visualizzazioni di pagina su quel post della community e portare quei dati al team di ingegneria e dire: “Ehi, c'è domanda per questo. Mettiamolo sulla roadmap del prodotto.”
Hai degli ultimi consigli per i leader di supporto che desiderano scalare le loro organizzazioni come la tua?
I miei altri consigli si concentrano su come reclutare e trattenere i migliori talenti. Molti dei team di supporto hanno enormi sfide in quanto la loro retention tende ad essere piuttosto bassa. Una delle cose che ci ha permesso di avere successo è che la retention del nostro team è estremamente alta. Negli ultimi 18 mesi, solo un membro del mio team ha cambiato ruolo, il che è piuttosto inusuale per questo settore. E quelle persone che hanno lasciato il mio team negli ultimi tre anni e mezzo sono rimaste tutte in Lucid e sono passate ad altri dipartimenti, portando le intuizioni sugli utenti acquistate in altre parti della società. Ma credo che se dai potere alle persone nell'organizzazione di supporto per assumersi veramente la responsabilità della strategia di alto livello, piuttosto che semplicemente attraversare email o affrontare chiamate, questo è davvero motivante per loro e li aiuta a costruire competenze che possono poi trasferire in altri settori, sia che si tratti di un altro ruolo in azienda o internamente all'interno del team.
È la cosa che mi piace ripetere di volta in volta: coinvolgere il team il più possibile nella strategia, perché alla fine sarà ciò che li terrà entusiasti, appassionati e in crescita.
Che bel modo di concludere. Grazie mille per il tuo tempo, Keyvan! Come possono i nostri lettori mettersi in contatto con te se hanno domande sulla tua filosofia di supporto o su Lucidchart?
Puoi connetterti con me su LinkedIn.

