Reduzindo transferências que frustram os clientes

Um cliente liga para o banco às 9h para resolver um problema simples: um cartão bloqueado por engano. Às 9h40, ele já contou a mesma história três vezes, para três atendentes diferentes, em três sistemas que não conversam entre si. O problema técnico levaria dois minutos para ser resolvido. A frustração levou trinta e oito minutos para ser construída — um handoff de cada vez.

Handoffs não são um detalhe operacional menor. São o ponto exato em que a experiência do cliente se rompe, porque é onde a responsabilidade muda de mãos e a memória do processo se perde. A tese deste artigo é simples e vale ser dita sem rodeios: reduzir handoffs não é um projeto de atendimento, é um projeto de desenho de processo. Treinar equipes para "serem mais empáticas" durante a transferência trata o sintoma. Mapear o processo, identificar por que a transferência existe e redesenhar o fluxo para eliminá-la (ou torná-la invisível) trata a causa.

Por que os handoffs são o ponto mais frágil da jornada do cliente?

Cada transferência exige que o cliente repita contexto, que um novo agente reconstrua o histórico e que o processo sobreviva a uma lacuna de informação. É nesse intervalo — entre quem entregou e quem recebeu — que as coisas se perdem: um dado não é passado adiante, uma prioridade é reinterpretada, uma promessa feita pelo primeiro atendente não chega ao segundo. O cliente sente isso como incompetência da empresa. Na prática, é uma falha de desenho: ninguém projetou o que acontece na costura entre dois processos.

O conceito de service blueprint, formalizado por Lynn Shostack em seu artigo "Designing Services That Deliver" (Harvard Business Review, janeiro de 1984), já apontava exatamente para isso: a experiência do cliente é o resultado visível de uma linha de interação, mas por trás dela existe uma linha de visibilidade — processos internos, sistemas e responsabilidades que o cliente nunca vê, mas cujos defeitos ele sente a cada vez que é passado adiante. Um handoff mal desenhado é uma falha que atravessa a linha de visibilidade e aparece do outro lado como frustração.

O que acontece, na cabeça do cliente, quando ele é transferido?

A resposta curta: o esforço percebido dispara, e esforço é o preditor mais forte de deslealdade. A pesquisa conduzida por Matthew Dixon, Karen Freeman e Nicholas Toman, publicada como "Stop Trying to Delight Your Customers" (Harvard Business Review, julho de 2010), com base em dados da CEB (hoje parte da Gartner), mostrou que reduzir o esforço do cliente tem impacto maior sobre a lealdade do que tentar encantá-lo. Um handoff é, por definição, esforço extra: exige repetição, espera e reconstrução de contexto — nada disso soma valor, tudo isso soma atrito.

Aqui vale trazer a distinção de Richard Thaler entre fricção legítima e sludge, descrita em seu artigo "Nudge, Not Sludge" (Science, outubro de 2018). Fricção é o atrito necessário — verificar identidade antes de mover dinheiro, por exemplo. Sludge é o atrito que existe só porque ninguém removeu, geralmente porque beneficia a operação interna e prejudica quem está do outro lado. A maioria dos handoffs que irritam clientes é sludge disfarçado de processo: existe porque departamentos foram desenhados em silos, não porque o cliente precisa dele.

Há ainda um efeito de memória que agrava o problema. Pela regra do pico-fim (peak-end rule), descrita por Daniel Kahneman e colegas no estudo "When More Pain Is Preferred to Less" (Kahneman, Fredrickson, Charles & Redelmeier, Psychological Science, 1993), as pessoas julgam uma experiência pelo momento de maior intensidade e por como ela termina — não pela média de tudo que aconteceu. Se o handoff acontece perto do fim do atendimento, ele sequestra a lembrança inteira. Um processo de vinte minutos, bom em dezoito deles, pode ser lembrado como péssimo só porque os dois últimos minutos foram uma transferência mal feita.

Como mapear os handoffs antes de tentar eliminá-los?

Ninguém redesenha o que não enxerga. A tentação operacional é atacar o handoff mais visível — geralmente o que gerou a última reclamação — sem entender se ele é sintoma de um problema maior. O caminho correto começa pelo mapeamento, não pela solução.

