top of page
Foto do escritorCamila Rodrigues

Como o desafio de escalar o Inner Loop de NPS nos levou para muito além do óbvio no iFood

O NPS apesar de muito utilizado, permite diferentes formatos de aplicação dos resultados. Há empresas que usam apenas como score, mas já existem exemplos que aplicam algo que a Bain & Company conta neste artigo, do qual o "S" de Score foi atualizado para "S" de System (Figura), elevando o NPS que até então era apenas um indicador, para um loop de melhoria contínua.

O ínicio do Inner Loop no iFood

Aqui no iFood nós seguimos inquietos em encontrar um modelo ideal de aplicar o close the loop aos nossos clientes. Este desafío faz parte do meu escopo aqui no time de Voice of the Customer (VoC), que responde a diretoria de Program Management da área de Customer Experience, e tem por propósito: Potencializar a cultura centrada no cliente dentro do iFood (interno) e Ser reconhecida mundialmente como uma empresa centrada no cliente (externo).

Tem sido um caminho difícil, do qual colhemos muitas vitórias, mas também ocorreram frustrações. Mas antes de você seguir a leitura, acho que é um bom momento para te contar que a intenção deste artigo não é te ensinar como começar a trabalhar o NPS na sua empresa - temos ótimos materiais sobre isso amplamente divulgados aqui mesmo no Linkedin ou noutras plataformas. E sim, como dar o próximo passo se seu negócio está passando por um momento parecido com o qual estávamos tempos atrás. Por isto, vim aqui escrever este artigo, para contar como evoluimos o modelo de praticar o inner loop para um formato que é único, formatado na medida exigida pelo nosso negócio.

Inicialmente, quero reforçar que a nossa cultura no iFood garante liberdade de testar hipóteses e quando erramos, precisamos corrigir rápido. Com essa metodologia atrelada a algumas tentativas, saímos do óbvio. E a grande provocação que os faço neste momento é o quanto o seu processo se identifica com o texto do artigo abaixo?

The surveys usually ask for “a few minutes of your time” but then require 15 or 20 minutes to complete. Worse, you never get an acknowledgment beyond an automated thank you. You have no way of knowing whether the company actually read your survey, thought about the issues you raised and took action to improve things.

Where’s the incentive to invest your time? Eu me peguei exatamente nesta questão quando cheguei no time, pois nós já estávamos com um processo solidificado de melhoria contínua tracionada pelo NPS, onde diversas áreas estratégicas consumiam os insumos da pesquisa como fonte para priorizar seus trabalhos, e já colecionávamos inúmeros cases de sucesso desta atuação. Então, a minha resposta para o trecho destacado acima foi: SIM cliente, nós lemos o seu feedback, entendemos o seu problema e direcionamos melhorias a partir de seu relato, nós só não te contamos nada disso. E, teoricamente, o Inner Loop me parecia ser mais fácil de implantar quando comparado ao Huddle ou Outer Loop.

Pensando no nosso core business, temos três grandes clientes, os entregadores, os usuários e os parceiros. Eu iniciei o meu trabalho por Restaurantes (parceiros). E, só uma breve explicação de como trabalhamos a pesquisa, nós coletamos o NPS relacional, onde cada restaurante tem um intervalo de pelo menos 90 dias entre as respostas, e acompanhado da pergunta da escala de 0 a 10, temos uma secundária aberta para que ele possa justificar a sua resposta. A partir daí, usamos uma IA para fazer a leitura desses comentários e classifica-los em pouco mais de 40 assuntos, denominadas, internamente, de tagueamento (existem outras nomenclaturas, aqui usamos tags). Esquema abaixo:

Primeira tentativa: mensagem padrão Após algumas leituras, benchmarkings e um teste que demonstrou-se promissor, fomos pelo caminho do óbvio, mandar uma resposta padrão de acordo com a Tag que o cliente abordou dentro da pergunta aberta do NPS, nas datas que se sucedem a resposta. Em parceria com o time de CRM, estruturamos 14 textos de comunicação, conforme critérios abaixo:

  • Início/Próximo: neste momento agradeciamos a resposta pela pesquisa, nos desculpavamos pelo ocorrido e reforçavámos a leitura do seu feedback.

  • Meio/Facilitador: de forma sucinta, contávamos as iniciativas que a Cia estava tomando a partir do seu feedback.

  • Meio/Resolutivo: neste momento explicavámos os restaurante as regras de negócio inerente aquele tema.

  • Fim/CTA: agradecimentos finais e um texto reforçando nossos canais de atendimento com um CTA.

