Chamados no Portal Nyverra: guia completo de incidentes e requisições

Quase todo problema de service desk nasce no mesmo ponto: o chamado. É por ele que a demanda entra, é nele que o relógio do SLA começa a correr e é nele que a operação precisa provar, ao final, o que foi feito. Um chamado mal registrado gera retrabalho, SLA estourado e cliente insatisfeito; um chamado bem conduzido é a diferença entre “apagar incêndio” e operar com método.

Este guia percorre o módulo de Chamados do Portal Nyverra ITSM de ponta a ponta: o que é (e o que não é) um chamado, como funciona a triagem, o cálculo de prioridade e SLA, os trâmites internos e públicos, transferência e escalação, aprovações, observadores e as ações em massa. Ao final você terá o mapa completo do fluxo — do registro ao encerramento.

Interface do módulo no Portal Nyverra ITSM.

O que é um chamado — e o que não é

No Portal, um chamado é um ticket numerado (prefixos como IN- para incidentes e RS- para requisições) que carrega solicitante, cliente, classificação, responsável, prazo e todo o histórico de interações. É importante não confundir os conceitos do ITIL:

Conceito	Objetivo	Exemplo
Incidente	Restaurar um serviço que parou ou degradou	“O e-mail da diretoria está fora do ar”
Requisição	Atender um pedido padronizado	“Preciso de acesso à pasta X”
Problema	Eliminar a causa raiz de incidentes recorrentes	“A VPN cai todo dia às 9h”
Mudança	Alterar algo em produção com controle e risco	“Atualizar o ERP para a versão 12”

O chamado resolve o agora. Quando a demanda se repete, ela deve evoluir para Problema; quando exige alteração planejada, para Mudança. O Portal permite encadear esse fluxo dentro do próprio ticket, vinculando chamados a problemas, mudanças e chamados filhos.

Quem usa: perfis e visibilidade

A visibilidade é controlada por RBAC (controle de acesso por papéis). O mesmo ticket é visto de formas diferentes conforme o perfil:

Perfil	O que vê e faz
Cliente	Abre e acompanha apenas os chamados do seu escopo; não vê notas internas.
Técnico / operador	Lista, captura, transfere, registra trâmites, controla tempo e encerra, conforme permissões (ver todos, do grupo ou atribuídos).
Administrador	Configura tipos, categorias, urgências, impactos, regras de SLA, calendário e a view padrão por equipe.

O ciclo de vida de um chamado

O Portal trabalha com estados padrão do fluxo — e cada transição tem consequência no SLA e nas notificações:

Status	Significado	Impacto no SLA
REGISTRADO	Acabou de ser criado, ainda na fila de triagem.	Relógio correndo desde a criação.
EM_ATENDIMENTO	Há um responsável trabalhando no ticket.	Relógio correndo.
PENDENTE	Aguardando terceiros (cliente, fornecedor).	Pausa o SLA automaticamente.
RESOLVIDO	Solução aplicada; aguarda confirmação/fechamento.	SLA de resolução cumprido.
FECHADO	Ciclo encerrado.	Fim do ciclo.
CANCELADO	Demanda não procede ou foi cancelada.	Fim do ciclo.

Quando um chamado entra em PENDENTE (por exemplo, “aguardando cliente”), o Portal congela o relógio do SLA e o retoma quando o estado muda de volta — evitando que a equipe seja penalizada por dependências externas. Esse detalhe é um dos que mais impacta os indicadores de compliance.

Abertura e triagem

Criar bem é metade do atendimento. Na abertura, o Portal captura:

• Solicitante: um usuário da operação ou um contato do cliente.
• Cliente e, quando aplicável, localização/ramificação.
• Classificação: tipo de chamado, categoria/área (ex.: Infraestrutura Linux, NOC, Aplicações) e subcategoria.
• Assunto e descrição — quanto melhor descrever o sintoma, mais rápido o diagnóstico.
• Urgência e impacto — que combinados definem a prioridade.
• Vínculos: ativo (CMDB), fornecedor, chamado relacionado (pai) e tipo de relacionamento.
• Observadores — quem deve receber os avisos do ticket.
• Anexos já na criação e campos personalizados por categoria.

