Use o e-mail cadastrado no banco de anotações. Só quem entra consegue editar prioridade e observação.
Importar planilha
Arraste o CSV exportado do GLPI para atualizar os chamados, ou a planilha de acompanhamento diário (Tickets Maersk) para atualizar o histórico. O formato é reconhecido automaticamente.
Solte o arquivo aqui ou clique para escolher .csv separado por ponto e vírgula
Os dados importados valem só nesta janela. Para deixar permanente, baixe o painel atualizado e use esse arquivo no lugar do atual.
Plantão
Meus chamados () · em aberto, da última atualização mais antiga para a mais recente
Precisa de ação · clique para abrir a lista já filtrada
Saúde dos dados · o que está inconsistente entre GLPI e Azure
Chamados em aberto () · dos mais antigos para os mais novos
Última subida em produção
A semana em números
Onde estão os chamados
Com o time de dev
Fluxos de Trabalho do Suporte MultiTMS (nstech)
Base para criação de artefato. Documento descreve apenas fluxos de trabalho (quem faz, em que ordem, com qual ferramenta e o que sai de cada etapa). Versão 1.0 · 18/10/2026 · Autor: Rafael
0. Convenções
Atores (raias)
Raia
Papel no fluxo
Cliente
Abre o chamado e valida o atendimento
Suporte
Triagem, análise, registro de problema, retorno ao cliente, documentação
DEV
Valida a categoria quando há dúvida técnica, analisa e corrige bugs
PO
Transforma melhorias em História de Usuário
Ferramentas (ícones do desenho)
Ícone
Ferramenta
Uso no fluxo
Laranja/vermelho (macro)
GLPI
Abertura do chamado e macros de status ("Em atendimento", "Em Análise Técnica", "Atendido"), campos Análise de Causa e Justificativa de Causa
Asterisco laranja
Claude (skills)
/analisar-chamado-multitms, /criar-bug, /criar-us, documentação, mensagem ao cliente
Azul
Azure DevOps
Cards "Problema em prod" e "História de Usuário", atribuição de dev
Tipos de nó
Tipo
Descrição
inicio / fim
Eventos de início e fim
tarefa
Atividade executada por um ator
subprocesso
Atividade que tem fluxo próprio detalhado neste documento (caixa com barras laterais no desenho)
decisao
Losango com saídas rotuladas
Status do chamado no GLPI (macros)
Aberto→Em atendimento→ (Em Análise Técnica, quando vira bug) →Atendido
1. Fluxo principal: Atendimento de chamado (F01)
Objetivo: levar um chamado da abertura ao encerramento, roteando por categoria (Dúvida, Bug, Melhoria).
Gatilho: cliente abre chamado no GLPI.
Saídas: chamado "Atendido" no GLPI, card no DevOps (quando bug ou melhoria), regra registrada na documentação.
1.1 Etapas
GLPIClaude (skills)Azure DevOpsDecisãoSubprocesso (fluxo próprio no guia)
Ver a tabela de etapas
ID
Raia
Etapa
Tipo
Ferramenta
Próximo
F01-00
Cliente
Início
● início
—
F01-01
F01-01
Cliente
Abrir chamado
tarefa
GLPI
F01-02
F01-02
Suporte
Macro "Em atendimento"
tarefa
GLPI
F01-03
F01-03
Suporte
Rodar /analisar-chamado-multitms
tarefa
Claude
F01-04
F01-04
Suporte
Analisar chamado
subprocesso (F02)
—
D1
D1
Suporte
Como você avalia a categoria do chamado?
◆ decisão
—
Bug/Melhoria → F01-05 Dúvida → D2
D2
Suporte
Existe a regra na documentação?
◆ decisão
Documentação MultiTMS
Sim → F01-20 Não → F01-05
F01-05
Suporte
Validar com Dev/PO
tarefa
—
D3
D3
DEV
Como você avalia a categoria do chamado?
◆ decisão
—
Melhoria → F01-06 Bug → F01-08 Dúvida → F01-19
F01-06
PO
Criar US da melhoria
subprocesso (F05)
Claude
F01-07
F01-07
PO
Criar card História de Usuário no DevOps
subprocesso
Azure DevOps
F01-20
F01-08
Suporte
Criar problema em prod
subprocesso (F04)
Claude
F01-09
F01-09
Suporte
Criar card Problema em prod no DevOps
subprocesso
Azure DevOps
F01-10
F01-10
Suporte
Macro "Em Análise Técnica"
tarefa
GLPI
F01-11
F01-11
DEV
Encaminhar um dev responsável
tarefa
Azure DevOps
F01-12
F01-12
DEV
Analisar o card
tarefa
Azure DevOps
F01-13
F01-13
DEV
Subir correção
tarefa
—
D4
D4
Suporte
A correção resolveu o problema?
◆ decisão
—
Sim → F01-15 Não → F01-14
F01-14
Suporte
Preencher evidências
tarefa
Azure DevOps
F01-12 (loop)
F01-15
Suporte
Preencher causa e justificativa
tarefa
GLPI (Fluxo Cabotagem)
F01-19
F01-19
Suporte
Inserir regra na documentação
subprocesso (F07)
Claude
F01-20
F01-20
Suporte
Retornar pro cliente
subprocesso (F03)
Claude
F01-21
F01-21
Cliente
Validar atendimento
tarefa
GLPI
D5
D5
Cliente
Card atendido?
◆ decisão
—
Sim → F01-22 Não → D4
F01-22
Suporte
Macro "Atendido"
tarefa
GLPI
F01-99
F01-99
—
Fim
● fim
—
—
1.2 Caminhos resumidos
Dúvida com regra documentada
Abrir→Em atendimento→Análise→Dúvida→regra existe→Retornar pro cliente→Validar→Atendido
Dúvida sem regra documentada
regra não existe→Validar com Dev/PO→DEV confirma Dúvida→Inserir regra na documentação→Retornar pro cliente→Validar→Atendido
Bug
Validar com Dev/PO→DEV confirma Bug→Criar problema em prod→Card no DevOps→Em Análise Técnica→Dev responsável→Analisar→Subir correção→Resolveu? (loop com evidências até resolver)→Causa e justificativa→Inserir regra na documentação→Retornar pro cliente→Validar→Atendido
Melhoria
Validar com Dev/PO→DEV confirma Melhoria→PO cria US→Card História de Usuário→Retornar pro cliente→Validar→Atendido
• Reprovação do cliente: "Card atendido? Não" devolve para a decisão "A correção resolveu o problema?", reabrindo o ciclo de evidências e correção.
1.3 Diagrama (Mermaid)
1.4 Pontos a confirmar no desenho
1. No caminho Melhoria, o desenho não passa por "Preencher causa e justificativa" nem por "Inserir regra na documentação". Confirmar se é intencional (a regra só entra na documentação quando a melhoria for entregue).
2. Em "Card atendido? Não", a seta volta para "A correção resolveu o problema?". Para chamados de Dúvida ou Melhoria isso não se aplica; confirmar o destino da reprovação nesses casos (provavelmente volta para "Analisar chamado").
3. Escalonamento Cloudworks: nem todo chamado "Com dev" vai para o Azure DevOps, alguns vão para a Cloudworks (ver F06). O desenho ainda não tem essa saída.
2. Subfluxo: Análise e diagnóstico do chamado (F02)
Expande: F01-04 "Analisar chamado".
Objetivo: chegar à causa-raiz e à categoria correta antes de qualquer encaminhamento.
Gatilho: chamado em "Em atendimento" e skill /analisar-chamado-multitms executada.
Saídas: categoria (Dúvida, Bug, Melhoria), Análise de Causa (lista fechada do plugin Fluxo Cabotagem), Justificativa de Causa em texto puro, casos semelhantes no histórico.
ID
Etapa
Detalhe
F02-01
Coletar o mínimo
Nº do chamado, cliente, instância, ambiente (prod, homolog, QA), documento envolvido (chave, protocolo, ID), XML da carga/documento, print ou mensagem de erro literal
D1
Tem o mínimo para investigar?
Não → F03 (modelo "Retorno parcial / pedido de informação" ou "Abertura pedindo XML") e aguarda cliente · Sim → F02-02
F02-02
Localizar o momento no ciclo da carga
Criação da carga → vínculo de NF-e → cálculo de frete → emissão de CT-e → MDF-e → integração pós-viagem
F02-03
Aplicar checklist por documento
CT-e, MDF-e, NF-e, NFS-e, EDI PROCEDA, CIOT (checklist-diagnostico-multitms)
F02-04
Consultar a documentação MultiTMS
PDFs locais (Navegação e Rodoviário) e documentação de Carga, Fatura, Tipo de Operação
F02-05
Cruzar com o histórico do GLPI
Export CSV diário: casos semelhantes, causas já usadas pelo time
F02-06
Formular hipótese → onde verificar → como confirmar
Em EDI, apontar registro e posição; não inventar conteúdo de campo
F02-07
Entender o incidente como ocorreu
O estado atual da tela não invalida o diagnóstico de um problema passado
D2
Qual a natureza da causa-raiz?
Parametrização/cadastro · Uso/regra de negócio · Integração do lado do cliente · Infraestrutura externa (SEFAZ, prefeitura, InvoiCy/Migrate) · Defeito do produto · Oportunidade de melhoria
F02-08
Mapear para a categoria do F01
Parametrização, uso, integração do cliente e infra externa →Dúvida · Defeito do produto →Bug · Comportamento correto mas insuficiente →Melhoria
F02-09
Preencher campos do GLPI
Análise de Causa (lista fechada) e Justificativa de Causa (texto corrido, sem HTML, sem rótulos)
Regra de classificação: falha externa (ex.: webservice municipal fora) é classificada como Dúvida, não como "Falha na aplicação".
3. Subfluxo: Comunicação com o cliente (F03)
Expande: F01-20 "Retornar pro cliente" e os pedidos de informação do F02.
Objetivo: responder com linguagem acessível e tecnicamente correta.
Tom externo profissional e acessível; usar nomes reais de campos (ex.: AcordoFaturamento); não tratar gap de configuração como bug; propor evolução em vez de "correção" quando for melhoria
F03-03
Revisar
Sem dados sensíveis desnecessários; causa resumida em 1 a 2 frases
F03-04
Publicar no GLPI
Segue para "Validar atendimento" (F01-21)
Tom interno (dev, chat): direto e informal (modelo "Mensagem rápida de chat").
4. Subfluxo: Registro de bug "Problema em prod" (F04)
Expande: F01-08 e F01-09.
Ferramenta: skill /criar-bug + Azure DevOps.
Saída: texto pronto para colar no work item "Problema em prod" (não gera documento).
ID
Etapa
Detalhe
F04-01
Partir da análise do F02
Causa-raiz e evidências já levantadas
F04-02
Entrevista etapa 1: dados básicos e planejamento
URL, Versão, Data de atualização · Previsão de término, Prioridade, Responsável
F04-03
Entrevista etapa 2: comportamento
Comportamento observado com evidência real de produção, esperado vs. observado, passos para reproduzir
F04-04
Gerar texto dos campos
Dados básicos, Description, Planejamento
F04-05
Criar card no DevOps
Colar nos campos do work item "Problema em prod"
F04-06
Macro "Em Análise Técnica" no GLPI
Volta ao F01-10
5. Subfluxo: Criação de História de Usuário (F05)
Expande: F01-06 e F01-07.
Ferramenta: skill /criar-us + Azure DevOps.
Saída: US em Word (.docx) no papel timbrado da nstech e card "História de Usuário".
ID
Etapa
Detalhe
F05-01
Partir da análise do chamado (F02)
Entrada pode ser print, texto colado ou só o número do chamado
F05-02
Entrevista etapa 1: cabeçalho
Código da US informado pelo Rafael (padrão NFTP-1116; usar XXXXXX se ainda não existe), Ambiente de Aplicação (URL), Responsáveis
F05-03
Entrevista etapa 2: entendimento do problema
—
F05-04
Entrevista etapa 3: regra de negócio e limites
Sem detalhe técnico, o dev decide a implementação
F05-05
Rascunho no chat
Marcadores no lugar dos prints
D1
Rascunho aprovado?
Não → ajustar e voltar a F05-05 · Sim → F05-06
F05-06
Gerar .docx timbrado
Caixa emoldurada com título sombreado, depois Ambiente e Responsáveis
F05-07
Criar card História de Usuário no DevOps
Volta ao F01-20
Regra de trilha: defeito de produção nunca vira US, vai para F04.
6. Subfluxo: Escalonamento técnico (F06)
Objetivo: decidir para onde vai um chamado que sai do suporte para o técnico.
Status: rascunho, critério de escolha a confirmar.
Objetivo: cada chamado resolvido que revelou regra não documentada vira conteúdo na Documentação MultiTMS.
ID
Etapa
Ferramenta
Detalhe
D1
A seção da regra já existe?
—
Não → F07-01 · Sim → F07-02
F07-01
Documentar a etapa
/documentar-etapa-multitms
Template de 8 seções, com jornada do usuário e dicionário de campos críticos
F07-02
Revisar o bloco existente
/revisar-doc-multitms
Reescreve no template de 8 seções (migra blocos antigos de 6 seções)
F07-03
Publicar na documentação
—
Documentação do cliente e, quando for regra interna, POP/FAQ do time
8. Fluxo: Gestão e acompanhamento da fila (F08)
Objetivo: visão diária da fila Cabotagem e dos cards em desenvolvimento.
Gatilho: rotina diária.
ID
Etapa
Ferramenta
Detalhe
F08-01
Exportar CSV do GLPI
GLPI
Mesmo modelo todo dia, fila Cabotagem, com campos do plugin Fluxo Cabotagem
F08-02
Atualizar painel
Painel "Chamados Cabotagem"
Gestão de chamados passa a ser 100% pelo painel (Google Agenda descontinuado)
F08-03
Reconciliar fontes
GLPI, painel, DevOps
Apontar divergências acionáveis (status, duplicidades, causa não preenchida)
F08-04
Monitorar "Problema em prod"
Azure DevOps
Cards ainda ativos parados em sprint antiga
F08-05
Cobrar / reencaminhar
—
Dev responsável ou Cloudworks
9. Fluxo: Melhoria contínua da documentação por chamados (F09)
Objetivo: usar as causas dos chamados para achar lacunas na documentação.
Gatilho: periódico, a partir de um export CSV em lote.
ID
Etapa
Ferramenta
Detalhe
F09-01
Ler export CSV do GLPI
/gaps-doc-por-chamados-multitms
Análise de Causa e Justificativa de Causa
F09-02
Agrupar por tema recorrente
—
—
F09-03
Listar gaps provados pelos chamados
—
Entrega no chat, sem arquivo
F09-04
Auditar a documentação
/auditar-doc-multitms
Lacunas contra o padrão de 8 seções, backlog único priorizado (.md)
F09-05
Executar backlog
F07
Documentação do cliente e POP/FAQ interno
10. Fluxo: Registro de reuniões em ATAs (F10)
Objetivo: guardar decisões de reuniões (maioria no Microsoft Teams) e usar o acervo na revisão da documentação.
Status: processo em construção.
ID
Etapa
Detalhe
F10-01
Realizar reunião
Microsoft Teams
F10-02
Registrar ATA
Livro de Atas
F10-03
Extrair regras e decisões
Itens que afetam regra de negócio do MultiTMS
F10-04
Alimentar revisão da documentação
Entrada para F07 e F09
11. Fluxo: Documentação de processo interno (F11)
Objetivo: transformar processos internos do time (infra, suporte, operação) em POP.
Ferramenta:/documentar-processo-nstech.
ID
Etapa
Detalhe
F11-01
Entrevista guiada
Claude pergunta, Rafael responde
F11-02
Montar POP em Markdown
—
F11-03
Revisar e publicar
Base de POP/FAQ interno
12. Mapa de relacionamento entre fluxos
Fluxo
Chama
É chamado por
F01 Atendimento de chamado
F02, F03, F04, F05, F06, F07
—
F02 Análise e diagnóstico
F03 (pedido de informação)
F01
F03 Comunicação com o cliente
—
F01, F02
F04 Registro de bug
—
F01
F05 Criação de US
—
F01
F06 Escalonamento técnico
F04, F05, F08
F01
F07 Inserir regra na documentação
—
F01, F09, F10
F08 Gestão da fila
F06
rotina diária
F09 Melhoria contínua da documentação
F07
periódico
F10 ATAs de reunião
F07, F09
reuniões
F11 Processo interno (POP)
—
sob demanda
Aguardando retorno por responsável (nstech)
Divisão da fila · nstech × Maersk
Texto do informe diário
Gerado a partir do export do GLPI. Chamados nstech usam o técnico atribuído; pendentes usam o requerente Maersk. Marca (+30 dias) para os que passam de 30 dias em aberto.
Fila por idade
Fila por status
Carga por técnico (aberto × resolvido)
Chamados em aberto () · ordenados por idade
Escala de plantão ()
Dias úteis: das 18:00 do dia até as 08:00 do dia seguinte. Sábado e domingo: quem assume às 08:00 fica até as 08:00 do dia seguinte. A linha em destaque é o plantão em andamento agora. A coluna Chamados conta os chamados abertos dentro da janela do plantão, pela data de abertura no GLPI; plantão futuro aparece como traço.
Tickets em aberto por dia · fonte
· período
Entradas e saídas por dia
Tickets com mais de 30 dias
Chamados por instância · agrupado
· visão
Registro diário
Fluxo semanal · barras = resolvidos por
· linha branca = abertos · linha roxa = backlog no fim da semana
SLA por técnico (resolvidos)
Distribuição do tempo de solução
Chamados por nível
Módulos mais afetados
Análise de causa (campo do GLPI)
Preenchimento da causa por técnico (resolvidos)
Análise de causa por instância · recorte
· considera a data de solução
Aliança Navegação ·
Maersk Truck ·
Chamados e causas ()
Respeita os filtros da página. O CSV sai separado por ponto e vírgula, pronto para abrir no Excel.
Resolvidos recentes sem causa registrada ()
resolvidos nos últimos
Chamados já fechados em que o campo "Análise de Causa" do plug-in Fluxo Cabotagem ficou em branco. Respeita os filtros da página.
Ações estruturais o que foi feito e se funcionou
filtra todos os gráficos desta aba
Evolução de uma tela ·
Carga travada em alguma etapa ·
NFS-e / prefeitura
CIOT, frete e pedágio
Cards do time de desenvolvimento ()
Mensagem para o time de dev · os cards da seleção acima que ainda não foram concluídos
Atividades ()
Backlog do time no Azure DevOps: histórias, defeitos, problemas em produção, tarefas e casos de teste. A coluna Deploy é inferida pela data: mostra a primeira subida em produção posterior à conclusão do item. Itens concluídos antes do primeiro deploy registrado, ou que ainda não subiram, ficam sem versão. Fonte: export do board.
Atualizações em produção () · ● Aliança● Maersk LNS
Clique na linha para ver os itens que foram naquela release. Registro das subidas de versão em produção. As datas aparecem como marco vertical no Histórico diário e no Fluxo semanal, com uma linha por ambiente (laranja = Aliança, azul = Maersk LNS), para comparar o antes e o depois de cada entrega. Só a estreia de cada versão vira marco: subir de novo a mesma versão é hotfix e fica marcado na tabela, sem poluir os gráficos. Itens da release vem da planilha de releases (ligação pela versão: 8.13.0.4 lê a release 8.13), por isso hotfix da mesma versão mostra a mesma lista. Itens do board conta os work items do Azure fechados na janela daquele deploy. Fonte: painel de atualizações da nstech e planilha Itens por release Instância 1 e 3.
