Fluxo de atendimento
Esta página mostra o caminho de um chamado do começo ao fim: primeiro a linha do tempo das grandes etapas, depois o fluxograma com as decisões e desvios, e por fim os fluxos paralelos que podem ser disparados no meio do caminho.
Linha do tempo das etapas
As oito grandes etapas, em ordem. Cada uma detalhada logo abaixo do seu título.
- Abertura do chamadoO cliente registra a demanda pelo portal. O chamado entra na lista Produção com os campos preenchidos: Cliente, Escola, Motivo do chamado, Profissional solicitante, Unidade logada e Link.
- Triagem e classificaçãoO coordenador de SD analisa o chamado, identifica a natureza (dúvida, solicitação operacional, bug ou evolução) e define a prioridade e o responsável.
- DistribuiçãoO chamado é replicado ou movido para a lista Demandas SD com status "criar tarefa sd", atribuído ao analista adequado com base em especialidade, familiaridade com o assunto e carga horária disponível.
- LiberaçãoApós atribuição e revisão, o status muda para "liberado", indicando que o analista pode iniciar o atendimento.
- AtendimentoO analista trabalha na resolução (status "em atendimento"). Se precisa de informação do cliente, o chamado original vai para "aguardando cliente".
- Em esperaQuando o atendimento depende de terceiros (engenharia, reunião com cliente, deploy pendente), o card fica "em espera" até a dependência ser resolvida.
- ResoluçãoO analista resolve e o status muda para "atendido". Se necessário, um aviso de fechamento é enviado ao cliente.
- FechamentoApós confirmação do cliente ou prazo sem retorno, o chamado é fechado definitivamente.
Fluxograma completo
O fluxograma mostra as mesmas etapas, agora com as decisões e os desvios. As cores das bordas indicam o tipo de passo: azul para o caminho principal, cinza tracejado para pausas, vermelho para bug e verde para conclusão.
Fluxos paralelos que podem ser disparados
No meio do atendimento, alguns caminhos alternativos podem ser abertos. Eles não substituem o fluxo principal — correm ao lado dele.
Criação de card [BUG]
Quando a triagem ou o atendimento identifica um defeito no sistema, um card de bug é criado seguindo template padronizado (seções: Relato, Problema, Informações e Solução). O bug é vinculado ao chamado original com dependência "bloqueia" e entra no backlog de sustentação ou na sprint atual.
Teste de card
Quando uma correção ou evolução é entregue pela engenharia, um card de teste é criado na Demandas SD e distribuído à equipe de QA. Classificação = "Teste de card", com nível Baixo (30 min), Médio (1 h) ou Alto (2 h+) conforme a complexidade do checklist.
Escalação para engenharia
Demandas que exigem desenvolvimento são convertidas em cards [COA] (Customização ou Ajuste) e encaminhadas ao backlog de evoluções para priorização em sprint.
Reuniões com clientes
Alguns chamados resultam em reuniões de alinhamento (homologação, treinamento, configuração) que ficam registradas como cards "em espera" até sua realização.
Como a equipe resolve, na prática
O passo a passo que o analista segue dentro da etapa de atendimento:
- Leitura e compreensão — lê o relato do cliente, identifica a funcionalidade afetada e o cenário descrito.
- Reprodução / investigação — acessa a base do cliente (ou base de QA) para reproduzir o problema ou verificar a configuração.
- Diagnóstico — classifica como dúvida (orientação), erro operacional (ajuste de dados), bug (defeito no sistema) ou evolução (funcionalidade inexistente).
- Resolução direta — se for dúvida ou ajuste operacional, resolve e responde ao cliente com prints e orientações.
- Escalação — se for bug, cria o card [BUG] vinculado; se for evolução, registra como [COA] no backlog.
- Retorno ao cliente — comunica a solução, envia evidências (prints, vídeos) e, se necessário, orienta sobre como evitar a recorrência.
- Fechamento — após confirmação do cliente, o chamado é encerrado.