How Lucidchart’s Support Team Drives Revenue by Helping Customers Help Themselves

Lucidchart, door Lucid Software, is een visueel productiviteitsplatform dat mensen helpt ideeën, informatie en processen duidelijk te delen. Via een robuust helpcentrum, online community en één-op-één ondersteuning, biedt het supportteam van Lucidchart service aan meer dan 15 miljoen blije gebruikers, terwijl de teamomvang en het aantal tickets gelijk blijven. We hebben gesproken met Keyvan Sadigh, Senior Director van Customer Operations bij Lucidchart, om erachter te komen hoe zijn team hun ondersteuningscapaciteiten heeft opgeschaald en omzet heeft gegenereerd zonder het team uit te breiden.

Bedankt dat je erbij was, Keyvan! Kun je ons iets vertellen over je achtergrond en wat context geven over hoe je Senior Director of Customer Operations bij Lucidchart bent geworden?

Zeker! Ik heb een lange carrière achter de rug met veel wendingen. Ik ben afgestudeerd aan Cornell met een graad in biologie en dacht dat ik mijn doctoraat in genetica wilde behalen. Ik heb twee jaar gewerkt in een biomedisch laboratorium in Boston, waar ik genetisch onderzoek deed, en besloot toen dat die levensstijl niet bij mij paste. Ik was een beetje in de war over wat ik wilde doen omdat ik mijn hele leven wetenschap had gestudeerd, en nu wilde ik niet meer de onderzoekroute inslaan.

Dus in plaats daarvan deed ik Teach for America in Philadelphia, waar ik twee jaar wiskunde aan middelbare scholieren lesgaf. Ik dacht dat het een goede gelegenheid voor me zou zijn om na te denken en een stap terug te nemen van alles wat ik had gedaan. Aan het eind van mijn tijd daar begon ik naar banen te kijken en bereikte ik een vriend van mij die bij Google werkte en me aanmoedigde om te solliciteren voor een functie daar. Ik kwam bij Google op een moment dat ze zich heel erg richtten op het opbouwen van hun helpcentra. Gmail was een relatief nieuw product, maar het gebruikersbestand groeide heel snel. Google had geen telefoonnummer dat mensen konden bellen of een e-mail voor ondersteuning, dus we werkten aan een strategie om een helpcentrum te bouwen waar gebruikers zichzelf kunnen helpen en elkaar kunnen helpen.

Ik deed dat ongeveer vier jaar in verschillende functies, en daarna wilde ik een kans wagen als people manager, dus ik verhuisde naar Google’s kantoor in Dublin, Ierland, waar ik hielp hun communitystrategie in verschillende Europese markten te lanceren. Dus opnieuw was de gedachte dat als we een platform konden bieden voor gebruikers om elkaar te helpen, ze in staat zouden zijn om veel sneller een kwalitatief hoogstaand antwoord te krijgen dan ze anders zouden kunnen.

Ik zou één jaar in Dublin blijven, maar ben uiteindelijk bijna vier jaar gebleven. Ik vond het geweldig, het was een geweldige tijd. Ik was in staat om mensen van verschillende culturen te managen, wat een heel nieuwe ervaring voor mij was en echt geweldig was. Aan het einde van mijn tijd daar, het voelde alsof het bedrijf een heel goed draaiende motor was waarin ik maar een klein stukje speelde, en ik begon de creativiteit van de eerdere dagen bij Google te missen waar ik blootstelling had aan veel verschillende soorten taken en er meer sprake was van een all-hands-on-deck-filosofie.

Ik begon te kijken naar veel kleinere bedrijven en wilde iets met een cultuur die vergelijkbaar was met Google, dus bekeek ik de website van Google Ventures om bedrijven te vinden waarin Google investeerde en Lucid was er één van. Onze CEO Karl Sun is toevallig ook een voormalige Google-werknemer, en wat ik leuk vond aan mijn gesprek met hem was #1, zijn nadruk op mensen en echt een cultuur opbouwen die mensen in staat stelt om geweldige dingen te doen; en #2 het bouwen van een platform, Lucidchart, dat mensen in staat stelt om visueel te communiceren via software.

