A reunião de revisão de Service Cloud quase sempre tem o mesmo gráfico: SLA prometido em 4 horas, SLA realizado em 14, com pico de 28 nas terças. A diretoria pergunta "por que o sistema não está cumprindo o que prometemos?". O time de TI tem a resposta certa, mas costuma ficar em silêncio: o sistema cumpre o que dá pra cumprir. O problema é que o número prometido nunca foi calculado — foi escolhido em reunião comercial, antes da operação ser medida.
SLA não é decoração no contrato. É promessa medida em capacidade. Esse texto é sobre o erro mais caro e mais comum de implantação de Service Cloud: configurar regras de SLA sem ter calculado a capacidade real do time que vai atender.
A genealogia do SLA fictício
Quase todo SLA mal calibrado em Service Cloud nasce do mesmo lugar: o comercial fechou um deal prometendo "atendimento em 4 horas" porque o concorrente prometia 6. Foi pro contrato. Time de operação descobriu seis meses depois. A configuração no Service Cloud reflete a promessa, não a realidade — Entitlements, Milestones, Escalation Rules tudo apontando pra uma meta que ninguém testou contra a capacidade.
A consequência tem três faces. Primeira: violação crônica de SLA. O dashboard fica vermelho permanente, todo mundo aprende a ignorar — e quando uma violação importante acontece, ela some no ruído. Segunda: time de atendimento sob pressão constante, com burnout previsível em 6–12 meses. Terceira: NPS que cai no segundo trimestre, sem explicação clara — porque cliente percebe SLA não cumprido como quebra de promessa, não como problema de configuração.
SLA mal calibrado polui o Service Cloud inteiro. Quando todo case está em violação, nenhum case está. O sistema vira semáforo perpetuamente quebrado.
O cálculo que ninguém faz antes
A conta pra calibrar SLA é razoavelmente simples, e quase ninguém faz antes da implantação. Cinco números bastam pra ter o piso.
- Volume médio diário de casos. Histórico de 3–6 meses de tickets que entraram (qualquer canal). Distribuído por hora do dia, dia da semana.
- Tempo médio de atendimento (TMA) por tipo. Não a média geral — média por categoria. Caso simples (10 min), caso médio (40 min), caso complexo (3h). Categorizar antes faz diferença de duas vezes no cálculo final.
- Tempo produtivo do atendente. Não 8 horas. Descontar treinamento, reunião, intervalo, ferramenta lenta, escalonamento que paralisa. Realista: 5–6 horas de trabalho efetivo por jornada.
- Pico vs. média. Operação dimensionada pela média quebra no pico. Calcular pico semanal/mensal e dimensionar pra cobrir 80–90% dos picos, não a média.
- % de casos que precisam escalonar. Casos que param na fila do nível 2/3 contam diferente — tempo de atendimento explode, e capacidade efetiva cai.
Com esses cinco, dá pra calcular capacidade efetiva por hora e SLA atingível por categoria. Tipicamente o número que sai é mais alto do que o prometido, e às vezes muito mais. Aceitar isso antes de implantar evita o resto.
Como configurar Service Cloud em cima de capacidade real
Quando o cálculo foi feito, Service Cloud entrega o que deve. Quatro decisões de configuração que importam.
SLA por categoria, não SLA único. Caso simples tem SLA de 2 horas. Caso médio, 8 horas. Caso complexo, 24 horas. Entitlements e Milestones suportam isso nativamente. Promessa única pra tudo é o caminho mais rápido pra falhar.
Roteamento que respeita skill, não só disponibilidade. Omni-Channel com queues por skill, não fila única. Atendente que sabe resolver o problema termina em 30 minutos; quem não sabe escalona em 2 horas. SLA por skill é mais realista que SLA por canal.
Escalation baseada em tempo e em sintoma. Não só "passou de X horas, escalona". Também "cliente respondeu duas vezes sem resolução, escalona". Essa segunda regra captura o caso ruim antes do SLA estourar — geralmente quando o atendente já entrou em ciclo improdutivo.
Dashboard de capacidade, não só de SLA. Service Cloud entrega dashboard executivo de capacidade em poucos cliques: casos abertos por atendente, idade média da fila, projeção de SLA na próxima hora. Esse painel ajuda gerente a redistribuir antes da violação — não depois.
A conversa difícil: renegociar SLA com o cliente
Quando o cálculo mostra que o SLA prometido é impossível, o caminho honesto é renegociar — não fingir que o sistema vai dar conta. A conversa funciona melhor quando segue três passos.
Mostrar o cálculo, não a desculpa. Cliente respeita número, não justificativa. Apresentar: "operamos com X atendentes, capacidade real de Y casos/dia, pico semanal de Z, SLA atingível em 90% dos casos é de W horas, não 4". Argumento numérico é difícil de refutar.
Oferecer SLA por categoria. Cliente raramente precisa de 4 horas em tudo. Precisa de 4 horas em casos críticos, e tolera 12 em rotineiros. SLA escalonado por severidade resolve a tensão entre custo e expectativa.
Vincular SLA mais agressivo a investimento. Se cliente de fato precisa de SLA agressivo geral, isso muda o dimensionamento da operação — mais atendentes, ferramenta especializada, Agentforce absorvendo o que pode ser automatizado em atendimento. Aí muda o preço. SLA é custo, não promessa grátis.
Onde Service Cloud não resolve
Vale dizer o que SLA bem configurado não conserta. Não conserta processo torto — atendente sem autoridade pra resolver continua escalonando, como já argumentei sobre processo antes da ferramenta. Não conserta produto ruim — se o cliente tem 30% de chamados sobre o mesmo bug, SLA mais apertado não muda o número de chamados, só os faz chegar mais rápido. Não substitui IA quando o volume justifica — em operação grande, agente automatizado em casos onde dado é suficiente absorve 30–50% do volume e libera capacidade.
Service Cloud bem implantado é uma das melhores plataformas de atendimento do mercado. Mas é plataforma — e plataforma exige número antes de promessa. Empresa que aceita essa lógica entrega SLA confiável e cliente confiante. Empresa que continua escolhendo SLA em reunião comercial vai gastar os próximos dois anos explicando dashboard vermelho.