Como desenhar SLAs de atendimento com bot + humano

Um SLA unico assume que um unico ator e responsavel do inicio ao fim. No atendimento hibrido isso e falso: a responsabilidade troca de mao varias vezes. O bot atende, tenta resolver, transfere para a fila humana, o agente responde, pede um dado ao cliente e espera. Se o relogio do SLA corre o tempo todo, o time leva a culpa por periodos em que a bola nem estava com ele. O relogio precisa pausar e contar por estagio, seguindo quem de fato deve agir naquele momento. Sem isso, voce penaliza o agente pelo tempo que o cliente demorou para responder e premia uma operacao que parece rapida so porque o bot fecha ticket sem resolver nada.

Em vez de um numero, trabalhe com um pequeno conjunto de SLAs que medem momentos diferentes da jornada. Cada um responde a uma pergunta distinta e o bot influencia cada um de um jeito proprio.

O erro comum e otimizar so o first response time. Com bot, ele fica lindo e esconde o que importa: o time to human e o resolution time. Meca os tres juntos, senao o bot vira uma maquina de responder rapido sem resolver.

Modele o ticket como uma maquina de estados. Cada estado define de quem e a responsabilidade e, portanto, se o relogio do SLA de resolucao conta ou pausa. A regra e simples: o relogio so conta quando a bola esta com o time. Quando o bot esta no controle ou quando se espera o cliente, o relogio do time pausa.

            [Bot ativo]
          relogio: nao conta p/ time
                |
         pede humano | resolve
                v          \
         [Fila humana]      v
       relogio: CONTA    [Resolvido]
                |
          agente assume
                v
       [Em atendimento]
         relogio: CONTA
            /        \
   pede dado          resolve
        v                v
[Aguardando cliente]  [Resolvido]
 relogio: PAUSA
        |
  cliente responde
        v
  volta p/ Fila humana ou Em atendimento

Os estados que mais geram disputa sao "bot ativo" e "aguardando cliente". Nos dois, o tempo nao deve pesar contra o agente, porque a acao depende do bot ou do proprio cliente. Ja "fila humana" e "em atendimento" sao integralmente do time e ali o relogio corre cheio.

Quando varios tickets esperam um agente, a ordem importa tanto quanto a velocidade. Atender por ordem de chegada e simples, mas deixa caso urgente atras de caso trivial e estoura SLA sem necessidade. Combine criterios.

• Por prioridade: cliente VIP, plano pago ou assunto critico (cobranca, falha de pagamento) sobem na fila.
• Por tempo de espera: dentro da mesma prioridade, quem espera ha mais tempo e atendido primeiro, evitando inanicao.
• Por SLA em risco: tickets cujo tempo restante ate estourar o SLA esta baixo ganham boost automatico, mesmo com prioridade media.
• Por esforco do handoff: ticket que o bot ja qualificou e resumiu pode ser resolvido rapido e desafogar a fila.

Uma fila madura mistura esses sinais num score unico. O SLA em risco e o desempate mais importante: nao adianta priorizar VIP se um caso comum vai estourar em dois minutos e manchar a metrica do dia.

O calculo justo soma apenas o tempo em que o ticket esteve sob responsabilidade do time. A funcao abaixo percorre os intervalos de estado e acumula so os que contam, ignorando bot ativo e aguardando cliente.

// sla.js
// Estados que contam para o SLA de resolucao do time humano.
const ESTADOS_QUE_CONTAM = new Set(['fila_humana', 'em_atendimento']);

// Recebe os segmentos de estado do ticket, na ordem em que ocorreram.
// Cada segmento: { estado, inicio, fim } com timestamps em ms.
// Retorna o tempo (ms) sob responsabilidade do time, descontando
// bot ativo e aguardando cliente.
function tempoSobResponsabilidadeDoTime(segmentos) {
  return segmentos.reduce((total, seg) => {
    if (!ESTADOS_QUE_CONTAM.has(seg.estado)) return total;
    const fim = seg.fim ?? Date.now(); // segmento aberto: conta ate agora
    return total + Math.max(0, fim - seg.inicio);
  }, 0);
}

// Verifica se o ticket cumpriu o SLA de resolucao.
function cumpriuSla(segmentos, slaMs) {
  return tempoSobResponsabilidadeDoTime(segmentos) <= slaMs;
}

// Exemplo: SLA de 30 min (1800000 ms).
const segmentos = [
  { estado: 'bot_ativo',          inicio: 0,       fim: 120000 },  // 2 min, nao conta
  { estado: 'fila_humana',        inicio: 120000,  fim: 300000 },  // 3 min, conta
  { estado: 'em_atendimento',     inicio: 300000,  fim: 600000 },  // 5 min, conta
  { estado: 'aguardando_cliente', inicio: 600000,  fim: 4200000 }, // 60 min, NAO conta
  { estado: 'em_atendimento',     inicio: 4200000, fim: 4500000 }, // 5 min, conta
];

tempoSobResponsabilidadeDoTime(segmentos); // 780000 ms = 13 min
cumpriuSla(segmentos, 1800000);            // true: 13 min <= 30 min

module.exports = { tempoSobResponsabilidadeDoTime, cumpriuSla };

Repare que o relogio bruto marcaria 75 minutos, mas o tempo justo e 13. Sem a pausa, esse ticket estouraria o SLA por culpa do cliente que sumiu por uma hora. O segredo e guardar cada transicao de estado com timestamp para reconstruir os segmentos depois.

Um numero agregado de resolution time esconde de quem foi a demora. Separe o tempo por fase para que cada area olhe a sua. Assim voce melhora o bot, dimensiona o time e cobra o cliente sem injusticas.

• Tempo de bot: quanto o ticket passou em bot ativo. Mede se o bot resolve ou so empurra.
• Tempo de fila: quanto esperou na fila humana antes de um agente assumir. Mede dimensionamento do time.
• Tempo de humano: quanto durou o atendimento ativo do agente. Mede a produtividade real, e o unico que pesa no SLA dele.
• Tempo aguardando cliente: quanto ficou parado esperando resposta. Nunca entra no SLA do time, mas ajuda a entender resolucao lenta.

Com essa separacao, fila alta vira problema de capacidade (contrate ou ajuste turnos), tempo de humano alto vira problema de treino ou ferramenta, e tempo de bot alto sem resolucao vira problema de fluxo do bot. Cada um responde pelo que controla, e a conversa de melhoria deixa de ser briga sobre um numero unico.