Dat was een nieuw concept voor mij. We zijn er allemaal van bewust wat het betekent om visueel te communiceren, maar traditioneel hebben we vertrouwen op dingen zoals vergaderingen, notities of spreadsheets om met elkaar te communiceren. Lucid had de grenzen van wat mensen in een browser kunnen doen, verderop geduwd en streefde ernaar ons in staat te stellen om visueel te denken op een meer samenwerkende manier. Dus ik was echt overtuigd van de missie van het bedrijf.

Toen ik begon, was het supportteam maar vier mensen, en het was zeer gericht op e-mailondersteuning. De taak die ik kreeg was dat ons gebruikersbestand extreem snel groeide - het was elk jaar verdubbeld gedurende vier of vijf opeenvolgende jaren - maar we waren ervan overtuigd dat de juiste strategie was om onze gebruikers hun beste, snelste antwoord te geven door zichzelf te helpen. Dus dat is wat ik moest doen.

Wow, het klinkt alsof je echt dat creatieve element hebt gekregen waar je naar op zoek was door van een supportteam ter grootte van Google naar een team van vier bij Lucidchart te verhuizen!

Absoluut.

Dus nu je bent opgeschaald bij Lucidchart, heb ik gehoord dat je sindsdien je supportteam stabiel hebt gehouden op 10 mensen en het ticketvolume in de afgelopen jaren gelijk is gebleven. Welke rol speelt een klein team in je ondersteuningsstrategie?

Mijn strategie richt zich echt op het bieden van rijke inhoud die ons team kan meten om gebruikers te helpen zelf te vinden wat ze zoeken. Ik gebruik altijd het voorbeeld van een geldautomaat om dit te illustreren: Wanneer je tijdens normale kantooruren naar een bank gaat, word je met deze vraag geconfronteerd: Wil ik de bank binnenlopen, in de rij staan en mijn vraag stellen? Of wil ik mezelf helpen bij de geldautomaat? Meestal is het de geldautomaat. En als we die analogie nemen en toepassen op de technologie, dan denkt Lucidchart dat een goed geschreven helpcentrumartikel niet alleen voldoende is, maar eigenlijk zelfs de voorkeur heeft voor 90% van wat onze gebruikers willen doen.

Bovendien is het helpcentrum eigenlijk een geweldige manier om de vraag naar veel verschillende dingen te meten. Als je kunt aantonen dat tienduizenden mensen een artikel over een bepaald onderwerp bekijken, kun je die informatie naar de techniek brengen en pleiten voor wijzigingen die worden ondersteund door echte klantgegevens. Terwijl wanneer gebruikers e-mails naar ons ondersteuningsteam indienen, het volume meestal veel lager is en dus de gegevens minder bruikbaar zijn wanneer we het presenteren aan ons ontwikkelingsteam. Het is geweldig geweest voor ons om te kunnen aantonen dat zelfs als slechts 15 gebruikers een e-mail hebben gestuurd met een verzoek om een functie, duizenden gebruikers ook artikelen in het helpcentrum hebben bezocht die gerelateerd zijn aan die functie.

Het tweede punt is dat onze inhoud van het helpcentrum nu in zes verschillende talen is gelocaliseerd, dus er zijn inherent kosten verbonden aan het hebben van hoogwaardige inhoud die door jouw team wordt geschreven. Dus voor lange staartinhoud bieden we een community waar gebruikers hun eigen inhoud kunnen indienen, en andere gebruikers er van kunnen profiteren. Het voorbeeld dat ik leuk vind om voor dit concept te gebruiken is dat we een Android-app voor Lucidchart hebben, en er letterlijk duizenden verschillende Android-telefoons zijn, dus als een gebruiker problemen heeft met hun specifieke telefoon en hoe deze samenwerkt met onze software, is de kans dat we die specifieke telefoon kunnen krijgen behoorlijk laag. Maar een van onze 15 miljoen gebruikers heeft waarschijnlijk die telefoon en heeft misschien zelfs hetzelfde probleem ervaren. Dus soms is onze rol om onze gebruikers met elkaar te verbinden zodat ze elkaar kunnen helpen.

