Lucidchart, da Lucid Software, é uma plataforma de produtividade visual que ajuda as pessoas a compartilharem ideias, informações e processos com clareza. Através de um robusto centro de ajuda, comunidade online e assistência um-a-um, a equipe de suporte do Lucidchart atende mais de 15 milhões de usuários felizes, tudo isso enquanto mantém o tamanho da equipe e o volume de tickets estáveis. Conversamos com Keyvan Sadigh, Diretor Sênior de Operações de Clientes no Lucidchart, para descobrir como sua equipe ampliou suas capacidades de suporte e aumentou a receita sem aumentar o tamanho da equipe.

Obrigado por se juntar a nós, Keyvan! Você pode compartilhar um pouco do seu histórico e dar um pouco de contexto sobre como você se tornou Diretor Sênior de Operações de Clientes no Lucidchart?

Claro! Tive uma longa carreira com muitas reviravoltas. Formei-me em Biologia na Cornell e pensei que queria fazer meu doutorado em genética. Trabalhei por dois anos em um laboratório biomédico em Boston fazendo pesquisa em genética e depois decidi que essa vida não era para mim. Fiquei um pouco confuso sobre o que eu queria fazer porque estudei ciência minha vida toda e agora não queria seguir o caminho da pesquisa.

Então, ao invés disso, fiz o Teach for America na Filadélfia, onde ensinei matemática do ensino médio para alunos do primeiro e do terceiro anos por dois anos. Achei que seria uma boa oportunidade para refletir e dar um passo para trás de tudo que eu vinha fazendo. No final do meu tempo lá, comecei a procurar empregos e entrei em contato com um amigo meu que trabalhava no Google e me encorajou a me candidatar a um cargo lá. Entrei no Google em um momento em que eles estavam muito focados em construir seus centros de ajuda. O Gmail era um produto relativamente novo, mas sua base de usuários estava crescendo muito rapidamente. O Google não tinha um número de telefone que as pessoas pudessem ligar ou um e-mail para suporte, então trabalhamos em uma estratégia para construir um centro de ajuda onde os usuários pudessem ajudar a si mesmos e ajudar uns aos outros.

Fiz isso por cerca de quatro anos em diferentes capacidades, e então quis experimentar a gestão de pessoas, então me transferi para o escritório do Google em Dublin, na Irlanda, onde ajudei a lançar sua estratégia comunitária em vários mercados europeus. Então, a ideia era que se pudéssemos fornecer uma plataforma para os usuários se ajudarem, eles poderiam obter uma resposta de alta qualidade muito mais rapidamente do que poderiam de outra forma.

Deveria estar em Dublin por um ano, mas acabei ficando por quase quatro. Eu amei, foi um ótimo momento. Pude gerenciar pessoas de diferentes culturas, o que foi uma experiência muito nova para mim e realmente ótima. No final do meu tempo lá, senti que a empresa era um motor muito bem administrado do qual eu era apenas uma pequena parte e comecei a sentir falta da flexibilidade dos primeiros dias no Google, onde eu poderia ter exposição a muitos tipos diferentes de tarefas e era mais uma filosofia de todos a bordo.

Comecei a olhar para empresas muito menores e queria algo com uma cultura semelhante ao Google, então olhei para o site do Google Ventures para encontrar empresas nas quais o Google estava investindo e a Lucid era uma delas. Nosso CEO, Karl Sun, é na verdade um ex-funcionário do Google também, e o que gostei da minha conversa com ele foi #1, sua ênfase nas pessoas e realmente construir uma cultura que capacita as pessoas a fazerem grandes coisas; e #2, construir uma plataforma, Lucidchart, que permite que as pessoas se comuniquem visualmente através do software.

Isso era um conceito novo para mim. Todos nós sabemos o que significa comunicar visualmente, mas tradicionalmente dependemos de coisas como reuniões, anotações ou planilhas para nos comunicarmos. A Lucid começou a ultrapassar os limites do que as pessoas podem fazer em um navegador e visa nos permitir pensar visualmente de uma maneira mais colaborativa. Então eu realmente acreditei na missão da empresa.

Quando entrei, a equipe de suporte tinha apenas quatro pessoas e estava muito focada em suporte por e-mail. A tarefa que me foi dada era a de que nossa base de usuários estava crescendo extremamente rápido – tinha dobrado a cada ano por quatro ou cinco anos consecutivos – mas estávamos confiantes de que a estratégia certa era permitir que nossos usuários obtivessem suas melhores e mais rápidas respostas ajudando a si mesmos. Então, era isso que eu fui trazido para fazer.

