Central de tickets · o console de atendimento

A Central de tickets é o console onde a sua equipe trabalha os chamados: fila com visões salvas, conversa com o cliente no centro e contexto com relógios de SLA e IA à direita. Aqui ficam também o e-mail de entrada, as macros, o roteamento, as automações, os incidentes, a base de conhecimento e as métricas do time.

A Central de tickets é o console de atendimento do SellioCRM: um lugar só para trabalhar os chamados em fila, do primeiro e-mail do cliente até a pesquisa de satisfação. Ela usa o mesmo objeto Ticket do CRM, então tudo que você já registra (assunto, empresa, contato, categoria, canal) continua valendo e aparece na visão 360º do cliente.

Abra pelo menu lateral, no grupo Atendimento, em Central de tickets. O objeto Tickets continua no mesmo grupo para quem prefere o cadastro em formulário, o quadro por status e as visões de lista.

Layout em três painéis

O console abre em três painéis, pensado para quem atende o dia inteiro: à esquerda as visões e filas com contadores, ao centro a conversa com o cliente, à direita o contexto do chamado. No celular o painel de visões vira um seletor no topo da lista, para não ocupar espaço.

A fila e as visões salvas

• A coluna da esquerda traz visões prontas com o número de chamados em cada uma: Abertos, Não atribuídos, Meus, Pendentes (aguardando cliente ou terceiro) e Resolvidos hoje.
• Visões salvas: crie um filtro nomeado por status, prioridade, atribuição e grupo, por exemplo Urgentes do time de suporte. Ele aparece na lista com o próprio contador.
• Acima da fila ficam a busca (por assunto ou solicitante), o filtro de prioridade e a ordenação: mais recentes, mais antigos, por prioridade ou por prazo de SLA.
• Cada linha mostra o assunto, o solicitante, o status, a prioridade, o responsável e o estado do SLA, com selos coloridos para leitura rápida.
• Ações em massa: marque a caixa do topo para selecionar vários chamados e aplicar status ou responsável de uma vez.

O console do agente

Ao abrir um chamado, a conversa aparece no centro em ordem cronológica e as propriedades ficam à direita: solicitante, canal de entrada, etiquetas, status, prioridade, categoria, responsável e grupo. Alterar qualquer propriedade salva na hora.

1. No compositor, escolha Resposta ao cliente para escrever algo que o cliente verá, ou Nota interna para registrar algo visível só para a equipe.
2. A nota interna aparece destacada em cor diferente, para não se confundir com o que foi dito ao cliente.
3. Clique em Anexar para enviar arquivos junto da mensagem (até 25 MB cada). Numa resposta pública, os links dos anexos também vão no corpo do e-mail enviado ao cliente.
4. Escreva e clique em Enviar (ou Adicionar nota).

• Número de protocolo: todo chamado recebe um número sequencial por organização, no formato #000123. Ele é imutável, aparece na fila, no topo do chamado e no e-mail de resposta.
• Linha do tempo: a aba Linha do tempo funde, em ordem, as mensagens públicas e internas e os eventos de mudança (criação, status, prioridade, responsável e outras propriedades).
• Menções e seguidores: numa nota interna, use Mencionar para chamar um colega. Ele recebe uma notificação e passa a seguir o chamado. Qualquer pessoa pode seguir ou deixar de seguir pelo painel de propriedades e é avisada a cada atualização.

Macros e variáveis

1. Clique em Gerenciar macros para criar respostas prontas com título e corpo.
2. Opcionalmente, a macro define o status e a prioridade a aplicar quando for usada.
3. No compositor, selecione a macro em Aplicar macro: o corpo entra no campo de resposta e, se configurado, status e prioridade são aplicados.

Macros e respostas aceitam variáveis entre chaves duplas, preenchidas no envio: {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} e {{org_name}}, entre outras. Em Canais e roteamento você define uma Assinatura do atendimento, anexada às respostas públicas; a assinatura pessoal do agente, quando existe, tem prioridade.

SLA: prazos, pausa, horário e feriados

O estado do SLA aparece na fila e no chamado: No prazo ou SLA estourado enquanto está aberto, e Resolvido no prazo ou Resolvido fora do prazo depois de resolvido. À direita, os relógios de primeira resposta, próxima resposta e resolução fazem contagem regressiva e mudam de cor: verde, amarelo perto do prazo e vermelho quando vence. Ao mudar o status para Resolvido ou Fechado, a data de resolução é carimbada automaticamente.

• Pausa automática: ao mover o chamado para Aguardando cliente ou Aguardando terceiro, o relógio de resolução pausa e um selo SLA pausado aparece. Ao voltar para um status ativo, o relógio retoma. O tempo em espera não conta contra a sua meta nem nas métricas.
• Próxima resposta: cada política pode ter um alvo de próxima resposta. O relógio começa quando o cliente responde e reinicia a cada nova resposta pública do agente.
• Horário comercial: na aba SLA e horário você define dias, horas e o fuso (informe um fuso como America/Sao_Paulo para respeitar o horário de verão). Desligue a restrição para contar tempo corrido (atendimento 24x7).
• Feriados: cadastre feriados por data. Nesses dias o expediente é considerado fechado e o prazo é empurrado para o próximo dia útil.
• Políticas: cada política casa por prioridade, grupo ou categoria (em branco significa qualquer) e define alvos em minutos úteis. Elas são avaliadas na ordem da lista e a primeira ativa que casa vale. Sem política casando, valem as horas por prioridade de Configurações, Atendimento.
• Risco de violação: uma barra estimada indica se o chamado está com risco baixo, médio ou alto de estourar o prazo, com o motivo.

E-mail de entrada: o e-mail vira chamado

