O tier de suporte era um sistema de triagem para uma escassez que acabou

Um cliente escreve com um problema que leva quatro minutos para seu melhor engenheiro resolver. Leva quatro dias para o tier de suporte. Não porque a resposta é difícil, porque a resposta é rara, e o sistema é construído para racioná-la.

Essa lacuna de quatro dias é o tema inteiro deste post. Não é um problema de pessoal. É a forma visível de uma decisão que sua empresa tomou anos atrás, quando construiu uma escada para racionar sua coisa mais escassa.

O tier de suporte era um sistema de triagem para uma escassez que acabou.

Para que o tier de fato servia

Tire o organograma e um tier de suporte é um mecanismo fazendo um trabalho: proteger as poucas pessoas que sabem as respostas difíceis das muitas pessoas que fazem perguntas fáceis.

Você tem um punhado de especialistas. Você tem uma enxurrada de tickets. A maioria dos tickets é rotineira; alguns são genuinamente difíceis. Se você deixar cada ticket alcançar um especialista, os especialistas se afogam e o trabalho rotineiro espreme o trabalho difícil. Então você constrói um filtro. O tier-1 pega tudo e resolve o que consegue a partir de um script. O que não consegue, escala para o tier-2. O que o tier-2 não consegue, escala de novo. O especialista vê apenas o que sobrevive a dois filtros.

Esse é um bom design para a restrição sob a qual foi construído. A restrição era: julgamento sênior é escasso, caro e mora num pequeno número de cabeças. A escada o raciona.

O custo da escada é arcado inteiramente pelo cliente, e é pago em duas moedas. A primeira é tempo, cada escalonamento é um repasse, e cada repasse é uma fila. A segunda é repetição: toda vez que um ticket sobe um degrau, o cliente re-explica o problema para alguém que não estava lá na última conversa. O tier não apenas desacelera a resposta. Ele faz o cliente carregar o contexto escada acima à mão.

A correção ingênua que todo mundo tenta primeiro

A resposta óbvia, uma vez que você sente essa dor, é tornar o tier-1 melhor. Escreva uma base de conhecimento mais profunda. Dê à linha de frente uma caixa de busca melhor. Treine-os mais duro, dê scripts mais apertados, deflexione mais antes de qualquer um escalar.

Isso ajuda um pouco e não corrige nada, e vale ser preciso sobre por quê.

Uma base de conhecimento melhor ainda coloca um humano no meio que tem que encontrar o artigo certo, entender um problema que ele pode não ter a profundidade para entender, e decidir se este é o caso rotineiro que o script cobre ou o caso raro que parece rotineiro até não ser. A parte difícil do tier-1 nunca foi ler a resposta. Era saber qual pergunta você de fato está sendo feito. Uma KB mais profunda entrega a um júnior um manual mais grosso e pede que ele seja sênior. O manual melhorou. O julgamento não se moveu.

A segunda correção ingênua é jogar um chatbot na frente da fila, um modelo que responde a partir da mesma KB antes de um humano se envolver. Isso deflexiona o verdadeiramente trivial, e então bate numa parede que é instrutiva. O bot responde a partir da documentação, e a documentação descreve o produto como projetado, não como ele de fato se comporta para este cliente, com a configuração dele, na conta dele, depois daquela coisa que ele fez na última terça. No momento em que a pergunta depende do estado real do cliente, o bot genérico está de volta recitando o manual, confiantemente, o que é pior.

Ambas as correções compartilham um ponto cego. Elas tratam a resposta como uma busca. Mas uma resposta sênior nunca foi uma busca. Era uma busca mais tudo o que o sênior sabia sobre este cliente, este produto, e as últimas quarenta vezes em que esse exato problema acabou não sendo o problema.

O gargalo nunca desaparece. Ele apenas sobe um degrau.

O que muda quando a melhor resposta está codificada

Aqui está a mudança, dita claramente, e o resto do post é o mecanismo dela.

Por toda a história do suporte, a resposta sênior morou numa cabeça. Ela só podia estar em um lugar de cada vez, tinha horário de expediente, e levava anos para cultivar outra. Essa é a escassez que o tier foi construído para racionar. A coisa que mudou é que a resposta sênior não precisa mais morar numa cabeça. Ela pode ser codificada, escrita como um playbook que um sistema roda toda vez, contra o contexto completo do cliente que está perguntando.

O tier de suporte era um sistema de triagem para uma escassez que acabou.

Codificar a resposta não é o mesmo que documentá-la, e a diferença é o jogo inteiro. Um documento é uma descrição que um humano tem que ler, interpretar e aplicar. Um playbook codificado é o raciocínio real do sênior tornado executável: quando um cliente reporta isto, cheque aquilo primeiro, porque nove em cada dez vezes o problema declarado é um sintoma de uma causa diferente; se a conta dele está em este estado, a correção é uma coisa; se está em aquele estado, é outra. O júnior tinha o manual. O sistema tem o método.

E o método consegue rodar contra algo que o júnior nunca teve: o estado real do cliente. Não o produto como documentado, mas esta conta, esta configuração, este histórico, lido no momento em que a pergunta chega. O sênior era bom em parte porque o sênior lembrava. Um sistema que segura a memória da empresa e o contexto do cliente juntos não precisa lembrar. Ele já está com o arquivo aberto.

Então a resposta que costumava exigir sobreviver a dois escalonamentos, porque só o especialista segurava tanto o método quanto a memória, agora pode acontecer na primeira mensagem. Não uma resposta pior entregue mais rápido. A resposta de nível sênior, entregue primeiro.

