Como criar um app de helpdesk (chamados) com IA

Como criar um app de helpdesk (chamados) com IA

Você descreve quem abre o chamado, quais informações ele precisa dar e por quais status o pedido passa. O Zugo gera o app com formulário de abertura, fila de atendimento e histórico, testa numa sandbox e publica em seu-suporte.zugo.run. Um app de três páginas custa 1.200 créditos, e cada ajuste depois custa 300.

O ganho real não é o visual da fila. É parar de perder pedido no meio de conversa de WhatsApp e conseguir responder "em que pé está o meu chamado" sem procurar em três lugares.

Quando a planilha e o WhatsApp deixam de dar conta?

Quando mais de uma pessoa atende. Enquanto é você sozinho, a conversa no celular funciona e qualquer sistema é burocracia. A partir do segundo atendente, começa a duplicidade: dois respondem o mesmo pedido, e um terceiro fica sem resposta nenhuma.

O segundo sinal é a pergunta "e aquele chamado de terça?". Se responder isso exige rolar histórico de conversa, o custo do atendimento já é maior que o custo de montar um app.

O terceiro é a cobrança do cliente. Sem número de protocolo e sem status visível, toda cobrança vira uma conversa do zero, e a sensação de descaso aparece mesmo quando o time está trabalhando.

Planilha compartilhada resolve por algumas semanas e quebra pelos motivos de sempre: alguém apaga uma linha, dois editam ao mesmo tempo, o status fica escrito de cinco formas diferentes. Validação antes do dado entrar é justamente o que um app faz e uma planilha não.

O que precisa existir num chamado para ele não se perder?

Poucos campos, todos úteis: quem abriu, categoria, descrição, prioridade e um identificador. Cada campo obrigatório a mais reduz a chance de o pedido ser aberto pelo canal certo.

O identificador é o que muda a conversa. Um número de protocolo transforma "aquele problema da impressora" em algo rastreável, e é ele que aparece no assunto do e-mail e na cobrança do cliente.

Categoria vale a pena mesmo com poucos itens, porque é o que permite descobrir, três meses depois, que metade dos chamados é sobre a mesma coisa. Esse dado costuma pagar o projeto sozinho: ele mostra onde arrumar o processo em vez de continuar atendendo.

Anexo é subestimado. Print da tela, foto do equipamento, cópia do boleto. Sem anexo, o primeiro contato vira sempre um pedido de mais informação, e o chamado nasce com um dia de atraso.

Quais status usar e quem age em cada um?

Cinco bastam. Mais que isso e ninguém atualiza, menos que isso e a fila não diz nada.

A coluna que mais importa é a segunda. Um status que não diz de quem é a bola serve só para enfeitar a tela. "Aguardando o solicitante" existe exatamente para que o relógio pare do lado certo quando o time já fez a parte dele.

Peça na descrição que a fila mostre, por padrão, apenas os chamados em aberto e ordenados por prioridade. Fila que abre com tudo, inclusive o que foi fechado em janeiro, é fila que ninguém olha.

Helpdesk interno ou atendimento ao cliente: o que muda?

Muda quem entra e o que a pessoa pode ver. No helpdesk interno (TI, facilities, RH), todo mundo tem conta e é razoável exigir login para abrir chamado.

No atendimento ao cliente, exigir cadastro antes de reclamar afasta gente. O formato que funciona é abertura pública com e-mail e telefone, e login apenas para o time que atende. Como as contas de usuário funcionam num projeto gerado está em a IA consegue criar login e contas de usuário.

Se o que você quer não é resolver problema e sim coletar sugestão e priorizar melhoria, o formato certo é outro, e ele está descrito em como criar um mural de feedback.

E se o objetivo for acompanhar oportunidade de venda em vez de problema, a estrutura é de funil e não de fila. O desenho disso está em como criar um CRM com IA.

Como descrever o app para a IA gerar a estrutura certa?

Diga quem abre, quem atende, quais categorias existem e quais status o chamado percorre. Nomes reais geram um app que o time entende sem treinamento.

App de chamados para o suporte interno de uma empresa com 40 pessoas.
Abertura com login por e-mail corporativo.
Campos: título, categoria, descrição, prioridade e anexo.
Categorias: computador, rede, sistema, acesso, equipamento.
Status: novo, em atendimento, aguardando o solicitante, resolvido, fechado.
Tela de fila para o time, com filtro por status, categoria e responsável.
Tela do solicitante mostrando só os chamados dele.
E-mail automático na abertura e a cada mudança de status.