1. Reconstrua a jornada real, não a desenhada. Sente com quem atende o telefone, não só com quem escreveu o procedimento. O fluxo documentado e o fluxo praticado raramente são o mesmo processo.
2. Marque cada ponto em que a responsabilidade muda de dono. Um handoff nem sempre é uma transferência de canal (do chat para o telefone); às vezes é uma transferência silenciosa de responsabilidade dentro da mesma equipe, sem que o cliente perceba — até o processo travar.
3. Registre o que se perde em cada passagem. Contexto, tempo, prioridade e, às vezes, a própria solicitação. Pergunte: o que o segundo agente precisa saber que o primeiro sistema não registra?
4. Classifique cada handoff por motivo de existência. Ele existe por regulação, por especialização técnica genuína, ou porque dois departamentos nunca se sentaram para desenhar a interface entre eles?
5. Quantifique o custo — para o cliente e para a operação. Tempo perdido, retrabalho, chamadas repetidas, agentes duplicando esforço. Isso transforma um incômodo qualitativo em um caso de negócio.

Esse exercício é, essencialmente, descoberta de processo aplicada à experiência do cliente — e é também a espinha dorsal de um bom redesenho de processo. Sem esse mapa, qualquer tentativa de "reduzir transferências" vira uma meta de RH sem lastro operacional.

Todo handoff é ruim? Quais valem a pena manter?

Não. Essa é a distinção que separa um projeto de redesenho sério de uma caça-fantasmas. Alguns handoffs protegem o cliente — uma transferência para um especialista em fraude, por exemplo, é bem-vinda quando comunicada com clareza. O problema nunca é a existência do handoff; é a opacidade dele.

• Handoffs de especialização legítima — quando a complexidade do caso genuinamente exige outra competência. Mantenha, mas comunique o motivo e o tempo esperado.
• Handoffs de conformidade — exigidos por regulação ou por segurança, especialmente comuns em bancos e seguradoras. Mantenha, mas elimine a repetição de dados que o sistema já possui.
• Handoffs de silo organizacional — existem porque duas áreas nunca desenharam a interface entre si. Estes são os candidatos naturais à eliminação.
• Handoffs de sistema — o atendente muda porque o software muda, não porque o problema mudou. Frequentemente resolvíveis com integração técnica, não com mais gente.
• Handoffs de escalonamento mal calibrado — quando a primeira linha não tem autonomia para resolver o que deveria resolver, e cada caso "sobe" por padrão, não por necessidade real.

Uma estratégia de escalonamento bem desenhada resolve boa parte da última categoria: define com clareza o que a linha de frente pode decidir sozinha, e isso, por si só, elimina uma fatia enorme das transferências desnecessárias.

Como reduzir handoffs sem quebrar a operação?

A resposta não é "acabar com todas as transferências" — é reduzir as que não agregam valor e tornar invisíveis as que restam. Isso exige trabalho de arquitetura de processo, não só boa vontade.

• Aumente a autonomia da primeira linha. Cada decisão que a primeira pessoa pode tomar sem escalar é um handoff que nunca acontece. Isso é escolha de default: o caminho padrão do processo deveria ser "resolver aqui", não "transferir se em dúvida".
• Elimine a repetição de informação. Se o cliente já digitou o número do protocolo no menu telefônico, o próximo agente não deveria pedir de novo. Tecnicamente trivial, operacionalmente raro — e é a fonte número um de irritação em transferências.
• Redesenhe o handoff como transição visível, não como ruptura silenciosa. Quando a transferência é inevitável, diga ao cliente o que vai acontecer, para quem, e por quê. Isso não reduz o número de handoffs, mas reduz drasticamente o esforço percebido — e o esforço percebido é o que realmente importa.
• Consolide o histórico do cliente em um único registro acessível. Um blueprint de serviço que mapeia sistemas e não só pessoas revela rapidamente onde a informação fica presa entre plataformas.
• Meça a carga de trabalho antes de redesenhar o time. Muitos handoffs de silo escondem um problema simples de dimensionamento: uma equipe está sobrecarregada e empurra casos para frente. Uma calculadora de dimensionamento de equipe ajuda a verificar se o handoff é sintoma de processo mal desenhado ou de time subdimensionado — são dois problemas com soluções muito diferentes.
• Trate o retorno da transferência como parte do processo. Se o agente B não consegue resolver e devolve o caso ao agente A, isso precisa ter um caminho tão claro quanto o encaminhamento original — hoje, na maioria das operações, esse caminho de volta simplesmente não existe.

