Exemplo prático. Este é um exemplo prático ilustrativo, não um resultado de cliente: o time de suporte e seus números são premissas. Mostra a busca do lado do agente, uma ferramenta que fica atrás do agente de suporte, não na frente do cliente. O agente faz uma pergunta em linguagem simples, recebe uma resposta com fonte citada, permanece no ticket e envia a resposta.
Imagine um time de CX de e-commerce de médio porte que quer mexer no tempo de primeira resposta em tickets complexos. Este post cobre em que consiste o design, o que medir e o que ele não faz. Não relata nenhum resultado, porque não há cliente por trás.
O time é hipotético, e qualquer número que você poderia esperar aqui também. O design se apoia no trabalho de atendimento ao cliente que descrevemos em /ai-for/customer-support. Mais uma coisa logo de iníCIO: é só assistência ao agente. Nenhum chatbot fala com um cliente em momento algum.
#O que estava deixando os agentes mais lentos?
As respostas existem. Encontrá-las não escala. Um ticket complexo significa um agente abrindo o histórico do Zendesk, um documento de produto e um PDF de política de envio, e depois montando a resposta à mão. Anos de tickets antigos guardam o precedente, e ninguém consegue pesquisar esse arquivo no tempo em que um cliente espera.
Então a primeira resposta ficava numa fila enquanto o agente procurava. Essa espera é o número sobre o qual o líder de suporte é cobrado. Tempo de primeira resposta, não volume de tickets.
A ia pode reduzir o tempo de primeira resposta no suporte sem um chatbot?
Sim, esse é o objetivo. Uma ferramenta interna de busca permite que os agentes façam perguntas em linguagem simples sobre tickets históricos, documentos de produto e pdfs de políticas e recebam uma resposta com fonte citada. O agente continua escrevendo e enviando a resposta. Um time mediria o tempo de primeira resposta em tickets complexos antes e depois, sem bot voltado ao cliente.
#Em que consiste o design?
Uma ferramenta interna de busca sobre três fontes: tickets históricos, os documentos de produto e os pdfs de política de envio. O agente digita uma pergunta do jeito que perguntaria a um colega mais experiente. A resposta volta com a fonte citada, para que o agente possa checar antes de mandar para o cliente.
- Busca em todos os tickets antigos numa única consulta, não aba por aba.
- Respostas com fonte citada, para que o agente verifique a origem em vez de confiar numa caixa-preta.
- Respostas embasadas nos pdfs de política de envio, onde de fato ficam as regras dos casos de exceção.
- O agente permanece no ticket. A ferramenta nunca responde a um cliente por conta própria.
Treinar o time de suporte faz parte do design, não é uma entrega no fim. O KPI a combinar é o tempo de primeira resposta em tickets complexos, medido antes e depois. O que ele move quem dirá são os seus próprios dados, não este post.
#Isso não é a mesma coisa que um bot de desvio de tickets?
Não, e a diferença é justamente o ponto. Uma jogada de deflexão tenta reduzir o volume de tickets respondendo diretamente aos clientes. Este design mira outro número: o tempo de primeira resposta, colocando a busca atrás do agente. O cliente continua falando com uma pessoa.
We are
A Stennir constrói ia que fica atrás dos seus agentes de suporte: busca, triagem, rascunho-e-revisão, medida pelo tempo de primeira resposta e pela qualidade da resolução.
We aren't
A Stennir não é uma fornecedora de chatbot para o cliente final e não vende desvio de tickets como objetivo; o agente permanece no ticket e os seus clientes continuam falando com pessoas.
Ferramentas como Zendesk AI, intercom fin ou as sugestões do gorgias funcionam dentro de seus próprios muros: suas macros, seus artigos de ajuda, suas respostas salvas. Este design acrescenta busca sobre o resto. Os tickets históricos, os documentos de produto, os pdfs de política de envio, os runbooks. é lá que se escondem as respostas dos tickets complexos.
Os KPIS que movemos são o tempo de primeira resposta e a qualidade da resolução em tickets complexos, não headcount. Dizemos isso desde o primeiro dia e medimos.
#Isso funcionaria para o nosso time de suporte?
O teste de encaixe é simples. As suas respostas já vivem em lugares lentos para pesquisar? Anos de tickets, uma pilha de pdfs de política, documentos de produto que mudam. Se os agentes perdem minutos procurando antes de cada resposta complexa, esse é o tempo que a busca pretende devolver.
Este design faz parte do nosso trabalho de consultoria de ia, com o treinamento do time de suporte incorporado a partir do nosso lado de treinamento em ia. Se você quer ver como as peças se encaixam, o journal tem mais exemplos práticos como este.
Se os seus agentes ficam procurando respostas antes de cada resposta complexa, esse é o atraso que este design ataca. conte o que você está construindo e diremos se a busca é a alavanca, ou se não é.
