A evolução do SLA: do tempo de resposta ao impacto no negócio

Service Delivery: quando o SLA deixa de ser suficiente

O serviço pode cumprir o prazo e ainda assim não entregar valor

Durante muito tempo, o Service Level Agreement (SLA), ou Acordo de Nível de Serviço, foi uma das principais referências para avaliar a qualidade das entregas do Service Delivery: tempo de resposta, tempo de resolução, percentual de chamados atendidos dentro do prazo, cumprimento do acordo, data de entrada versus data de entrega. A lógica é simples e necessária, pois se existe um serviço, é preciso estabelecer um nível de serviço.

O problema começa quando o SLA deixa de ser uma medida de desempenho e passa a ser a definição de desempenho, porque uma operação pode cumprir 95% dos seus SLAs e ainda assim oferecer uma experiência ruim. Pode responder rapidamente à solicitação errada. Pode encerrar um chamado sem resolver sua causa. Pode cumprir o prazo enquanto o usuário precisa abrir três novos chamados para chegar à solução. Pode atingir a meta operacional e continuar gerando fricção para o negócio.

Essa é a questão que o Service Delivery precisa enfrentar: estamos medindo a velocidade com que entregamos o serviço, ou o valor que o serviço efetivamente produz?

O SLA é importante, mas mede apenas uma parte da história

O Service Level Agreement nasceu para criar clareza, definir expectativas, estabelecer responsabilidades e dar previsibilidade à relação entre quem presta e quem recebe um serviço. Nesse sentido, o SLA continua indispensável, já que uma operação sem níveis de serviço definidos dificilmente consegue administrar capacidade, priorização, qualidade e governança. Mas o SLA responde principalmente a uma pergunta: entregamos o serviço dentro do parâmetro combinado? Ele não necessariamente responde se o problema foi resolvido, se a experiência foi boa ou se aquele contato era sequer necessário. A diferença parece pequena, mas operacionalmente é enorme.

Quando o indicador se transforma no objetivo, o comportamento da operação se adapta a ele. Se a meta é responder em quatro horas, a organização aprende a responder em quatro horas. Se a meta é encerrar 90% dos chamados em determinado prazo, a organização aprende a encerrar chamados dentro daquele prazo, mas encerrar não é necessariamente resolver, e responder não é necessariamente atender à necessidade.

Essa distinção importa porque muitos serviços atravessam processos, sistemas e áreas diferentes. Uma solicitação de alteração cadastral pode depender de dados; uma dúvida sobre remuneração pode envolver política, folha e gestor; um onboarding pode envolver RH, TI, facilities, segurança e liderança; uma movimentação internacional pode envolver payroll, mobilidade, benefícios, jurídico e compliance. O usuário não enxerga esses silos. Ele enxerga apenas se o problema foi resolvido.

A experiência não respeita o organograma

Esse é um dos principais desafios do Service Delivery contemporâneo. A organização pode estar estruturada em HRBP, centros de excelência, Shared Services, payroll, talent e outras áreas, mas a experiência do usuário não acontece em caixas organizacionais. Ela acontece em uma jornada.

O usuário não pensa "agora vou entrar no processo de benefícios"; ele pensa "vou ter um filho". Não pensa "vou abrir uma solicitação de onboarding"; pensa "começo na empresa na segunda-feira". Não pensa "vou acessar o processo de mobilidade"; pensa "vou trabalhar em outro país". Essas situações atravessam processos, e por isso o Service Delivery precisa olhar para momentos e jornadas, não apenas para transações.

A Mercer | Leapgen vem apontando justamente essa transformação. Em seu estudo de HR Service Delivery, com mais de 300 organizações, a consultoria identifica a crescente importância da workforce experience e argumenta que os modelos tradicionais, como sistemas de ticketing adaptados para RH, atendimento de Tier 1 e estruturas centradas em call center, estão se tornando insuficientes; a recomendação é redesenhar o modelo a partir das interações desejadas pela força de trabalho (Mercer | Leapgen). A McKinsey chega a uma conclusão semelhante em sua pesquisa sobre novos modelos operacionais de RH: empresas mais avançadas passaram a organizar serviços em torno da jornada do colaborador e a atribuir responsabilidade de ponta a ponta a determinados serviços, reduzindo handoffs e fragmentação (McKinsey, 2025). Quanto mais handoffs existem, maior a probabilidade de atraso, retrabalho, perda de informação e frustração. O serviço precisa ser desenhado a partir da experiência, não a partir do organograma.