En dat is echt geweldig om te zien omdat wanneer we naar het verkeer voor ons helpcentrum en de community kijken, het de groei van het gebruikersbestand in feite heeft overtroffen. En dan, in antwoord op jouw punt, als we kijken naar het volume van supporttickets voor producten in de afgelopen drie jaar, is dat in wezen gelijk gebleven. Voor mij betekent dat dat gebruikers eigenlijk echt genieten van en zich aangetrokken voelen tot dit zelfhulpmodel.

Als het gaat om jouw online community, heb je enig idee wat voor soort mensen kennis bijdragen en andere gebruikers helpen? Het is een leuk concept om na te denken over iemand die zijn eigen persoonlijke tijd besteedt aan het praten over jouw product om mensen te helpen die ze niet kennen.

Onze community is nog steeds een werk in uitvoering - vaak zullen gebruikers vragen stellen en zijn wij de degenen die op hen reageren in de community, maar andere gebruikers kunnen nog steeds profiteren van dat antwoord. In toenemende mate zien we echter dat andere gebruikers binnenkomen en het antwoord geven, wat het beste scenario is voor onze doeleinden.

Om jouw vraag te beantwoorden waarom, er zijn heel weinig producten in de wereld waar gebruikers heel gepassioneerd over zijn, maar ik heb het geluk gehad om aan zo eentje als Lucidchart te werken dat zeker onder die categorie valt. Want zelfs als ons product niet precies bij de behoeften van een gebruiker aansluit, en ze soms door gekke omwegen moeten gaan om het te blijven gebruiken, kiezen ze ervoor om dat te doen.

Een voorbeeld van deze passie is een gebruiker die de Lucidchart iPhone-app daadwerkelijk heeft opgezet als hun dagelijkse agenda. Dit is een gebruiksgeval dat ons team nooit zou hebben kunnen voorzien voor het product, maar om welke reden dan ook besloot deze gebruiker dat onze oplossing beter was dan Google en Apple’s agenda’s, en ondanks dat wij helemaal niet op dat gebruiksgeval gericht zijn, deden zij er alles aan om het te laten werken met hun gebruik.

Dus als we aan die mentaliteit denken, is veel van wat gebruikers proberen te doen, de grenzen van wat ons product kan doen, te verleggen. En door anderen te helpen en hun gebruiksgevallen te delen, voedt dat hun passie. Ze houden van dit product en ze willen die passie met anderen delen.

Dat is geweldig. Hoe houdt jouw team deze gebruikersideeën en inzendingen bij?

Binnen onze community hebben we een sectie genaamd deel jouw diagrammen; we willen graag van gebruikers horen over de nieuwe manieren waarop ze ons product gebruiken. Dus dat is een manier waarop we horen over sommige van deze gebruiksgevallen. De meer voorkomende manier is dat ons team nog steeds zeer betrokken is bij het beantwoorden van e-mails. Hoewel het ticketvolume gelijk blijft, krijgen we nog steeds ongeveer 600 productgerelateerde ondersteuningse-mails per week. En dus zal een gebruiker ons bereiken en zeggen: “Dit is wat ik probeer te doen maar ik ben tegen deze hindernis aangelopen. Zou je alsjeblieft naar mijn document kunnen kijken en me helpen met dit probleem?” Vaak zijn de documenten waar ze hulp mee willen, vrij eenvoudig gebruik van onze sjablonen, maar soms zien we echt innovatieve gebruiksgevallen van ons product, en in die gevallen vragen we ze vaak of ze het niet erg vinden om ze in de community te plaatsen zodat andere gebruikers er ook van kunnen profiteren.

Doen innovatieve ideeën die op die manier binnenkomen ooit hun weg terug naar jouw product? Hoe deel je dat werk intern?

We werken samen met onze teams voor Klantensucces en Oplossingen Engineering om een rapport over de Klantstem op te stellen dat feature-aanvragen van al onze klanten verzamelt. En in het geval van sjabloonverzoeken hebben we een producttemplate-team dat we nieuwe en door gebruikers gegenereerde ideeën indienen. Dat team doet hun eigen onderzoek naar de inzendingen en beoordeelt de mogelijkheid om een officiële sjabloon aan het product toe te voegen. We hebben ook een sjabloongalerij binnen ons helpcentrum, en een deel van onze door gebruikers gemaakte inhoud belandt daar en is op die manier vindbaar.