Na prática, esse é o visual dos comunicados:

Resultado? Deu muito ruim. O motivo é que a gente negligenciou a real reclamação do restaurante, à causa raiz, e acabamos por responder algo que por mais que conectasse a justificativa, não conectava a solução. Calma, ficou confuso? vou dar um exemplo para tangibilizar melhor: Imagina que um cliente lhe deu uma nota zero no NPS, e justificou essa nota com o seguinte comentário "o atendimento de vocês é muito demorado". No modelo que trabalhamos, nossa IA classificaria o texto com a tag "Demora no atendimento", e a partir disso nós enviaríamos um texto muito generalista para o cliente, dividido nos quatro momentos da figura acima. E, com base nisso, vimos que era preciso entender qual é esse atendimento demorado, sobre o que era exatamente, para só então construirmos uma mensagem que conectasse melhor ao restaurante, e não responder especificamente sobre o tema demora no atendimento de forma global. Segunda tentativa: mensagem personalizada E lá vou eu, pelo caminho óbvio, e com ajuda do time de data insights, passamos a cruzar as respostas desta tag demora no atendimento com os tickets de suporte dos últimos 60 dias para aquele restaurante, e assim identificamos se e qual deles tinha sido tratado fora da SLA, deste modo, a gente saberia a causa raiz e conectaríamos a resposta. Resutaldo? deu ruim de novo. O problema em fazer isso é que mais uma vez tentamos simplificar demais a opinião do cliente. Na boa, demora no atendimento está atrelado a expectativas, e não ao SLA interno da Cia. Se não entendeu, vou te dar um exemplo.

Veja bem, uma empresa de seguros pode ter em seus protocolos o prazo máximo de 90 minutos para chegada de um guincho quando acionada pelo cliente, parece ser um prazo razoável né? então, eu passo a dizer que quando o guincho chega após 90 minutos, ele não atendeu ao prazo. Porém, isso só vale para a empresa mesmo. A depender da ocasião da qual a solicitação do guincho é feita, 30 minutos já se torna uma eternidade, quem dirá os 90 do procedimento. Portando, mesmo que o guincho chegue dentro deste prazo de 90 minutos estipulado pela Cia, a expectativa do cliente não foi atendida, e ele transborda isso para o NPS como "Demora no atendimento". Logo, o conceito de demora na voz do cliente não está diretamente conectado ao seu SLA, e sim a situação da qual ele estava inserido. Terceira (quase) tentativa: adição de mais perguntas ao NPS Desta forma, continuávamos dando respostas que não conectavam a reclamação apresentada pelo cliente. E a esta altura, eu já estava precisando lidar com aquela hipótese anti-metodologica de que só o comentário da pergunta aberta não era suficiente, e que seria preciso extraír mais informações no momento da pesquisa, noutras palavras, adcionar mais perguntas para o cliente responder. Supondo que fossemos seguir por este caminho, só seria relativamente viável se usássemos perguntas de múltipla escolha.

Entretanto, calejado das tentativas sem sucesso já realizadas, pensei com cuidado sobre propor essa possibilidade a minha liderança, e esse trecho do artigo da Bain & Company foi a cereja do bolo para que eu refutasse a ideia:

Days later, Jose received an email asking for feedback. He decided to respond, completing the online survey in about 15 minutes. The last 10 questions, which asked him about his income, ethnicity, gender and so on, seemed typical, but he thought the company should already have all that information from his insurance application. As he closed out the browser window, he realized that the multiple-choice questions hadn’t given him the opportunity to explain the real reasons why he found his recent call unsatisfying. Recomeço: como repensamos o Inner Loop E, se você leu até aqui, já percebeu que o assunto é complexo, e se eu ainda não te convenci, deixa eu fazer um lembrete, o exemplo que trabalhamos acima é apenas do assunto "Demora no Atendimento", lembre que aqui temos outras 40 tags com suas próprias complexidades. E foi aí que decidimos, eu e minha liderança, por declinarmos dos textos prontos, pois apesar de ser relativamente fácil implantar e automatizar, ele tem um impacto pequeno na vida de quem o recebe - nossa conclusão.

