Como este tema funciona na sua empresa
Gestão de chamados é frequentemente ad-hoc: email, WhatsApp, ticket manual em planilha Excel ou Google Sheets. Primeira prioridade é estruturar o mínimo viável: sistema simples (Jira free, Helpdesk grátis, até formulário Google que converge em planilha). Definir prioridades claras (P1=crítico=resolve agora, P2=importante=hoje, P3=normal=esta semana), tempo de resposta esperado (P1=1h, P2=4h). Custo: R$ 0-2k/mês. Ganho: visibilidade — não perder chamados em email, saber quantos estão abertos.
Sistema de ticketing implementado (Jira, Zendesk, Freshdesk, Helspdesk), mas fluxos variam por equipe — ninguém seguindo SLA consistente, escalação é caótica, relatórios são manuais. Desafio: padronizar processo, validar que 90% dos chamados resolvem dentro de SLA, automação básica (roteamento, escala automática se fora de SLA). Custo: R$ 2-10k/mês. Esperado: MTTR cai 20-30% após estruturação.
ITSM corporativo (ServiceNow, Jira Service Management, BMC Remedy). Fluxos complexos com automação sofisticada: roteamento inteligente por skills, escalação condicional, integração com base de conhecimento e RPA. Objetivo: MTTR <4 horas para P1 (crítico), 95% dos P1/P2 dentro de SLA. Custo: R$ 20-100k+/mês. Operação exige ITIL SME em casa.
Gestão de chamados é processo estruturado de receber, classificar, priorizar, atribuir, resolver e fechar solicitações de suporte técnico em um fluxo controlado, com SLAs definidos por prioridade, rastreamento de progresso, escalação automática se fora de prazo, e feedback de usuário, permitindo medir tempo de resolução (MTTR), satisfação e identificar padrões para melhorias[1].
Elementos essenciais de um fluxo de chamados eficiente
1. Recebimento centralizado em múltiplos canais: Usuário pode abrir ticket via: portal web, email (converge em ticket único), chat integrado, telefone (técnico abre ticket). Tudo converge em único sistema de ticketing. Usuário gera número único (ex: #12847) e pode rastrear: "meu chamado está em progresso, técnico respondeu às 14:30". Sem isso, usuário fica esperando resposta em email ou WhatsApp enquanto suporte busca em chat.
2. Classificação automática e clara: Cada chamado precisa de: (a) Categoria (acesso, hardware, software, rede, impressora, email), (b) Prioridade (P1/P2/P3/P4), (c) Impacto (afeta 1 pessoa vs. 100 pessoas). Classificação automática por keywords reduz overhead: "email não funciona" ? categoria "email", prioridade "P2", impacto "1 pessoa". Usuário não precisa escolher, sistema decide. Se errar, técnico corrige em 10 segundos.
3. Atribuição e roteamento intelligente: Ticket é automaticamente roteado para técnico apropriado. Exemplos: "categoria acesso" ? routing para "Time de Identidade"; "categoria impressora" ? routing para "especialista impressora". Se especialista está ocupado, entra na fila dele (honra FIFO). Sem roteamento intelligente, chamados se acumulam ou vão para pessoa errada (demora).
4. Escalação automática se fora de SLA: Se ticket está marcado P1 (SLA = resolve em 1h) e está aberto há 1h05m, sistema automaticamente escala para gerente. Gerente vê: "este chamado está fora de SLA, ação urgente". Sem escalação automática, chamado importante fica travado e ninguém sabe.
5. Comunicação transparente com usuário: Usuário vê status em tempo real: "aberto ? atribuído a João ? em progresso ? aguardando informação (de você) ? resolvido ? validação do usuário". Notificações automáticas: "seu chamado foi resolvido, valide se OK". Sem isso, usuário fica no escuro, liga novamente perguntando status.
6. Resolução, validação e fechamento: Técnico documenta solução em campo de "resolução" (não é comment vago, é descrição exata). Marca como "resolvido". Sistema envia para usuário: "seu problema foi resolvido? (Sim/Não)". Se Não, chamado reabre automaticamente (não fica "falsamente fechado"). Se Sim, após 5 dias sem reabertura, fecha definitivamente. Validação é crítica — evita falsos positivos que voltam a assombrar.
Definindo SLAs por prioridade: um exemplo realista
SLA (Service Level Agreement) = tempo máximo esperado para primeira resposta + tempo máximo para resolução. Exemplo de SLAs recomendados:
| Prioridade | Definição | Resposta | Resolução | Exemplos |
|---|---|---|---|---|
| P1 (Crítico) | Impacta negócio ou muitas pessoas | 15 min | 1 hora | Email corporativo inteiro fora, servidor down, acesso para 50+ pessoas negado |
| P2 (Alto) | Impacta 2-20 pessoas ou sistema importante | 1 hora | 4 horas | Departamento inteiro sem acesso VPN, impressora corporativa fora, sistema crítico lento |
| P3 (Médio) | Impacta 1 pessoa ou não é crítico | 4 horas | 1 dia útil | Usuário não consegue imprimir, email lento, reset de senha, ajuda com software |
| P4 (Baixo) | Solicitação, pergunta, sem impacto urgente | 1 dia | 3 dias | Requisição de software, questão de procedimento, pedido de melhor documentação |
Índices esperados: 95% dos P1 dentro de SLA, 95% P2 dentro de SLA, 90% P3 dentro de SLA. Fora de SLA = escala automática para gerente. Reporte mensal: quantos % foi atingido SLA? Onde está problema? (ex: se P3 resolvem em 2 dias, mas SLA é 1, precisa mais técnico ou KB).
Automação para reduzir esforço manual
Automação reduz trabalho repetitivo que não agrega valor:
- Resposta automática: "Recebemos seu chamado #12847, esperado resposta em 2h, você receberá atualização." Usuário sabe que foi recebido, não fica ansioso. Custa zero.
- Roteamento baseado em categoria/urgência: "email" ? equipe de email, "acesso" ? equipe de identidade. Automático, sem humano roteando manualmente. Economiza 5 min por ticket × 100 tickets/dia = 500 min/dia economizados.
- Sugestão de artigos de KB: Usuário abre chamado "não consigo reimprimir", sistema sugere 3 artigos de KB relevantes. Se encontra resposta lá, fecha e fecha o próprio chamado (self-service). Não precisa escalação. Reduz 20-30% de tickets em empresas com boa KB.
- Fechamento automático de chamados: Se chamado está "resolvido" há 5 dias sem reabertura, fecha automaticamente. Sem isso, lista de chamados "resolvidos" fica gigante, relatórios inúteis. Com isso, cada ticket "não-resolvido" que aparece é genuinamente problema.
- Escalação automática por tempo: Se P1 está aberto há 1h, escala. Se P2 está há 4h, escala. Se P3 está há 8h (passou do dia útil), escala. Sem isso, você descobre problema só na segunda-feira de manhã.
- Agregação para KB: Problema comum que abriu 50 chamados em 1 semana? Sistema detecta, avisa: "este problema é recorrente, considere criar artigo de KB". KB fica atualizada, próximos usuários se auto-resolvem.
Com 50%+ de automação, mesmo time reduzido consegue MTTR mais baixo que time grande sem automação.
Métrica crítica: MTTR (Mean Time To Resolution)
MTTR é tempo médio do chamado ser aberto até estar resolvido (validado por usuário). Exemplo: P1 deve ter MTTR <1h. P2 <4h. P3 <1 dia. MTTR é indicador de saúde da operação:
- MTTR subindo? Indicador: equipe com falta de conhecimento (KB fraca), falta de autorização (escalações desnecessárias), problema recorrente não está sendo atacado na raiz.
- MTTR cai mas satisfação também cai? Indicador: técnico está resolvendo rápido mas de forma ríspida, ou está fazendo "gambi" que quebra depois (falso positivo de resolução).
- Variação alta em MTTR? Indicador: alguns técnicos são rápidos, outros lentos (treinamento desigual), ou alguns tipos de problema são muito mais complexos que outros (priorização errada).
Acompanhar MTTR por tipo de problema ajuda identificar onde melhorar: se "password reset" tem MTTR de 10 min mas "email não funciona" tem 4h, focar recursos em email.
Integração com base de conhecimento
Base de conhecimento (KB) alimentada pela gestão de chamados reduz chamados futuros. Exemplo de virtude:
- Usuário abre chamado "não consigo imprimir"
- Técnico resolve: "problema era driver da impressora desatualizado"
- Técnico documenta em KB: "Como reinstalar driver de impressora — 5 passos"
- Próximo usuário com mesmo problema abre ticket, sistema sugere o artigo de KB
- Usuário se auto-resolve (chamado fechado, sem técnico envolvido)
- Sistema detecta padrão ("este artigo resolveu 30 tickets"), integra em onboarding de novo funcionário
KB bem alimentada reduz 20-30% do volume de chamados triviais. ROI: economiza horas, reduz MTTR global, melhora satisfação (usuário resolve sozinho, não espera técnico).
Sinais de que fluxo de chamados precisa estruturação urgente
Se você se reconhece em três ou mais situações abaixo, gestão de chamados está caótica e precisa estruturação.
- Chamados se perdem em email ou WhatsApp; ninguém sabe quantos estão abertos, há quanto tempo, quem é responsável
- Tempo de resposta varia muito: alguns resolvem em 30 min, outros em 5 dias, sem critério claro de prioridade
- Mesmo problema recorrente abre novo chamado toda vez (nenhuma aprendizado); KB não existe ou é obsoleta
- Quando técnico responsável sai de férias, ninguém consegue ajuda (processo é "pede para João" e só João sabe)
- Não há relatório de satisfação; não se sabe se usuários estão satisfeitos ou frustrados
- Escalação é caótica: técnico simplesmente manda email para especialista, sem prioridade, sem rastreamento
- Capacidade do time é questionável, mas não há métrica para base para justificar contratação (você "sente" que é pouco, mas não prova)
Caminhos para estruturar fluxo de gestão de chamados
Estruturação pode ser feita internamente se houver gestor capaz de desenhar processo, ou com consultoria para validação e metodologia pronta.
Implementar sistema escolhido, desenhar fluxo com time, treinar.
- Perfil: Gestor de suporte + técnico com experiência em ITSM ou service management
- Tempo: 1-2 meses para desenho de fluxo + setup sistema + treinamento inicial
- Faz sentido quando: Volume pequeno-médio, equipe cooperativa, desenho de fluxo é simples
- Risco: Fluxo mal desenhado no início é difícil corrigir depois (dependências em processo tudo). Requer "parada" para redesenho, disruptivo.
Consultor desenha fluxo com você (workshop com stakeholders), implementa sistema, treina time, acompanha ramp-up.
- Tipo: Consultor ITIL 4 certificado, especialista Service Management, ou big consulting com prática
- Vantagem: Experiência acumulada, metodologia pronta (ITIL best practices), validação externa, ramp-up mais rápido
- Faz sentido quando: Volume alto, compliance crítica, quer fazer certo de primeira, não tem expertise interna
- Resultado: Fluxo implementado em 2-3 meses, KPIs baseline estabelecido, time treinado, melhoria visível (MTTR -20-30%, FCR +10-15%)
Precisa estruturar fluxo de gestão de chamados?
Se organizar suporte técnico é prioridade operacional, o oHub conecta você a especialistas em ITIL e Service Management. Descreva volume de chamados em 3 minutos, receba propostas personalizadas de consultores e implementadores, sem custo ou compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Qual é o MTTR (tempo de resolução) esperado para suporte técnico?
Depende da criticidade. P1 (crítico): <1 hora. P2 (alto): <4 horas. P3 (médio): <1 dia. P4 (baixo): <3 dias. Expectativa de mercado: 95% dos P1/P2 dentro de SLA. Empresas boas conseguem isso; empresas que começam têm ~70%.
Como escolher melhor sistema de ticketing?
Pequena: Jira free ou Helpdesk grátis (suficiente para <50 usuários). Média: Zendesk (R$ 2-5k/mês), Freshdesk (R$ 2-10k/mês), Jira Service Management (R$ 3-8k/mês). Grande: ServiceNow (>R$ 20k/mês). Critério: volume de usuários, integração com sistemas atuais, suporte 24/7 necessário?, automação desejada?
Quanto custa implementar fluxo de chamados bem estruturado?
Ferramenta: R$ 0-100k/mês (depende solução). Implementação: R$ 5-50k consultoria (pequena/média: R$ 10-20k; grande: R$ 30-50k+). Treinamento: R$ 2-10k. ROI: payback em 6-12 meses por redução de MTTR (menos escalações = menos custo por chamado).
Como evitar fila infinita de chamados?
SLA claro por prioridade (P1=1h, P2=4h), escalação automática se fora de SLA, base de conhecimento para autoatendimento (reduz 20-30%), feedback de usuário para priorizar melhorias, análise mensal de causas raiz de atrasados (por quê P3 resolveu em 2 dias se SLA é 1? Falta técnico? Falta conhecimento?), automação de tickets triviais.
Qual é impacto de boa gestão de chamados na satisfação do usuário?
Grande. Usuário vê progresso (não está no escuro), sabe quando problema será resolvido (expectativa clara), recebe notificações (não fica perguntando status), consegue se auto-resolver via KB (rápido). Satisfação typically sobe 20-30 pontos (em escala 0-100) após implementação de fluxo estruturado.
Qual é diferença entre gestão de chamados e helpdesk?
Helpdesk = primeira linha de atendimento (pessoa que atende). Gestão de chamados = processo que coordena todo o ciclo (receber, priorizar, resolver, fechar). Gestão de chamados pode envolver múltiplas linhas (N1, N2, N3). Sistema de ticketing é ferramenta que habilita gestão de chamados.