Contrato de SLA

Em vez de afirmações vagas como “o suporte técnico funciona bem”, um SLA estabelece limites claros: com que rapidez o prestador atende a uma solicitação, quanto tempo leva para resolver uma interrupção crítica e qual deve ser a porcentagem de tempo em que o serviço deve estar disponível (uptime).

Um SLA registra o acordo entre o prestador e o destinatário do serviço:

• prestador: o departamento de TI, uma empresa de terceirização, um provedor de serviços em nuvem, a gestão de instalações;
• beneficiário: uma unidade de negócios, um cliente corporativo, um usuário individual.

Um SLA raramente existe como um contrato jurídico independente. Geralmente, é um anexo a um contrato de prestação de serviços ou uma política interna para equipes de atendimento. A força de um SLA reside em sua mensurabilidade: cada parâmetro pode ser verificado por meio de registros e relatórios.

Tipos de SLA

Na prática de gerenciamento de serviços, existem três tipos principais de SLA em TI:

1. SLA baseado em serviço. Um único acordo para todos os usuários de um determinado serviço. Por exemplo, um SLA para e-mail corporativo: as regras são as mesmas para um gerente e para o CEO.
2. SLA baseado no cliente. Um acordo que abrange todos os serviços prestados a um cliente (ou departamento) específico. Por exemplo, um cliente VIP tem prazos de resposta a incidentes mais rigorosos do que os usuários do plano básico.
3. SLA multinível. Um formato mais complexo, dividido em níveis. Por exemplo: o nível corporativo (regras gerais para todos os funcionários), o nível do cliente (garantias adicionais para um departamento específico) e o nível do serviço (métricas específicas para um sistema ERP essencial para os negócios).

SLA, OLA e UC: qual é a diferença?

Na ITIL (IT Infrastructure Library), um Acordo de Nível de Serviço sempre vem acompanhado de dois outros tipos de acordo. Eles atuam em conjunto para abranger toda a cadeia de responsabilidades.

• SLA (Acordo de Nível de Serviço) — um acordo entre a TI e a empresa (ou entre um provedor e um cliente). O cliente se preocupa apenas com o resultado final estabelecido neste documento;
• OLA (Acordo de Nível Operacional) — um acordo entre equipes dentro da organização do provedor. Por exemplo, a primeira linha de suporte deve encaminhar um incidente complexo para a segunda linha em até 15 minutos, e a segunda linha deve responder em até uma hora. O cliente nunca tem acesso a esse documento, mas, sem cumprir seus OLAs, o provedor não pode cumprir o SLA;
• UC (Contrato de Base) — um contrato com um fornecedor externo ou subcontratado. Por exemplo, o SLA garante ao cliente que um servidor estará disponível, mas o próprio servidor é fornecido por um data center por meio de um UC. Os termos do UC não devem ser menos rigorosos do que os do SLA.

Por que você precisa de um SLA

A adoção de um acordo de nível de serviço resolve vários problemas críticos de negócios de uma só vez:

1. Gerenciamento de expectativas. Um SLA define claramente o que é considerado normal e descarta exigências exageradas.
2. Avaliação objetiva da qualidade. Com um SLA, a crítica “vocês trabalham muito devagar” torna-se construtiva: “este mês, vocês não cumpriram o tempo de resposta em 15 tickets de um total de 100”.
3. Priorização do trabalho. Os agentes da centralde atendimento sabem qual ticket deve ser resolvido primeiro. Um servidor fora do ar (prioridade crítica segundo o SLA) é consertado antes de uma impressora com defeito (baixa prioridade).
4. Redução de riscos. As penalidades estabelecidas no SLA motivam o provedor a manter a infraestrutura em funcionamento.

Quem utiliza os SLAs?

Historicamente, o termo surgiu no setor de TI (padrões ITIL/ITSM), mas hoje um acordo de nível de serviço é utilizado sempre que há um serviço interno ou externo:

• TI e telecomunicações: provedoresde nuvem (garantias de disponibilidade de servidores), desenvolvedores de software, equipes de suporte técnico;
• Terceirização B2B: serviçosde contabilidade , limpeza, segurança, logística;
• centros internos de serviços compartilhados: administraçãode RH (em quanto tempo o RH deve processar um pedido de licença), suporte jurídico (em quantos dias um advogado deve analisar um contrato).

Estrutura do SLA: o que um acordo inclui

Um documento bem redigido não deve deixar margem para ambiguidades. A estrutura padrão de um SLA inclui:

1. Definição do serviço. O que exatamente é fornecido? Uma descrição detalhada do serviço (por exemplo, “Suporte no local de trabalho”).
2. Horário de atendimento. Quando o serviço está disponível? (por exemplo, 24 horas por dia, 7 dias por semana, ou dias úteis das 9h às 18h).
3. Matriz de incidentes e prioridades. Como as solicitações são classificadas (de “Crítico” a “Baixo”).
4. Métricas-alvo. Númerosespecíficos : tempo de resposta, tempo de resolução, porcentagem de disponibilidade.
5. Responsabilidades das partes. O que o cliente deve fazer (por exemplo, conceder acesso em tempo hábil) e o que o prestador deve fazer.
6. Multas e incentivos. Multas por não cumprimento das métricas (geralmente uma porcentagem da taxa de serviço) e, com menos frequência, bônus por superá-las.
7. Procedimento de relatório e revisão. Com que frequência os relatórios do SLA são elaborados e em que condições o documento pode ser alterado.