Tudo bem se neste momento você discordar desta conclusão, e ainda me disser que a empresa xpto usa esse processo e funciona muito bem. Primeiro, eu acredito, porque penso que esse processo realmente funciona em situações muito específicas, mas não num cenário amplo como principal ou única solução. Segundo, quando estiver diante de um case de sucesso no modelo acima, tente entender se realmente quem o conta separou o fazer do funcionar, pois o fato de fazer não significa que funciona, cuidado! Tem gente que faz, e a partir isto, deduz que funciona. Mas funciona pra quem?


Para mim só é sucesso esse modelo se realmente gerou valor para quem recebe a informação (o cliente), caso contrário, a empresa xpto só está fazendo. Tem uma pergunta que pode ajudar a tirar a prova dos nove: "Como vocês medem se o cliente realmente ficou satisfeito?" eu ainda não lidei com uma resposta convincente para isso - vamos adiante.

Como recomeçamos? utilizando a metodologia de Problem Solving, aplicada na McKinsey & Company e outras consultorias (saiba mais). Vale reforçar que para aplicar essa metodologia de forma correta, fomos capacitados pela Ventus Learning num Programa de Solução de Problemas aqui no iFood - super recomendo por sinal. Solução: como saímos do obvio no Inner Loop Inicialmente contextualizamos o problema numa pergunta bem definida, utilizando a técnica smart: Como implementar em até 90 dias um processo de Inner Loop escalável e mensurável, para responder 70% dos super detratores (notas 0 e 1) de forma satisfatória em até 72h após coleta da pesquisa, e que gere insumos/insights para direcionar as frentes de trabalho internas?

Com a questão chave nos dando direção, e já com apoio de um grupo multidisciplinar, quebramos o problema numa árvore de questões que nos trouxe 4 ramificações secundárias: a. Tagueamento; b. Contato com o parceiro; c. Satisfação; e d. Comunicação interna.

O passo seguinte foi uma leitura e ressignificação dos comentários de cada uma das tags. Basicamente, quando vamos começar a trabalhar com IA, o que fazemos é formar um relatório de tags manuais, chamado de base de conhecimento, que será usado para treinar o sistema - a partir daí a gente define que quando a inteligencia classificar um comentário com aquela tag, a reclamação já é conhecida. Porém, aqui fizemos o papel inverso, nós pegamos os comentários depois de passar pela IA, e lemos uma base grande individualmente, com a intenção de responder a seguinte pergunta:

Qual a principal dor precisamos resolver dentro desta Tag? Resultando numa planilha neste modelo:

Fazer esse processo acima, na lógica pode parecer que as respostas já são conhecidas, mas na prática o resultado reserva algumas gratas surpresas - recomendo que o faça com frequência, até mesmo para entender se a dor ali representada está alinhada com a mensagem que estamos replicando internamente. Legal, fiz isso, e em seguida vem um pulo do gato. Quando você pega as 40 tags existentes, divide por igual, normalmente você vai encontrar meia dúzia, ou menos, que são as mais representativas (Princípio de Pareto). Algo mais ou menos como o histograma fictício abaixo:

O mais comum neste momento é você priorizar ali as duas ou três tags com maior volume, por exemplo, e passar a criar planos de ação encima delas. Cuídado, cautela nesta leitura, pois ela pode não representar a causa a ser resolvida e você será direcionado para um caminho díficil. Por isso, com base na tabela anterior, antes de priorizarmos quais dores vamos atacar, fizemos uma divisão simples das tags em dois grupos: a) O que é acionável/causa raíz (laranja); b) O que é um reflexo do problema/consequência (azul). Tornando o histograma algo mais ou menos assim:

Percebemos então que aquelas tags que tinham muito volume, nem sempre representavam a causa raíz, e com isso quando fazia-se uma distribuição % da quantidade de respostas por classificação, as demais acabavam perdendo relevância - é como se a Tag F ou H não fossem grande problema no momento, quando comparado com A e B. Mas, depois de fazer esse exercício, você percebe que as tags de reflexo do problema são compostas por uma ou mais tags acionáveis. Logo, no momento de estruturar o trabalho, no histograma expugarmos as tags de reflexo, e passamos a ter a visão abaixo:

