# SLA e tickets em agencia WordPress: Os 5 pilares da gestão

<strong>SLA e tickets</strong> são o contrato e o registro que transformam suporte em processo previsível numa agência WordPress. Segundo a <a href="https://developer.wordpress.org/cli/commands/" rel="noopener" target="_blank">documentação do WP-CLI (2026)</a>, atualizações e manutenção de vários sites viram um único comando automatizável. Um SLA real exige monitoramento, não boa vontade: queda fora do horário sem alerta já viola o prazo. Defina severidade, prazo e canal antes de prometer.

SLA e tickets formam a base operacional de qualquer agência que mantém dezenas de sites WordPress sob contrato. O SLA (Service Level Agreement) é o acordo que define quanto tempo a agência tem para responder e resolver cada tipo de problema. O ticket é o registro individual de cada chamado, com histórico, prioridade e prazo. Sem os dois andando juntos, o suporte vira fila de WhatsApp e o cliente nunca sabe se foi atendido. Este guia mostra como estruturar SLA e tickets na prática, qual ferramenta usar e por que o acordo depende de monitoramento automatizado. Para a visão geral da rotina, veja a <a href="https://full.services/gestao-de-sites-wordpress/">central de gestão de sites WordPress da FULL</a>.

---

## SLA e tickets: O que cada termo define na pratica

SLA e tickets resolvem dois problemas distintos, e um SLA típico de agência separa isso em 3 ou 4 níveis de severidade, com prazos entre 1 hora (site fora do ar) e 24 horas (ajuste cosmético). O SLA promete o prazo; o ticket prova que o prazo foi cumprido.

Cada chamado nasce com uma categoria que herda o relógio do acordo. Sem o ticket, o SLA é só uma frase bonita no contrato, sem nenhum dado por trás que comprove o atendimento.

<table id="sla-tickets-pilares">
  <caption>SLA e tickets: severidade, prazo e o que dispara cada nível</caption>
  <thead>
    <tr>
      <th scope="col">Severidade</th>
      <th scope="col">Prazo de resposta tipico</th>
      <th scope="col">Exemplo de chamado</th>
    </tr>
  </thead>
  <tbody>
    <tr><th scope="row">Critica</th><td>1 hora</td><td>Site fora do ar, checkout WooCommerce quebrado</td></tr>
    <tr><th scope="row">Alta</th><td>4 horas</td><td>Erro em formulário, plugin gerando tela branca</td></tr>
    <tr><th scope="row">Media</th><td>8 horas</td><td>Lentidao perceptivel, alerta de segurança</td></tr>
    <tr><th scope="row">Baixa</th><td>24 horas</td><td>Ajuste de texto, troca de imagem</td></tr>
  </tbody>
</table>

A maior parte das agências erra ao prometer um único prazo para tudo. Nos tickets de suporte da FULL, a gente vê que misturar "site caiu" e "trocar a cor do botão" na mesma fila atrasa o que importa. Separar por severidade é o primeiro pilar de SLA e tickets que funciona.

## Por que tickets sem SLA viram caos operacional

Tickets sem SLA viram caos porque uma agência que gerencia 40 ou 50 sites chega fácil a dezenas de chamados por semana, e sem prazo a fila é atendida por quem grita mais alto, não por urgência. Um sistema como Awesome Support, Fluent Support ou SupportCandy organiza o histórico, mas sem um prazo amarrado a cada categoria ele só vira um arquivo bonito de reclamações.

O SLA é o que dá peso à fila: ele transforma "uma lista de pedidos" em "uma fila com relógio rodando", onde o chamado de severidade crítica sobe ao topo. Sem isso, chamados de baixa prioridade abertos cedo empurram os críticos abertos depois, e o cliente do site fora do ar espera atrás de um pedido de troca de banner. Para escolher a ferramenta, compare as opções em <a href="https://full.services/plugins-para-sistema-de-tickets-e-atendimento-no-wordpress/">plugins de sistema de tickets para WordPress</a>.

## Onde hospedar o helpdesk: Dentro do WordPress ou em SaaS

