Como desenhar SLAs de atendimento com bot + humano

Um SLA único assume que um único ator é responsável do início ao fim. No atendimento híbrido isso é falso: a responsabilidade troca de mão várias vezes. O bot atende, tenta resolver, transfere para a fila humana, o agente responde, pede um dado ao cliente e espera. Se o relógio do SLA corre o tempo todo, o time leva a culpa por períodos em que a bola nem estava com ele. O relógio precisa pausar e contar por estágio, seguindo quem de fato deve agir naquele momento. Sem isso, você penaliza o agente pelo tempo que o cliente demorou para responder e premia uma operação que parece rápida só porque o bot fecha ticket sem resolver nada.

Em vez de um número, 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 próprio.

O erro comum é otimizar só o first response time. Com bot, ele fica lindo e esconde o que importa: o time to human e o resolution time. Meça os três juntos, senão o bot vira uma máquina de responder rápido sem resolver.

Modele o ticket como uma máquina de estados. Cada estado define de quem é a responsabilidade e, portanto, se o relógio do SLA de resolução conta ou pausa. A regra é simples: o relógio só conta quando a bola está com o time. Quando o bot está no controle ou quando se espera o cliente, o relógio do time pausa.

            [Bot ativo]
          relógio: não conta p/ time
                |
         pede humano | resolve
                v          \
         [Fila humana]      v
       relógio: CONTA    [Resolvido]
                |
          agente assume
                v
       [Em atendimento]
         relógio: CONTA
            /        \
   pede dado          resolve
        v                v
[Aguardando cliente]  [Resolvido]
 relógio: PAUSA
        |
  cliente responde
        v
  volta p/ Fila humana ou Em atendimento

Os estados que mais geram disputa são "bot ativo" e "aguardando cliente". Nos dois, o tempo não deve pesar contra o agente, porque a ação depende do bot ou do próprio cliente. Já "fila humana" e "em atendimento" são integralmente do time e ali o relógio corre cheio.

Quando vários tickets esperam um agente, a ordem importa tanto quanto a velocidade. Atender por ordem de chegada é simples, mas deixa caso urgente atrás de caso trivial e estoura SLA sem necessidade. Combine critérios.

• Por prioridade: cliente VIP, plano pago ou assunto crítico (cobrança, falha de pagamento) sobem na fila.
• Por tempo de espera: dentro da mesma prioridade, quem espera há mais tempo é atendido primeiro, evitando inanição.
• Por SLA em risco: tickets cujo tempo restante até estourar o SLA está baixo ganham boost automático, mesmo com prioridade média.
• Por esforço do handoff: ticket que o bot já qualificou e resumiu pode ser resolvido rápido e desafogar a fila.

Uma fila madura mistura esses sinais num score único. O SLA em risco é o desempate mais importante: não adianta priorizar VIP se um caso comum vai estourar em dois minutos e manchar a métrica do dia.

O cálculo justo soma apenas o tempo em que o ticket esteve sob responsabilidade do time. A função abaixo percorre os intervalos de estado e acumula só 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 relógio bruto marcaria 75 minutos, mas o tempo justo é 13. Sem a pausa, esse ticket estouraria o SLA por culpa do cliente que sumiu por uma hora. O segredo é guardar cada transição de estado com timestamp para reconstruir os segmentos depois.

Um número agregado de resolution time esconde de quem foi a demora. Separe o tempo por fase para que cada área olhe a sua. Assim você melhora o bot, dimensiona o time e cobra o cliente sem injustiças.

• Tempo de bot: quanto o ticket passou em bot ativo. Mede se o bot resolve ou só 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, é o único que pesa no SLA dele.
• Tempo aguardando cliente: quanto ficou parado esperando resposta. Nunca entra no SLA do time, mas ajuda a entender resolução lenta.

Com essa separação, 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 resolução vira problema de fluxo do bot. Cada um responde pelo que controla, e a conversa de melhoria deixa de ser briga sobre um número único.