Como automatizar os relatórios de SLA e de resolução de tickets para clientes de MSP

Comprovar a conformidade com o SLA (acordo de nível de serviço) é fundamental para MSPs (provedores de serviços gerenciados). Isso vai muito além de um exercício de relatórios: sustenta a confiança do cliente e valida o bom desempenho. Além disso, os clientes esperam transparência, principalmente quando há obrigações contratuais em jogo.

Para isso, vale a pena automatizar os relatórios de SLA e de resolução de tickets. Os relatórios automatizados para clientes eliminam o processo manual e entregam um fluxo consistente e repetível. Assim, os MSPs conseguem acompanhar tendências de desempenho, identificar problemas cedo e apresentar relatórios sem a carga de trabalho habitual.

Este guia mostra as ferramentas, os scripts e os fluxos de trabalho necessários para criar relatórios de SLA precisos em escala.

Para uma visão geral rápida, assista ao nosso guia em vídeo Como automatizar os relatórios de SLA e de resolução de tickets para clientes de MSP.

Como automatizar os relatórios de SLA e de resolução de tickets

📌 Pré-requisitos:

• Uma plataforma PSA ativa, como NinjaOne, Autotask ou ConnectWise.
• As políticas de SLA precisam estar atribuídas a cada cliente, para que os sistemas saibam quais prazos se aplicam.
• Os registros de data e hora e as categorias dos tickets devem estar corretos, para garantir a precisão dos relatórios.
• Permissões de administrador são necessárias para o PowerShell e para consultas de dados via script.
• Acesso aos logs de eventos ou aos dados locais do sistema, para confirmar a linha do tempo dos incidentes.

Defina as métricas de SLA e os parâmetros de resolução

Antes de configurar relatórios automatizados que mostrem aos clientes a conformidade com os parâmetros de SLA, defina o que será medido.

📌 Casos de uso:

• Padroniza o monitoramento de SLA em todos os clientes.
• Cria a base para relatórios e painéis automatizados.
• Permite mostrar as métricas e metas de desempenho exigidas no contrato.

📌 Pré-requisitos:

• Políticas de SLA atribuídas por cliente no PSA.
• Registro correto de data e hora das mudanças de status do ticket (criado, reconhecido, resolvido).
• Tipos ou categorias de ticket definidos para agrupar os dados de SLA.

Estas são as métricas de conformidade de SLA que devem entrar nos seus relatórios:

• Tempo até o reconhecimento (TTA)
• Tempo até a resolução (TTR)
• Percentual de conformidade de resposta ao SLA
• Taxa de sucesso na resolução por categoria (hardware, software, rede)
• Número de tickets escalados em relação aos resolvidos
• Número de tickets de SLA perdidos ou reabertos

Extraia dados de SLA e de tickets com PowerShell ou API

Com as métricas definidas, o próximo passo é extrair os dados de tickets do PSA. A maioria das plataformas aceita consultas ou exportações via API (interface de programação de aplicações), que podem ser filtradas e agendadas pelo PowerShell.

📌 Casos de uso:

• Automatiza o monitoramento de SLA em vários clientes.
• Reduz o esforço manual nas revisões mensais de tickets.
• Dá suporte a painéis e relatórios por categoria de SLA ou status de violação.

📌 Pré-requisitos:

• Um token de API com permissão para consultar tickets.
• PowerShell na versão 5.1 ou superior.
• RMM ou Agendador de Tarefas com acesso para automatizar a execução dos scripts.

Veja um exemplo de trecho em PowerShell que extrai tickets resolvidos de uma API de PSA e os exporta para CSV:

$headers = @{ "Authorization" = "Bearer $token" }
$response = Invoke-RestMethod -Uri "https://api.ninjaone.com/v2/tickets" -Headers $headers
$response | Where-Object { $_.resolved -eq $true } | Export-Csv "C:\Reports\SLAReport.csv" -NoTypeInformation

Para filtrar o relatório por cliente, período ou status de SLA, é preciso alterar o script. Adicione parâmetros de consulta à URL da API ou use condições no PowerShell.

Use o Registro para rastrear eventos locais de SLA ou do agente (opcional)

📌 Casos de uso:

• Adiciona uma trilha de auditoria local das respostas baseadas em script vinculadas aos IDs dos tickets.
• Ajuda a validar quando um alerta ou uma ação de correção foi disparado.
• Enriquece os painéis do RMM com o contexto de tickets por endpoint.

📌 Pré-requisitos:

• Permissões de administrador para gravar no Registro.
• Um RMM ou script para atualizar os valores do registro.
• Um padrão de nomenclatura para mapear os tickets entre os sistemas.

Para marcar eventos relacionados ao SLA localmente, crie valores de registro personalizados. Veja como:

1. Abra o Editor do Registro.
2. Navegue até este caminho: HKEY_LOCAL_MACHINE\SOFTWARE
3. Em seguida, clique com o botão direito na pasta SOFTWARE, escolha Novo > Chave e dê o nome Org.
4. Clique com o botão direito na chave Org e selecione Novo > Chave. Dê o nome: SLAEvents
5. Dentro da chave SLAEvents , clique com o botão direito no painel à direita e escolha Novo > Valor de Cadeia de Caracteres.
6. Dê o nome LastAcknowledgedTicket. Clique duas vezes nele e informe um ID de ticket (por exemplo, TKT-10129) como dados do valor.
7. Crie outro valor de cadeia de caracteres em SLAEvents. Dê o nome LastActionTime. Clique duas vezes e defina os dados do valor com o registro de data e hora do evento (por exemplo, 2025-08-15T14:23Z)

Depois de criados, esses valores podem ser lidos por scripts ou coletados pelo seu RMM.

💡 Dica: esta é uma forma manual de acompanhar o SLA. Já o sistema de tickets do NinjaOne monitora a conformidade com o SLA automaticamente.

Execute scripts no CMD para obter contexto do endpoint ou monitorar serviços

Os scripts do Prompt de Comando servem para coletar dados básicos do sistema em dispositivos Windows. Com eles, dá para verificar o que acontecia em um endpoint no momento em que o ticket foi criado: tempo de atividade, serviços com falha ou eventos ligados a problemas do sistema. Isso deixa o processo de relatórios de resolução de tickets mais fluido.

📌 Casos de uso:

• Ajuda a confirmar se o problema estava ligado a uma reinicialização, uma pane ou uma indisponibilidade.
• Apoia a análise de causa raiz ao correlacionar o comportamento do endpoint com os tickets.
• Útil quando o PowerShell não está disponível.

📌 Pré-requisitos:

• Acesso de administrador para executar o Prompt de Comando com privilégios elevados.
• Os endpoints precisam estar com o registro de logs e o histórico de eventos ativados.
• O processo de relatórios deve permitir salvar ou enviar os logs.

Veja alguns exemplos de comandos do Prompt de Comando:

Verificar o tempo de atividade do sistema

systeminfo | findstr "System Boot Time"

Isso retorna a última vez em que o sistema foi reiniciado, o que ajuda a confirmar se o dispositivo foi reiniciado antes ou depois de o problema ser relatado.

Listar serviços com falha ou parados

sc query type= service state= all | findstr "STOPPED"

Este método identifica quais serviços não estão em execução. Depois, basta comparar com o problema relatado para ver se algum serviço crítico estava fora do ar quando o ticket foi criado.

Exportar entradas recentes do log do sistema

wevtutil qe System /q:"*[System[(EventID=7034)]]" /f:text /c:20

Isso extrai os últimos 20 eventos do log do sistema referentes a serviços interrompidos de forma inesperada. Ajuda a confirmar quando o dispositivo sofreu um erro crítico.

💡Observação: use esses comandos para verificar o comportamento do endpoint no período em que o ticket foi aberto ou resolvido.

Como criar modelos de relatório para entrega ao cliente

Depois de reunir os dados de conformidade de SLA e de tickets, o próximo passo é exportar os tickets e apresentá-los ao cliente de forma clara. Os relatórios devem resumir as principais métricas e os SLAs não cumpridos, além de apontar onde há espaço para melhorias.

📌 Casos de uso:

• Ajuda a entregar relatórios consistentes e personalizados com a sua marca.
• Simplifica os relatórios recorrentes e as revisões de SLA.
• Comunica tendências, avanços e riscos em linguagem simples.

📌 Pré-requisitos:

• Os dados de SLA e de tickets já coletados.
• Uma ferramenta para criar gráficos ou tabelas (MS Excel, Google Sheets).
• Uma estrutura de relatório definida e padronizada, reutilizável entre clientes.

Inclua estes elementos essenciais no relatório:

• Resumo executivo – deve trazer o percentual de conformidade com o SLA e as estatísticas principais.
• Tendências de tickets – volume, tipos e padrões de resolução dos tickets.
• Análise de SLAs não cumpridos – IDs dos tickets e os motivos pelos quais foram abertos.
• Desempenho dos técnicos (opcional) – tempos médios de resposta e de resolução.
• Recomendações – lacunas de serviço, causas raiz e pontos de melhoria, sobretudo em relação à análise de SLAs não cumpridos e ao desempenho dos técnicos.

Estas são as opções de formato recomendadas:

• Microsoft Excel, exportado via PowerShell. Por exemplo, você pode usar este comando de amostra com dados de tickets filtrados:

$response = Invoke-RestMethod -Uri "https://api.psa.com/v2/tickets" -Headers @{ "Authorization" = "Bearer $token" }
$filtered = $response | Where-Object { $_.resolved -eq $true }
$filtered | Export-Excel -Path "C:\Reports\SLA_Report_July.xlsx" -WorksheetName "ResolvedTickets" -AutoSize