Uau, parece que você realmente obteve a flexibilidade que estava procurando ao mudar de uma equipe de suporte do tamanho do Google para uma equipe de quatro pessoas na Lucidchart!

Com certeza.

Agora que você ampliou a equipe na Lucidchart, ouvi dizer que você manteve sua equipe de suporte estável em 10 pessoas e o volume de tickets plano ao longo dos últimos anos. Que papel ter uma equipe pequena desempenha em sua estratégia de suporte?

Minha estratégia foca realmente em fornecer conteúdo rico que nossa equipe pode medir para permitir que os usuários ajudem a si mesmos a encontrar o que estão procurando. Eu sempre uso o exemplo de um caixa eletrônico para ilustrar isso: Quando você vai a um banco durante o horário comercial normal, você se depara com esta pergunta: Quero entrar no banco, esperar na fila e fazer minha pergunta? Ou quero ajudar a mim mesmo no caixa eletrônico? Normalmente, é no caixa eletrônico. E se aplicarmos essa analogia ao mundo tecnológico, na Lucidchart achamos que um artigo do centro de ajuda muito bem escrito não é apenas suficiente, mas na verdade é preferível para 90% do que nossos usuários estão tentando fazer.

Além disso, o centro de ajuda é realmente uma ótima maneira de medir a demanda por muitas coisas diferentes. Se você puder mostrar que dezenas de milhares de pessoas estão acessando um artigo sobre um certo tópico, você pode então levar essa informação para a engenharia e pressionar por mudanças apoiadas por dados reais dos clientes. Enquanto isso, quando os usuários enviam e-mails para nossa equipe de suporte, o volume tende a ser muito menor e, assim, os dados se tornam menos acionáveis quando os apresentamos à nossa equipe de engenharia. Tem sido ótimo para nós poder mostrar que mesmo que apenas 15 usuários tenham enviado e-mails pedindo um recurso, milhares de usuários visitaram artigos do centro de ajuda também relacionados a esse recurso.

A segunda parte é que nosso conteúdo do centro de ajuda agora está localizado em seis idiomas diferentes, então há um custo inerente em ter conteúdo de alta qualidade escrito pela sua equipe. Então, para conteúdo de cauda longa, fornecemos uma comunidade onde os usuários podem ir para enviar seu próprio conteúdo, e outros usuários podem se beneficiar dele. O exemplo que gosto de usar para esse conceito é que temos um aplicativo Android para a Lucidchart, e há literalmente milhares de telefones Android diferentes, então se um usuário tem um problema com seu telefone específico e como ele interage com nosso software, as chances de conseguirmos acessar aquele telefone específico são bem baixas. Mas um dos nossos 15 milhões de usuários provavelmente tem aquele telefone e pode ter até enfrentado exatamente o mesmo problema. Então, às vezes, nosso papel é conectar nossos usuários uns aos outros para que possam ajudar uns aos outros.

E isso tem sido realmente ótimo de ver porque, quando olhamos para o tráfego do nosso centro de ajuda e da comunidade, ele realmente superou o crescimento da base de usuários. E então, para seu ponto, quando olhamos para o volume de tickets de suporte a produtos nos últimos três anos, ele basicamente permaneceu estável. O que, para mim, implica que os usuários realmente gostam e estão se inclinando para esse modelo de autoajuda.

Quando se trata de sua comunidade online, você tem ideia de que tipo de pessoas estão contribuindo com conhecimento e ajudando outros usuários? É um conceito legal pensar em alguém passando seu próprio tempo pessoal falando sobre seu produto para ajudar pessoas que eles não conhecem.

Nossa comunidade ainda é um trabalho em progresso – muitas vezes os usuários fazem perguntas e somos nós que respondemos a elas na comunidade, mas depois outros usuários ainda podem se beneficiar dessa resposta. No entanto, estamos vendo cada vez mais que outros usuários estão entrando e fornecendo a resposta, que é o melhor cenário para nossos propósitos.

Para responder sua pergunta sobre o por quê, há muito poucos produtos no mundo que os usuários são muito apaixonados, mas tive a sorte de trabalhar em um como o Lucidchart que definitivamente se encaixa nessa categoria. Porque mesmo quando nosso produto não corresponde exatamente às necessidades de um usuário, e eles têm que passar por algumas soluções alternativas malucas para continuar usando-o, eles escolhem fazê-lo.