Vale notar que este trabalho conecta diretamente com o desenho mais amplo do serviço. Reduzir handoffs isoladamente, sem revisar a jornada inteira, produz ganhos pontuais que se dissolvem em poucos meses. É por isso que esse tipo de intervenção rende mais quando é tratado como parte de um exercício de desenho de serviço completo, e não como um ajuste isolado de callcenter.

Handoffs internos entre departamentos são diferentes dos handoffs de canal?

Sim, e a distinção muda a solução. Um handoff de canal acontece quando o cliente muda de meio — do chatbot para o telefone, do e-mail para uma loja física. Um handoff departamental acontece quando o caso muda de dono dentro da mesma empresa, ainda que o cliente permaneça no mesmo canal.

Os handoffs de canal geralmente se resolvem com integração de dados: o histórico da conversa precisa viajar com o cliente, não ficar preso no canal de origem. Os handoffs departamentais são mais difíceis, porque exigem redesenhar incentivos e propriedade de processo — normalmente o departamento que "recebe" o caso não tem motivo algum para tratá-lo com a mesma urgência de quem o originou. Isso é um problema clássico de governança de experiência: sem um dono único da jornada de ponta a ponta, cada área otimiza sua própria métrica interna e ignora o custo que impõe à área seguinte. Uma estratégia de governança de CX resolve exatamente essa lacuna, atribuindo responsabilidade pela jornada completa, não apenas pelo pedaço que cada departamento controla.

Como saber se a redução de handoffs está realmente funcionando?

Handoff reduzido que não aparece em nenhuma métrica é boato, não resultado. Os indicadores certos são poucos e específicos:

• Número médio de transferências por caso resolvido — a métrica mais direta, e a mais fácil de manipular se não for acompanhada de outra.
• Taxa de resolução no primeiro contato — sobe quando handoffs desnecessários caem, porque mais casos são fechados por quem primeiro os recebeu.
• Esforço do cliente (Customer Effort Score) — captura a percepção, que é o que realmente prediz lealdade, não apenas o número bruto de passagens.
• Tempo total de ciclo, do primeiro contato à resolução — handoffs quase sempre alongam esse tempo mais do que qualquer outra variável isolada.
• Taxa de retrabalho — quantos casos voltam porque a solução da primeira passagem estava incompleta.

Cruzar essas métricas com gestão de feedback do cliente fecha o ciclo: o dado operacional mostra onde o processo falha, e a voz do cliente confirma se a correção foi sentida — não apenas registrada em planilha. Sem esse cruzamento, é fácil comemorar uma queda no número de transferências que não mudou nada na percepção de quem foi atendido.

O que muda quando a redução de handoffs é tratada como projeto de jornada, não de callcenter?

A diferença é escopo. Um projeto de callcenter otimiza o script e o roteamento dentro do próprio centro de contato. Um projeto de jornada olha para trás de onde o cliente liga e para frente de onde a ligação termina — porque, na maioria dos casos, a razão do handoff nasceu muito antes do primeiro contato. Um cliente que liga para resolver um cadastro incompleto está, na prática, sofrendo as consequências de um formulário mal desenhado semanas atrás. Corrigir o roteamento da ligação sem corrigir o formulário é tratar o sintoma para sempre e nunca a causa.

É por isso que mapear jornadas do cliente de ponta a ponta — não apenas o momento do atendimento — revela onde os handoffs realmente nascem. E é também onde ferramentas de mapeamento estruturado fazem diferença prática: plataformas como a René Studio permitem registrar cada etapa e ponto de contato como dado estruturado, pontuar o impacto de cada handoff na experiência e visualizar, no arco emocional da jornada, exatamente em que momento a transferência derruba a percepção do cliente — em vez de depender de um mapa estático que fica desatualizado assim que o processo muda.

Uma organização sem handoffs perfeitos é a meta errada

Nenhuma operação complexa vai chegar a zero transferências, e não deveria tentar — algumas existem para proteger o cliente, não para atrapalhá-lo. A meta certa é mais modesta e mais poderosa ao mesmo tempo: que cada handoff que sobreviver ao redesenho seja um handoff que o cliente nem perceba como perda de contexto, porque a informação chegou antes dele, e a transição foi anunciada, não sofrida. Isso não se resolve com um treinamento de empatia na próxima reunião de equipe. Resolve-se sentando com o processo, mapa na mão, perguntando por que cada passagem de bastão existe — e tendo a disciplina de eliminar as que não têm boa resposta.