Também dá para usar uma versão em PDF, mas é preciso salvar o arquivo manualmente nesse formato.

• Power BI (business intelligence) para outros painéis com métricas ao vivo.
• Relatório em HTML com gráficos e tabelas.
• Relatório agendado nativo do PSA.

Garanta que esses relatórios sejam segmentados por cliente e alinhados aos limites e metas de SLA de cada um.

Automatize a geração e o envio dos relatórios

A última etapa na criação de relatórios automatizados para clientes é a entrega. Para isso, agende scripts que exportem os relatórios e enviem e-mails.

📌 Casos de uso:

• Entrega resumos de SLA e relatórios de resolução de tickets sem esforço manual.
• Garante relatórios pontuais e “nunca atrasados” para todos os clientes.

📌 Pré-requisitos:

• Um script de relatório funcional que gere saídas em CSV, XLSX ou PDF.
• As credenciais do servidor de e-mail ou do destino de arquivos dos clientes.
• Uma plataforma RMM ou PSA compatível com scripts ou relatórios agendados.

Há várias formas de automatizar a entrega dos relatórios:

• Agendar scripts para exportar os dados de SLA e enviá-los por e-mail ao cliente.
• Envio via API para SharePoint, S3 ou uma pasta FTP segura.
• Usar as ferramentas de agendamento nativas do PSA. Um bom exemplo são os relatórios exportados do NinjaOne.
• Também é possível disparar a automação pelo seu RMM.

Veja um exemplo de envio de e-mail com PowerShell:

Send-MailMessage -From "[email protected]" -To "[email protected]" `
-Subject "Monthly SLA Performance - July" `
-Attachments "C:\Reports\SLAReport_July2025.pdf" `
-SmtpServer "smtp.msp.com"

⚠️ Pontos de atenção

Outros pontos a considerar ao automatizar os relatórios de SLA e de resolução de tickets

Mapeie os SLAs para cada cliente

Cada cliente tem exigências diferentes de tempo de resposta e de resolução. Garanta que cada ticket esteja vinculado à política de SLA correta no seu sistema PSA.

Padronize os dados de tickets entre os ambientes

Use as mesmas categorias de ticket, nomes de status e fluxos de trabalho em todos os clientes. Isso facilita filtrar, representar em gráficos e comparar o desempenho do SLA ao longo do tempo.

Guarde os dados brutos para auditorias

O ideal é manter os logs de tickets exportados e os registros de data e hora de resolução por pelo menos 12 a 24 meses. Esse histórico ajuda em revisões contratuais, contestações de faturamento e auditorias externas.

Separe os dados por cliente

Isso é essencial em ambientes multitenant. Sempre filtre e exporte os tickets por ID de cliente, o que evita vazamento de dados e mantém os relatórios limpos e precisos.

Solução de problemas nos relatórios de SLA e de resolução de tickets

Registros de data e hora ausentes

Verifique se o sistema de tickets está registrando todas as mudanças de status necessárias, como:

• Criado
• Reconhecido
• Escalado
• Resolvido

Sem isso, as métricas de SLA do relatório ficam incompletas.

Mapeamento de SLA incorreto

Confirme se as regras de automação do PSA e as filas de tickets estão aplicando as políticas de SLA corretas para cada cliente. Um ticket roteado para o lugar errado afeta as estatísticas e distorce os números.

Falhas nos scripts do PowerShell

Se os scripts não estiverem exportando ou enviando os relatórios, verifique problemas de permissão na API, tokens expirados ou erros no próprio script.

Exibição inconsistente de fusos horários

Se os registros de data e hora do relatório não baterem com o histórico do ticket, normalize tudo para UTC ou, melhor ainda, converta para o horário local do cliente.

Serviços NinjaOne

Com NinjaOne, os MSPs automatizam os relatórios de SLA e simplificam o acompanhamento da resolução de tickets em todos os clientes. Veja os recursos na tabela abaixo:

Relatórios automatizados de SLA e de tickets mantêm MSPs e clientes alinhados

Automatizar os relatórios de SLA e de resolução de tickets ajuda os MSPs a serem mais transparentes, responsáveis e eficientes. Reduz o tempo gasto com exportações manuais, melhora a precisão dos relatórios e garante que os compromissos de serviço sejam cumpridos e fiquem visíveis.

Vimos como definir as métricas de SLA certas, extrair dados de tickets com PowerShell ou API, validar eventos de resolução com o Registro e ferramentas do CMD e formatar relatórios para entrega ao cliente. Com esses métodos em prática, os MSPs entregam relatórios de SLA confiáveis e alinhados às políticas, em escala.

Temas relacionados:

• Automações essenciais do NinjaOne Ticketing para começar
• O que é um acordo de nível de serviço (SLA) de MSP?
• 6 dicas de relatórios de help desk para o gerenciamento de TI moderno
• Além da solução de problemas: boas práticas de relatórios de TI