Toda equipe de operações deve ter indicadores que determinem o nível atual do serviço. No entanto, quando o seu time se preocupa apenas em “medir”, pode acabar não entendendo o que é mais importante para dar o sonhado “próximo passo”, perdendo-se em métricas e análises improdutivas.

Neste artigo, vamos entender o porquê do SLA (Service Level Agreement) ser determinante para a identificação dos gargalos no atendimento e como ele se relaciona ao controle de filas.

O SLA no atendimento

Para uma equipe de operações que receba demandas de clientes internos e/ou externos, o SLA geralmente significa uma métrica de tempo limite para resolução dos chamados abertos, definido a partir da perspectiva do cliente (afinal, é um acordo).

Existem vários “tipos” de SLA, por exemplo: o prazo até uma primeira resposta, o tempo total de solução, ou o tempo de espera do solicitante. Além disto, o SLA pode ser diferente dependendo da criticidade e categoria do chamado.

Na prática, softwares de help desk (como o Desk Manager) deixam a visão de SLA muito clara e, a partir do momento em que as regras são configuradas, não é necessário se preocupar muito com a medição de tempo: o próprio sistema calcula os prazos de cada item.

O “pulo do gato”, na verdade, estará na sua capacidade de utilizar estes dados para gerenciar o seu time obtendo o máximo de produtividade e, consequentemente, diminuindo o tempo (e custo) de resolução de cada chamado. É aqui que vamos introduzir o processo orientado a filas.

A importância das filas para o seu processo

A sua equipe de atendimento, provavelmente, recebe uma variedade de chamados. Esses chamados diferem com relação ao tipo de solicitação, funcionalidade do produto ou serviço, prioridade de atendimento ou criticidade, tipo de tratativa necessária.

A maioria dos processos é dividida, portanto, em “níveis” de atendimento, como N1, N2 e N3, ou subprocessos como triagem, respostas simples, resolução de bugs e etc.

Você já sabe que cada uma destas “categorias” demandará uma abordagem diferente. Será que este chamado deve ser atendido imediatamente, ou será que devo priorizar outro item? E o que determinará a ordem de atendimento? O SLA é muito importante para decisões no seu dia-a-dia: o que tem prazo menor, tende a ser prioritário e (provavelmente) será atendido antes.

Mas será que não devo levar nenhum outro fator em consideração para direcionar os esforços do meu time? Se eu tenho um item com SLA menor mas de rápida resolução, e outro com um pouco mais de prazo mas que demora mais, será que não seria melhor, de modo a atender aos dois SLAs com o menor risco possível, tratar o de maior touch time primeiro? E como eu encontro estes pontos críticos no dia-a-dia?

É aqui que entram os processos orientados às filas. Através do monitoramento do tamanho de cada fila, identificam-se os subprocessos que representam o maior risco, em um determinado momento.

Cada nível do seu atendimento, ou subprocesso, contará com sua respectiva fila. Uma fila para triagem, para N1, para N2 e para N3, ou então uma fila para cada categoria de chamado.

É importante conhecer algumas das características daquele subprocesso específico, como quanto tempo, em média, um item daquela categoria demora para ser concluído, ou então, qual é a criticidade, ou qual é o prazo (SLA) de entrega para itens daquela fila. Somente assim, será possível definir qual é o tamanho “ideal” de estoque para esta solicitação.

Considere um chamado de dúvida simples. Não é legal deixar seu cliente esperando muito tempo por um esclarecimento, então este chamado costuma ter um SLA de primeira resposta menor. No entanto, esta categoria de chamado tipicamente não exige tanto tempo de solução.

Suponha, neste caso, que esteja definido um SLA de 2h, mas um tempo total de solução (touch time + tempo de espera) de 30 min. Se houver um único agente respondendo a esta questão, em tempo integral, fica claro que um tamanho de fila maior do que quatro chamados representa risco: um quinto chamado corre sério risco de não ser respondido dentro de 2h (5 x 30 min = 2h30).

Você já deve ter entendido nosso ponto: considerando alguns fatores típicos do subprocesso e seu SLA, é possível calcular o tamanho de fila máximo.

Aplicando este cálculo a todas as categorias de chamados, você poderá trabalhar com sistemas de alerta e alocar mais agentes em processos mais críticos ou sobrecarregados. Isto é essencial em equipes que não controlam a quantidade e os chamados recebidos a cada momento, como é o caso de suporte.

Analisando a frequência e duração dos alertas, você identificará quais filas representam os gargalos do seu processo, ou seja: qual subprocesso está trabalhando no limite da sua operação, e poderá trabalhar na melhoria direcionada a este caso.

Como nos ensina a “teoria das restrições”, trabalhar no gargalo é a forma mais direta de diminuir o lead time de um processo, ou o tempo médio exigido de ponto a ponta.

Uma última observação: perceba que quanto mais precisamente você identificar os tempos médios de resolução de uma fila e quanto mais precisa for a divisão do seu processo em categorias de chamados, mais relevantes serão as variáveis consideradas e mais próximo da realidade estará o seu modelo. Ou seja: melhor você terá identificado o seu problema (gargalo), e mais eficiente será sua tratativa.