Percebe a diferença? Trazendo este conceito para a realidade, vamos pensar num dos exemplos que trabalhamos anteriormente, o de "Demora no Atendimento". Supondo que ela fosse a tag A do primeiro histograma, provavelmente a gente iria concluir que a principal dor que temos que resolver para melhorarmos o indicador de NPS são os nossos prazos de atendimento - e os planos de ação seriam direcionados a trabalhar SLA, forecast, TMA, entre outros. Porém, se pensarmos essa tag por um ângulo mais amplo, a grande verdade é que seu cliente só buscou o suporte por ter um problema. Então, eu deveria investir mais energia resolvendo esse problema que gera um esforço do cliente em ter que me contatar (e só então ocorre a demora), do que gastar energia tentando prestar um suporte mais ágil de um problema que vai continuar existindo. Então, demora no atendimento deve ser classificado como um reflexo do problema/consequência, e não como uma tag acionável de causa raíz.

Desse modo, depois de fazermos essa reclassificação, e expurgarmos algumas tags da conta, tivemos uma visão mais clara das dores acionáveis que precisamos atuar. Calma, eu sei, e o que eu faço com o cenário de reflexo, deixo ele pra lá? Claro que não, no fundo, o cenário B acaba sendo composto por vários cenários A, sendo assim, ao resolver um problema de causa raiz, por consequência, você verá mudanças também nas tags que são reflexos. Exemplificando, é como se a Tag C fosse 15% + um percentual da Tag A, conforme imagem. Logo, ao tratar o problema da Tag C, eu também reduzo a Tag A:

Desta forma, a etapa seguinte seria priorizar quais desses assuntos de causa raíz deve ser empregado maior esforço. E então vou pedir uma licença poética, para trazer uma matriz que o meu colega Victor Zanini, atual Head de Design aqui do iFood, aplicou lá na Conta Azul - sua antiga empresa (artigo). Nós adaptamos e aplicamos esse modelo de matriz para priorizarmos as tags (chamadas pelo Victor de Categorias):

Definidas as tags prioritárias, chegamos no momento de testar. Só que dessa vez fomos pelo caminho do contato por telefone - a principio não parece o mais promissor, mas eu estava confiante. E para isso, contratamos dois novos Foodlovers para o time. E aqui vai uma dica, se você tem pouco braço para tracionar essas ligações, um bom caminho é começar ligando para aqueles respondentes que na penúltima pesquisa foram promotores, e migraram para detratores na última coleta - privilegiamos esses contatos por aqui também. A combinação das recomendações acima resultou no processo a seguir:

Resultado? Bingo! Foi justamente ao pegarmos a rota mais improvável que acertamos em cheio. Através das ligações, começamos a ouvir diáriamente nossos clientes com um nível de profundidade até então desconhecido e único, histórias detalhadas das mais variadas situações, que eram agrupadas dentro de uma mesma tag pelo mecanismo da IA. Que momento meus amigos, que momento! Fricções: superando os desafios da implementação Como nem tudo são flores, surgiram três novos desafios, e vou contar como superamos cada um deles:

  • Produtividade do telefone:

O principal problema eram as ligações não atendidas, a conta era de 7 tentativas para 1. Além disto, 1 a cada 4 ligações atendidas o parceiro não tinha disponibilidade ou interesse de seguir com o contato, portanto, os números oficiais eram de 28 ligações para 3 contatos com sucesso. Internamente, arredondamos o número para 10 ligações para 1 sucesso.

Para convertermos a situação, testamos um modelo de agendamento com 50 restaurantes detratores, onde no dia seguinte a resposta, enviávamos a eles uma mensagem questionando se tinham interesse em agendar uma conversa por telefone, e para aqueles que topavam, faziamos a sugestão de turno manhã ou tarde. O resultado provou um ganho significativo de produtividade, pois 30% agendavam, e a cada 5 ligações agendadas, 4 nos atendiam.

