Lucidchart, av Lucid Software, är en visuell produktivitetsplattform som hjälper människor att dela idéer, information och processer med tydlighet. Genom ett robust hjälpcenter, onlinecommunity och personlig assistans betjänar Lucidcharts supportteam över 15 miljoner nöjda användare, samtidigt som teamstorlek och biljettvolym hålls platta. Vi satte oss ner med Keyvan Sadigh, Senior Director of Customer Operations på Lucidchart, för att ta reda på hur hans team har skalat sina supportmöjligheter och drivit intäkter utan att öka storleken på teamet.

Tack för att du var med oss, Keyvan! Kan du berätta om din bakgrund och ge lite kontext kring hur du kom att bli Senior Director of Customer Operations på Lucidchart?

Självklart! Jag har haft en lång karriär med många svängar och vändningar. Jag tog examen från Cornell med en examen i biologi och trodde att jag ville ta min doktorsexamen i genetik. Jag arbetade i två år på ett biomedicinskt laboratorium i Boston med genetikforskning, och bestämde mig sedan för att det livet inte var för mig. Jag var lite förvirrad över vad jag ville göra för jag hade studerat naturvetenskap hela mitt liv, och nu ville jag inte gå ner på forskningsvägen.

Så istället gjorde jag Teach for America i Philadelphia, där jag undervisade gymnasieelever i matematik för nybörjare och juniorer i två år. Jag tyckte att det skulle erbjuda en bra möjlighet för mig att reflektera och ta ett steg tillbaka från allt jag hade gjort. I slutet av min tid där började jag söka jobb och kontaktade en kompis som arbetade på Google och uppmuntrade mig att ansöka om en roll där. Jag anslöt mig till Google vid en tidpunkt när de fokuserade mycket på att bygga ut sina hjälpcenter. Gmail var en relativt ny produkt, men dess användarbas växte mycket snabbt. Google hade ingen telefonnummer folk kunde ringa eller en e-postadress för support, så vi arbetade på en strategi för att bygga ett hjälpcenter där användare kunde hjälpa varandra.

Jag gjorde det i ungefär fyra år i olika roller, och sedan ville jag prova på att leda människor, så jag överflyttades till Googles kontor i Dublin, Irland där jag hjälpte till att lansera deras community-strategi i flera europeiska marknader. Så än en gång, tanken var att om vi kunde ge en plattform där användarna kunde hjälpa varandra, skulle de kunna få ett högkvalitativt svar mycket snabbare än vad de annars skulle kunna få.

Jag skulle ha stannat i Dublin i ett år men slutade med att stanna i nästan fyra. Jag älskade det, det var en sådan bra tid. Jag kunde leda människor från olika kulturer vilket var en mycket ny erfarenhet för mig som var riktigt bra. Mot slutet av min tid där kände jag att företaget var en mycket välfungerande maskin som jag bara var en liten del av, och jag började sakna den slitstarka atmosfären från de tidigare dagarna på Google där jag kunde få insyn i många olika typer av uppgifter och det var mer av en all-hands-on-deck-filosofi.

Jag började titta på mycket mindre företag och ville ha något med en liknande kultur som Google, så jag tittade på Google Ventures hemsidan för att hitta företag som Google investerade i och Lucid var ett av dem. Vår VD Karl Sun är också en tidigare Google-anställd, och vad jag gillade med min konversation med honom var #1, hans betoning på människor och verkligen bygga en kultur som ger människor möjlighet att göra stora saker; och #2 bygga en plattform, Lucidchart, som möjliggör att människor kan kommunicera visuellt genom programvara.

Detta var ett nytt koncept för mig. Vi är alla medvetna om vad det betyder att kommunicera visuellt men traditionellt har vi förlitat oss på saker som möten eller anteckningar eller kalkylblad för att kommunicera med varandra. Lucid hade börjat tänja på gränserna för vad människor kan göra i en webbläsare och syftade till att möjliggöra att vi kan tänka visuellt på ett mer samarbetsvilligt sätt. Så jag blev verkligen övertygad av företagets mission.

När jag anslöt mig var supportteamet bara fyra personer, och det fokuserade mycket på e-postsupport. Den uppgift jag fick var att vår användarbas växte extremt snabbt – den hade fördubblats varje år i fyra eller fem år i rad – men vi var övertygade om att den rätta strategin var att låta våra användare få sina bästa, snabbaste svar genom att hjälpa sig själva. Så det är vad jag blev anställd för att göra.