Principais métricas de nível de serviço

A qualidade do serviço é controlada por meio de métricas do SLA. As mais comuns são:

• tempo de resposta: o tempo decorrido entre o envio de um ticket e o momento em que um agente o assume (ou responde ao cliente);
• tempo de resolução: o tempo que decorre desde a criação do ticket até a resolução completa do problema;
• MTTR (Tempo Médio de Recuperação/Resolução): o tempo médio para restaurar o serviço após uma falha;
• disponibilidade (uptime): a porcentagem de tempo em que o serviço está totalmente operacional (os famosos “noves”, por exemplo, 99,99%);
• FCR (Resolução no Primeiro Contato): a porcentagem de tickets que um agente resolve no primeiro contato, sem encaminhá-los para outras equipes de suporte.

Como redigir um SLA: passo a passo

Você pode redigir um SLA que realmente funcione, em vez de ficar acumulando poeira em uma gaveta, em cinco etapas.

Etapa 1. Defina seu catálogo de serviços. Faça uma lista completa do que você faz. Não escreva “Garantir as operações de TI”; escreva “Suporte a e-mail corporativo”, “Reparo de computadores”.

Passo 2. Priorize as solicitações. Descreva como um incidente crítico (o site está fora do ar) difere de uma solicitação de serviço (alguém precisa de um novo mouse).

Passo 3. Defina métricas realistas. Não estabeleça um tempo de resposta de 5 minutos se houver apenas um engenheiro de plantão. Baseie-se em dados históricos. As métricas devem ser mensuráveis e alcançáveis.

Passo 4. Chegue a um acordo sobre as responsabilidades. Discuta as penalidades com a empresa ou com o cliente. Elas devem ser proporcionais ao custo do serviço.

Passo 5. Configure as regras em sua central de atendimento. Um SLA é inútil se for monitorado por uma pessoa com um cronômetro. Todas as métricas devem ser monitoradas automaticamente em seu sistema de TI.

Como monitorar a conformidade com o SLA

O acompanhamento manual do desempenho do SLA (no Excel ou por e-mail) gera erros e disputas com o cliente. Para automatizar o processo, as organizações utilizam sistemas de central de atendimento com a prática de Gerenciamento de Nível de Serviço (SLM) integrada à sua arquitetura.

Nos sistemas de gerenciamento de serviços (por exemplo, o SimpleOne ITSM), as métricas são monitoradas automaticamente:

• indicadores configuráveis. O sistema faz mais do que apenas iniciar um cronômetro. Você define condições claras para quando o cronômetro deve começar, quando deve ser pausado (por exemplo, enquanto se aguarda a resposta do usuário) e quando deve parar;

• visualização por meio de widgets. Os agentes não precisam ficar lembrando dos prazos. Um widget dedicado, diretamente no formulário do ticket, mostra uma contagem regressiva em tempo real até o prazo final para cada métrica-alvo (SLO — Objetivos de Nível de Serviço);
• ações e escalações automatizadas. Se o tempo de resposta ou resolução se aproximar de um limite crítico (risco de violação do SLA), o sistema pode alterar automaticamente a prioridade do ticket, movê-lo para o topo da fila ou notificar o líder de turno para que ele possa intervir;
• um repositório único de contratos. Todos os requisitos e acordos aprovados (SLAs, OLAs, contratos subjacentes) são armazenados no sistema e vinculados a serviços específicos no portfólio de serviços. Isso elimina disputas: no final do mês, a plataforma gera relatórios transparentes para cada cliente com base em registros concretos do sistema;
• balanced scorecards com código de semáforo — uma ferramenta da plataforma SimpleOne para gerenciamento visual de KPIs e métricas. Ela permite criar painéis de resumo com resultados codificados por cores e identificar rapidamente desvios.

Erros comuns na implementação de SLAs

1. SLA apenas por ter um SLA. O acordo é redigido em linguagem jurídica densa e arquivado, enquanto o suporte funciona “como der na hora”.
2. Metas irrealistas (o SLA da melancia). O provedor prometeu 99,99% de tempo de atividade e resolução de incidentes em 10 minutos sem contar com a equipe ou a arquitetura necessárias para cumprir isso. Os relatórios estão todos “verdes” (a casca da melancia), enquanto os clientes estão furiosos (vermelhos por dentro).
3. Métricas desconexas do negócio. O SLA abrange a “disponibilidade do servidor”, mas não a “disponibilidade de cobrança”. O servidor está funcionando, mas os clientes não conseguem pagar. A empresa não se importa com o servidor; ela precisa do serviço.
4. Esquecer os OLAs e os UCs. Você prometeu resolver o problema do cliente em até 2 horas (SLA), mas o contrato do seu fornecedor externo exige apenas que ele substitua um disco rígido com falha em até 24 horas (UC). Você inevitavelmente não vai cumprir o prazo.

Resumo

O que é um SLA? É uma garantia de previsibilidade no relacionamento entre cliente e prestador de serviços.

Ter um documento acordado elimina a emoção das disputas: em vez de procurar alguém para culpar, as partes abrem a matriz de responsabilidades e analisam os números. No entanto, um SLA só funciona em conjunto com as ferramentas de automação certas — sem um sistema de ITSM, é praticamente impossível monitorar os compromissos em tempo real.