O que um fluxo de aprovação de suporte realmente cobre
Um fluxo de aprovação entra em ação sempre que alguém da equipe não tem permissão para agir sozinho. No suporte, isso costuma significar três tipos de solicitação:
- Dinheiro: reembolsos, créditos, gestos de boa vontade e isenções de taxas acima do que um agente pode conceder.
- Exceções: qualquer coisa fora da política escrita, como uma devolução fora do prazo ou um cancelamento sem diagnóstico. Meu guia sobre gestão de exceções de suporte explica como registrá-las.
- Trabalho de IA: respostas e ações redigidas por um agente de IA que uma pessoa confere antes de saírem.
O caso do dinheiro é o mais antigo, e os agentes de linha de frente o descrevem do mesmo jeito em todos os setores. Assim um profissional de suporte de uma operadora de telecomunicações descreveu uma escada real de créditos:
"Supervisors can approve up to about $300 in credits, then whatever is left gets rolled up to their managers. Floor support or SME'S have about the same limit as a supervisor, but they do not have access to things like the credit qué and a few other things."
Isso é um fluxo de trabalho, mesmo que ninguém jamais o tenha escrito: tem limites por função, uma fila que só alguns enxergam e, por cima, uma passagem para cima. Escrevê-lo é o primeiro passo, e ele pertence aos seus SOPs de suporte, ao lado da própria política.
O cartão de solicitação é onde a maioria dos fluxos quebra, então começo por ele. Um aprovador deveria conseguir decidir só pelo cartão:
Se o gerente precisa abrir o ticket, rolar a conversa e ainda consultar o pedido, a aprovação leva 15 minutos em vez de 15 segundos. Do lado da fila, vejo o custo disso toda semana: o cliente espera e o agente vira mensageiro de uma decisão que não tomou.
Decida o que precisa de aprovação antes de escolher uma ferramenta
A pergunta da ferramenta vem em segundo lugar. Primeiro, decida quais solicitações precisam de uma segunda pessoa, e para isso uso dois testes.
Teste 1: está acima do limite do agente? Defina faixas de valor, dê um aprovador a cada faixa e deixe os agentes resolverem tudo abaixo da sua faixa sem pedir. Aprovação para valores minúsculos é puro desperdício, como um comentarista apontou depois de esperar por um reembolso de 37 centavos:
"This is why for the store it is better to have a smoother process for small price adjustments, it should not be necessary to wait 15 minutes for the store manager's approval on a 37 cent refund, nor should he even have to deal with it at all, that is a waste of his time and salary to be attending to something so minor."
Teste 2: dá para desfazer? Este importa mais quando há IA no meio, porque um reembolso pode ser revertido ou baixado, mas uma promessa em um e-mail não pode ser retirada. Uma discussão recente sobre o que agentes de IA devem fazer sem aprovação chegou exatamente a isto:
"imo the cutoff isnt really about the action type, its about reversibility. if the agent does something you can undo in 30 seconds, let it run. if undoing it requires an apology email to a customer, that needs approval."
Junte os dois testes e você tem uma escada. Os números abaixo são um exemplo, não uma referência. Escolha os seus a partir do seu próprio histórico de reembolsos:
A maioria dos tickets deve parar no degrau mais baixo. Se metade dos seus tickets de reembolso sobe a escada, os limites estão baixos demais, e cada subida adiciona uma espera para o cliente. O guia da matriz de aprovação de reembolsos detalha como definir as faixas. Também há um contraponto justo: algumas aprovações existem por um motivo, já que o pessoal de linha de frente nem sempre sabe por que um preço ou uma política foi definido de certo jeito. A meta é menos aprovações, mais bem direcionadas, não zero.
Onde cada helpdesk coloca as aprovações
Passei pelas centrais de ajuda dos helpdesks que mais vejo nos rollouts da eesel. Eles se dividem em três grupos: ferramentas com um objeto de aprovação real, ferramentas feitas para aprovações de TI e ferramentas em que "aprovação" significa um rascunho compartilhado mais uma permissão que se retira. Escolha a sua para ver a configuração, onde os aprovadores decidem e o requisito de plano:
Resumindo: se você precisa de um objeto de aprovação com status, bloqueio de fechamento e registro, Zendesk Professional, Freshservice e Jira Service Management são os únicos três desta lista que o oferecem para tickets. Os demais chegam lá com processo.
Zendesk: solicitações de aprovação reais, a partir do Suite Professional
O Zendesk cita reembolsos como caso de uso de exemplo: um agente recebe um ticket de reembolso, cria uma solicitação de aprovação e a envia a um aprovador, como o líder da equipe. As regras são rígidas de um jeito útil, segundo a documentação de aprovações do Zendesk:
- Até 5 aprovadores por solicitação. Com mais de um, todos precisam aprovar, e uma recusa recusa o bloco inteiro.
- O aprovador não pode ser o solicitante do ticket, o responsável nem quem criou a solicitação. A separação de funções já vem embutida.
- Aprovadores de grupo só funcionam com grupos de até 30 membros, e vale a primeira resposta.
- Uma solicitação pendente impede o fechamento do ticket até que todos respondam ou ela seja retirada.
- As solicitações não podem ser editadas depois de criadas. Você retira e recria.
Vale conhecer as lacunas antes de projetar em torno disso. Não há cadeia sequencial: se você precisa de líder e depois gerente, cria uma solicitação, espera e cria a próxima. O Zendesk também não documenta configuração de lembretes, então cobrar um aprovador lento é um trabalho manual de compartilhar o link. Um product manager do Zendesk também confirmou nos comentários que aprovar por resposta de e-mail está descartado por motivos de conformidade.
A parte do Slack é a grande mudança de 2026. Desde maio de 2026, aprovadores individuais recebem uma DM no Slack, e as aprovações de grupo abrem um canal privado temporário com todos os integrantes do grupo:
Em outubro de 2026, o Zendesk adicionou comentários do Slack que sincronizam de volta ao ticket como registro auditável. Você ainda não pode criar nem retirar uma solicitação pelo Slack. Para fluxos automatizados, a receita de action flows pode pausar por até 30 dias e se ramificar em Approved, Denied, Withdrawn ou Expired, embora o Zendesk diga que as ações de aprovação avançadas exigem seu programa de acesso antecipado.
Se você está no Suite Team, a alternativa são as side conversations, que são uma conversa à parte e não um objeto de aprovar ou negar. Os requisitos de plano estão no meu detalhamento de preços do Zendesk, e o guia de funções e permissões explica quem pode criar solicitações.
Freshservice e Jira Service Management: cadeias de nível TI
As duas ferramentas vêm do lado de TI e isso aparece: as aprovações são ali um objeto de primeira classe, com uma lógica de várias etapas que os helpdesks de atendimento ao cliente não têm.
No Freshservice, os aprovadores ficam em grupos e os grupos ficam em uma cadeia. Cada grupo tem uma regra (Everyone, Anyone, Majority ou First Responder), e a cadeia também tem uma:
Dois recursos que eu gostaria que as ferramentas de atendimento ao cliente copiassem. O Freshservice pode lembrar os aprovadores a cada N horas, e os aprovadores podem delegar aprovações a um colega com datas de início e fim, o que resolve o problema do "gerente está de férias". Os preços vão de US$ 19 a US$ 99 por agente por mês, cobrados anualmente, com fluxos de multiaprovação marcados em todos os planos. Meu guia de preços do Freshservice traz o detalhe dos planos.
O Jira Service Management adiciona a aprovação como uma etapa em um status do fluxo de trabalho. Você escolhe o número de aprovadores, de onde eles vêm e de quais campos excluí-los, como responsável ou relator. Os aprovadores agem pela central de ajuda, pelo e-mail, Slack ou Teams, e não precisam de licença do JSM. O artigo sobre preços do Jira Service Management explica por que os 100 e-mails por dia do plano Free podem atrapalhar as notificações de aprovação.
Se sua equipe de suporte já divide uma conta Freshworks ou Atlassian com a TI, pode valer a pena rodar as aprovações de reembolso lá. Se não, essas ferramentas dão muito trabalho de configuração para uma equipe de suporte que só quer o sim de um gerente.
Front, Help Scout e Freshdesk: rascunhos e permissões
Esses três não têm botão de aprovar para tickets. O que eles têm é um rascunho que outra pessoa pode ver, além de uma forma de impedir que certas pessoas enviem.
A política que o próprio Front sugere é "sempre compartilhar o rascunho com um gerente para aprovação em perguntas sobre preços", segundo seu artigo sobre fluxos de suporte. Rascunhos compartilhados vêm ativados por padrão em caixas de entrada compartilhadas, mas os colegas não são notificados a menos que você os mencione com @:
Para transformar isso em regra firme, você remove a permissão "Send messages" de um grupo, como os recém-contratados. Isso exige o Enterprise a US$ 105 por assento por mês e só cobre canais compartilhados. O Front também sugere uma tarefa vinculada atribuída a um gerente para pedidos de aprovação, que funciona em todos os planos e traz a conversa de volta ao topo quando a tarefa é resolvida. O detalhe dos planos está no meu artigo de preços do Front.
A abordagem documentada do Help Scout é mais simples: agentes novos salvam respostas como rascunhos, e um gerente envia em nome deles pelo menu Send options. Os Light Users, que podem deixar notas mas não responder, exigem Plus ou Pro. O problema é que o Help Scout afirma que não há método para restringir conversas individuais, então você não pode dizer "este agente precisa de aprovação só em tickets de reembolso". Mais no detalhamento de preços do Help Scout.
O Freshdesk documenta um fluxo de aprovação, mas para artigos da base de conhecimento no Enterprise, não para tickets. A autorização de tickets no Freshdesk é um processo que você constrói com funções e permissões e notas internas. O guia de aprovações do Freshdesk percorre essas opções.
Gorgias e HubSpot: direitos por função, aprovações em outro lugar
O Gorgias controla reembolsos por função, não por aprovação. Usuários Basic, Lead e Admin podem disparar um reembolso ou cancelamento do Shopify direto do ticket, usuários Observer e Lite não, e não encontrei um teto de valor por agente nas tabelas de permissões de usuário. O mais próximo de uma etapa de revisão é que as ações de macro aparecem sob o editor, onde o agente pode visualizá-las, editá-las ou removê-las antes de enviar. Se você precisa de um gerente no circuito no Gorgias, é um desenho de funções e uma norma de equipe, que você pode reforçar com regras do Gorgias que marquem tickets de reembolso para um líder conferir.
O HubSpot tem a interface de aprovação mais polida do grupo, com Approve, Reject e Request changes no registro, mas ela é para negócios e orçamentos. Tickets não estão na lista de objetos de aprovação do HubSpot. As regras do pipeline de tickets no Service Hub Professional podem limitar quem edita tickets em certas etapas, mas superadministradores, fluxos de trabalho e a API podem contorná-las. Meu guia de IA para HubSpot Service Hub cobre o que o lado de suporte pode automatizar.
Coloque o limite de valor também na camada de pagamento
Quando seu helpdesk não consegue impor um limite, às vezes o sistema de pagamento consegue. O Stripe tem a aprovação de reembolso nativa mais clara que encontrei: uma regra de aprovação por duas partes em "Refund is created", com um limite de valor opcional. Um usuário não pode aprovar a própria solicitação, e solicitações não aprovadas expiram após 14 dias, segundo a documentação de aprovações por duas partes do Stripe.
O admin online do Shopify tem permissões de reembolso ligadas ou desligadas, sem limite de valor. O Shopify POS é diferente: reembolsos, descontos e crédito de loja podem ser configurados como "Approval required", e um gerente aprova digitando seu PIN. Funções personalizadas de POS são um recurso do POS Pro.
Aprovando respostas e ações de IA
Tudo acima presume que um agente humano pede e um humano aprova. Com um agente de IA na fila, há uma segunda camada por cima: a IA prepara o trabalho e uma pessoa o aprova antes que chegue ao cliente ou aos seus sistemas. Um comentarista do Hacker News descreveu bem essa configuração muito antes de a maioria dos fornecedores lançá-la:
"Now if AI agents are free to issue refunds or discounts by their own? Great, let's do that and suddenly most people are on board. But get ready for rampant abuse. Best solution would be an AI cyborg system where it readies a recommendation and a human swings by and approves or denies it without wasting time talking to people."
Isso é parecido com o que os fornecedores lançam agora, cada um à sua maneira:
- Zendesk auto assist (parte do complemento Copilot) sugere ações que um agente aprova antes de rodarem. Administradores podem marcar uma ação como pré-aprovada, e a orientação do próprio Zendesk é que ações de escrita como reembolsos continuem aprovadas pelo agente. Meu guia de ações do auto assist traz a configuração.
- Front As regras do Autopilot têm um campo "Hold reply for review" que cria um rascunho em vez de enviar, e o Front recomenda começar por aí antes da automação completa.
- Help Scout Os AI Drafts são escritos para os agentes revisarem e ajustarem antes de enviar, no Plus e no Pro.
- Gorgias O AI Agent tem uma configuração "Customer confirmation", mas note quem aprova: o comprador confirma, não um gerente. Ela é ativada automaticamente para ações irreversíveis, como cancelar um pedido.
- Stripe aplica regras de aprovação padrão a reembolsos criados com chaves de API marcadas como de agente. Até a camada de pagamento trata reembolsos iniciados por IA como um ator separado.
Este é o fluxo que eu buscaria para uma solicitação de reembolso com IA no meio:
O que as pessoas subestimam é o que os revisores realmente fazem com os rascunhos de IA. Em um teste com tráfego real em uma caixa de entrada do Zendesk de e-commerce, a triagem teve 93% de precisão, mas os agentes enviaram apenas 12% dos rascunhos de IA como estavam. O padrão foi olhar de relance e reescrever: um rascunho de 8 a 15 frases reduzido a 1 a 3 frases. Cerca de 65% das reescritas eram de tamanho e tom, o tipo de coisa que se resolve treinando com as respostas enviadas pela própria equipe, e só cerca de 5% eram a IA errando nos fatos.
Duas lições do lado da fila. Primeiro, um botão de sim ou não não basta. Um cliente do Freshdesk me disse que precisava editar os rascunhos de IA antes de enviar, porque aprovar como está ou rejeitar o obrigava a copiar e colar. Segundo, confira se a versão editada é a que é enviada. Um colega sinalizou uma vez um cliente do Freshdesk cujos rascunhos editados saíam como a versão original sem edição, o que deixou o fluxo inutilizável até ser corrigido. Teste esse caminho antes de confiar nele.
Se você está comparando ferramentas de copiloto de IA, esses dois detalhes dizem mais do que qualquer demo. A visão do próprio Freshdesk sobre rascunhos está no meu artigo sobre os rascunhos de resposta com IA do Freshdesk.
Como opero IA com aprovação prévia na eesel
O colega de IA da eesel foi projetado do jeito que você integraria uma pessoa nova. Ele não recebe um interruptor de autonomia no primeiro dia. Ganha autonomia com trabalho revisado. Na prática, isso se resume a uma configuração por ação, escolhida por agente, como descrito na documentação de Actions and Approvals:
- Auto: roda sozinha, a menos que as instruções digam para perguntar antes em determinada situação.
- Needs approval: o agente prepara a ação, e uma pessoa a aprova ou nega antes que algo aconteça.
- Disabled: o agente não pode usá-la de jeito nenhum.
As ações são agrupadas em Read e Write, então um ponto de partida comum é Read em Auto e a maior parte de Write em Needs approval, com ações de baixo risco como notas internas em Auto:
Quando uma ação precisa de aprovação, o aprovador vê o texto exato da resposta ou o valor do reembolso (ou a tag) e escolhe entre três botões. Approve executa agora. Always allow executa e passa essa ação para Auto daí em diante, só para esse agente. Deny a ignora, e o agente segue sem ela. Esse botão "Always allow" é a etapa de formatura: você aprova reembolsos em um agente de loja cinco vezes, eles parecem certos, e você o libera.
A aprovação chega onde o aprovador já trabalha, o que importa, já que o administrador do Zendesk que citei no começo não queria mais uma aba para vigiar. As aprovações aparecem no painel da eesel, como um cartão na conversa do Slack de onde a execução partiu, como um link em um e-mail ou nota do helpdesk, e no terminal:
Algumas regras em que me apoio ao configurar um cliente novo:
- Políticas de exceção vão em linguagem simples. Você pode deixar as respostas em Auto e escrever "pergunte antes de responder qualquer coisa sobre reembolsos", e o agente pergunta só nesses casos. A documentação inclui modelos para exatamente isso, como escalar qualquer reembolso acima de US$ 100 ou pular o pedido de foto em reclamações de dano abaixo de US$ 50. Foi assim que um administrador de suporte ensinou ao agente a regra "diagnostique antes de cancelar": corrigindo-o como a uma pessoa nova.
- Somente Editors podem aprovar. Owners e Editors decidem. Viewers veem as aprovações mas não agem sobre elas, e no Slack quem clica é associado a um Editor por e-mail.
- Nada é aprovado automaticamente por tempo esgotado. Uma ação pendente continua pendente, e o agente deixa uma nota de que uma pessoa fará o acompanhamento. Cada decisão mostra quem decidiu e quando na página Activity.
- Nada roda até você criar uma automação. Conectar o Zendesk não faz o agente responder a ninguém.
Para equipes que vivem no terminal, ou que querem que Claude Code, Codex ou Cursor gerenciem aprovações, a CLI da eesel conduz o mesmo agente do painel. eesel approvals lista o que está esperando, eesel approvals approve <id> --always aprova e gradua a ação de uma vez, e eesel integrations zendesk actions imprime cada ação com sua configuração de aprovação. As escritas da CLI seguem as mesmas permissões, então as escritas de um Viewer ficam sempre retidas para um Editor.
Antes que qualquer coisa disso toque um cliente, peço uma simulação primeiro. Com um helpdesk conectado, o agente reproduz tickets passados reais e compara suas respostas com o que a equipe enviou. No exemplo da documentação, 17 de 20 tickets amostrados coincidiram, com uma pontuação por tema e uma lista de correções ordenada. Isso diz quais ações estão prontas para Auto e quais devem ficar atrás de uma aprovação. Para o quadro geral, veja meus artigos sobre colegas de IA e o agente de IA para helpdesk.
Erros comuns em fluxos de aprovação
- Aprovar tudo. Se todo reembolso precisa de um gerente, o gerente vira a fila. Aumente os limites dos agentes até a maioria dos tickets parar no degrau mais baixo.
- Uma solicitação magra. "Posso reembolsar isto?" obriga o aprovador a reconstruir o ticket. Use o cartão de cinco linhas: pedido, solicitação, linha da política, recomendação, prazo.
- Sem lembrete nem aprovador reserva. Não encontrei configuração de lembrete de aprovações na documentação do Zendesk nem do Jira. Se a sua ferramenta também não tem, defina um SLA interno para aprovações e nomeie um reserva.
- Sem registro escrito. Uma aprovação em uma DM é invisível para o próximo agente. Mantenha a decisão no ticket para que alimente seu registro de exceções e as futuras mudanças de política.
- Graduar a IA cedo demais. Passe uma ação para automático depois de trabalho revisado, não depois de uma boa demo. O verbete sobre guardrails de IA cobre outros limites que vale definir, e a injeção de prompt é o motivo pelo qual as ações de reembolso merecem cuidado extra.
- Esquecer para onde vão os escalonamentos. Aprovação e escalonamento são parentes. Se uma aprovação é negada, o agente precisa de um caminho claro, o que cobrem o escalonamento por IA e o escalonamento entre equipes.
Quando as políticas mudarem, atualize as regras de aprovação no mesmo dia também. Meu guia de gestão de mudanças de política mostra como manter agentes, macros e instruções de IA em sincronia, e o controle de acesso de agentes de suporte explica como delimitar o que cada assento, inclusive o da IA, pode tocar.
Experimente a eesel para IA com aprovação prévia na sua fila
Se você usa Zendesk, Freshdesk, Gorgias ou outro helpdesk ao qual a eesel se conecta, o colega de IA para helpdesk da eesel pode começar como você começaria qualquer pessoa nova com reembolsos: ele redige a resposta ou o reembolso, e você aprova pelo Slack, pelo ticket ou pelo painel. Ações que continuam saindo certas ganham "Always allow", e tudo que custa dinheiro pode ficar atrás do seu OK pelo tempo que você quiser. A visão de relatórios mostra quantas ações foram aprovadas, rejeitadas ou ainda aguardam, por ferramenta:
As aprovações não custam nada a mais. Um ticket ou chat é 1 crédito, não importa quantas respostas e ações ele exija, com assentos ilimitados; o plano gratuito tem 100 créditos e não pede cartão, e os planos pagos começam em US$ 299 por mês por 500 créditos. Experimente a eesel na sua própria fila com todas as respostas em Needs approval e veja quantas você teria enviado como estavam.