A Resposta Concisa
O Omni-Channel não é um mecanismo de distribuição, mas sim um modelo de capacidade. Ele faz uma única pergunta a cada momento: qual a carga de trabalho que este agente consegue suportar agora? Se a resposta a essa pergunta estiver incorreta – por exemplo, se um chat e um e-mail tiverem o mesmo peso –, o roteamento funcionará exatamente como configurado e prejudicará o serviço.
Portanto, a ordem de trabalho é: primeiro o modelo de capacidade e pesos, depois as habilidades, em seguida os Entitlements e Milestones, e só no final as automações de escalonamento.
O Modelo de Capacidade: O Ponto Que Define Tudo
O Omni-Channel atribui a cada agente uma "cota de trabalho" (Capacidade) e um peso a cada item de trabalho. Um contact center que define um peso uniforme para todos os canais obterá um dos dois resultados: agentes de chat sobrecarregados, ou agentes que tratam e-mails parecendo ocupados enquanto estão disponíveis.
Um ponto de partida razoável para calibração:
| Tipo de Trabalho | Característica | Peso Relativo Recomendado |
|---|---|---|
| Chamada Telefônica | Síncrona completa | Ocupa toda a capacidade |
| Chat ao Vivo | Síncrono com pequenas pausas | Alto, geralmente 2-3 simultâneos no máximo |
| E-mail / Formulário | Assíncrono | Baixo |
| Case Aguardando Cliente | Inativo | Zero - deve liberar capacidade |
A última linha é a mais comum nos erros: um Case que espera pelo cliente e continua a ocupar capacidade faz com que os agentes pareçam ocupados, embora não tenham trabalho ativo.
Habilidades: Menos É Mais
O Roteamento Baseado em Habilidades (Skills-Based Routing) parece uma melhoria óbvia, mas na prática é a fonte mais comum de solicitações travadas. Quanto mais requisitos de habilidades são adicionados, maior a chance de que não haja um agente disponível que atenda a todos eles.
Três regras para evitar isso: definir habilidades apenas quando a ausência delas realmente impede o atendimento; definir um nível de Fallback para cada requisito, que é ativado após um tempo de espera definido; e verificar mensalmente quantas solicitações foram alocadas via Fallback – uma porcentagem alta indica que o modelo não está alinhado com a equipe do contact center.
Entitlements e Milestones: Do Compromisso ao Mecanismo
Um SLA que aparece apenas em um relatório é um registro pós-evento. Entitlements e Milestones o transformam em um mecanismo ativo:
- Entitlement define qual cliente tem direito a qual nível de serviço – geralmente um padrão e algumas exceções contratuais.
- Milestone define os pontos de tempo medidos: primeira resposta, atualização periódica, resolução.
- Business Hours determinam quando o relógio está em execução e devem ser configurados para cada fuso horário e para cada canal separadamente.
- Stopped Time congela o cronômetro enquanto aguarda o cliente – sem isso, as métricas penalizam o contact center pelo comportamento do cliente.
- As Ações do Milestone geram alertas e escalonamentos antes da violação, geralmente em torno de 75-80% do tempo.
A regra principal: se o primeiro alerta chegar após a violação, o mecanismo está medindo, não gerenciando.
As decisões fundamentais sobre a definição do Case e do relógio de SLA são detalhadas em Implementação do Service Cloud.
Como Saber Se o Modelo Não Está Aguentando
Cinco sinais precoces, antes que as métricas mensais revelem um problema:
- Alta porcentagem de alocações via Fallback – as habilidades não correspondem à equipe.
- Solicitações na fila de alocação por mais de alguns minutos – falta de capacidade ou regra de Overflow ausente.
- Agentes relatando sobrecarga, enquanto o relatório de capacidade mostra disponibilidade – pesos incorretos.
- Concentração incomum de violações de SLA em um horário fixo do dia – problema de equipe, não de roteamento.
- Alta taxa de solicitações alocadas e imediatamente abandonadas – agentes recusando trabalho que não lhes convém.
Medição Contínua
| Métrica | O Que Ela Revela |
|---|---|
| Tempo na fila de alocação | Se o modelo encontra um agente a tempo |
| Utilização média da capacidade | Se os pesos são realistas |
| Violações por Milestone | Onde exatamente o SLA é quebrado |
| Taxa de escalonamentos evitados | Se o alerta precoce está funcionando |
| Diferenças nas violações entre canais | Se um determinado canal está sendo prejudicado no roteamento |
Ordem de Implementação
Ative um canal com um único Entitlement e sem habilidades, calibre os pesos com dados reais por duas semanas, e só então adicione um segundo canal e habilidades. A ativação completa em um único dia impede a capacidade de identificar qual componente causou a sobrecarga e geralmente termina com o desligamento do roteamento e o retorno às filas manuais.
Resumo
O Omni-Channel é um modelo de capacidade, não de distribuição, e o SLA é um mecanismo de alerta, não um relatório. Esses dois princípios determinam se o contact center funcionará de acordo com o sistema ou encontrará maneiras de contorná-lo – e a diferença é revelada já na primeira semana de operação.