Wow, det låter som att du verkligen fick den slitstarka atmosfären som du letade efter när du gick från ett Google-stort supportteam till ett fyramannateam på Lucidchart!

Absolut.

Så nu när du har skalat upp på Lucidchart, har jag hört att du sedan dess har hållit ditt supportteam stabilt på 10 personer och biljettvolymen platt under de senaste åren. Vilken roll spelar att ha ett litet team i din supportstrategi?

Min strategi är verkligen fokuserad på att tillhandahålla rikt innehåll som vårt team kan mäta för att låta användare få hjälp med det de söker. Jag använder alltid exemplet med en bankomat för att illustrera detta: När du går till en bank under normala öppettider, ställs du inför denna fråga: Vill jag gå in i banken, vänta i kö och ställa min fråga? Eller vill jag hjälpa mig själv vid bankomaten? Vanligtvis är det bankomaten. Och om vi tar den analogin och tillämpar den på teknikvärlden, så tycker vi på Lucidchart att en välskriven artikel i hjälpcentret inte bara är tillräcklig, utan faktiskt föredragen för 90% av vad våra användare försöker göra.

Dessutom är hjälpcentret faktiskt ett bra sätt att mäta efterfrågan för många olika saker. Om du kan visa att tiotusentals personer kommer till en artikel om ett visst ämne, kan du ta informationen till teknisk avdelning och driva på förändringar som stöds av verkliga kunddata. Medan när användare skickar e-post till vårt supportteam, tenderar volymen att vara mycket lägre och därmed är datan mindre handlingsbar när vi presenterar den för vår teknikteam. Det har varit fantastiskt för oss att kunna visa att även om endast 15 användare har skickat e-post och frågat efter en funktion, så har tusentals användare besökt artiklar i hjälpcentret som också rör den funktionen.

Den andra delen är att vårt innehåll i hjälpcentret nu är lokaliserat till sex olika språk, så det finns en inneboende kostnad för att ha högkvalitativt innehåll skrivet av ditt team. Så för långsvansinnehåll tillhandahåller vi en community där användare kan gå för att lämna sitt eget innehåll, och andra användare kan dra nytta av det. Exemplet jag gillar att använda för detta koncept är att vi har en Android-app för Lucidchart, och det finns bokstavligen tusentals olika Android-telefoner, så om en användare har ett problem med sin specifika telefon och hur den interagerar med vår programvara, är chansen att vi faktiskt kan få tag på just den telefonen ganska låg. Men en av våra 15 miljoner användare har förmodligen den telefonen och har kanske till och med upplevt det exakta problemet. Så ibland är vår roll att koppla samman våra användare så att de kan hjälpa varandra.

Och det har varit riktigt bra att se för när vi ser trafiken till vårt hjälpcenter och community, så har det faktiskt överstigit tillväxten av användarbasen. Och när vi tittar på produktstödsbiljettvolymen över de senaste tre åren har den i princip förblivit platt. Vilket för mig antyder att användare verkligen gillar och dras till denna självhjälpsmodell.

När det kommer till din online-community, har du någon aning om vilken typ av personer som bidrar med kunskap och hjälper andra användare? Det är ett coolt koncept att tänka på någon som spenderar sin egen personliga tid på att prata om din produkt för att hjälpa människor som de inte känner.

Vår community är fortfarande ett arbete i utveckling – många gånger kommer användare att ställa frågor och vi är de som svarar dem i communityn, men andra användare kan fortfarande dra nytta av det svaret. Ökande ser vi dock att andra användare kommer in och ger svaret, vilket är det bästa scenariot för våra syften.

För att besvara din fråga om varför, finns det väldigt få produkter i världen som användare är mycket passionerade över, men jag har haft turen att arbeta med en som Lucidchart som definitivt faller under den kategorin. För även när vår produkt inte exakt matchar en användares behov, och de ibland måste gå igenom galna omvägar för att fortsätta använda den, väljer de att göra det.

Ett exempel på denna passion är en användare som faktiskt ställde in Lucidchart iPhone-appen som sin dagliga kalender. Detta är en användning av produkten som vårt team aldrig skulle ha föreställt sig, men av vilken anledning som helst beslutade denna användare att vår lösning faktiskt var bättre än Google och Apples kalendrar, och trots att vi överhuvudtaget inte riktar in oss på det användandet, gick de över och bortom för att få det att fungera med deras användningsfall.