Um exemplo dessa paixão é um usuário que realmente configurou o aplicativo Lucidchart no iPhone para ser seu calendário diário. Esse é um caso de uso que nossa equipe nunca imaginou para o produto, mas por algum motivo esse usuário decidiu que nossa solução era melhor do que os calendários do Google e da Apple, e apesar do fato de que não focamos nesse caso de uso, ele foi além e se empenhou para fazer funcionar com seu caso de uso.

Portanto, se pensarmos sobre essa mentalidade, muito do que os usuários estão tentando fazer é ultrapassar os limites do que nosso produto é capaz de fazer. E ajudando os outros e compartilhando seus casos de uso, isso alimenta sua paixão. Eles amam esse produto e querem compartilhar essa paixão com os outros.

Isso é incrível. Como sua equipe mantém essas ideias e contribuições dos usuários atualizadas?

Dentro da nossa comunidade, temos uma seção chamada compartilhar seus diagramas; queremos ouvir dos usuários sobre as maneiras novas que estão usando nosso produto. Então, essa é uma maneira como ouvimos sobre alguns desses casos de uso. A maneira mais comum é que nossa equipe ainda está muito envolvida em responder e-mails. Embora o volume de tickets esteja estável, ainda recebemos cerca de 600 e-mails de suporte relacionados ao produto por semana. E então um usuário entra em contato conosco e diz: “Isso é o que estou tentando fazer, mas encontrei este obstáculo. Você se importaria de dar uma olhada no meu documento e me ajudar com este problema?” Frequentemente, os documentos dos quais eles querem ajuda são usos bem diretos de nossos modelos, mas outras vezes vemos alguns casos de uso realmente inovadores de nosso produto, e nesses casos frequentemente perguntaremos se eles não se importariam de postá-los na comunidade para que outros usuários também possam se beneficiar.

Ideias inovadoras que chegam dessa forma alguma vez entram de volta em seu produto? Como você compartilha esse trabalho internamente?

Trabalhamos em parceria com nossas equipes de Sucesso do Cliente e Engenharia de Soluções para elaborar um relatório da Voz do Cliente que compila pedidos de recursos vindos de todos os nossos clientes. E no caso de pedidos de templates, temos uma equipe de templates de produto para a qual enviamos novas ideias geradas por usuários. Essa equipe faz sua própria pesquisa sobre as submissões e depois avalia a possibilidade de adicionar um template oficial ao produto. Temos também uma galeria de templates dentro do nosso centro de ajuda, e parte do conteúdo feito pelos nossos usuários acaba lá e é descobrível desse jeito.

Acho que nossa visão de longo prazo é que o centro de ajuda e a comunidade combinados sejam muito mais um lugar para inspiração e ajuda proativa ao invés de ser um lugar onde os usuários só vão quando algo está quebrado. Queremos levar as pessoas além dessa percepção que ainda é o padrão geral na indústria.

Parece que você está envisionando mais uma via de mão dupla entre sua empresa e seus clientes.

Absolutamente.

Isso me lembra dos valores centrais da Lucid: Trabalho em equipe em vez de ego; inovação em tudo que fazemos; empoderamento individual, iniciativa e propriedade; e paixão e excelência em cada área. Criar uma via de mão dupla fala tanto sobre muitos desses. Como mais você incorpora esses valores centrais em sua abordagem de Experiência do Cliente (CX)?

É legal porque esses valores centrais são estabelecidos em um nível de empresa e ressoam especialmente conosco porque estamos do lado voltado para o cliente da empresa. Além disso, esses valores centrais são algo que enfatizamos em todos os lançamentos da empresa e em todas as atualizações da empresa. E uma vez por ano temos um retiro da empresa onde tiramos três dias de folga para ir a Zion National Park ou Bear Lake para construir equipe e focar em nossa estratégia para o próximo ano e também reafirmar nossos valores centrais a todas as novas pessoas que estão participando de seu primeiro retiro.

Isso é ótimo de ouvir. Tentamos incorporar nossos valores centrais em tudo que fazemos na Guru também.

Então, como sua equipe aborda a educação proativa do cliente? Qual é a divisão entre os lados proativos e reativos de ser uma equipe de CX?

Vamos começar com o reativo, que é algo que acho que fazemos muito bem atualmente. Se um usuário sabe o que está tentando fazer no produto e vem ao nosso centro de ajuda ou comunidade tentando descobrir como fazê-lo, nós forneceremos o conteúdo que eles precisam e muitas vezes suplementaremos com vídeos e capturas de tela para garantir que eles estejam prontos para o sucesso.

Acho que o modelo que estamos tentando avançar, que é o modelo proativo, não é apenas dizer às pessoas como fazer algo, mas também dizer a elas por que fazê-lo dessa forma. Imagine que um usuário vem ao nosso centro de ajuda e, por meio de outros meios e sinais, sabemos que ele é um professor de biologia. Queremos levar esse professor a conteúdo personalizado que não apenas mostra direções passo a passo sobre como fazer o que ele está buscando, mas na verdade mostra qual template usar para fazê-lo. Nossas equipes especializadas – neste exemplo, a equipe de educação – estão trabalhando para fornecer melhores e mais informativas casos de uso.

Se um cliente estiver lendo sobre como usar um determinado recurso, podemos capturar alguns dos sinais de produto de outros usuários que usaram esse recurso e fornecer essas informações ao cliente, junto com outros recursos que usuários semelhantes também trabalharam. Então, pegamos esse conceito e levamos ao centro de ajuda e dizemos: "Ok, você acabou de ler um artigo sobre apresentações. Agora você deve ler este artigo sobre camadas e como mostrar e esconder diferentes camadas porque sabemos que esses dois recursos andam juntos no produto." Isso é um pouco do que estamos tentando alcançar.

Como você formaliza essa estratégia em metas? Parece que suas metas vão além de apenas manter o volume de tickets estável e reduzir o tempo de resposta inicial.

Nosso “Santo Graal” para métricas de suporte é vincular o que um usuário faz no centro de ajuda ao que ele faz em seguida no produto. Ao olhar para um artigo específico, digamos sobre vinculação de dados, queremos então ter uma meta como: de cada 1.000 usuários que leem esse artigo, 700 deles entram no produto e usam o recurso de vinculação de dados. E, recentemente, conseguimos vincular o uso do centro de ajuda de volta ao uso do produto. Assim, podemos extrapolar a partir disso e encontrar correlações entre o uso do centro de ajuda e o uso do produto.

Isso, eu acho, é realmente o cerne do que estamos tentando fazer: aumentar o uso do nosso produto. E então ser capaz de atribuir um valor à retenção dos usuários. Podemos então dizer que, se compararmos 1.000 usuários que visitaram o centro de ajuda com 1.000 que não visitaram, nossas taxas de retenção aumentaram essa porcentagem porque ensinamos algo valioso a eles. Ou mesmo indo um passo além da retenção e verificando se suas taxas de engajamento também aumentaram.

Eu adoro isso. Recentemente, conversei com vários líderes de CX e o tema de suporte como um gerador de receita, e não como um centro de custo, continua aparecendo. Você parece assinar esse modelo de suporte que pode gerar receita e não apenas incorrer custos?

Absolutamente, mas nossa equipe vai ainda além. Muitas vezes, um usuário nos contata e diz: “Ei, adoramos usar o Lucidchart, mas estamos tendo um problema com a importação de um documento. Nossos documentos importados estão com aparência estranha. Se conseguíssemos resolver esse problema, poderíamos expandir nosso uso do Lucidchart na nossa empresa.” Então, ajudaremos com o problema de suporte e, em seguida, passaremos para nossa equipe de vendas.

“No último ano, o suporte foi, na verdade, a terceira maior fonte de leads de vendas na empresa. Se você olhar para a quantidade de receita gerada por esse canal de suporte, ela supera em muito os salários do que a equipe está sendo paga. Portanto, na verdade, não somos um centro de custo de forma alguma.”

Isso é extremamente impressionante! Quais outras métricas sua equipe rastreia? E quais métricas você recomendaria que outros líderes de suporte que admiram seu modelo rastreassem?

Uma das coisas que nos orgulhamos é o quão rapidamente o centro de ajuda e os sites da comunidade estão crescendo – o que chamamos de suporte em escala – em comparação com o suporte um a um, que é e-mails, chamadas telefônicas e suporte por chat.

Uma maneira de medir o crescimento do suporte um a um é olhando para o número de e-mails por base de usuários. Então, rastreamos quão rapidamente nossa base de usuários está crescendo e como rapidamente cada uma de nossas plataformas de suporte está crescendo, e depois normalizamos uma em relação à outra para descobrir o número de e-mails enviados por 10.000 usuários ativos do produto. E, em contraste, quantas visualizações de página do centro de ajuda estamos recebendo por cada 10.000 usuários ativos do produto.

Se eu olhar para o lado do suporte um a um, isso é mais tradicional: olhamos para coisas como o tempo de resposta inicial, satisfação do cliente e o que chamamos de tempo de espera do usuário, que é o tempo que leva desde que um ticket é enviado até ser resolvido, subtraindo qualquer tempo que estamos esperando para que o cliente nos retorne com mais informações.

Quando olhamos para o suporte em escala, é um pouco diferente do suporte um a um. Então, entre os usuários que estão usando suporte em escala – seja o centro de ajuda ou a comunidade – o que eles estão fazendo no produto? Qual é a taxa de retenção de sete dias versus a taxa de retenção de 30 dias versus a taxa de retenção de pessoas que não estão usando o centro de ajuda? E então, também podemos vincular isso à receita. As pessoas que estão visitando o centro de ajuda, tendem a fazer upgrade mais? Elas tendem a expandir o número de usuários em sua conta? Eu diria que essas são as principais métricas que temos rastreado, embora isso continue sendo um trabalho em andamento.

Você disse algo antes sobre investigar com que frequência um determinado artigo em seu centro de ajuda é usado e que esses dados informam decisões futuras de produtos. Isso se relaciona um pouco ao que fazemos no Guru em termos de conhecimento, então como você pensa sobre os dados e o conhecimento que você coleta através do seu centro de ajuda em relação à sua estratégia?

Essa é uma ótima pergunta. Sempre gostamos de dizer que nosso suporte um a um informa nosso suporte em escala. Então, se vemos um problema que está crescendo na comunidade, como se um usuário publica algo na comunidade que ele quer saber como fazer algo e vemos que está recebendo muitas visualizações, então, na verdade, atualizaremos isso para um artigo de centro de ajuda e o localizaremos para gerar ainda mais tráfego. E então, se eu olhar para os volumes de tickets, a mesma coisa pode ser dita. Se recebemos muitos e-mails sobre como fazer algo no produto, então olharemos para esses e-mails e pensaremos: “Ok, isso faz mais sentido como uma postagem na comunidade ou como um artigo de centro de ajuda?” Então há uma espécie de processo de graduação onde, se vemos muitos e-mails sobre algo, isso passa a ser uma postagem na comunidade. Se isso então gera muito tráfego, passa a ser um artigo de centro de ajuda.

E então, podemos medir o sucesso do que estamos fazendo. Então, uma vez que criamos este artigo do centro de ajuda, podemos voltar e ver se tivemos uma diminuição nesse tipo de tickets porque agora estamos gerando mais tráfego para o suporte escalado.

A última parte se refere às visualizações de página. Visualizações de página para nós podem frequentemente substituir o volume de e-mails. Se recebemos uma postagem na comunidade que é um pedido de recurso, podemos mostrar o engajamento e as visualizações de página dessa postagem na comunidade e levar esses dados para a equipe de engenharia e dizer: “Ei, há demanda para isso. Vamos colocar isso no cronograma do produto.”

Você tem alguma dica final para líderes de suporte que desejam escalar suas organizações como a sua?

Minhas outras dicas se concentram em como recrutar e reter os melhores talentos. Muitas organizações de suporte enfrentam grandes desafios, pois sua retenção tende a ser bastante baixa. Uma das coisas que realmente nos permitiu ter sucesso é que a retenção da nossa equipe é extremamente alta. Nos últimos 18 meses, apenas um membro da minha equipe fez a transição, o que é meio que sem precedentes neste campo. E aqueles indivíduos que deixaram minha equipe nos últimos três anos e meio permaneceram todos na Lucid e foram para outros departamentos, levando as percepções de usuários que adquiriram para outras partes da empresa. Mas eu acho que se você empoderar as pessoas na organização de suporte para realmente assumir a propriedade da estratégia de alto nível, em vez de apenas lidar com e-mails ou enfrentar chamadas telefônicas, isso realmente é empoderador para elas e as ajuda a desenvolver habilidades que podem então ser transicionadas para outras áreas, seja outra função na empresa ou internamente dentro da equipe.

Essa é a coisa que gosto de reafirmar repetidamente: inclua a equipe em o máximo possível da estratégia, porque, em última análise, isso será o que os manterá animados, apaixonados e em crescimento.

Que ótima maneira de terminar. Muito obrigado pelo seu tempo, Keyvan! Como nossos leitores podem entrar em contato com você se tiverem perguntas sobre sua filosofia de suporte ou Lucidchart?

Você pode se conectar comigo no LinkedIn.