Ik denk dat onze langetermijnvisie is dat het helpcentrum en de community samen veel meer een plek voor inspiratie en proactieve hulp moeten zijn in plaats van een plek waar gebruikers alleen naartoe gaan wanneer er iets kapot is. We willen mensen verder helpen dan die perceptie die nog steeds de algemene standaard in de industrie is.

Het klinkt alsof je meer een tweerichtingsstraat tussen jouw bedrijf en jouw klanten voor ogen hebt.

Absoluut.

Dat doet me denken aan de kernwaarden van Lucid: Teamwerk boven ego; innovatie in alles wat we doen; individuele empowerment, initiatief en eigenaarschap; en passie en uitmuntendheid in elk gebied. Het creëren van een tweerichtingsstraat spreekt zoveel van die waarden aan. Hoe belichaam je die kernwaarden anders in jouw CX-aanpak?

Het is cool omdat deze kernwaarden op bedrijfsniveau zijn vastgesteld, en ze zijn vooral waar voor ons omdat we aan de klantgerichte kant van het bedrijf werken. Daarnaast zijn deze kernwaarden iets dat we benadrukken bij elke bedrijfskickoff en bij elke bedrijfsupdate. En eenmaal per jaar hebben we een bedrijfsbrede retraite waar we drie dagen vrij nemen om naar Zion National Park of Bear Lake te gaan om teamvorming te doen en te focussen op onze strategie voor het komende jaar en ook onze kernwaarden opnieuw te benadrukken aan al het nieuwe personeel dat hun eerste retraite bijwoont.

Dat is geweldig om te horen. We proberen ook onze kernwaarden te belichamen in alles wat we doen bij Guru.

Dus hoe benadert jouw team proactieve klanteducatie? Wat is de verdeling tussen de proactieve en de reactieve kanten van een CX-team zijn?

Laten we beginnen met de reactieve kant, iets dat ik denk dat we momenteel zeer goed doen. Als een gebruiker weet wat ze proberen te doen in het product en ze komen naar ons helpcentrum of community om te proberen uit te vinden hoe ze dat moeten doen, zullen we hen de inhoud geven die ze nodig hebben en vaak aanvullen met video's en schermafbeeldingen om ervoor te zorgen dat ze goed worden voorbereid op succes.

Ik denk dat het model waar we naartoe proberen te bewegen, dat is het proactieve model, is dat we niet alleen mensen vertellen hoe ze iets moeten doen, maar ook waarom ze het op die manier moeten doen. Stel je voor dat een gebruiker naar ons helpcentrum komt en via andere middelen en signalen weten we dat ze een biologie-docent zijn. We willen die docent naar gepersonaliseerde inhoud brengen die niet alleen stap-voor-stap instructies toont over hoe ze kunnen doen wat ze willen, maar ook welke sjabloon ze moeten gebruiken om het te doen. Onze gespecialiseerde teams – in dit voorbeeld, het onderwijsteam – werken eraan om betere, meer informatieve gebruikscenario's te bieden.

Dus als een klant leest over hoe een bepaalde functie te gebruiken, kunnen we enkele productsignalen van andere gebruikers die die functie hebben gebruikt vastleggen en die informatie aan de klant aanbieden, samen met andere functies waarmee vergelijkbare gebruikers hebben gewerkt. Dus nemen we dat concept naar het helpcentrum en zeggen we: "Oké, je hebt net een artikel over presentaties gelezen. Nu moet je dit artikel over lagen lezen en het tonen en verbergen van verschillende lagen, omdat we weten dat die twee functies hand in hand gaan in het product.” Dat is een beetje wat we proberen te bereiken.

Dus hoe formaliseer je deze strategie in doelen? Het klinkt alsof jouw doelen verder gaan dan alleen het ticketvolume gelijk houden en de eerste reactietijd verminderen.