Compare com "faça um app de helpdesk". As duas descrições geram algo funcional. Só a primeira gera o seu, com a separação entre a tela do time e a tela do solicitante, que é a decisão mais importante do projeto e a mais fácil de esquecer.

Como avisar o solicitante sem virar caçador de e-mail?

Com a integração do Resend, que cuida do envio de e-mails do projeto. Um e-mail na abertura, com o número do protocolo, e outro a cada mudança de status resolve a maior parte das cobranças antes que elas aconteçam.

Vale escrever o texto desses e-mails você mesmo, em vez de aceitar o padrão gerado. Duas frases claras com o número do chamado e o que acontece a seguir valem mais que um modelo bonito e vago.

O sentido oposto tem um limite honesto: e-mail que chega e vira chamado sozinho não é algo que sai de um prompt. Se o seu canal de entrada é a caixa de e-mail do suporte, o caminho realista é manter a abertura pelo formulário e divulgar o link nas assinaturas.

Dá para controlar SLA e prazo de resposta?

Dá para o essencial: registrar a data de abertura, calcular há quanto tempo o chamado está parado e destacar em vermelho o que passou do combinado. Isso resolve o problema de gestão na maioria das operações pequenas.

O que exige mais trabalho é a régua completa: prazo diferente por prioridade, contagem apenas em horário comercial, pausa automática quando o status é "aguardando o solicitante", escalonamento para o gestor. Cada uma dessas regras é uma rodada de edição, e é honesto dizer que a soma delas leva tempo.

Se a sua operação vive de SLA contratual com multa, uma ferramenta de helpdesk de mercado já resolve isso pronta e provavelmente sai mais barata em horas do que reconstruir a mesma lógica. Vale comparar antes de começar.

Quanto custa em créditos montar e manter?

Créditos são gastos para gerar e para editar. Publicar não custa nada, e o app publicado não consome nada enquanto está no ar.

O plano gratuito dá 2.400 créditos e serve para experimentar. O Pro custa $25 por mês com 20.000 créditos, cerca de 16 plataformas multipágina, 33 construções ou 66 edições. O Business custa $50 por mês com 20.000 créditos.

Um helpdesk costuma consumir mais no primeiro mês de uso real que na criação. O time usa, descobre que falta o campo de setor, edita. Descobre que a fila precisa de filtro por responsável, edita de novo. Quatro a seis rodadas até estabilizar é o esperado.

Sobre tempo: um app com três telas leva alguns minutos para ser gerado. Antes da entrega ele passa por uma sandbox, e o que não abre não é entregue. A sandbox confirma que a tela sobe, não que o seu fluxo de status faz sentido: abra três chamados de teste e percorra todos os status antes de liberar para o time.

O que o Zugo não faz num helpdesk?

Não substitui uma plataforma de atendimento completa. Telefonia, chat ao vivo, base de conhecimento com busca e relatório gerencial avançado são domínios inteiros, e ferramentas dedicadas fazem isso melhor.

Não integra sozinho com o seu sistema de estoque, com o ERP nem com o cadastro de clientes que você já mantém. Dá para aproximar por edições, e quando o projeto cresce o caminho é exportar o código pelo GitHub e seguir com um desenvolvedor.

Regra de negócio muito específica se afina em rodadas, não em um único prompt. Fila por turno, revezamento automático entre atendentes, pesquisa de satisfação com nota: cada uma leva uma ou duas edições.

E o mais importante: um app de chamados não conserta um processo ruim. Se ninguém assume o chamado hoje, a fila organizada vai apenas mostrar isso com mais clareza. Nesse caso a ferramenta ajuda, mas quem resolve é a decisão de quem atende o quê.

Por onde começar?

Escreva as suas categorias e os seus status em uma folha antes de abrir a ferramenta. Cinco categorias, cinco status, uma frase explicando quem age em cada um. Esse é o trabalho que a IA não pode fazer no seu lugar.

Depois gere a primeira versão, rode uma semana com o time real e só então acrescente automação. Dá para começar pelo plano gratuito em zugo.dev e crescer o app conforme a fila mostrar o que falta.