1. Abra a Central de tickets e vá à aba Canais e roteamento.
2. Clique em Gerar endereço de suporte. O CRM mostra um endereço no formato support+seu-codigo@dominio.
3. No seu provedor de e-mail, encaminhe a caixa de suporte para esse endereço.
4. Pronto: novos e-mails abrem chamados e as respostas do cliente entram na mesma conversa.

O remetente é associado a um Contato pelo e-mail; na primeira vez o Contato é criado, e o canal do chamado fica como E-mail. Toda resposta enviada ao cliente leva o código do chamado no assunto, no formato [#XXXXXXXX]. Quando o cliente responde mantendo o código, a mensagem entra na mesma conversa em vez de abrir um chamado novo; se o chamado estava resolvido ou fechado, ele reabre.

Confirmação automática de recebimento: em Canais e roteamento, ative a Confirmação de recebimento e escreva o texto com as variáveis. Quando um e-mail abre um chamado novo, o solicitante recebe na hora a confirmação com o número de protocolo. Nasce desligada.

Mesclar chamados e conversas paralelas

Quando o mesmo assunto virou dois chamados, abra o que ficará como principal e clique em Mesclar. As mensagens do outro passam para o principal e ele é encerrado com um aviso apontando para onde foi.

Precisa falar com um fornecedor ou com outra equipe sem que o cliente veja? Use as Conversas paralelas, logo abaixo da conversa principal: informe um assunto e os participantes por e-mail, escreva a mensagem e o CRM a envia. Tudo fica registrado no chamado, separado da conversa com o cliente.

Atribuição automática e automações

Em Canais e roteamento, defina para cada equipe como os chamados são distribuídos ao entrarem no grupo: Rodízio (alterna entre os agentes) ou Por carga (o agente com menos chamados abertos primeiro). Deixe em Desligada para atribuir sempre à mão.

Na aba Automações você cria regras do tipo quando algo muda, então aja. Cada regra tem um evento (o chamado é criado, ou uma propriedade muda), condições opcionais de status, prioridade, categoria, grupo e responsável, e uma ou mais ações.

• Ações: definir status, prioridade ou categoria; atribuir a um agente ou a um grupo; aplicar uma macro; notificar o responsável; notificar o grupo inteiro; enviar a pesquisa de satisfação.
• As regras rodam no exato momento da criação ou da mudança, em qualquer lugar do CRM: console, edição do registro ou integração.
• Arraste pela alça à esquerda do nome para reordenar; elas são avaliadas de cima para baixo.
• Automações por tempo: rodam sozinhas de tempos em tempos e agem pelo prazo, por exemplo escalar um chamado sem primeira resposta há X horas úteis, avisar quando o prazo está perto de estourar ou fechar os resolvidos há N dias. Cada uma age no máximo uma vez por chamado.
• Webhooks de saída: em Canais e roteamento, avise sistemas externos a cada evento do chamado (criado, atualizado, resolvido, nova mensagem), enviando para uma URL assinada ou para os canais de mensagem já conectados no hub de Integrações.

Inteligência artificial do chamado

Com a IA ativa, o painel da direita analisa o chamado e sugere: categoria e urgência, sentimento do cliente com nota de 0 a 100, resumo do histórico, chamados semelhantes e artigos da base de conhecimento. No compositor, o botão Sugerir resposta (IA) rascunha uma resposta a partir da conversa, no idioma da sua interface. A IA nunca envia nada ao cliente sozinha: você revisa, edita e decide.

Base de conhecimento e help center

A sua base de conhecimento alimenta um portal público de autoatendimento com busca por título, conteúdo e etiquetas. No fim da página, o formulário de ainda preciso de ajuda sugere artigos relacionados enquanto a pessoa digita (deflexão) e, se ainda assim for necessário, abre um chamado direto no seu CRM.

• Em Marketing, Base de conhecimento, a aba Artigos permite escrever, editar e enviar para revisão; a aba Revisão é a fila de aprovação (Aprovar e publicar ou Rejeitar com motivo); a aba Importar cria um rascunho a partir de uma URL; a aba Feedback mostra os artigos mais úteis e os que precisam de atenção pelos votos dos leitores.
• Cada gravação guarda um histórico e você pode restaurar uma versão anterior.
• Cada artigo tem um idioma, e a busca pública pode filtrar pelo idioma do leitor.
• Na aba SLA e horário você monta os formulários de abertura do portal: além de nome, e-mail, assunto e mensagem, adicione campos próprios de texto, lista ou e-mail, com exibição condicional. Marque um como padrão para o help center usar.

Incidentes e página de status

1. Abra a aba Incidentes do console e crie um incidente com título e severidade.
2. Vincule os chamados afetados pelo mesmo evento.
3. Publique atualizações na linha do tempo do incidente e comunique todos os afetados de uma vez, por e-mail aos solicitantes dos chamados vinculados.
4. Ao resolver, registre a causa raiz e o post-mortem.
5. Marque como público para expor uma página de status aberta aos seus clientes.

Satisfação e métricas

Ao resolver ou fechar um chamado, o CRM envia automaticamente uma pesquisa de satisfação por e-mail ao solicitante, com nota de 1 a 5 e um comentário. É uma única vez por chamado. Quando o cliente responde, a nota aparece no bloco Satisfação do console e é gravada nos campos do próprio chamado. Ligue ou desligue em Automações, Pesquisa de satisfação, e use Reenviar pesquisa quando quiser pedir de novo.

Na aba Métricas você acompanha o período de 7, 30 ou 90 dias: chamados criados, resolvidos e em aberto, tempo médio de primeira resposta, tempo médio de resolução, percentual dentro do SLA, satisfação média com a taxa de resposta, backlog, resolução no primeiro contato, taxa de reabertura e carga por equipe, com segmentação por canal e por categoria e uma tabela por agente. Os indicadores mostram a variação em relação ao período anterior e um mini-gráfico diário, e os relatórios podem ser exportados em PDF ou XLSX.

Perguntas comuns

• O envio da pesquisa depende do e-mail do solicitante, do campo do chamado ou do Contato vinculado, e de o envio de e-mail estar configurado.
• Ao exportar ou anonimizar os dados de um titular em Configurações, Privacidade, o conteúdo das mensagens e das avaliações daquele solicitante também é incluído ou anonimizado.
• Integrações com help desks externos criam chamados no CRM automaticamente; depois de criados, você os trabalha aqui como qualquer outro.
• No aplicativo móvel você também acompanha a fila, abre um chamado, responde e muda o status.
• Para o cliente acompanhar sozinho os próprios chamados, responder e reabrir, veja o artigo do portal do cliente.

Chamado pai e filho, regras de auto-resposta e mapeamento de canal

Um chamado agora pode pender de outro. Você define o pai no chamado e os filhos aparecem em lista, com uma guarda que recusa laço ou corrente funda demais, e um aviso quando você tenta fechar um pai que ainda tem filho aberto. A auto-resposta virou **regras** em vez de um texto fixo: cada regra tem condições próprias (canal, categoria, prioridade, horário comercial, só a primeira mensagem, palavras-chave) e mensagem própria, e vence a primeira que casa. A guarda anti-laço não é desligável, de propósito: responder a uma caixa automática é como duas secretárias eletrônicas conversando para sempre. E o canal do chamado passa a vir de uma **tabela de mapeamento** que você controla, então o chamado que chegou por telefone no seu help desk deixa de ser gravado como "portal" e o relatório por canal para de mentir.

Onde ficam: o pai e os filhos aparecem no próprio chamado, no painel **Casos relacionados**. As regras ficam em **Configurações → Respostas automáticas**, e o mapeamento em **Configurações → Canais de chamado**; os dois são de quem administra a conta.

O chamado ganhou uma terceira aba, **Contexto**, e é nela que o console parou de mandar você para outra tela. Ela traz os campos do próprio chamado (inclusive os que você criou), os registros relacionados, as atividades e tarefas, os arquivos, os casos pai e filhos, e os outros chamados abertos do mesmo cliente. Se você desenhou um Canvas para o objeto Chamado, é esse layout que manda aqui também, então você não desenha a mesma coisa duas vezes.

Encerrar um chamado com um código de desfecho

Resolver um chamado era escrever texto livre no campo Resolução. Isso descreve o que aconteceu, mas não classifica: dois agentes escrevem o mesmo desfecho de dez maneiras, e ninguém consegue responder quantos chamados do mês passado foram defeito do produto e quantos foram erro de configuração. O campo Categoria também não ajuda, porque ele classifica o assunto na abertura do chamado, não o desfecho no encerramento.

Por isso o desfecho agora é uma lista curta que você controla, em **Configurações → Códigos de desfecho**. Cada código tem um rótulo, um escopo e uma opção que define se escolhê-lo exige uma explicação (use essa opção em "Outro", que sozinho não explica nada). A mesma lista serve a chamados e a chamadas telefônicas, então você mantém um vocabulário só, em vez de dois dizendo a mesma coisa.

1. Abra Configurações → Códigos de desfecho e clique em Gerar a lista padrão, ou escreva a sua própria lista.
2. Ligue "Exigir um desfecho ao resolver" se quiser a regra valendo.
3. No console, escolha o desfecho na caixa Encerramento, à direita, antes de resolver o chamado.

Três comportamentos que vale conhecer, porque são de propósito:

• **Ligar a exigência antes de ter algum código não bloqueia nada.** Do contrário, ela congelaria todos os chamados da empresa no dia em que alguém marcasse a caixa, sem nada disponível para escolher.
• **Quem cobra a exigência é o servidor, não a tela.** Fechar pela lista, por uma macro, pela API ou pelo terminal passa pela mesma checagem.
• **Um código que já foi usado não pode ser excluído, só desativado.** Excluí-lo tiraria o significado de todo chamado encerrado com ele, e os seus relatórios antigos começariam a mentir em silêncio.

Frase pronta: textos prontos atrás de um atalho digitado

Até agora o único texto pronto do console era a macro, e a macro também aplica status e prioridade: inserir uma frase mudava o chamado sem ninguém pedir. A frase pronta não escreve nada além do texto. É por isso que ela pode ser leve, pessoal e alcançável por um atalho que você digita.

1. No compositor, digite :: seguido do começo de um atalho, por exemplo ::hi.
2. Continue digitando para estreitar a lista, ou digite só :: para ver a biblioteca inteira.
3. Escolha uma frase na lista, ou termine o atalho e confirme para inserir a que casa exatamente.
4. Leia o texto antes de enviar: as variáveis entre chaves duplas, como {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} e {{org_name}}, são preenchidas no envio da resposta, igual às macros.

São três bibliotecas: **pessoal** (só você vê), **da equipe** (quem está naquela equipe) e **da empresa** (todo mundo que atende). O mesmo atalho pode existir em mais de uma, e vence a mais próxima de você: a sua frase pessoal vence a da equipe, e a da equipe vence a da empresa. Assim você mantém a sua versão do ::hi sem pedir a ninguém que mude o padrão da casa.

• **O atalho não tem espaço nem dois-pontos**, e vai até 40 caracteres. Um atalho com espaço jamais seria digitável depois do ::, então ele é recusado ao salvar em vez de virar uma frase que nunca aparece.
• **O atalho é único dentro da própria biblioteca.** O mesmo ::hi pode existir como frase pessoal e como frase da empresa; duas da empresa não.
• **A busca ignora maiúsculas e acentos** e olha o atalho, depois o título, depois a pasta. O corpo nunca é buscado: uma palavra comum casaria com meia biblioteca e o atalho perderia a serventia.
• **A ordem é sempre a mesma**: atalho que começa com o que você digitou, depois atalho que contém, depois título, depois pasta. Uma lista que mudasse de ordem entre duas aberturas faria você escolher a frase errada por memória muscular.
• **A pasta é texto livre** e serve só para agrupar a biblioteca na tela. Não há um cadastro de categorias separado para manter.

As suas frases pessoais são suas para criar, editar e excluir, sem pedir nada a ninguém. As frases da equipe e da empresa são padrão da casa, porque mudam o que todo mundo vai mandar ao cliente amanhã, então pertencem a quem administra as configurações. Ninguém edita a frase pessoal de outra pessoa, nem quem administra.

E-mails do chamado: texto seu por evento, idioma, categoria e fila

Cinco momentos do chamado podem levar um texto seu: **aberto**, **atualizado**, **resolvido**, **pesquisa** e **encerramento**. Cada modelo é escrito num idioma e pode, opcionalmente, ficar restrito a uma categoria, a uma fila, ou às duas.

A escolha segue uma ordem declarada, e ela se lê melhor em duas metades: o sistema decide primeiro **o que dizer** e só depois **em que idioma dizer**. As famílias são visitadas da mais específica para a mais genérica: fila e categoria, depois fila, depois categoria, depois a genérica. A fila pesa mais que a categoria porque a fila é o time que responde e o texto é a voz dele; a categoria é só o assunto.

• **Filtro vazio é curinga, filtro preenchido tem de casar.** Um modelo sem categoria serve a qualquer categoria. Um modelo com categoria serve só àquela, e nunca faz as vezes do texto genérico.
• **Idioma, dentro da família escolhida**: primeiro o exato (pt-BR), depois a mesma língua base (pt-PT serve a pt-BR), depois o idioma de reserva, que é o inglês enquanto você não disser outro.
• **A família que não tem nenhum desses três idiomas é pulada**, e a próxima, menos específica, é tentada. Mandar o texto genérico no idioma de quem lê é melhor do que mandar o texto certo num idioma que a pessoa não lê.
• **A especificidade vem antes do idioma.** Se a família de Faturamento só existe em inglês e a genérica existe em português, quem escreve em português recebe o texto de Faturamento em inglês. O conserto é acrescentar a linha em português da mesma família, que é exatamente o que a tabela pede de você.

O idioma considerado é o de **quem abriu o chamado**, a pessoa que lê o e-mail, e não o do agente. Assunto e corpo aceitam as mesmas variáveis das macros e das frases prontas, e a prévia mostra qual modelo venceu e em que idioma antes de qualquer coisa sair.

Swarm: chamar gente para um caso difícil e registrar o que saiu dali

A sessão de swarm registra o ritual que até agora vivia espalhado em notas internas: quem foi chamado, em que papel, para responder a que pergunta, até quando, e o que se concluiu. **Ela registra a sessão; não abre canal de Slack e não inicia videoconferência.** A conversa continua acontecendo onde já acontece (nota interna, menção, seguidores, chat interno); o que passa a existir é a memória dela.

1. No chamado, abra um swarm e escreva o motivo. O prazo é opcional, e não pode estar no passado.
2. Quem abre a sessão é o **relator**, e passa a seguir o chamado.
3. Chame as pessoas necessárias como **especialista** (sem limite) ou como **escriba** (assento único). Quem é chamado recebe um aviso com o motivo e passa a seguir o chamado.
4. Feche a sessão com o **desfecho**. Ele volta ao chamado como nota interna, para o próximo agente a pegar o caso ler sem abrir mais nada.

• **Uma sessão aberta por chamado.** Duas partiriam a atenção em duas, e o desfecho não teria uma casa só.
• **Relator e escriba são assentos únicos enquanto ocupados**; especialista não tem teto, porque chamar gente é justamente o propósito do swarm.
• **O relator não sai da sessão.** O caminho de saída é fechá-la dizendo o que se concluiu, nem que seja 'não se concluiu nada'.
• **Fechar exige o desfecho**, e encerra a participação de todos, para os minutos de gente pararem de crescer sozinhos.
• **Quem saiu continua aparecendo no registro.** Quem participou tem de continuar verdade amanhã.

Retorno agendado e lembrete pessoal

Duas ações parecidas que não são a mesma coisa. O **retorno** é uma tarefa sobre o chamado: pode ficar com outra pessoa e aparece na lista do dia como qualquer tarefa. O **lembrete** é sempre seu, e toca na hora que você pediu, não no resumo do fim do dia.

1. No chamado, escolha Agendar retorno ou Me lembrar.
2. Escreva quando, com as suas palavras: amanhã 9h, em 2 horas, sexta, próxima semana, ou uma data como 2026-09-10 14:30. Os dez idiomas do produto são entendidos.
3. No retorno, escolha o tipo (tarefa, ligação, e-mail ou reunião) e, se quiser, a pessoa que fica com ele. O lembrete é sempre tarefa, e sempre seu.

• **Dia sem hora vira 09:00** no fuso da organização, o mesmo padrão que o resto do produto usa.
• **Duração mantém a hora atual**, porque a duração já carrega a hora dentro dela. Minuto e hora contam em tempo real; dia e semana andam no calendário, então o horário de verão não os desloca.
• **Horário que já passou vai para o dia seguinte**, como faz qualquer aplicativo de lembrete. Já um dia no passado é recusado em vez de adivinhado: adivinhar que dia você quis dizer seria inventar.
• **Além de 365 dias é recusado.** É o filtro do dedo errado, o 2027 digitado em 2026 que ninguém veria.

A tela ecoa o horário que foi realmente **gravado**, e não as palavras que você digitou, sempre que as 09:00 foram assumidas por você ou o horário foi empurrado para o dia seguinte. Duas respostas diferentes para 'quando isto vence' é exatamente a confusão que esse eco existe para evitar.

Abas de trabalho: vários casos abertos ao mesmo tempo

O console abria um caso por vez, e escolher outro substituía o anterior. Quem atende em volume mantém três ou quatro casos em andamento (um esperando o cliente, um esperando a engenharia, um sendo escrito), e cada troca perdia o rascunho e o lugar da rolagem. A barra de abas de trabalho fica acima da conversa, e aparece assim que existe uma segunda coisa aberta.

• **Um clique simples abre uma aba de prévia**, mostrada em itálico, e a próxima prévia toma o lugar dela. Escrever nela, ou fixá-la, torna a aba definitiva. Sem isso, passear por uma fila de vinte casos abriria vinte abas.
• **O mesmo caso nunca abre duas vezes.** Clicar de novo só ativa a aba, com o rascunho e a sub-aba que você deixou ali.
• **O ponto azul avisa que há resposta escrita e não enviada** naquela aba. É o que você precisa ver antes de fechá-la, não depois.
• **Cada aba lembra a sua sub-aba** (Conversa, Histórico ou Contexto), então você volta onde estava e não no começo.
• **Até oito abas.** Acima disso sai a aba mais antiga sem rascunho; se todas tiverem rascunho, o teto cede, porque perder trabalho escrito é pior do que uma barra comprida.
• **Fechar a aba ativa ativa a vizinha da direita**, e a da esquerda quando não há direita, como faz um navegador.

**Fechar as salvas** fecha todas as abas sem rascunho e preserva as que têm rascunho: a faxina nunca leva trabalho escrito junto. As abas vivem no seu próprio navegador, neste aparelho, então elas são suas e não da equipe.

Contexto do cliente: saúde, valor, plano e histórico de atendimento

A aba Contexto do chamado abre com um bloco que responde, antes de você escrever uma linha, se este cliente está bem, quanto ele vale, em que plano está e quantas vezes já foi mal atendido. Nada disso é digitado por alguém: tudo é composto do que o produto já guarda sobre aquela conta.

• **Saúde** mostra a nota e, mais importante, **os fatores que a formam**. O número sozinho não diz nada em que agir; os fatores dizem se o problema é uso, atendimento, dinheiro ou relacionamento.
• **Valor** traz a receita ganha, a receita recorrente e o último movimento, para que uma expansão no mês passado e uma redução no mês passado não pareçam a mesma coisa.
• **Plano** diz qual plano, desde quando e quando renova, e acende o aviso quando a renovação já está marcada como em risco.
• **Histórico de atendimento** conta os chamados anteriores, quantos estouraram o SLA, a satisfação deste cliente e se há caso crítico aberto agora.

Abaixo do bloco, toda a conversa com esse contato aparece numa linha só, seja qual for o canal: chat, SMS, WhatsApp, e-mail e chamados juntos, em ordem. É o mesmo histórico que a ficha do contato mostra, trazido para dentro do console para ninguém trocar de tela só para lembrar o que já foi dito.

Supervisão: a mesma operação, vista por quem coordena

O console responde "o que eu faço agora?" para quem atende. A supervisão responde outra pergunta, para outra pessoa: a operação está dando conta neste momento. É uma tela separada, feita para ficar aberta numa TV, e ela se atualiza sozinha.

• **A operação está dando conta?** Itens abertos por fila, quantos estão sem dono, quantos esperam por nós e quantos vão estourar o prazo na próxima hora. Saber o que vai estourar não é a mesma coisa que saber o que já estourou, e o painel mantém os dois separados.
• **Quem está sobrecarregado e quem está livre?** Itens abertos por pessoa contra o teto dela, quem saiu do rodízio e quem lidera a fila.
• **Onde está o gargalo?** A fila com mais espera, o canal que mais traz entrada, e a fila de onde ninguém consegue pegar item, porque ela exige uma habilidade que ninguém do time tem.
• **O que aconteceu na última hora?** A trilha de atribuição já é append-only, então o painel apenas a mostra.

A supervisão é de quem administra, e isso é deliberado: ela mostra a carga de cada pessoa e quem está fora do rodízio. Monitorar gente é ato de gestão declarado, não efeito colateral de abrir uma tela. O painel é de leitura, então nada nele reatribui nem repriorizar: ele aponta, e o trabalho se faz onde ele já mora.

Catálogo de serviços: uma vitrine no lugar do chamado em branco

Quem precisa de algo interno hoje abre um chamado vazio e escreve o que lembra. O catálogo troca isso por uma vitrine: uma lista do que dá para pedir, cada item com o seu formulário, a sua fila e a sua prioridade. O pedido abre um chamado de verdade, já preenchido.

1. Em Configurações, Catálogo de serviços, quem administra monta o catálogo: categorias, itens e as perguntas de cada item.
2. Qualquer pessoa abre a mesma tela, escolhe um serviço e preenche o formulário dele.
3. O sistema abre um chamado na fila do item, com a prioridade dele e as respostas dentro, no mesmo formato que o portal já usa.
4. Se o item exige aprovação, o chamado abre na hora e a aprovação pendente trava a resolução dele: ninguém fecha antes de alguém decidir.

• **Desativar um item não cancela o que já foi pedido.** Desativar quer dizer "não peça mais isto", nunca "cancele o que está em andamento": os chamados abertos seguem abertos, com a mesma fila e o mesmo prazo.
• **Item que já foi pedido não pode ser excluído, só desativado.** Excluir faria o histórico mentir sobre o que foi pedido.
• **O pedido congela um retrato do formulário.** Se as perguntas mudarem depois, o pedido antigo continua mostrando as perguntas que aquela pessoa realmente respondeu.
• **O estado do pedido não é uma cópia.** Ele é lido da própria aprovação a cada consulta, então nunca diverge do que o motor de aprovação decidiu em outro lugar.

Catálogo de serviços · cumprimento do pedido

Um item do catálogo pode ter um plano de cumprimento: o que precisa acontecer depois que alguém pede o serviço, e em que ordem. Cada passo vira uma **tarefa de verdade**, com responsável, prazo, lembrete e um lugar na lista de tarefas que a pessoa abre todo dia, e a dependência entre os passos é a mesma que as tarefas já têm. O plano é congelado no pedido quando o cumprimento **começa**, não na hora de pedir: editar o item depois nunca reescreve um pedido em andamento, e a versão nova vale do próximo início em diante.

Quem coordena o trabalho tem a fila de cumprimento: o que está pendente, com quem e há quanto tempo. Pedido aprovado que ninguém iniciou aparece no **topo**, com a idade à vista, porque aprovar não inicia nada, alguém ainda precisa colocar o plano para rodar. Item sem aprovação a esperar começa assim que é pedido.

1. Desenhe o plano no item do catálogo: assunto, tipo de tarefa, prazo em dias contados do início, quem recebe e, quando fizer diferença, o passo anterior de que ele depende.
2. Quando alguém pede o serviço, o chamado abre como sempre abriu. Se o item exige aprovação, o cumprimento espera a decisão; sem aprovação a esperar, ele começa na hora.
3. Ao iniciar o cumprimento, o plano é congelado no pedido e as tarefas nascem na ordem das dependências, cada uma com dono e prazo.
4. O painel do pedido no chamado mostra cada passo, com quem ele está, o prazo e o que já foi concluído. Os passos também aparecem na linha do tempo do chamado, porque são tarefas comuns presas ao caso.
5. Marque Entregue quando o serviço chegou de fato à pessoa. Passo obrigatório ainda aberto bloqueia, com o motivo à vista; passo marcado como não obrigatório nunca bloqueia.
6. Marcou por engano? Estorne a entrega com uma nota. Isso é um lançamento novo: a entrega anterior continua no histórico, nada é apagado.

Ativos do cliente · o chamado é sobre este equipamento

O chamado passa a apontar para o **equipamento** do cliente, a unidade instalada com número de série, e não só para o modelo de produto que foi vendido. No chamado você escolhe o equipamento na base instalada do cliente, buscando pela série, que é como o cliente se identifica ao telefone. Só entra equipamento do cliente daquele chamado, e daí em diante o histórico do próprio equipamento passa a contar o atendimento: casos ligados, desligados e resolvidos ficam na mesma linha do tempo da instalação, das mudanças de lugar e das manutenções.

A parada é registrada por **gente**, ou a partir do chamado. Não há telemetria nem sinal de máquina aqui, então disponibilidade, MTTR e MTBF valem exatamente o que valer a disciplina de quem registra. A tela diz isso em voz alta em vez de enfeitar o número.

• Garantia e cobertura: o selo de garantia (ativa, vencendo, vencida) e o contrato de serviço aparecem antes de você abrir a boca com o cliente.
• Localização: mover o equipamento registra para onde ele foi, então o histórico de local é a leitura desses movimentos, não um campo único que esquece o passado.
• Troca com linhagem: substituir aposenta o antigo e cria o novo herdando conta, contrato e local, com um evento de cada lado apontando para o outro.
• Ciclo de vida: ativo, em manutenção, em RMA, aposentado e baixado. Baixado não volta, porque a baixa é fato contábil; o caminho de volta é registrar um ativo novo com a linhagem do antigo.
• Parada: abrir e fechar a parada, planejada ou não. O mesmo ativo nunca fica parado duas vezes ao mesmo tempo, e paradas sobrepostas são fundidas antes de somar, então a disponibilidade nunca fica negativa.
• Disponibilidade: o percentual na janela, com a parcela planejada separada da não planejada, porque janela de manutenção combinada com o cliente não é promessa quebrada. MTTR e MTBF ficam vazios sem amostra suficiente.
• Risco e próxima ação: criticidade, idade, falhas repetidas, cobertura e disponibilidade medida somam um score explicável, e o motor declara o que teve de assumir por falta de dado.

Base de conhecimento · dono, revisão e uso

A base ganhou a camada que responde quem responde por cada artigo e se ele ainda merece confiança: um dono, um revisor, um ciclo de revisão em dias e, a partir deles, o artigo **vencido de revisão**. O quadro de governança é ao vivo, calculado quando você o abre, então nunca depende de a varredura noturna ter rodado. Só o artigo publicado é cobrado: o rascunho ainda está sendo escrito e o arquivado saiu de circulação.

A visibilidade deixou de ser só publicado ou não. Cada artigo tem uma audiência: **externo** é o que o help center e o portal mostram a quem tem o link, e **interno** nunca sai do CRM. Todo artigo nasce externo, exatamente como se comportava antes, então nada muda até você decidir o contrário.

• Dono e revisor são pessoas da sua equipe, definidas por artigo. Sem dono, o artigo é sinalizado no quadro, que é onde a falta de dono se resolve.
• Ciclo de revisão em dias: a próxima revisão é a última revisão mais o ciclo. Artigo sem ciclo nunca vence, e ninguém é cobrado por ele.
• O aviso de revisão vencida vai para o **dono** do artigo, uma vez por vencimento. Artigo sem dono não avisa ninguém, porque despejar a metade sem dono no sino de quem administra todo dia ensina as pessoas a ignorar o sino.
• Arquivar tira o artigo de circulação com autor, data e trilha, em vez de alguém editar um campo de status em silêncio. Desarquivar devolve ao rascunho, nunca direto ao ar.
• Rascunho por IA a partir de chamados resolvidos: escolha até cinco casos encerrados, aponte uma lacuna se quiser, e o assistente escreve um artigo reaproveitável. Ele **nasce sempre como rascunho** e entra na mesma fila de revisão de qualquer artigo escrito à mão: a IA propõe, a pessoa aprova. Só chamado resolvido entra, porque um caso em aberto ainda não tem resposta.
• Leitura por artigo: quantas visitas abriram cada artigo, por qual porta, e quais artigos publicados ninguém leu no período, que é a fatia da base que não trabalha.

Autosserviço · o assistente e a taxa de deflexão

A base de conhecimento pública ganhou um assistente. Ele responde ancorado **só** nos seus artigos publicados e mostra as fontes que usou, para quem lê uma resposta gerada poder conferir de onde ela saiu. Quando não acha nada, diz que não achou e leva ao formulário de abertura, e a pergunta sem resposta é registrada como lacuna de cobertura. Ele nunca preenche o silêncio com um passo inventado, e quando não há IA configurada mostra os artigos encontrados em vez de fingir que está fora do ar.

É isso que torna a deflexão mensurável, e a definição é estrita de propósito: **chamado evitado é uma declaração explícita** de quem estava a caminho de abrir um caso e desistiu, depois de receber uma resposta ou um artigo sugerido e clicar que aquilo resolveu. Nada além disso conta.

• Ler um artigo não conta. Quem lê pode estar comparando, pesquisando, ou lendo o artigo errado a caminho de abrir o chamado do mesmo jeito.
• Buscar sem desfecho não conta. Fechar a aba não é sucesso.
• O chamado vence a declaração: se a pessoa disse que resolveu e abriu um caso na mesma visita, a visita conta como chamado. Preferimos medir de menos.
• A visita que não decidiu nada fica inteiramente fora da taxa, nem em cima nem embaixo, e é reportada à parte como indecisa.
• A taxa é a fatia das visitas que **decidiram alguma coisa** e decidiram não abrir chamado. Sem nenhuma decisão no período a taxa fica vazia e nunca 0%, porque não saber e zero por cento são respostas diferentes.
• O funil (buscas, perguntas, perguntas respondidas) mede alcance, não resultado, e nada dele entra na taxa.

Analytics de atendimento · relatórios prontos, achados e projeção

A aba Analytics do console de chamados responde o que nenhuma tela respondia: há quanto tempo a fila está parada, quanto de cada marco prometido foi cumprido, quanto escalou, o que a voz, o bot e a mensageria andaram fazendo, quanto os incidentes custaram em chamados, para onde o volume vai e, no fim, o que fazer a respeito. Todo número chega já calculado do servidor, então não há duas telas discordando em silêncio sobre a mesma conta.

Duas leituras que parecem a mesma e não são: **a idade corre no relógio** (o tempo de calendário desde a criação do chamado) e **o prazo corre no expediente** (a promessa de SLA, com as pausas descontadas). Elas têm nomes diferentes de propósito. Misturá-las daria dois números com o mesmo rótulo e nenhum jeito de saber qual deles foi quebrado.

• Relatórios prontos: um clique transforma o modelo num relatório seu, com nome no seu idioma. Dali em diante ele é um relatório comum, editável, compartilhável, exportável e agendável como qualquer outro, sem nenhum motor separado por trás.
• Achados: SLA abaixo do combinado, entra mais do que sai, fila envelhecendo, reabertura, escalonamento, lacuna de conhecimento. Cada um vem com os números que o sustentam, uma causa provável e uma ação, ordenados por peso.
• Cumprimento por marco: primeira resposta, próxima resposta e resolução, e não só a resolução. Próxima resposta é toda vez que o cliente volta a falar depois de já ter sido respondido uma vez, e só entra na conta o caso que de fato tinha alvo.
• Envelhecimento da fila por faixas (menos de um dia, de um a três, de três a sete, mais de uma semana), no geral, por fila e por atendente, com o chamado mais velho à vista.
• O bot tem três desfechos, não dois: contido sem humano, transferido a um humano, e **pediu humano e ninguém veio**, que é fila abandonada e antes se escondia dentro do número de contenção.
• Voz, mensageria e incidentes têm cada um a sua leitura, porque uma conversa de WhatsApp não é um chamado e um incidente se mede pelo que custou em casos e pela causa raiz que volta sempre.
• Projeção de volume: tendência mais um índice por dia da semana, para que sábado não seja projetado como se fosse terça.

IA que age no chamado, com política

A IA já lia todos os chamados (categoria, urgência, sentimento, resumo) e ninguém consumia isso. Agora ela pode **escrever** categoria e prioridade no chamado, mas só sob uma política que o espaço de trabalho define, e ela vem **desligada por padrão**: nada muda até quem administra ligá-la em **Configurações → IA de atendimento**. Campo a campo você escolhe entre **Não fazer nada**, **Sugerir (uma pessoa confirma)** e **Escrever quando estiver confiante**. Escrever só acontece acima de um limiar de confiança que você define (de 50% a 100%, 80% por padrão); abaixo dele, a mesma proposta vira sugestão que se aplica com um clique.

No console, a caixa **Sugestões da IA** lista o que está esperando: o valor proposto com a confiança e o motivo de não ter sido escrito (a política manda só sugerir, abaixo do limiar, uma pessoa já tinha escolhido um valor, teto diário atingido), com **Aplicar** e **Dispensar**. O que a política escreveu sozinha fica visível no histórico da caixa como escrito pela política, para o atendente saber que a categoria não foi ele quem pôs. **Classificar com IA agora** roda a mesma política pela sua mão. A caixa some para o espaço de trabalho que não ligou a política e não tem sugestão nenhuma.

• A IA classifica contra as **suas** listas de categoria e prioridade. Valor que não é uma das suas opções nunca é gravado, e sem opções cadastradas num campo ela fica quieta em vez de inventar uma.
• Valor escolhido por uma pessoa não é sobrescrito. Por padrão o modo automático só preenche o que está vazio ou ainda no default do formulário; substituir uma escolha humana exige a opção explícita **Permitir que a IA substitua um valor escolhido por uma pessoa**.
• Rascunho de resposta **nunca é enviado**. Aceitar um rascunho o coloca no compositor com **Usar no compositor**; revisar, editar e enviar continuam sendo seus. Resolver e fechar um chamado também nunca são automáticos: não existe modo para isso, em lugar nenhum.
• Cada escrita automática conta no teto diário de ações compartilhado com o agente (**Configurações → IA**, autonomia do agente). No teto, a IA volta a só sugerir e diz isso na caixa e na tela da política, com os números de hoje: escritos, sugeridos, segurados pelo teto, esperando uma pessoa.
• Tudo deixa trilha: cada escrita automática no livro de ações do agente, cada chamada de IA no registro de auditoria de IA quando ele está ligado, e a própria mudança de política na trilha de auditoria.
• **Rodar quando um chamado é criado** aplica a política sem automação configurada. Com isso ligado, criar um chamado pela tela espera a IA por alguns segundos antes de o chamado aparecer; se a IA estiver indisponível (sem chave, teto de gasto, provedor fora) o chamado é criado assim mesmo, sem nada escrito.
• As automações do chamado e as regras por tempo ganharam duas ações: **Classificar com IA (pela política de IA de atendimento)** e **Rascunhar resposta com IA (nunca enviada)**. Uma regra que primeiro fixa a categoria e depois pede a IA não vê a IA desfazê-la.
• A mesma análise do mesmo texto nunca gera duas sugestões e nunca conta duas vezes no teto; repetir uma rodada não custa nada.

Trabalho de campo a partir do chamado

O chamado que precisa de visita não é mais redigitado em outra tela. Com a vertical de Serviços de Campo ligada, a caixa **Trabalho de campo** do console abre a ordem de campo direto do chamado, marca a visita e mostra ao atendente o que o cliente pergunta ao telefone: próxima visita, se está atrasada, última visita, técnico, equipamento. Tudo é lido ao vivo da ordem, das visitas e da trilha de status, então uma mudança feita no quadro de despacho é o que o chamado mostra na próxima abertura. A ordem leva o assunto e a descrição do chamado como problema, e a prioridade do chamado mapeada para a da ordem (crítica vira urgente, alta fica alta, média normal, baixa baixa).

**Abrir ordem de campo** pede a **propriedade**, que é obrigatória porque o chamado não sabe o endereço da visita: as propriedades do cliente vêm primeiro e marcadas, cliente com uma só propriedade já a tem pré-selecionada, e chamado sem contato nem empresa busca na base inteira por nome, endereço ou CEP (as 50 primeiras, com aviso para refinar). Quando o chamado aponta para um ativo cujo número de série casa com exatamente um equipamento daquela propriedade, o equipamento é **sugerido** com uma caixa de marcação, nunca escolhido por você. Tipo de ordem (reparo por padrão), técnico e janela de chegada são opcionais; com janela, a primeira visita é marcada na hora e aparece no quadro de despacho; sem janela, a ordem fica em rascunho, ainda sem visita.

• **Marcar visita** acrescenta uma visita à mesma ordem pelo console: retorno é a visita 2, 3 e assim por diante, nunca uma segunda ordem. Um chamado tem no máximo uma ordem, e um segundo clique em abrir responde que ela já existe.
• A janela de chegada e o técnico da própria ordem só são preenchidos quando estavam vazios: uma segunda visita não reescreve o combinado da primeira.
• **Visita atrasada** aparece quando a janela já começou e a visita ainda está só marcada, ou seja, ninguém saiu. O seletor de mudança de status oferece só as transições que a máquina de estados da vertical aceita a partir do status atual.
• Quando o trabalho de campo é **concluído**, **não pôde ser concluído** ou foi **cancelado**, quem cuida do chamado é avisado no idioma dele com um link para o console, venha a mudança do console, da tela da vertical ou do app. Despachado, a caminho e esperando peça ficam visíveis na caixa sem tocar o sino de ninguém.
• **O status do chamado nunca muda sozinho** quando o campo termina. Confirmar com o cliente e resolver o chamado é decisão de quem atende.
• **Desvincular** desfaz o laço entre chamado e ordem e nada mais: a ordem segue viva na vertical, com a trilha dela. Cancelá-la é uma transição da vertical, feita lá.
• A tarefa-lembrete na data da visita é opcional e reusa o módulo de atividades; aparece na linha do tempo do chamado e na lista de tarefas do técnico, ou na do dono do chamado quando não há técnico.
• Com a vertical desligada, a caixa diz isso e aponta para **Configurações · Verticais**, em vez de mostrar um botão que falharia. Ela oferece o caminho leve que todo espaço de trabalho tem, **Abrir uma ordem de serviço**, e mostra essa ordem e os agendamentos dela quando existe uma.

Onde configurar: **Configurações → Frases prontas** para as frases, **Configurações → Modelos de e-mail do chamado** para os textos transacionais, e **Configurações → Habilidades** para quem sabe o quê e o que cada fila exige. O swarm, o retorno e as abas de trabalho não precisam de configuração: já estão no console.

Abrir este artigo dentro do sistema →