Onze "Heilige Graal" voor ondersteuningsstatistieken is om de acties die een gebruiker in het helpcentrum onderneemt, te koppelen aan wat ze vervolgens in het product doen. Als we naar een bepaald artikel kijken, zeg bijvoorbeeld over dataverbindingen, willen we dan een doel hebben zoals: uit elke 1.000 gebruikers die dat artikel lezen, gaan 700 van hen vervolgens naar het product en gebruiken de functie voor dataverbindingen. En onlangs hebben we de bruikbaarheid van het helpcentrum kunnen koppelen aan het gebruik van het product. Dus kunnen we daaruit extrapoleren en correlaties vinden tussen het gebruik van het helpcentrum en het gebruik van het product.

Dat is denk ik het hart van wat we proberen te doen: het gebruik van ons product verhogen. En dan de waarde van gebruikersbehoud kunnen vaststellen. We kunnen dan zeggen dat als we 1.000 gebruikers die het helpcentrum hebben bezocht vergelijken met 1.000 die dat niet hebben gedaan, onze retentiecijfers deze procent zijn gestegen omdat we hen iets waardevol hebben geleerd. Of zelfs nog een stap verder gaan en kijken of hun betrokkenheidspercentages ook zijn gestegen.

Ik hou hiervan. Ik heb onlangs met verschillende CX-leiders gesproken en het thema dat ondersteuning een omzetgenerator is in plaats van een kostenpost, komt steeds terug. Klinkt het alsof je het eens bent met dat model van ondersteuning dat omzet kan genereren in plaats van alleen maar kosten te maken?

Absoluut, maar ons team gaat zelfs nog verder. Vaak neemt een gebruiker contact met ons op en dan zeggen ze: “Hé, we houden van het gebruik van Lucidchart, maar we hebben een probleem met het importeren van een document. Onze geïmporteerde documenten zien er vreemd uit. Als we dit probleem konden oplossen, zouden we ons gebruik van Lucidchart in ons bedrijf kunnen uitbreiden.” Dus we helpen met het ondersteuningsprobleem en dan geven we het door aan ons verkoopteam.

“In het afgelopen jaar was ondersteuning eigenlijk de derde grootste bron van verkoop leads bij het bedrijf. Als je kijkt naar de hoeveelheid omzet die via dit ondersteuningskanaal binnenkomt, overtreft dit veruit de salarissen van wat het team betaald krijgt. Dus we zijn eigenlijk GEEN kostenposten.”

Dat is extreem indrukwekkend! Welke andere statistieken houdt jouw team bij? En welke statistieken zou je aanbevelen dat andere ondersteuningsleiders die jouw model waarderen, bijhouden?

Een van de dingen waar we trots op zijn, is hoe snel het helpcenter en de community-sites groeien – wat we geschaalde ondersteuning noemen – vergeleken met persoonlijke ondersteuning, zoals e-mails, telefoongesprekken en chatondersteuning.

Een manier om de groei van persoonlijke ondersteuning te meten, is door te kijken naar het aantal e-mails per gebruikersbasis. Dus we volgen hoe snel onze gebruikersbasis groeit, en we volgen hoe snel elk van onze ondersteuningsplatformen groeit, en dan normaliseren we één naar de ander om het aantal e-mails te vinden dat verstuurd wordt per 10.000 actieve gebruikers van het product. En in vergelijking, hoeveel paginaweergaven van het helpcenter krijgen we per elke 10.000 actieve gebruikers van het product.

Als ik kijk naar de persoonlijke ondersteuning, dat is traditioneler: we kijken naar dingen zoals de tijd voor de eerste reactie, klanttevredenheid en wat we noemen wachttijd voor gebruikers, waar de tijd die verloopt vanaf het indienen van een ticket tot het opgelost is, minus enige tijd dat we wachten op de klant om ons met meer informatie terug te bellen.

Als we naar geschaalde ondersteuning kijken, is het een beetje anders dan persoonlijke ondersteuning. Dus, van die gebruikers die geschaalde ondersteuning gebruiken – of het nu het helpcenter of de community is – wat doen ze daarna in het product? Wat is hun zeven-daagse retentiegraad versus de 30-daagse retentiegraad versus de retentiegraad van mensen die het helpcenter niet gebruiken? En dan kunnen we het ook aan omzet koppelen. Mensen die het helpcenter bezoeken, upgraden ze meer? Tendensen ze naar het uitbreiden van het aantal gebruikers op hun account? Ik zou zeggen dat dit de belangrijkste statistieken zijn die we hebben gevolgd, hoewel dit nog steeds een werk in uitvoering is.