Por que “primeiro contato” é o ponto inteiro

É tentador ler tudo isso como “IA torna o tier-1 mais barato”, e essa leitura erra o que de fato muda.

Um tier-1 mais barato ainda mantém a escada. Você ainda teria escalonamentos, ainda teria repasses, ainda teria o cliente re-explicando o problema para cada novo degrau. Você teria apenas tornado o degrau de baixo menos caro de manter. O imposto sobre o cliente, a fila, a repetição, os dias, permanece inalterado. Você otimizou o filtro. O filtro é o problema.

A mudança real colapsa a escada, e a colapsa de baixo para cima. Quando o primeiro contato pode produzir uma resposta de nível sênior, os degraus acima dele perdem sua razão de existir para os casos que o sistema consegue tratar. Não há nada para escalar, porque o escalonamento existia para alcançar uma profundidade que agora está disponível imediatamente. O ticket difícil que costumava levar quatro dias não se move mais rápido pelos tiers. Ele os pula.

E os casos que o sistema genuinamente não consegue tratar, o problema verdadeiramente novo, a decisão de julgamento com risco real, o cliente que precisa de um humano para ser dono do resultado, esses vão direto para o humano que deveria tê-los tido o tempo todo, sem ser diluído pelo trabalho rotineiro que costumava enterrá-los. O especialista deixa de ser o recurso raro que você raciona. Ele vira o recurso que você reserva para os problemas que de fato merecem uma pessoa.

Essa é a inversão. A velha escada protegia o sênior mantendo os clientes longe dele. A nova forma protege o cliente dando a cada um deles a resposta do sênior primeiro, e protege o sênior entregando a ele apenas o trabalho para o qual um humano é unicamente necessário.

A parte difícil que ninguém te avisa

Se isto fosse fácil, já estaria em todo lugar, então vale ser honesto sobre o que torna difícil. Três coisas.

Primeiro, o playbook tem que ser real, não aspiracional. Codificar o raciocínio do sênior significa de fato extraí-lo, as checagens que ele roda, a ordem em que as roda, os casos em que a resposta óbvia é a errada. Esse conhecimento é em grande parte não documentado, porque morava numa cabeça que nunca precisou escrevê-lo. Tirá-lo de lá é trabalho, e é trabalho que nenhuma base de conhecimento jamais forçou alguém a fazer.

Segundo, o sistema tem que saber quando não sabe. Uma máquina de respostas sempre-ligada que é confiante nos casos que não deveria tocar é pior que a escada, porque pelo menos a escada escalava. A disciplina que importa é a mesma que um bom sênior tem: a disposição de dizer este aqui precisa de uma pessoa, e de roteá-lo para lá de forma limpa, com o contexto já montado para que o humano não comece do zero. O escalonamento não desaparece. Ele fica raro, e fica limpo.

Terceiro, e esta é a que as pessoas pulam, a resposta tem que ser segura de agir sobre ela. Um sênior conquista confiança ao longo de anos; um sistema tem que conquistá-la ticket por ticket, e isso significa que ele não pode apenas falar. Ele tem que ter permissão de fazer as coisas seguras diretamente e de perguntar antes das consequentes, do jeito que você deixaria um novo contratado de confiança tratar a rotina e dar um pulinho nas irreversíveis. Confiança é uma escada que você sobe, não um interruptor que você liga. O sênior codificado a sobe da mesma forma que um humano faria.

Nenhuma dessas é razão para não poder ser feito. São as razões pelas quais tem que ser construído de propósito, como um sistema, em vez de aparafusado como uma caixa de busca mais inteligente.

A virada: para que uma resposta sênior sempre serviu

Aqui está a parte que não é sobre software de suporte.

Construímos o tier para racionar expertise escassa, e em algum momento do caminho começamos a tratar o racionamento como normal, como apenas o jeito que o suporte funciona. Um cliente com um problema real espera dias por uma resposta que existe, totalmente formada, numa cabeça a dois escalonamentos de distância. Chamamos isso de o processo. Nunca foi o processo. Era o tecido cicatricial em volta de uma escassez.

Tire a escassez e a pergunta fica desconfortável. Se todo cliente pudesse receber sua resposta mais experiente no primeiro contato, o que o tier algum dia protegia? Não qualidade, a resposta sênior sempre foi a boa. Ele protegia disponibilidade. Ele racionava acesso ao seu melhor pensamento porque seu melhor pensamento não podia estar em dois lugares ao mesmo tempo. Isso era uma restrição, não um valor. E no momento em que a restrição se levanta, manter a escada não é prudência. É só fazer o cliente pagar por uma escassez que você não tem mais.

A promessa aqui não é tickets mais rápidos. É que a lacuna entre sua melhor resposta existe e este cliente a recebeu fecha até zero. O julgamento mais experiente da sua empresa deixa de ser uma coisa que os poucos alcançam depois de uma espera, e vira o piso sobre o qual todos pisam desde a primeira palavra.

---

É isso que estamos construindo na Apollo, não uma linha de frente mais barata, mas uma empresa cuja melhor resposta está codificada, sempre-ligada, e alcança cada cliente no primeiro contato. A lacuna de quatro dias nunca foi sobre quão difícil era o problema. Era sobre quão rara era a resposta. Torne a resposta comum, e a escada que você construiu para racioná-la vira a única coisa te desacelerando.