Como este tema funciona na sua empresa
Geralmente usam apenas SLA com fornecedor externo. OLA interno é informal (não documentado). UC com terceiros é raro. XLA não existe. Desafio: não sabem que precisam de OLA para suportar SLA externo. Abordagem: introduzir OLA simples entre times internos antes de assinar SLA com fornecedor (melhora chances de cumprimento).
Usam SLA com fornecedor, começam estruturar OLA interno. UC aparece em contratos com subcontratados. XLA em consideração (ferramentas de monitoramento de experiência). Desafio: garantir cascata (SLA?OLA?UC). Abordagem: mapear cadeia de dependências de SLAs, definir OLAs para cada camada. UC com fornecedor de infraestrutura deve ser melhor que OLA que oferece ao cliente.
Gestão sofisticada de SLA/OLA/UC em carteira. XLA em uso para serviços críticos. Desafio: orquestração de múltiplas cadeias. Abordagem: framework integrado com dashboards que mostram cascata e impactos. Cada SLA ? múltiplos OLAs ? múltiplos UCs. XLA correlacionado com SLA técnico.
SLA, OLA, UC e XLA são instrumentos distintos de gestão de serviço em TI: SLA (Service Level Agreement) com cliente externo; OLA (Operational Level Agreement) entre times internos; UC (Underpinning Contract) com fornecedor de terceiro; XLA (Experience Level Agreement) focado em experiência do usuário final. Cada um tem propósito, escopo e audiência diferentes, mas trabalham em cascata[1].
Definições: SLA vs OLA vs UC vs XLA
SLA (Service Level Agreement): acordo formal com cliente externo sobre nível mínimo de desempenho do serviço. Audiência: cliente. Penalidades: financeiras (desconto em fatura). Exemplo: "99,9% disponibilidade". OLA (Operational Level Agreement): acordo entre times internos para suportar um SLA externo. Audiência: times internos. Penalidades: bônus/avaliação (não financeiras). Exemplo: "infraestrutura 99,95% uptime". UC (Underpinning Contract): contrato com fornecedor de terceiro que suporta um SLA ou OLA anterior. Audiência: fornecedor externo. Penalidades: contratuais (penalidade em contrato). Exemplo: "fornecedor de cloud 99,99% SLA". XLA (Experience Level Agreement): acordo focado não em uptime técnico, mas em experiência do usuário final. Audiência: usuários finais (indiretamente). Penalidades: reputação, churn. Exemplo: "tempo de carregamento <2s".
Relação de cascata: cada SLA requer OLAs + UCs
SLA externo 99,9% com cliente impõe: OLA1 infraestrutura 99,95%, OLA2 suporte 99,95%, UC fornecedor cloud 99,99%. Por quê? SLA externo é promessa ao cliente. Para cumprir, precisa de suporte interno (OLA) E suporte de fornecedor (UC). Se qualquer um falha, SLA falha. Exemplo: "SLA 4h tempo de resolução" depende de: (1) OLA resposta suporte 15 min. (2) OLA diagnóstico infraestrutura 60 min. (3) UC resolução fornecedor 180 min. Total: 4h. Se UC com fornecedor é 5h, então OLA deve ser <180 min para fechar no prazo (cascata ao contrário). Comunicação clara entre camadas é crítica.
Diferenças de audiência, formalidade e consequência
Audiência: SLA = cliente/contrato; OLA = times internos; UC = fornecedor de fornecedor; XLA = usuários finais. Formalidade: SLA e UC = contrato assinado (legal); OLA = memorando (menos formal); XLA = pode ser informal (baseado em dados de RUM). Penalidades: SLA e UC = financeiras/legais; OLA = bônus/avaliação; XLA = reputação/satisfação. Medição: SLA = técnico (uptime%); OLA = técnico + operacional; UC = técnico (depende do contrato); XLA = experiência (latência, taxa de erro). Renegociação: SLA = anual/bienal (estável); OLA = trimestral (flexível); UC = anual (depende de SLA que apoia); XLA = conforme necessidade (baseado em dados RUM).
Típico: SLA externo (99,9%) + informal OLA interno (infraestrutura "tenta fazer 99,95%"). Sem UC formalizado (fornecedor cloud é apenas outsourcing). Sem XLA (não medem experiência). Risco: se fornecedor falha, pequena empresa não tem proteção contratual (UC). Recomendação: começar com contrato claro com fornecedor (UC).
SLA externo 99,9%, OLA interno 99,95%, UC com fornecedor 99,99%. Documentado. Cascata clara. XLA em piloto (1-2 aplicações críticas). Dashboard simples mostra: SLA status, OLAs status, UC status. Revisão: trimestral de SLA/OLA, anual de UC. Ação: se OLA em risco, escalar para aumentar recursos. Se UC em risco, contato com fornecedor para remediação.
Framework integrado: múltiplos SLAs (por negócio/produto) ? múltiplos OLAs ? múltiplos UCs. XLA em uso (RUM contínuo). Dashboard executivo mostra cascata completa. Automação: se UC em risco, alerta automático para OLA. Se OLA em risco, alerta para SLA. Correlação SLA-OLA-UC-XLA: quando SLA violado, qual camada falhou? Relatório detalhado.
XLA como evolução: quando SLA técnico não reflete realidade
Quando implementar XLA: quando SLA técnico não reflète experiência real. Exemplo: uptime 99,9% mas usuários reclamam (lentidão). Solução: adicionar XLA "tempo de carregamento <2s". XLA é complemento de SLA, não substituição. Ambos necessários. SLA técnico = fundação (sistema precisa estar "up"). XLA = qualidade (sistema precisa ser rápido/responsivo). Tendência: XLA crescendo em organizações que focam em experiência de cliente (fintech, e-commerce, SaaS). Para TI tradicional (infraestrutura), SLA técnico continua dominante.
Diferença prática: quem liga quem em cadeia de responsabilidade
SLA liga você (TI) ao cliente. OLA liga você (TI) à sua infraestrutura (teams internos). UC liga você (TI) ao fornecedor de infraestrutura. XLA liga você (TI) ao usuário final (indiretamente). Cadeia: Cliente ? SLA ? TI ? OLA ? Infraestrutura ? UC ? Fornecedor. E: TI ? XLA ? Usuário final (via RUM). Responsabilidade: "cliente está em pânico, SLA foi violado, quem falhou?" Rastreamento via cascata: SLA violado ? qual OLA falhou? OLA falhou ? qual UC falhou? UC falhou ? qual fornecedor falhou? Comunicação clara na cadeia é essencial.
Sinais de que você precisa estruturar SLA/OLA/UC/XLA
Se você reconhece três ou mais, comece estruturação agora.
- Tem SLA com cliente, mas não sabe o que internamente precisa fazer para cumprir
- SLA é violado frequentemente, culpa fica "perdida" entre times e fornecedor
- Fornecedor diz "não é nosso problema" enquanto você diz "não é nossa culpa"
- Não há contrato claro com fornecedor (apenas "acordo de cavalheiros")
- Usuários reclamam de experiência mas SLA técnico diz tudo OK (falta XLA)
- Cascata de responsabilidades não é clara (quem é responsável por quê)
- Não há dashboard que mostre status de SLA/OLA/UC em tempo real
Caminhos para estruturar SLA/OLA/UC/XLA
Sua equipe estuda ITIL e implementa framework.
- Perfil necessário: gestor de TI + especialista ITIL + representante de cada time
- Tempo estimado: 8-12 semanas
- Faz sentido quando: você tem tempo e dedicação, equipe é comprometida
- Risco principal: implementação incompleta (faltam UCs ou XLA)
Consultores estruturam framework, ferramentas fornecem dashboards.
- Tipo de fornecedor: consultores de ITIL, software de ITSM (ServiceNow, BMC), ferramentas de RUM (New Relic, Dynatrace)
- Vantagem: framework validado, dashboards profissionais, correlação automática SLA-OLA-UC-XLA
- Faz sentido quando: você quer qualidade de implementação, framework deve escalar a múltiplos SLAs
- Resultado típico: cascata clara, responsabilidades bem definidas, SLA compliance 80%+ vs. <50% antes
Quer estruturar framework SLA/OLA/UC/XLA na sua operação?
O oHub conecta você gratuitamente a consultores ITIL, especialistas em gestão de TI e provedores de ferramentas de observabilidade. Descreva sua situação (SLAs atuais, desafios, número de fornecedores) em menos de 3 minutos, receba propostas sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Framework bem estruturado melhora cumprimento de SLA e clareza de responsabilidades.
Perguntas frequentes
UC é a mesma coisa que SLA com fornecedor?
Não exatamente. UC é suporte contratual (contrato com fornecedor de fornecedor). SLA com fornecedor é seu acordo direto (ex: SLA com cloud provider). UC é contrato que você firma com fornecedor para apoiar OLA ou SLA que você oferece. Exemplo: você tem SLA 99,9% com cliente ? OLA interno 99,95% ? UC com cloud provider 99,99%.
XLA é emergente. Preciso implementar agora ou depois?
Não urgente, mas recomendado começar com aplicações críticas. Se você tem usuários finais (e-commerce, SaaS, fintech), XLA é importante (impacto direto em receita). Se infraestrutura pura (on-prem, backend), SLA técnico é suficiente por enquanto. Tendência: XLA crescendo (próximos 2-3 anos, será padrão).
Como correlacionar SLA-OLA-UC se uma violação acontece?
Processo: SLA foi violado ? qual OLA falhou? ? qual UC falhou? ? qual fornecedor falhou? Rastreabilidade é crítica. Sistema de tickets/ITSM deve rastrear: incidente ? impacto em SLA ? cascata de OLAs/UCs envolvidas ? responsável por resolução. Dashboard automatizado ajuda muito (alerta em tempo real).
UC precisa ser melhor que OLA que oferece ao cliente?
Sim, regra é: UC > OLA > SLA (na ordem de rigor). Exemplo: SLA 99,9% ? OLA 99,95% ? UC 99,99%. Por quê? UC é contrato com terceiro, você precisa de margem de segurança. Se UC = OLA, você não tem proteção (qualquer falha de fornecedor viola OLA).
Qual é a métrica de sucesso de SLA/OLA/UC/XLA bem estruturado?
SLA compliance >90% (vs. <50% antes). OLA compliance >95% (interno é mais fácil). UC compliance 100% (fornecedor está contratado). XLA compliance >85% (experiência é mais subjetiva). Redução de reclamações de cliente (correlação com XLA). Clareza de responsabilidades: quando problema ocorre, responsável é identificado em <1h.
Posso ter múltiplos SLAs para mesmo serviço (ex: diferente por cliente)?
Sim. Exemplo: cliente A requer SLA 99,99%, cliente B requer SLA 99,5%. Você oferece SLAs diferentes. Internamente, você precisa de OLA que suporte PIOR SLA (99,99%) para ambos = uma OLA. UC com fornecedor também apoia o pior caso. Assim, um único OLA/UC suporta múltiplos SLAs.