Procuramos o time de Produto que nos ajudou a levar o modelo para produção, e assim implantamos um fluxo onde todos os respondentes detratores do grupo de tags acionáveis, no dia seguinte a resposta da pesquisa, recebem um push direto no sistema agradecendo a resposta, e deixando opcional o caminho do agendamento:

O próprio restaurante tem autonomia de escolher agendar a conversa para data e horário desejado, pois nós garantimos três opções de data e 12 janelas de horário em cada uma dessas datas. Esse agendamento já cria automaticamente um evento na agenda do time, triplicando a produtividade diária. Imagem da agenda:



  • Restaurantes que ainda estão com seus problemas pendentes de solução

Durante o contato, nem sempre o cliente vai justificar algo que está no passado, as vezes ele trás um problema que ainda está pendente de solução. A princípio a gente estabeleceu um processo de prioridade junto ao time de atendimento, e retornávamos assim que era sinalizado que a tratativa foi realizada. No entanto, já falamos aqui sobre pegar o caminho do óbvio, e apesar deste formato ser funcional, a gente percebeu que tínhamos uma grande oportunidade em mãos.

Ao invés de priorizarmos com o time de atendimento, a gente mudou a rota, e passamos a trilhar a jornada oficial de suporte junto com o cliente, ou seja, abrir um chamado no suporte, aguardar o SLA de solução e tudo mais. Pois, ao priorizarmos aquele atendimento, estávamos passando o problema por um processo paralelo, que não representava a realidade de quem estava nos buscando para resolver uma situação semelhante. Por isso, ao optarmos em avançar pela jornada oficial, a gente ganhou a possibilidade de acompanhar na íntegra todo esforço do cliente para solução daquela situação (algo como um "cliente oculto"), claro que isso deve ser feito com cautela, avaliando as circunstâncias e combinando a regra do jogo com nosso cliente para, acima de tudo, não prejudica-lo.

Uma das descobertas que fizemos vai muito de encontro ao exemplo de Demora no Atendimento, a gente percebeu que alguns clientes tinham seu chamado respondido pelo atendimento via e-mail, mas quando faziamos um novo contato para questionar se recebeu a resposta, dizia que não.

Com um pouco de investigação, descobrimos que alguns desses clientes deduziam que receberiam uma ligação como retorno a sua solicitação, enquanto o mesmo já estava lá em sua caixa de e-mail ou ferramenta iFood (existe uma tela dedicada a acompanhar os chamados). Como estes não tinham o hábito de acessar esses meios com frequência, quando eles viam a resposta, chegavam a conclusão que nós demoravámos muito para responder (ou nem respondiamos). Insights como esse são valiosos, e nós os conectamos com as áreas de melhoría contínua, operações e produto, para que seja aprofundado a tematica e endereçado a solução.

  • Como registrar os contatos

A ligação já tem um roteiro padrão de perguntas, a maioria são exploratórias, de maneira a aproveitar melhor o diálogo com o parceiro, extraindo as informações de forma estruturada. Existem duas regras básicas que adotamos, deixar o parceiro a vontade para falar tudo que desejar, e se desprender do tempo, estamos ali para escutar sem pressa.

Após finalizar o contato, a analista cataloga todas as informações num formulário do Typerform, e para garantir que ela não esqueça nenhum ponto importante, a mesma tem acesso a escutar a gravação de todos os contatos. Esse formulário é integrado a um canal do Slack, onde as histórias são automaticamente compartilhadas com mais de 400 Foodlovers, que já conseguem interagir na thread da públicação, conforme exemplo:

Além disso, todas as histórias são armanezadas num banco de dados de VoC, e servem de apoio para construção dos mais váriados deep dives e análises internas, garantindo uma conexão perfeita entre os dados e a voz do cliente. Com isso, temos uma maior satisfação por parte do restaurante respondente, que foi devidamente ouvido e recebeu um posicionamento oficial e personalizado do iFood. Modelo de pesquisa: função que nasceu do Inner Loop Ao percebermos a riqueza das informações que os restaurantes forneciam, e a abertura que ganhamos destes parceiros atráves do contato de Inner Loop, criamos um pilar de pesquisas dentro do time, onde uma das analistas passou a ficar 100% dedicada a realização de uma metodologia que chamamos de quick survey (pesquisas rápidas, em sprint). Neste modelo passamos a convidar os restaurantes e clientes a uma entrevista em vídeo sobre algum tema específico, e esses depoimentos são anexos ao nosso banco de dados, sob consentimento do cliente (LGPD), e agregado a diversos materiais e fóruns internos. Ajudando assim, a dar ainda mais peso a voz aos nossos clientes.