Så om vi tänker på det mentalt, handlar mycket av det som användarna försöker göra om att tänja på gränserna för vad vår produkt är kapabel att göra. Och genom att hjälpa andra och dela sina användningsfall, brinner deras passion ytterligare. De älskar denna produkt och de vill dela den passionen med andra.

Det är fantastiskt. Hur håller ditt team koll på dessa användaridéer och inskickningar?

Inom vår community har vi en sektion som kallas dela dina diagram; vi vill höra från användare om de nya sätt som de använder vår produkt. Så det är ett sätt vi hör om några av dessa användningsfall. Det vanligare sättet är att vårt team fortfarande är väldigt mycket involverat i att svara på e-post. Även om biljettvolymen är platt, får vi fortfarande ungefär 600 produktrelaterade support-e-postmeddelanden per vecka. Och så kommer en användare att nå ut till oss och säga, "Detta är vad jag försöker göra men jag har stött på detta hinder. Skulle du ha något emot att titta på mitt dokument och hjälpa mig med detta problem?" Oftast är de dokument de vill ha hjälp med ganska straightforward-användningar av våra mallar, men ibland ser vi vissa riktigt innovativa användningar av vår produkt, och i dessa fall ber vi dem ofta om de skulle kunna posta dem i communityn så att andra användare också kan dra nytta av det.

Kommer innovativa idéer som kommer in på det sättet någonsin tillbaka till er produkt? Hur delar du det arbetet internt?

Vi samarbetar med våra team för Kundframgång och Lösningsutveckling för att sätta ihop en rapport om kundens röster som sammanställer funktionsförfrågningar från alla våra kunder. Och när det gäller mallförfrågningar har vi ett produkteam som vi skickar nya och användargenererade idéer till. Det teamet gör sin egen forskning om inskickningarna och utvärderar sedan möjligheten att lägga till en officiell mall till produkten. Vi har också ett mallgalleri inom vårt hjälpcenter, och vissa av vårt användarproducerade innehåll hamnar där och går att upptäcka på det sättet.

Jag tycker att vår långsiktiga vision är att hjälpcentret och communityn tillsammans ska vara mycket mer av en plats för inspiration och proaktiv hjälp istället för en plats användare bara går till när något är trasigt. Vi vill få människor bortom den uppfattningen som fortfarande är den allmänna normen i branschen.

Det låter som att du föreställer dig mer av en tvåvägsgata mellan ditt företag och dina kunder.

Absolut.

Det påminner mig om Lucids kärnvärden: Laganda före ego; innovation i allt vi gör; individuell bemyndigande, initiativ och ägande; och passion och excellens i alla områden. Att skapa en tvåvägsgata talar till så många av dessa. Hur annat gör du för att förkroppsliga dessa kärnvärden i din CX-strategi?

Det är coolt eftersom dessa kärnvärden är fastställda på företagsnivå, och de ringer särskilt sanna för oss eftersom vi är på den kundinriktade sidan av företaget. Utöver det, dessa kärnvärden är något som vi betonar vid varje företagets kickoff och vid varje företagsuppdatering. Och en gång om året har vi en företagsövergripande reträtt där vi tar tre dagar ledigt för att gå till Zion National Park eller Bear Lake för att bygga lag och fokusera på vår strategi för det kommande året och också återbetona våra kärnvärden till alla nya människor som deltar i sin första reträtt.

Det är fantastiskt att höra. Vi försöker inkorporera våra kärnvärden i allt vi gör på Guru också.

Så hur närmar sig ditt team proaktiv kundutbildning? Vad är uppdelningen mellan de proaktiva och de reaktiva sidorna av att vara ett CX-team?

Låt oss börja med den reaktiva, vilket är något som jag tycker att vi för närvarande gör mycket bra. Om en användare vet vad de försöker göra i produkten och de kommer till vårt hjälpcenter eller community för att försöka lista ut hur man gör det, kommer vi att ge dem det innehåll de behöver och ofta komplettera det med videor och skärmdumpar för att se till att de är inställda för framgång.

