Castro Podcasts: por que a tentativa de construir relacionamento via suporte ao cliente deu errado
(uncommonapps.nyc)- Após adquirir o Castro, tentou diferenciar o produto com um suporte humano: usar o produto todos os dias e responder a todos os e-mails, mas isso não gerou tanta lealdade ou boa vontade dos clientes quanto o esperado
- Quando era possível dar uma solução correta de imediato, a satisfação era alta, mas a maioria das respostas cuidadosas acabava desalinhada com as expectativas dos usuários e às vezes aumentava a frustração
- Consultas sobre preço da assinatura, bugs difíceis de reproduzir e pedidos de recursos podiam servir como sinal para melhorar o produto, mas eram difíceis de transformar em solução suficiente para o cliente apenas com uma resposta
- Problemas complexos que uma pessoa conseguia resolver, como conta e assinatura da App Store, tiveram boa receptividade, mas esse tipo representava menos de 1% de todos os e-mails de suporte
- Para a equipe do Castro, funcionava melhor ler os e-mails e focar em melhorar o produto do que escrever longas explicações, e as experiências positivas vinham mais de melhorias reais no produto do que das conversas de suporte
O modelo de suporte que o Castro esperava
- Ao adquirir o Castro, a avaliação foi que um suporte humano baseado na experiência real de uso poderia ser um diferencial fácil
- Como quase nunca recebia respostas úteis do suporte ao cliente dos serviços que usava no dia a dia, esperava-se que os clientes valorizassem o fato de usar o produto pessoalmente todos os dias, ler todos os e-mails e responder com atenção
- Quando o volume de e-mails ficou grande demais para ser administrado, foi pago a um usuário que conhecia bem o produto e enviava e-mails com frequência para assumir parte das respostas de suporte
- Esse usuário teve um desempenho especialmente bom em resolver diretamente os problemas dos usuários
- O resultado foi diferente do esperado
- Quando era possível responder na hora e oferecer uma solução exata, dava para surpreender o cliente
- Mas a maioria das respostas diligentes não gerava grande satisfação e, às vezes, deixava a pessoa ainda mais irritada
Perguntas sobre assinatura e preço
- E-mails sobre assinatura e preço quase não ajudavam a construir relacionamento
- O Castro já tinha pensado bastante no preço e no modelo de assinatura, e um único e-mail não mudaria a política
- Era possível explicar por que valia a pena pagar por um app essencial ou por que software combina bem com assinatura, mas em geral os usuários não ficavam satisfeitos com essa resposta
- Em dois anos, houve talvez uma única pessoa que recebeu com surpresa positiva a ideia de que a assinatura fazia sentido porque software custa dinheiro e exige trabalho diário
- Em 99% dos casos, por mais cuidadosa e gentil que fosse a explicação, a resposta seguinte vinha mais negativa do que o e-mail inicial
- Também foi testado oferecer mais 30 dias de teste para quem pedisse, mas isso não mudou o tom das conversas, e a taxa de conversão desse teste foi bem menor do que a do teste gratuito normal
O que os relatos de bug sinalizam, e seus limites
- E-mails sobre bugs são realmente úteis para quem os recebe
- Eles ajudam a identificar problemas que os usuários enfrentam todos os dias
- Se o bug já era conhecido e estava sendo corrigido, ou já tinha sido corrigido, era possível dar uma resposta satisfatória ao cliente
- Por causa da forma como a App Store distribui atualizações, também era comum que o bug já estivesse corrigido, mas ainda não liberado
- O problema é que muitos bugs não se encaixavam nesse caso ideal
- Havia bugs já relatados antes, mas que não podiam ser confirmados ou reproduzidos diretamente
- Isso acabava sendo uma experiência ruim para os dois lados, porque o usuário precisava fazer trabalho adicional ou não conseguia uma solução
- Muito ocasionalmente chegavam relatos detalhados com passos de reprodução ou condições relevantes
- Também havia bugs que estavam sendo relatados pela primeira vez
- O usuário podia fornecer detalhes, mas se o problema não aparecesse para outras pessoas, ele provavelmente cairia em baixa prioridade
- Também chegavam e-mails em que tudo se resumia a “não funciona”
- Sem informações adicionais do usuário, quase não havia o que fazer
- Havia ainda problemas já conhecidos, mas com correção grande demais, impacto pequeno demais ou número pequeno demais de pessoas afetadas, o que os deixava em baixa prioridade
- Havia bugs já relatados antes, mas que não podiam ser confirmados ou reproduzidos diretamente
- Esse tipo de resposta não criava proximidade significativa
- Dar uma resposta honesta próxima de “não consigo resolver isso hoje e nem vou tentar” podia ser uma experiência muito ruim para o usuário
- E-mails de suporte eram úteis como sinal de problema, mas o Castro normalmente obtinha dados melhores por telemetria e logs de crash
Os raros casos em que a intervenção humana realmente ajuda
- Às vezes chegavam perguntas complexas sobre o processo da App Store, problemas da loja, regiões específicas ou questões muito particulares de podcast
- Um usuário tinha assinatura do Castro em duas contas diferentes em momentos diferentes e queria encerrar uma delas sem perder o período já pago
- O Castro resolveu isso rapidamente, e esse tipo de agilidade era algo pelo qual os usuários realmente demonstravam gratidão
- Ainda assim, essas consultas representavam menos de 1% de todos os e-mails de suporte, então tinham peso pequeno demais para transformar suporte em estratégia de diferenciação
Clientes confusos e o peso da repetição
- Em alguns casos, clientes enviavam e-mails porque estavam confusos sobre como podcasts funcionam, como a App Store funciona, como usar o Mac ou outros problemas do entorno
- Esse tipo de caso era o mais próximo do relacionamento com clientes que se imaginava construir, mas teve os piores resultados
- O mesmo usuário tendia a voltar repetidamente, e, ao perceber que o Castro respondia, os pedidos ficavam mais frequentes e mais pesados
- Em vez de construir relacionamento e lealdade, o efeito prático era gastar muito tempo com quem mais exigia
- Essas pessoas não pagavam uma assinatura maior
- Raramente ficavam satisfeitas
- No fim, surgia a sensação de estar sendo explorado
Pedidos de recursos e direção do produto
- Pedidos de recursos e feedback geral parecem bons em teoria e às vezes são úteis, mas frequentemente vinham de um grupo pequeno e pouco representativo de usuários com opiniões fortes
- Implementar sugestões recebidas por e-mail aumenta bastante a chance de acabar recebendo um roadmap completo do produto
- O Castro é um app com direção clara, e já havia muita reflexão sobre o que construir e o que fazer em seguida
- A probabilidade de um pedido de recurso ser realmente implementado era baixa
- Se o produto fosse ajustado demais para power users exigentes, haveria o risco de afastar novos usuários que ainda não entendem bem como ele funciona
- Power users são, em termos relativos, um público que tende menos a abandonar o produto
- Afastar novos usuários seria algo fatal para o produto
- Do ponto de vista do usuário, qualquer resposta que não fosse “vamos fazer isso agora” costumava ser recebida de forma morna ou negativa
- Mesmo respostas honestas dizendo que a ideia já tinha sido considerada ou testada no passado, mas não funcionou bem, pouco ajudavam a criar lealdade ou proximidade
O modelo de operação de suporte que o Castro escolheu
- Para o Castro, investir tempo demais em suporte não era um diferencial, e frequentemente tinha efeito contrário
- Clientes que pagam assinatura, mas não pedem nada grátis por e-mail, merecem um app tão bom quanto aqueles que escrevem toda semana
- Quando há uma solução clara ou uma correção concreta para um problema específico, faz sentido agir de forma ativa
- Nos outros casos, funcionava melhor responder brevemente que o e-mail foi recebido com gratidão, está sendo lido e que o produto continuará sendo trabalhado para melhorar o problema
- Evitar explicações longas e detalhes geralmente gerava uma reação neutra, sem arrastar ninguém para conversas prolongadas ou gasto excessivo de tempo
- Para o Castro, o jeito que a maioria das empresas opera foi o que melhor funcionou
- É difícil construir lealdade ou proximidade no momento em que o usuário está frustrado e algo não funciona, e as experiências realmente positivas surgem quando o produto melhora de fato
1 comentários
Opiniões do Hacker News
Raramente recebi uma resposta útil do suporte ao cliente dos serviços que uso. Então pensei que, se eu usasse meu próprio produto todos os dias, lesse todos os e-mails e respondesse com atenção, as pessoas ficariam gratas e surgiriam alguma lealdade e simpatia
Eu opero um app usado por 16.000 pessoas, recebo de 2 a 5 tickets de suporte por semana e leio todos
Cerca de 20% do app foi criado com base em sugestões de usuários, e as pessoas em geral são gentis e divulgam o app gratuitamente em várias plataformas. Não há orçamento de marketing
Os usuários nem sempre expressam gratidão em palavras, mas ajudam ativamente a resolver problemas enviando passos claros para reproduzir bugs, screenshots ou vídeos, e respondendo rapidamente a perguntas de acompanhamento. Às vezes fico surpreso ao ver pessoas recomendando meu app em comentários no Reddit ou no YouTube
Se você está dando um bom suporte aos usuários, é bem provável que eles já estejam retribuindo à sua maneira
Não é um comentário especialmente interessante, mas como parece haver muitas reações negativas, queria acrescentar algum equilíbrio
Acho interessante que tenham feito o experimento, e obrigado por compartilhar os resultados. É um pouco deprimente, mas no geral parece razoável
Dar suporte a clientes corporativos que gastam até milhões de dólares por ano e dar suporte a usuários finais que contam cada centavo gasto são jogos completamente diferentes em termos de expectativas, capacidade técnica, profissionalismo etc.
Acho que este texto resume bem o fato de que nem sempre é possível ajudar todos os usuários. É uma lição difícil de aprender em suporte técnico, e todo mundo quer ser o herói brilhante que resolve o problema do cliente, mas a capacidade de dizer “não” da maneira certa não é comum
Para quem está atacando o autor: há uma quantidade enorme de pessoas que vão reclamar e xingar mesmo que você as pague para usar seu software. Conciliar os interesses do cliente, a pressão de tempo, a saúde mental individual etc. é praticamente o próprio trabalho de suporte técnico
Como é um registro que vale a pena revisitar, enviei imediatamente este texto a alguns fundadores em estágio inicial que estão queimando uma quantidade surpreendente de tempo com clientes indesejáveis
Idealismo não dura muito quando bate de frente com a realidade
O ponto central do texto é este: “Em outras palavras, a melhor abordagem para nós é a que a maioria das empresas adota”
Todo fundador inexperiente começa prometendo que não vai oferecer um suporte horrível como o de grandes empresas como Google ou Comcast, e acredita que isso será um caminho para o sucesso
Mas no fim aprende que precisa oferecer o mesmo nível de suporte que outras empresas do seu mercado oferecem. Mesmo que o suporte seja realmente melhor, ninguém percebe direito, e isso não tem grande significado
Fundadores inexperientes são teimosos, e isso também é uma virtude. Por isso, normalmente só aprendem essa lição depois de passar por ela pessoalmente
Mas o suporte ao estilo de grandes empresas só é inevitável quando a empresa necessariamente precisa escalar. Em muitos mercados, dá para sobreviver muito bem com margens mais altas e produtos e suporte premium
É deprimente ver suporte ao cliente como “diferencial” ou como uma forma de gerar receita. Você deveria simplesmente tentar fazer o que é melhor para o cliente
O feedback que você está recebendo agora é ouro, e, se for tratado corretamente, pode ser aproveitado, não ignorado. A atitude de presumir que quem se opõe ao modelo de preços não entende de negócios também diz muito
É preciso reconhecer que seu modelo de preços é ruim para algumas pessoas, especialmente para quem sofre de fadiga de assinaturas, e decidir se tudo bem perder o dinheiro delas ou nem recebê-lo desde o início
Falta na estratégia de suporte um canal por onde usuários com muitas perguntas possam perguntar, e na prática você está culpando os clientes por falhas da sua própria estrutura. Seria fácil criar algo como um fórum onde usuários avançados se ajudam e os desenvolvedores aparecem de vez em quando para ajudar ou registrar dores
Além disso, os processos de desenvolvimento e garantia de qualidade claramente precisam ser revisados. O motivo pelo qual relatórios de bug parecem “perda de tempo para todos” provavelmente é que o próprio app não tem registro de erros ou telemetria adequados. Ter de esperar por relatórios manuais de bug dos usuários já é uma falha por si só
É totalmente aceitável definir o produto como quiser e recusar pedidos de funcionalidades, mas dizer que você, sentado sozinho numa cadeira, pensou em todos os problemas em comparação com o pensamento distribuído das outras pessoas é bastante arrogante
Um app chamado PhotoSync oferece a opção premium por US$ 1 por mês ou US$ 24 vitalício. Provavelmente porque olharam o tempo médio de assinatura e viram algo perto de 2 anos. Deixando de lado o valor do dinheiro no tempo e os custos de processamento por transação
Pessoalmente, mesmo sem ter certeza de que eu usaria o app depois de 24 meses, preferi muito mais a compra única. Ela combina melhor com meu jeito um tanto confuso de administrar dinheiro
Quando você libera uma atualização para 2% dos usuários, precisa de logs e telemetria suficientes para saber se algo deu muito errado antes de liberar para os outros 98%
Por outro lado, provavelmente você não quer telemetria a ponto de detectar que o cliente Jim Smith tem um problema de WebRTC quando entra numa chamada sem microfone enquanto está com tunelamento dividido do Firefox e do Cloudflare Warp ativado
O autor escreveu que já tem telemetria boa o suficiente e que, por e-mail, não há muito o que dizer ao cliente além de uma resposta genérica como “estamos cientes do problema e agradecemos o relato”, o que não é útil nem para o cliente nem para eles
Na faculdade, trabalhei em uma padaria e, conversando com os clientes que vinham à loja, acabei fazendo alguns amigos de longa data
Mais tarde, usei essa experiência para conseguir um trabalho de suporte por e-mail, respondendo a perguntas de usuários sobre um plugin de software. Mesmo quando um cliente mandava e-mail uma vez por mês, nunca fiz amigos duradouros ali
A diferença é que, no suporte por e-mail/online, não existe esse tempo vazio humano. Na padaria, enquanto o pedido era aquecido ou assado, as pessoas esperavam e a conversa surgia naturalmente. Pelo menos era assim há 10 anos, quando celulares não eram tão onipresentes quanto hoje
Fico me perguntando se, no contexto de software, algo como um “horário aberto de atendimento” mensal no Zoom conseguiria recriar um pouco dessa sensação. Provavelmente não, mas talvez seja melhor do que responder e-mails
Eu me identifiquei com a parte “por mais cuidadosa e gentil que seja a explicação, em 99% dos casos a resposta é mais negativa do que o primeiro e-mail”
Quando atuava como líder de produto, eu gostava de fazer diretamente parte do trabalho de suporte ao cliente, e essa é uma experiência comum. O cliente que escreve um e-mail irritado não se importa com os seus motivos. Ele quer uma tarifa mais barata, um recurso específico, um desconto, um benefício gratuito, e não liga para o resto
Isso é a versão digital do cliente do tipo “quero falar com o gerente”, que acha que, se pressionar de forma grosseira, há nem que seja 10% de chance de conseguir o que quer, então vale a pena insistir até o fim
Às vezes eu tirava uma pequena satisfação de alguém perceber que havia uma pessoa que se importava do outro lado do endereço de e-mail, e nesses momentos parecia valer a pena
Mas, na maioria das vezes, é mais como jogar um jogo transacional em que a pessoa acha que, se reclamar alto o bastante, consegue exercer algum poder sobre a empresa
Também há grandes diferenças culturais nisso. As mensagens de clientes de um dos países em que oferecíamos o serviço eram descontroladamente agressivas. Às vezes havia até ameaças leves de violência, e 90% delas vinham de um único país, cujo nome não vou revelar, mas que acrescentei à minha lista mental de “lugares que não vou visitar”. Era estranho de tão consistente
Nem todos eram negativos; eram apenas diferentes. Em alguns países, as pessoas primeiro fazem elogios longos e depois pedem desconto de forma indireta. Em outros, entram em contato por um problema ou bug legítimo e, depois que é resolvido, esperam uma compensação pelo transtorno. Mesmo quando elas próprias causaram o problema
Em outros lugares, mesmo quando a conversa já poderia estar encerrada, reabriam o ticket todas as vezes para agradecer de forma prolixa
Isso me fez repensar minha própria postura quando interajo como cliente ou contratante, e também como pessoas de outros países podem enxergar o meu país
Histórias de fracasso são muito valiosas e, na minha opinião, mais úteis do que histórias de sucesso. Histórias de sucesso muitas vezes são racionalizações a posteriori
É uma pena ver os gênios de poltrona desta thread agindo como se fossem muito mais inteligentes e jamais fossem fracassar, ou pelo menos jamais fossem admitir o fracasso
O texto tem muitas observações valiosas, mas o enquadramento parece um pouco equivocado. Soa transacional e orientado a números
É bem sabido que usuários mais barulhentos não são necessariamente representativos. A maioria dos usuários satisfeitos não entra em contato com o suporte, mas eles também estão entre os usuários mais importantes com quem conversar para melhorar o produto
Para interpretar as solicitações dos usuários, você precisa criar seu próprio modelo de quem são seus usuários. Ou seja, precisa decidir se aquela solicitação de suporte é sinal ou ruído
Se a solicitação vem de alguém que pertence ao seu mercado-alvo e expressa uma dor, pode ser um sinal importante. Um pedido para cobrar apenas 20% do preço atual só é útil se você estiver pronto para considerar uma reestruturação da oferta. Se houver muitos e-mails assim, talvez exista uma oportunidade de produto mais barato com apenas determinados recursos. Caso contrário, basta responder “obrigado pelo e-mail. No momento não temos planos de alterar os preços” e seguir em frente
Ainda assim, é impressionante que esse tipo de conversa seja possível para um desenvolvedor que vende pela App Store. Sempre senti que a Apple, ao se colocar no meio, matou a capacidade de manter um relacionamento com o cliente. Nunca coloquei nada diretamente na Mac App Store
Conversar com usuários satisfeitos para melhorar o produto faz sentido, mas isso se chama pesquisa de mercado, não suporte ao cliente
O autor contratou alguém com conhecimento técnico, mas isso por si só não basta
Conhecimento técnico e habilidades interpessoais são coisas diferentes
Se alguém se deu ao trabalho de entrar em contato, é bem provável que a primeira impressão dessa pessoa sobre você já seja ruim. Se a resposta se concentra em “educar o cliente” ou se preocupa demais com a justiça do próprio negócio, é difícil causar uma boa impressão
Um ótimo suporte ao cliente deveria ser do tipo que faz o cliente querer compartilhar aquela interação com amigos ou nas redes sociais. O suporte descrito neste texto não parece ter muita chance de chegar a isso
Quando alguém reclama com a Uncommon Apps sobre o modelo de assinatura, e se não for possível mudar a opinião dessa pessoa — o que geralmente deve ser o caso —, eles poderiam enviar uma lista de alternativas
Assim, o ticket de suporte do Castro poderia terminar sendo útil. A Uncommon Apps perderia essa venda de qualquer forma, mas pelo menos ganharia algo em reputação
O fato de o CEO ou fundador cuidar do suporte de primeira linha talvez não seja tão motivo de orgulho quanto parece
Do ponto de vista do usuário, se o CEO ou fundador responde à minha pergunta, sinceramente começo a suspeitar que seja uma operação temporária de uma pessoa só que pode desaparecer na semana que vem
Além disso, uma experiência de suporte satisfatória não é necessariamente a mais rápida. Se eu peço algo e o suporte de primeira linha diz “não”, escala para a equipe de vendas, a equipe de vendas também diz “não” e então escala para o fundador, e o fundador diz “sim”, o usuário pode se sentir mais “ouvido” e com uma sensação maior de conquista
O resultado é o mesmo, mas em um dos casos a pessoa sente que conseguiu aquilo por conta própria