A triagem é o momento de rotear: a lista organiza os chamados por prazo e prioridade, e o operador direciona para o grupo certo. Uma classificação consistente é o que permite relatórios confiáveis e a sugestão automática de categoria por IA.

Prioridade: urgência × impacto

A prioridade não é subjetiva: ela decorre do cruzamento entre urgência (o quanto dói agora) e impacto (quantas pessoas/serviços são afetados). Um incidente que atinge toda a empresa é prioridade máxima mesmo sendo tecnicamente simples; um pedido individual é baixo impacto, por mais “urgente” que pareça ao solicitante. A matriz de priorização padrão do ITIL:

Impacto ↓ / Urgência →	Alta	Média	Baixa
Alto	Crítica (P1)	Alta (P2)	Média (P3)
Médio	Alta (P2)	Média (P3)	Baixa (P4)
Baixo	Média (P3)	Baixa (P4)	Baixa (P4)

A prioridade resultante define quais regras de SLA se aplicam ao chamado.

SLA: o que é medido e quando pausa

O Portal controla dois marcos principais: primeira resposta e resolução. Os prazos são calculados por tipo + prioridade, considerando o calendário comercial configurado (horário de atendimento e feriados — por isso um ticket aberto na sexta à noite não “vence” no fim de semana).

• Pausa automática: em PENDENTE, o SLA congela e retoma ao sair do estado.
• Alerta de vencimento: o operador vê o tempo restante no detalhe; o painel de SLA/OLA evidencia violações por fila.
• Visibilidade: técnicos e gestores acompanham o tempo restante; o cliente vê o status sem a exposição interna.

Um SLA “estranho” quase sempre tem uma dessas causas: chamado pausado (aguardando cliente), calendário diferente do esperado, ou regra de SLA específica do tipo de chamado. Vale conferir com o administrador antes de abrir um incidente sobre o próprio SLA.

A fila e a busca

Chamados maduros vivem de filtros. A lista do Portal oferece filtros rápidos (Todos, Meus, Minha fila, Abertos, Sem operador) e um painel com status, prioridade, cliente e período. Tudo isso é a base da view padrão: aquela combinação de filtros que faz a tela abrir já na fila que cada equipe atende. Quando o administrador define a view de um perfil, o usuário não a remove por conta própria — garante consistência operacional.

Atendimento: capturar e registrar trâmites

Com o chamado na mão, o operador captura o ticket para assumir a responsabilidade e passa a registrar trâmites. Aqui está uma separação que confunde muita gente — e que o Portal deixa explícita:

Tipo	Quem vê	Quando usar
Nota (interna)	Somente a equipe	Contexto técnico, hipóteses, passos de diagnóstico, escalonamento interno.
Resposta (pública)	Solicitante/cliente	Comunicação oficial, pedido de informação, aviso de resolução.

Escolher o tipo certo evita o constrangimento de expor ao cliente uma conversa interna — e evita deixar o cliente sem resposta por achar que a nota bastava. Além dos trâmites, o operador pode anexar arquivos e registrar tempo trabalhado (time tracking), quando o módulo está em uso.

Atribuição, transferência e escalação

Três operações distintas, com propósitos distintos:

• Atribuir: definir um operador responsável pelo ticket.
• Transferir: mover o chamado para outro grupo (e, opcionalmente, um operador destino), informando o motivo — que fica registrado no histórico. Use Transferir quando a demanda pertence a outra fila; não use “Editar” só para trocar fila ou responsável.
• Escalar / Desescalar: subir o atendimento de nível (N1 → N2 → N3) quando exige especialização, e descer quando retorna. O histórico de escalações preserva níveis de origem/destino, motivo, operador e tempo gasto.

Essas operações respeitam permissões: se o botão de transferir aparece desabilitado, normalmente é falta de permissão (TICKET_UPDATE_*) ou o chamado já está finalizado.