Jag tror att den modellen vi försöker röra oss mot, vilket är den proaktiva modellen, inte bara handlar om att berätta för människor hur man gör något, utan också att berätta för dem varför de ska göra det på det sättet. Tänk dig att en användare kommer till vårt hjälpcenter och genom andra medel och signaler vet vi att de är en biologistuderande. Vi vill leda den läraren till skräddarsytt innehåll som inte bara visar dem steg-för-steg-instruktioner om hur de ska göra det de vill, utan faktiskt visar dem vilken mall de ska använda för att göra det. Våra specialiserade team – i detta exempel utbildningsteamet – arbetar på att tillhandahålla bättre, mer informativa användningsfall.

Så om en kund läser om hur man använder en viss funktion, kan vi fånga några av produktinsignaler från andra användare som har använt den funktionen och ge den informationen till kunden, tillsammans med andra funktioner som liknande användare har arbetat med. Så tar vi det konceptet till hjälpcentret och säger: "Okej, du har precis läst en artikel om presentationer. Nu bör du läsa denna artikel om lager och visa och dölja olika lager eftersom vi vet att de två funktionerna går hand i hand i produkten." Det är lite av vad vi försöker uppnå.

Så hur formaliserar du denna strategi till mål? Det låter som att dina mål går bortom att bara hålla biljettvolymen platt och minska första svarstiden.

Vår "heliga graal" för supportmetrik är att koppla vad en användare gör i hjälpcentret till vad de sedan gör i produkten. När man tittar på en speciell artikel, säg om datalänkning, vill vi ha ett mål som: av varje 1 000 användare som läser den artikeln, går 700 av dem sedan in i produkten och använder datalänkning-funktionen. Och på senaste tid har vi kunnat koppla användandet av hjälpcentret tillbaka till användandet av produkten. Så vi kan sedan extrapolera därifrån och hitta korrelationer mellan hjälpcenteranvändning och produktanvändning.

Det är vad jag tycker är kärnan i vad vi försöker göra: öka användningen av vår produkt. Och att sedan kunna sätta ett värde på användarretention. Vi kan då säga att om vi jämför 1 000 användare som besökte hjälpcentret med 1 000 som inte gjorde det, gick våra retention rates upp denna procentandel eftersom vi lärde dem något värdefullt. Eller till och med gå ett steg längre och se om deras engagemangsgrader också ökade.

Jag älskar det. Jag har pratat med flera CX-ledare nyligen och temat att support är en intäktsgenerator snarare än en kostnadsavdelning dyker ständigt upp. Du låter som om du anser att den modellen för support driver intäkter istället för att bara orsaka kostnader?

Absolut, men vårt team går till och med längre än så. Många gånger kommer en användare att kontakta oss och de kommer att säga, “Hej, vi älskar att använda Lucidchart, men vi har ett problem med en dokumentimport. Våra importerade dokument ser konstiga ut. Om vi kunde lösa det här problemet skulle vi kunna utöka vår användning av Lucidchart på vårt företag.” Så vi hjälper till med supportproblemet, och sedan skickar vi det vidare till vårt försäljningsteam.

“Under det senaste året var support faktiskt den tredje största källan till försäljningslead på företaget. Om du ser på beloppet av intäkter som kommer in genom denna kanal av support överstiger det långt de löner som teamet får. Så vi är faktiskt INTE en kostnadsavdelning alls.”

Det är extremt imponerande! Vilka andra mätetal följer ert team? Och vilka mätetal skulle du rekommendera att andra supportledare som beundrar er modell följer?

En av de saker som vi är stolta över är hur snabbt hjälpcenter- och gemenskapswebbplatser växer – det vi kallar skalenlig support – jämfört med en-till-en-support, vilket är e-post, telefonsamtal och chattstöd.

Ett sätt att mäta tillväxten av en-till-en-support är att se på hur många e-postmeddelanden per användarbas. Så vi följer hur snabbt vår användarbas växer, och vi följer hur snabbt varje vår supportplattform växer, och sedan normaliserar vi en över den andra för att ta reda på antalet e-postmeddelanden som skickas per 10 000 aktiva användare av produkten. Och i kontrast, hur många visningar av hjälpcentrets sidor får vi per 10 000 aktiva användare av produkten.