Je zei eerder iets over hoe vaak een bepaald artikel in je helpcenter wordt gebruikt en dat die gegevens toekomstige productbeslissingen beïnvloeden. Dat spreekt een beetje tot wat we bij Guru doen in termen van kennis, dus hoe denk je over de data en kennis die je verzamelt via je helpcenter in relatie tot je strategie?

Dat is een geweldige vraag. We zeggen altijd dat onze persoonlijke ondersteuning onze geschaalde ondersteuning informeert. Dus als we een probleem zien dat zich in de community ontwikkelt, zoals als een gebruiker iets in de community plaatst dat ze willen weten hoe ze iets moeten doen en we zien dat het veel paginaweergaven krijgt, dan zullen we dat daadwerkelijk upgraden naar een helpcentervoor artikel en het lokaliseren om nog meer verkeer naar toe te leiden. En dan, als ik kijk naar de ticketvolumes, kan hetzelfde worden gezegd. Als we veel e-mails krijgen over hoe iets in het product moet, dan kijken we naar die e-mails en denken we: “Oké, maakt dit meer zin als een communitypost of als een helpcentervoor artikel?” Dus er is een soort van dit graduatieproces waar als we veel e-mails over iets zien, dan gaat het naar een communitypost. Als dat dan veel verkeer krijgt, gaat het naar een helpcentervoor artikel.

En dan kunnen we het succes van wat we doen meten. Dus zodra we dit helpcentervoor artikel hebben gemaakt, kunnen we terugkijken of we een afname hebben gezien in die soorten tickets omdat we nu meer verkeer naar de geschaalde ondersteuning sturen.

Het laatste deel gaat over paginaweergaven. Paginaweergaven kunnen voor ons vaak e-mailvolume vervangen. Als we een communitypost krijgen die een functieaanvraag is, kunnen we de betrokkenheid en paginaweergaven op die communitypost tonen en die gegevens naar het engineeringteam brengen en zeggen: “Hé, er is vraag naar dit. Laten we dit op de productroadmap zetten.”

Heb je nog laatste tips voor ondersteuningsleiders die hun organisaties willen schalen zoals de jouwe?

Mijn andere tips richten zich op hoe je top talent kunt werven en behouden. Veel ondersteuningsorganisaties hebben enorme uitdagingen omdat hun behoud vaak vrij laag is. Een van de dingen die ons echt in staat heeft gesteld om succesvol te zijn, is dat het behoud van ons team extreem hoog is. In de afgelopen 18 maanden is slechts één lid van mijn team overgestapt, wat in dit veld bijna ongehoord is. En diegenen die mijn team hebben verlaten in de afgelopen drieënhalf jaar, zijn allemaal binnen Lucid gebleven en zijn naar andere afdelingen gegaan, waarbij ze de gebruikersinzichten die ze hebben verworven naar andere delen van het bedrijf hebben meegenomen. Maar ik denk dat als je mensen in de ondersteuningsorganisatie de mogelijkheid geeft om echt eigenaarschap te nemen van de strategische doelen, in plaats van alleen maar door e-mails te jagen of telefoontjes te beantwoorden, Dan is het enorm empowering voor hen en helpt het hen vaardigheden te ontwikkelen die ze dan kunnen overdragen naar andere gebieden, of dat nu een andere rol binnen het bedrijf is of intern binnen het team.

Dat is hetgene dat ik keer op keer wil benadrukken: betrek het team in zoveel mogelijk van de strategie, want uiteindelijk is dat wat hen enthousiast, gepassioneerd en in groei zal houden.

Wat een geweldige manier om te eindigen. Heel erg bedankt voor je tijd, Keyvan! Hoe kunnen onze lezers contact met jou opnemen als ze vragen hebben over je ondersteuningsfilosofie of Lucidchart?

Je kunt me bereiken op LinkedIn.