Observadores, aprovações e relacionados

• Observadores (CC): pessoas que acompanham o chamado e recebem avisos, sem serem responsáveis — útil para supervisores e stakeholders.
• Aprovações: se o tipo de chamado exigir aprovação, o fluxo não avança até os aprovadores decidirem. A decisão fica em Aprovações pendentes (com contadores/badges).
• Relacionados: vincule o chamado a problemas (recorrência), mudanças (correção planejada) e chamados filhos/derivados — reconstruindo o contexto do incidente.

Ações em massa e exportação

Para demandas em lote, o Portal permite seleção múltipla e ações em massa: fechar, atribuir e mudar status de vários chamados de uma vez, com um resumo de sucessos e falhas por ticket. Já a exportação (Excel/PDF, conforme permissão) apoia a prestação de contas e a conferência de filas.

Notificações

Eventos relevantes — novo trâmite, atribuição, decisão de aprovação — disparam notificações in-app (sino no cabeçalho) e, quando configurado, por e-mail, chat e push no app mobile. Quem está na linha de frente percebe a mudança sem precisar ficar atualizando a tela.

Boas práticas que mudam o indicador

• Padronize classificação: tipos, categorias e subcategorias consistentes habilitam relatórios, SLA corretos e IA de sugestão.
• Separe nota de resposta: comunicação clara com o cliente, contexto rico para a equipe.
• Não deixe chamado órfão: capture ou atribua responsável ainda na triagem.
• Vincule o ativo (CMDB): chamados ligados ao CI permitem identificar recorrência por equipamento.
• Use a view padrão: a equipe abre já na fila certa, reduzindo tempo de triagem.
• Acompanhe o SLA por fila: aja antes do vencimento, não depois.

Erros comuns (e como resolver)

Situação	O que fazer
Não encontro o chamado na lista	Revise os filtros; teste “Meus” e “Minha fila”; confirme cliente e status.
Botão Transferir desabilitado	Confirme permissão e se o chamado não está finalizado.
SLA parece errado	Verifique se está pausado (aguardando cliente) e confirme calendário/regra com o admin.
Preciso aprovar algo	Use Aprovações pendentes, não apenas o detalhe do chamado.
Cliente “não recebeu” a resposta	Confirme se foi registrado como Resposta (pública) e não como Nota (interna).

Perguntas frequentes

Qual a diferença entre resolver e fechar?
“Resolvido” indica que a solução foi aplicada; “Fechado” encerra de fato o ciclo, normalmente após confirmação do cliente ou prazo de auto-fechamento.

O cliente vê os trâmites internos?
Não. Notas são sempre internas; Respostas são sempre visíveis ao solicitante.

Posso mudar o tipo de um chamado já aberto?
Dependendo da permissão e da política, sim — mas a mudança pode disparar novo SLA ou nova etapa de aprovação. Use com critério.

Como o Portal evita SLA injusto?
Pausando o relógio quando o chamado aguarda terceiros (status PENDENTE) e respeitando o calendário comercial.

Automatize via API

O módulo de Chamados é exposto por uma API REST. Os recursos mais usados em integrações:

• GET /api/tickets/busca-avancada — listagem com filtros e paginação.
• POST /api/tickets — abertura de chamado.
• GET /api/tickets/{id} — detalhe.
• POST /api/tickets/{id}/tramites — adicionar trâmite.
• POST /api/tickets/{id}/acoes — capturar/iniciar/encerrar/cancelar.
• POST /api/tickets/{id}/transferir, /escalar e /desescalar.
• POST /api/tickets/bulk-action — ações em massa.

A referência interativa está em developer.nyverra.com.

Conclusão

O módulo de Chamados do Portal Nyverra ITSM transforma a rotina do service desk em um fluxo controlado e auditável: classificação consistente, prioridade calculada, SLA com pausa automática, comunicação separada entre equipe e cliente, transferência e escalação rastreáveis, aprovações e ações em massa. É a diferença entre reagir e operar com previsibilidade — e o cliente percebe.