Om jag ser på en-till-en-support-sidan, det är mer traditionellt: vi ser på saker som första svarstid, kundnöjdhet och vad vi kallar användarväntetid, vilket är den tid det tar från det att en biljett har skickats in till den är löst, minus den tid vi väntar på att kunden ska återkomma med mer information.

När vi ser på skalenlig support, är det lite annorlunda än en-till-en-support. Så, av de användare som använder skalenlig support – oavsett om det är hjälpcentret eller gemenskapen – vad gör de då i produkten? Vad är deras retention rate för sju dagar kontra retention rate för 30 dagar kontra retention rate för personer som inte använder hjälpcentret? Och sedan kan vi också koppla det till intäkter också. Folk som besöker hjälpcentret, tenderar de att uppgradera mer? Tenderar de att öka antalet användare på sitt konto? Jag skulle säga att de är de stora mätetalen som vi har följt, men detta förblir fortfarande ett arbete i processen.

Du nämnde något tidigare om att gräva i hur ofta en viss artikel i ert hjälpcenter används och att dessa data informerar framtida produktbeslut. Det talar lite om vad vi gör på Guru i termer av kunskap, så hur tänker du på de data och den kunskap som ni samlar genom ert hjälpcenter som spelar in i er strategi?

Det är en bra fråga. Vi gillar alltid att säga att vår en-till-en support informerar vår skalenliga support. Så om vi ser ett problem som tar fart i gemenskapen, som om en användare lägger upp något i gemenskapen som de vill veta hur man gör något och vi ser att det får många visningar, så kommer vi faktiskt att uppgradera det till en artikel i hjälpcentret och lokalisera det för att driva ännu mer trafik till den. Och sedan, om jag ser på biljettvolymerna, kan samma sak sägas. Om vi får många e-postmeddelanden om hur man gör något i produkten, så kommer vi att titta på dessa e-postmeddelanden och tänka, “Okej, gör detta mer meningsfullt som ett gemenskapsinlägg eller som en artikel i hjälpcentret?” Så det finns någon typ av denna gradueringsprocess där om vi ser många e-postmeddelanden om något, så går det vidare till ett gemenskapsinlägg. Om det sedan får mycket trafik, går det vidare till en artikel i hjälpcentret.

Och sedan kan vi mäta framgången i vad vi gör. Så när vi skapar denna artikel i hjälpcentret, kan vi sedan gå tillbaka och se om vi fått en minskning av dessa typer av biljetter eftersom vi nu driver mer trafik till den skalenliga supporten.

Den sista biten handlar om sidvisningar. Sidvisningar kan ofta ersätta e-postvolym för oss. Om vi får ett gemenskapsinlägg som är en funktionsförfrågan, kan vi visa engagemanget och sidvisningarna på det gemenskapsinlägget och ta dessa data till ingenjörsteamet och säga, “Hej, det finns efterfrågan på detta. Låt oss få detta på produktens vägkarta.”

Har du några sista tips för supportledare som vill skala sina organisationer som din?

Mina andra tips fokuserar på hur man rekryterar och behåller topptalanger. Många supportorganisationer har stora utmaningar i att deras retentionsnivåer tenderar att vara ganska låga. En av de saker som verkligen har gjort att vi har varit framgångsrika är att vår teamretention är extremt hög. Under de senaste 18 månaderna har endast en medlem av mitt team övergått till något annat, vilket är ganska ovanligt inom detta område. Och de individer som har lämnat mitt team under de senaste tre och ett halvt åren har alla stannat inom Lucid och gått vidare till andra avdelningar, och tagit med sig de användarinsikter de har samlat in till andra delar av företaget. Men jag tror att om du ger människor i supportorganisationen möjligheten att verkligen ta ägande över strategin på hög nivå, snarare än bara att tränga igenom e-postmeddelanden eller ta itu med telefonsamtal, är det verkligen stärkande för dem och hjälper dem att bygga färdigheter som de sedan kan övergå till andra områden, vare sig det är en annan roll på företaget eller internt inom teamet.

Det är den sak som jag gillar att upprepa gång på gång: inkludera teamet i så mycket av strategin som möjligt, eftersom det i slutändan kommer att vara det som håller dem entusiastiska och passionerade och växande.

Vilken bra avslutning. Tack så mycket för din tid, Keyvan! Hur kan våra läsare kontakta dig om de har frågor om din supportfilosofi eller Lucidchart?

Du kan koppla med mig på LinkedIn.