O chamado não deveria ser a unidade básica de valor

O chamado é uma unidade operacional, mas o que o usuário procura não é um chamado: é uma resposta, uma solução, uma decisão, uma orientação, uma ação, ou, idealmente, não precisar abrir um chamado.

Imagine uma operação que recebe 10 mil solicitações por mês e responde 98% dentro do SLA. Parece excelente, mas e se 30% dessas solicitações forem recorrentes? E se metade delas puder ser eliminada por uma mudança de processo? E se parte significativa pudesse ser resolvida por autosserviço? E se os usuários estiverem abrindo novos chamados porque a primeira resposta não resolveu a questão? Nesse caso, aumentar a produtividade do atendimento não resolve o problema. É preciso reduzir a necessidade de atendimento. Essa é a mudança de mentalidade de administrar chamados para eliminar fricção.

Uma operação madura deveria olhar para a demanda evitável, não apenas para o volume de demandas. Se milhares de colaboradores procuram o RH todos os anos para esclarecer a mesma regra, o problema pode não ser de atendimento: pode ser que a regra seja complexa, o processo seja ruim, a comunicação não funcione, o sistema não ofereça a informação no momento certo, ou o desenho organizacional tenha criado uma dependência desnecessária do RH. Cada interação contém informação. Cada dúvida recorrente revela uma fricção. Cada escalonamento revela uma falha potencial. Cada exceção revela uma oportunidade de redesenho. Por isso, o Service Delivery não deveria ser apenas uma função de resposta; deveria ser uma fonte de inteligência sobre a operação de RH, usando dados não apenas para administrar a operação, mas para redesenhá-la.

Da eficiência para a efetividade

A evolução do Service Delivery pode ser entendida em três níveis: eficiência, efetividade e experiência. A KPMG sintetiza essa evolução em uma estrutura particularmente útil para modelos de próxima geração: Return on Efficiency, Return on Effectiveness e Return on Experience (KPMG, 2024). A consultoria argumenta que modelos de próxima geração precisam ir além de service agreements e buscar resultados de negócio, combinando eficiência, efetividade e experiências superiores (KPMG, 2024).

Essa estrutura muda a forma de olhar o indicador. Um SLA de 95% dos chamados respondidos dentro do prazo é um resultado bom, mas leva a outras perguntas: quantos foram efetivamente resolvidos no primeiro contato (resolução?); quantos voltaram a acontecer (recorrência)?; quanto esforço o usuário precisou fazer para obter a solução (esforço)?; como ele avaliou a interação (experiência)?; e, por fim, por que esse contato aconteceu (causa-raiz)? Essa última pergunta é frequentemente a mais valiosa, porque leva o Service Delivery para além do atendimento: leva para processo, tecnologia, política e Operating Model.

Talvez a evolução mais importante seja linguística. O Service Delivery tradicional pergunta "cumprimos o SLA?". O mais maduro pergunta "qual resultado produzimos?". A KPMG, ao discutir o next-generation service delivery model, destaca que a transformação deve buscar business outcomes, e não apenas service agreements (KPMG, 2024). A Mercer também vem defendendo uma mudança do modelo operacional de RH orientada por resultados, apontando que a introdução de GenAI e outras tecnologias vai forçar os modelos de atendimento em camadas a evoluir de forma radical, e que organizações com infraestrutura habilitadora mais forte estarão em melhor posição para aproveitar essas oportunidades (Mercer, 2024). Quando o resultado é o ponto de partida, a pergunta deixa de ser "quem é responsável por esta etapa?" e passa a ser "quem é responsável pelo resultado de ponta a ponta?".

O indicador precisa acompanhar a transformação

Se o Service Delivery mudou, os indicadores também precisam mudar. O SLA continua fazendo parte da arquitetura, mas passa a ocupar o lugar que realmente lhe pertence: uma dimensão do desempenho, não o desempenho inteiro. Uma arquitetura mais completa poderia combinar: