Eu j\u00e1 tive um cliente que tinha implementado a nossa solu\u00e7\u00e3o, mas praticamente n\u00e3o a usava no dia a dia.<\/p>\n\n\n\n
Na verdade, ele tinha constru\u00eddo uma solu\u00e7\u00e3o interna, uma esp\u00e9cie de “puxadinho”, para fazer parte do que a nossa plataforma j\u00e1 fazia. A nossa solu\u00e7\u00e3o estava l\u00e1, implementada, e at\u00e9 era usada, mas principalmente para conferir se os dados gerados internamente estavam corretos.<\/p>\n\n\n\n
Se eu olhasse apenas para a implementa\u00e7\u00e3o, poderia dizer que estava tudo certo. Se olhasse para alguns sinais de uso, poderia at\u00e9 concluir que o cliente estava avan\u00e7ando.<\/p>\n\n\n\n
Mas ele realmente estava adotando a solu\u00e7\u00e3o? N\u00e3o.<\/strong><\/p>\n\n\n\n E, se n\u00e3o estava adotando, dificilmente chegar\u00edamos ao valor que ele esperava quando decidiu comprar.<\/p>\n\n\n\n Esse caso me fez pensar em uma distin\u00e7\u00e3o que considero cada vez mais importante em Customer Success: implementa\u00e7\u00e3o, uso, ado\u00e7\u00e3o, valor e resultado n\u00e3o s\u00e3o a mesma coisa<\/strong>.<\/p>\n\n\n\n E entender a diferen\u00e7a entre elas pode mudar completamente a maneira como voc\u00ea trabalha uma conta.<\/p>\n\n\n\n Quando pensamos na jornada de um cliente, gosto de separar cinco etapas:<\/strong><\/p>\n\n\n\n IMPLEMENTA\u00c7\u00c3O \u2192 USO \u2192 ADO\u00c7\u00c3O \u2192 VALOR \u2192 RESULTADO<\/em><\/p>\n\n\n\n A primeira \u00e9 a implementa\u00e7\u00e3o.<\/p>\n\n\n\n Aqui, a pergunta \u00e9 relativamente simples: a solu\u00e7\u00e3o est\u00e1 pronta para ser usada?<\/p>\n\n\n\n Ela funciona corretamente? As pessoas certas t\u00eam acesso? Elas sabem como come\u00e7ar? Existe alguma barreira t\u00e9cnica ou operacional impedindo o primeiro uso?<\/p>\n\n\n\n Por exemplo, voc\u00ea pode ter conclu\u00eddo o onboarding e considerar a implementa\u00e7\u00e3o finalizada, mas descobrir que parte dos usu\u00e1rios ainda n\u00e3o tem acesso, uma integra\u00e7\u00e3o importante n\u00e3o est\u00e1 funcionando ou ningu\u00e9m deixou claro para o time o que ele deve fazer primeiro dentro da plataforma.<\/p>\n\n\n\n Tudo isso importa, mas a implementa\u00e7\u00e3o ainda significa apenas que criamos as condi\u00e7\u00f5es para que alguma coisa aconte\u00e7a.<\/strong><\/p>\n\n\n\n O passo seguinte \u00e9 o uso.<\/p>\n\n\n\n Agora queremos saber se as pessoas certas est\u00e3o realmente utilizando a solu\u00e7\u00e3o, para qual caso de uso e com qual frequ\u00eancia.<\/p>\n\n\n\n Por exemplo, imagine que 10 pessoas deveriam utilizar determinada funcionalidade semanalmente, mas apenas cinco est\u00e3o usando, ou que existe bastante atividade na plataforma, mas concentrada em uma funcionalidade que n\u00e3o tem rela\u00e7\u00e3o com o principal caso de uso definido com o cliente. Existe uso, mas ele talvez n\u00e3o seja o uso que esper\u00e1vamos.<\/p>\n\n\n\n E aqui come\u00e7a uma confus\u00e3o bastante comum, pois ver atividade dentro de uma plataforma n\u00e3o significa necessariamente que houve ado\u00e7\u00e3o.<\/strong><\/p>\n\n\n\n Um cliente pode fazer login. Pode executar determinadas a\u00e7\u00f5es. Pode at\u00e9 aparecer bem nos seus dashboards de uso.<\/p>\n\n\n\n Mas a pergunta que eu faria \u00e9: isso entrou de verdade na maneira como ele trabalha?<\/strong><\/p>\n\n\n\n \u00c9 a\u00ed que come\u00e7a a ado\u00e7\u00e3o.<\/strong><\/p>\n\n\n\n Quando uma solu\u00e7\u00e3o \u00e9 adotada, ela deixa de ser algo que o cliente simplesmente acessa e come\u00e7a a fazer parte do seu fluxo de trabalho<\/strong>. Existe recorr\u00eancia, existe uma mudan\u00e7a de comportamento e aquela solu\u00e7\u00e3o passa a ocupar um papel claro na maneira como o trabalho \u00e9 realizado.<\/p>\n\n\n\n Por exemplo, n\u00e3o \u00e9 apenas o time entrar na plataforma toda semana. \u00c9 uma reuni\u00e3o que antes era preparada manualmente passar a usar aqueles dados como parte do processo, ou uma an\u00e1lise que acontecia em uma planilha paralela passar a acontecer dentro da solu\u00e7\u00e3o. Alguma coisa na maneira de trabalhar mudou.<\/strong><\/p>\n\n\n\n Uma pergunta que pode ajudar a identificar isso \u00e9:<\/p>\n\n\n\n Se essa solu\u00e7\u00e3o desaparecesse amanh\u00e3, alguma coisa relevante na rotina desse cliente mudaria?<\/em><\/p>\n\n\n\n Se a resposta for n\u00e3o, talvez exista uso, mas ainda n\u00e3o exista ado\u00e7\u00e3o.<\/p>\n\n\n\n E mesmo ado\u00e7\u00e3o n\u00e3o \u00e9 o fim dessa jornada.<\/strong><\/p>\n\n\n\n Podemos ter uma solu\u00e7\u00e3o incorporada \u00e0 rotina e ainda precisar responder uma pergunta muito mais importante: isso est\u00e1 gerando valor?<\/p>\n\n\n\n Para mim, aqui precisamos voltar ao motivo<\/strong> pelo qual o cliente comprou.<\/p>\n\n\n\n O que ele queria melhorar? Qual problema precisava resolver? O que esperava fazer de forma diferente?<\/p>\n\n\n\n Valor aparece quando conseguimos conectar a ado\u00e7\u00e3o a algo que importa para aquele cliente<\/strong> e, principalmente, quando ele tamb\u00e9m consegue reconhecer<\/strong> essa conex\u00e3o.<\/p>\n\n\n\n Talvez o processo tenha ficado mais simples. Talvez uma equipe tenha ganhado tempo. Talvez uma decis\u00e3o tenha ficado mais f\u00e1cil. Talvez uma atividade que antes exigia v\u00e1rias etapas agora aconte\u00e7a de outra forma.<\/p>\n\n\n\n Por exemplo, se o cliente comprou a solu\u00e7\u00e3o porque levava horas para consolidar informa\u00e7\u00f5es de diferentes fontes, o valor pode aparecer quando ele passa a ter essas informa\u00e7\u00f5es dispon\u00edveis em um \u00fanico lugar e consegue tomar decis\u00f5es com muito menos esfor\u00e7o. N\u00e3o estamos olhando apenas para quantas vezes ele acessou a plataforma, mas para o que ficou melhor para ele depois que passou a utiliz\u00e1-la.<\/p>\n\n\n\n Mas eu ainda colocaria mais uma etapa depois de valor: resultado<\/strong>.<\/p>\n\n\n\n Perceber valor e conseguir demonstrar o impacto desse valor tamb\u00e9m s\u00e3o coisas diferentes.<\/strong><\/p>\n\n\n\n Se o objetivo inicial era melhorar a efici\u00eancia, conseguimos mostrar o que mudou? Se era aumentar receita, reduzir custos, diminuir risco ou melhorar alguma m\u00e9trica operacional, existe evid\u00eancia dessa mudan\u00e7a?<\/p>\n\n\n\n Por exemplo, se o cliente queria reduzir o tempo gasto naquele processo, podemos mostrar que algo que levava cinco horas agora leva duas? Se queria aumentar uma determinada convers\u00e3o, conseguimos comparar o indicador antes e depois? Aqui come\u00e7amos a sair da percep\u00e7\u00e3o de que “isso est\u00e1 ajudando” para uma evid\u00eancia concreta do impacto<\/strong>.<\/p>\n\n\n\n \u00c9 por isso que, para mim, a jornada n\u00e3o termina em ado\u00e7\u00e3o.<\/p>\n\n\n\n IMPLEMENTA\u00c7\u00c3O \u2192 USO \u2192 ADO\u00c7\u00c3O \u2192 VALOR \u2192 RESULTADO<\/em><\/p>\n\n\n\n A ado\u00e7\u00e3o \u00e9 importante, mas ela \u00e9 parte do caminho.<\/p>\n\n\n\n Depois de identificar onde o cliente est\u00e1, existe uma segunda pergunta que considero ainda mais interessante:<\/p>\n\n\n\n O que est\u00e1 impedindo esse cliente de avan\u00e7ar?<\/em><\/strong><\/p>\n\n\n\n Porque o mapa, sozinho, n\u00e3o resolve o problema.<\/p>\n\n\n\n Imagine dois clientes que implementaram uma solu\u00e7\u00e3o e ainda n\u00e3o chegaram \u00e0 ado\u00e7\u00e3o. \u00c0 primeira vista, os dois poderiam parecer ter o mesmo problema. Mas um pode n\u00e3o saber como incorporar a solu\u00e7\u00e3o \u00e0 rotina, enquanto o outro pode simplesmente n\u00e3o confiar nela.<\/p>\n\n\n\n A etapa \u00e9 a mesma. A barreira \u00e9 completamente diferente.<\/strong><\/p>\n\n\n\n Por isso, gosto de pensar no mapa desta forma:<\/p>\n\n\n\n IMPLEMENTA\u00c7\u00c3O \u2192 [barreira] \u2192 USO \u2192 [barreira] \u2192 ADO\u00c7\u00c3O \u2192 [barreira] \u2192 VALOR \u2192 [barreira] \u2192 RESULTADO<\/em><\/p>\n\n\n\n Essas barreiras podem aparecer de muitas formas.<\/p>\n\n\n\n Pode faltar conhecimento. Pode existir um problema de processo. As pessoas podem n\u00e3o entender por que deveriam mudar a maneira como trabalham. Pode faltar alinhamento entre as \u00e1reas. O cliente pode ter perdido clareza sobre o objetivo inicial. Pode existir dificuldade para medir o resultado.<\/p>\n\n\n\n Por exemplo, um cliente pode estar usando uma funcionalidade apenas porque algu\u00e9m determinou que ela deveria ser usada, mas o time nunca entendeu qual problema ela resolve<\/strong>. Outro pode ter adotado completamente a solu\u00e7\u00e3o, mas n\u00e3o ter definido no in\u00edcio nenhuma m\u00e9trica<\/strong> que permita demonstrar o impacto. Em ambos os casos existe uma barreira, mas a interven\u00e7\u00e3o necess\u00e1ria seria diferente.<\/p>\n\n\n\n Ou pode ser confian\u00e7a.<\/strong><\/p>\n\n\n\n Que era exatamente o que estava acontecendo com aquele cliente do in\u00edcio deste texto.<\/p>\n\n\n\n Quando come\u00e7amos a investigar por que aquele cliente n\u00e3o avan\u00e7ava, percebemos que simplesmente tentar aumentar o uso n\u00e3o resolveria o problema.<\/p>\n\n\n\n A solu\u00e7\u00e3o estava implementada e existia algum uso. Mas ela n\u00e3o tinha sido realmente incorporada<\/strong> \u00e0 maneira como o cliente trabalhava.<\/p>\n\n\n\n E o motivo era confian\u00e7a.<\/strong><\/p>\n\n\n\n O cliente confiava mais nos dados da solu\u00e7\u00e3o que havia constru\u00eddo internamente do que nos nossos. Por isso, usava a nossa plataforma principalmente como uma forma de conferir se os pr\u00f3prios dados estavam corretos.<\/p>\n\n\n\n Quando entendemos isso, nossa a\u00e7\u00e3o mudou.<\/strong><\/p>\n\n\n\n Em vez de simplesmente incentivar mais uso, come\u00e7amos a trabalhar a barreira<\/strong> que estava impedindo esse uso de evoluir. Foram muitas conversas, acompanhamento e demonstra\u00e7\u00f5es de que a plataforma j\u00e1 conseguia entregar coisas que o cliente estava tentando reconstruir internamente.<\/p>\n\n\n\n Aos poucos, a confian\u00e7a aumentou. E, com ela, o cliente come\u00e7ou a avan\u00e7ar.<\/strong><\/p>\n\n\n\n Se tiv\u00e9ssemos olhado apenas para uma m\u00e9trica de uso, provavelmente ter\u00edamos tentado resolver o problema errado<\/strong>.<\/p>\n\n\n\n Voc\u00ea n\u00e3o precisa transformar isso em um exerc\u00edcio enorme.<\/p>\n\n\n\n Escolha uma conta e comece tentando responder:<\/strong><\/p>\n\n\n\n Ela implementou? Est\u00e1 usando? Realmente adotou? Est\u00e1 percebendo valor? Existe um resultado que conseguimos demonstrar?<\/p>\n\n\n\n Depois, tente identificar qual \u00e9 a evid\u00eancia que sustenta sua resposta.<\/p>\n\n\n\n Por exemplo, n\u00e3o responda apenas “sim, ele adotou”. Procure a evid\u00eancia: o processo que antes acontecia em outro lugar agora acontece dentro da solu\u00e7\u00e3o, a equipe passou a utiliz\u00e1-la como parte de uma rotina recorrente ou um fluxo de trabalho foi alterado depois da implementa\u00e7\u00e3o. Da mesma forma, para dizer que existe resultado, procure algo que voc\u00ea consiga comparar, medir ou demonstrar.<\/p>\n\n\n\n E, principalmente, olhe para o espa\u00e7o entre a etapa atual e a pr\u00f3xima.<\/strong><\/p>\n\n\n\n O que est\u00e1 impedindo esse cliente de avan\u00e7ar? \u00c9 conhecimento? Processo? Comportamento? Confian\u00e7a? Alinhamento? Falta de clareza sobre o objetivo? Dificuldade de medir o impacto?<\/p>\n\n\n\n Por exemplo, se o cliente est\u00e1 usando, mas ainda n\u00e3o adotou, voc\u00ea pode descobrir que o problema n\u00e3o \u00e9 falta de treinamento, mas que o processo atual continua sendo mais f\u00e1cil para o time. Nesse caso, oferecer mais uma sess\u00e3o de treinamento provavelmente n\u00e3o vai resolver a barreira. Voc\u00ea precisaria entender a rotina do cliente e o que teria que mudar para a solu\u00e7\u00e3o realmente entrar nela.<\/p>\n\n\n\n A partir da\u00ed, a conversa muda.<\/p>\n\n\n\n Em vez de partir direto para “precisamos aumentar a ado\u00e7\u00e3o”, voc\u00ea consegue investigar qual problema precisa resolver para que a ado\u00e7\u00e3o aconte\u00e7a e continue avan\u00e7ando em dire\u00e7\u00e3o ao valor e ao resultado.<\/strong><\/p>\n\n\n\n Foi exatamente essa diferen\u00e7a que mudou a forma como trabalhamos aquele cliente.<\/p>\n\n\n\n E \u00e9 para isso que eu uso este mapa: n\u00e3o apenas para saber onde uma conta est\u00e1, mas para entender qual deve ser o pr\u00f3ximo passo.<\/strong><\/p>\n\n\n\n Se voc\u00ea tem uma conta espec\u00edfica<\/strong> e n\u00e3o consegue entender onde ela est\u00e1 travada<\/strong>, qual \u00e9 a barreira <\/strong>ou o que deveria fazer a seguir, podemos trabalhar esse caso juntos na mentoria.<\/strong><\/p>\n\n\n\n Na sess\u00e3o, analisamos o contexto da conta, identificamos onde o cliente realmente est\u00e1 e constru\u00edmos um pr\u00f3ximo passo que fa\u00e7a sentido para o seu cen\u00e1rio.<\/p>\n\n\n\nImplementar \u00e9 apenas o come\u00e7o<\/strong><\/h2>\n\n\n\n
Uso e ado\u00e7\u00e3o n\u00e3o s\u00e3o a mesma coisa<\/strong><\/h2>\n\n\n\n
O cliente adotou. E da\u00ed?<\/strong><\/h2>\n\n\n\n
Talvez a parte mais importante do mapa esteja entre as etapas<\/strong><\/h2>\n\n\n\n
Voltando ao “puxadinho”<\/strong><\/h2>\n\n\n\n
Em qual etapa seus clientes realmente est\u00e3o?<\/strong><\/h2>\n\n\n\n
Quer ajuda para aplicar isso em uma conta real?<\/strong><\/h2>\n\n\n\n