Hospedar o helpdesk dentro do WordPress economiza 1 assinatura, mas cobra um preço técnico em volume alto. Plugins como SupportCandy e Awesome Support rodam na mesma instalação do site, e a fila de e-mails de notificação disputa o mesmo wp_cron e o mesmo banco que atendem os visitantes.

Em pico, isso atrasa o disparo de abertura, e o relógio do SLA começa a contar antes do cliente saber que foi atendido.

A alternativa é o SaaS externo. Zendesk e Freshdesk rodam fora do WordPress, com fila e SLA nativos, mas cobram por agente ao mês, o que pesa numa agência pequena. O critério é o volume: até 15 ou 20 chamados por semana, o plugin nativo testado em <a href="https://full.services/glossario/ambiente-staging/">ambiente de staging</a> dá conta. Acima disso, a separação do SaaS compensa o custo, e boa parte das agências migra quando o suporte começa a competir com o site pelo servidor.

## Como o SLA depende de monitoramento, nao de boa vontade

Um SLA de 4 horas só é real quando existe monitoramento automatizado disparando o ticket antes do cliente perceber o problema. O ponto cego mais comum: a agência promete o prazo, mas o site cai às 23h de sexta e ninguém fica sabendo até segunda.

O acordo foi violado e nem havia chamado aberto. UptimeRobot verifica o site a cada poucos minutos e abre o ticket no momento da queda, fazendo o relógio do SLA começar pelo lado da agência.

Esse é o pilar que a maioria esquece. Monitorar <a href="https://full.services/glossario/uptime/">uptime</a> de forma automatizada não é luxo: é a condição para que o SLA e tickets tenham valor. A FULL conecta 150 mil sites e a gente vê que as agências mais maduras tratam o monitoramento como parte do SLA, não como item separado. Aprofunde em <a href="https://full.services/monitoramento-de-uptime-wordpress/">monitoramento de uptime no WordPress</a> e cruze com o seu <a href="https://full.services/checklist-de-manutencao-wordpress/">checklist de manutenção</a>.

## Automatize a manutenção para liberar a fila de tickets

Automatizar a manutenção recorrente corta boa parte dos tickets na origem e libera o SLA para o que é urgente. A maior parte dos chamados de uma agência não é emergência: é 1 update de plugin pendente, backup que falhou, cache que precisa limpar.

A documentação oficial do <a href="https://developer.wordpress.org/cli/commands/" rel="noopener" target="_blank">WP-CLI</a> mostra que essas tarefas viram um único comando rodável em script ou cron job, atualizando dezenas de sites de uma vez sem abrir um ticket por site.

O ganho é direto no <a href="https://full.services/glossario/kpi-wordpress/">KPI</a> de suporte. Quando a manutenção roda sozinha via <a href="https://full.services/glossario/wp-cli/">WP-CLI</a> de madrugada, a fila de tickets do horário comercial fica reservada para o que precisa de gente. Isso muda a equação do SLA: em vez de inflar a fila com tarefas previsíveis, a agência atende menos chamados e cumpre prazos com folga. Para o cliente, sai o <a href="https://full.services/relatorio-de-manutencao-wordpress/">relatório de manutenção</a> mostrando o que foi feito sem nenhum chamado aberto, o que reduz a ansiedade que gera ticket de "está tudo bem com meu site?".

## Como a FULL apoia a gestão de SLA e tickets