Por exempo, no slide abaixo o time de melhoría contínua construiu a jornada de um processo específico para usuários iFood, e nós de VoC incluímos trechos de falas em vídeo que tinhamos armazenados em nosso repositório, decorrente das quicks surveys com clientes e restaurantes realizadas anteriormente. Essas falas se conectam a cada momento da jornada, o que enriquece o material, já que a presença em vídeo do cliente ajuda a tangibilizar cada etapa com perfeição, reduzindo os espaços de hipóteses/dúvidas e recheando-os de certezas numa matriz CSD, por exemplo:

De olho no futuro, centrado no cliente Atualmente, são centenas de ligações de retorno à pesquisa de NPS todos os meses, além de uma quick survey semanal, que somadas resultam em muitas horas de conteúdo em aúdio e vídeo com feedbacks extremamente ricos e bem estruturados sendo gerados todos os dias. O melhor de tudo isso, é saber que além de conseguirmos atingir de forma positiva os respondentes da pesquisa, evoluímos o close the loop como um todo - não apenas o Inner Loop, permitindo um grau de aprofundamento da Voz do Cliente até então inimaginável, dado a escala do nosso negócio. E mesmo com tudo isso, seguimos inconformados e trabalhando em novos modelos de aperfeiçoamento, mas mas vou deixar para contar as novidades numa próxima oportunidade. Por ora, quero finalizar referênciando a Confirmit (link) que trás uma definição que gosto muito sobre todo trabalho que fazemos aqui no time:

Os programas Voice of the Customer comprovadamente ajudam as organizações a reter clientes, criar produtos melhores, oferecer melhores serviços e compreender sistematicamente a experiência do cliente para impulsionar a mudança. As organizações que entendem a jornada do cliente têm muito mais probabilidade de melhorar seus produtos para atender aos requisitos em evolução de seus clientes e, portanto, promover sua fidelidade

Também quero destacar que de acordo com os estágios de maturidade da experiência do cliente que são apresentados no espetacular livro da comunidade Amigos do CX (link), que tem como fonte: Lagow, D. & Magers, D. - 5 principles for Successfully Driving CX Across Your Organization, o iFood encontra-se atualmente no estágio 5 (figura abaixo) de seis estágios possíveis. O que demonstra que ainda temos muito trabalho a ser feito, mas que tudo que fizemos até aqui vem de encontro com nosso propósito de VoC Program, pois seguimos evoluindo nossas estratégias de atuação, ao passo que mantemos a consistência em ações de sustentação de tudo que já foi realizado.

Esse foi o nosso jeito de aplicar o Inner Loop aqui no iFood, e o meu jeito de te contar como tocamos tudo isso por aqui. Espero que esteja levando algo de bom consigo na bagagem, e se quiser trocar mais sobre o tema, conta comigo.

Referência ao time: Giulia Bonfiglioli, Amanda Rueda, Beatriz Freitas, Barbara Costa, Patricia Cruz, Tais Pinto, Thiago Vicente, Alexsandro Bascunan, Juliana Bessa, Rodrigo Soler, Victor Zanini e time Ventus Learning.


Denilson Marcelino | Coordenador de Voz do Cliente | IFOOD

Acumula em sua bagagem passagem por companhias como Leroy Merlin, Ifood, graduações em tecnologia, customer service e administração mas se destaca mesmo por sua paixão pelo universo de CX, drivado pelo propósito de proporcionar melhores experiências aos clientes. É fã de carteirinha de profissionais e empresas que colocam o cliente no centro de suas decisões.

495 visualizações1 comentário

1 Comment


Leticia Gouveia
Leticia Gouveia
Aug 16, 2022

Conteúdo sensacional! Obrigada Denilson, por compartilhar com a gente como vocês estão tocando o Inner Loop no Ifood. Realmente muito enriquecedor :D

Like
bottom of page