A FULL não vende um plugin de helpdesk, mas resolve a camada que faz SLA e tickets funcionarem: a infraestrutura de gestão por trás. O plano PRO da FULL custa R$849 e cobre até 10 sites, o que dá R$85 por site para manter monitoramento, backup automatizado e os 17 plugins do bundle ativos em um clique. Numa agência, esse R$85 por site é o custo de manter o suporte previsível em vez de apagar incêndio. Conheça os <a href="https://full.services/planos">planos da FULL</a> e centralize a operação em um <a href="https://full.services/painel-de-gestao-de-sites-wordpress/">painel de gestão de sites</a>. Para a estratégia mais ampla de operação, vale o material sobre <a href="https://full.services/agencia-wordpress/">como estruturar uma agência WordPress</a>.

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia: Como a FULL avalia SLA e tickets</h2>
<p>As recomendações deste guia vêm da observação qualitativa do suporte da FULL, que conecta 150 mil sites WordPress, entre <time datetime="2024-01">janeiro de 2024</time> e <time datetime="2026-06">junho de 2026</time>. A análise cruza o comportamento de plugins de helpdesk nativos (SupportCandy, Awesome Support, Fluent Support) com ferramentas SaaS externas (Zendesk, Freshdesk) e de monitoramento (UptimeRobot), em instalações WordPress 6.x com PHP 8.2. Nenhum percentual de proporção interna é afirmado: a FULL não publica dataset de tickets. Os prazos de severidade citados são referências de mercado comuns em contratos de agência, não médias proprietárias da casa.</p>
</aside>

<h2 id="faq">Perguntas frequentes sobre SLA e tickets</h2>

<details>
<summary>Por que SLA e tickets precisam andar juntos numa agencia?</summary>
<p>Porque um sem o outro não prova nada. O SLA define o prazo, mas é o ticket que registra quando o chamado abriu e fechou, gerando o dado que comprova o cumprimento. Sem ticket, o SLA de 4 horas é só uma frase no contrato. Sem SLA, o ticket vira uma lista sem prioridade que a agência atende por quem reclama mais alto, e não por urgência técnica real.</p>
</details>

<details>
<summary>E possível cumprir um SLA sem monitoramento de uptime automatizado?</summary>
<p>Não de forma confiável. Sem monitoramento, a agência só descobre que o site caiu quando o cliente liga, e o relógio do SLA já correu contra ela. Ferramentas como UptimeRobot verificam o site a cada poucos minutos e abrem o ticket no momento exato da queda. O monitoramento automatizado é a condição para o SLA ter valor: ele faz o prazo começar pelo lado da agência.</p>
</details>

<details>
<summary>Qual a diferenca entre helpdesk dentro do WordPress e SaaS externo?</summary>
<p>O helpdesk nativo (SupportCandy, Awesome Support) roda na mesma instalação do site e disputa wp_cron e banco com os visitantes, o que atrasa notificações em pico. O SaaS externo (Zendesk, Freshdesk) tem fila e SLA próprios, mas cobra por agente ao mês. A escolha é por volume: até cerca de 20 chamados semanais, o plugin nativo dá conta; acima disso, o SaaS tende a compensar o custo.</p>
</details>

<details>
<summary>Quanto tempo de resposta um SLA de agencia costuma prometer?</summary>
<p>Depende da severidade do chamado, e essa é a chave. Um SLA de agência bem escrito usa níveis: 1 hora para críticos (site fora do ar), 4 horas para alta prioridade (formulário quebrado), 8 horas para média e até 24 horas para ajustes cosméticos. Prometer um único prazo para tudo é o erro mais comum, porque obriga a tratar troca de banner com a mesma urgência de um checkout quebrado.</p>
</details>

<details>
<summary>O que entra num acordo de SLA e tickets bem escrito?</summary>
<p>Três elementos: severidade (quantos níveis e o que define cada um), prazo (resposta e resolução por nível) e canal (onde o ticket nasce e como o cliente acompanha). Um bom acordo também define o que NÃO está coberto e o horário de atendimento. Sem esses limites, todo chamado vira crítico e o SLA perde sentido. O ticket é o instrumento que torna cada um desses pontos mensurável no dia a dia.</p>
</details>

## Próximos passos para estruturar seu suporte

SLA e tickets deixam de ser burocracia quando viram o sistema nervoso da agência: severidade clara, fila com relógio, monitoramento que abre chamado sozinho e manutenção automatizada que esvazia a fila na origem. Comece definindo três níveis de severidade e amarre cada um a um prazo realista antes de escolher qualquer plugin. Depois conecte o monitoramento de uptime, porque sem ele o SLA é uma promessa que só é testada quando já foi quebrada. Para continuar aprendendo a operar sites em escala, o <a href="https://full.services/academy/">FULL Academy</a> reúne os guias de gestão, manutenção e suporte WordPress em um só lugar.
