ADR-601: Service Classes & SLA
Status: Accepted
Contexto
Equipe mínima, contratação difícil. Clientes pagando nível básico exigem entrega premium. Metas de SLA legadas (BASIC/PLUS/PREMIUM) prometem P1 30min 24/7 — requer plantão que MIDDAG não consegue montar. Sem limites visíveis entre níveis, sem opção pay-as-you-go, sem faixa Enterprise. Resultado: burnout, Michael escalado para tudo.
Decisão
Classes de Serviço: Free, Basic, Flex, Business, Enterprise, Government
| Classe | Modelo | Calendário SLA | Envolvimento Humano |
|---|---|---|---|
| Free | Sem custo | Nenhum (sem SLA) | Zero — self-serve |
| Basic | Incluído no produto | HC (9-18 BRT, Seg-Sex) | Mínimo — fila de tickets |
| Flex | Pay-as-you-go | HC (9-18 BRT, Seg-Sex) | Sob demanda — com crédito |
| Business | Plano mensal | HC com SLA reduzido | Alto — especialista, proativo |
| Enterprise | Contrato anual | Customizado (até 24/7) | Dedicado — TAM, SLA custom |
| Government | Contrato anual | Customizado (até 24/7) | Dedicado — compliance, licitação |
4 Princípios de Design
- Sistema aplica, não pessoas. Entitlement.support_class → classe → SLA → exibido ao cliente. Equipe não negocia.
- Low-touch por default. Free e Basic são self-serve. Tempo humano reservado para Business e Enterprise.
- Pague pelo que recebe. Tabela clara de inclusões. Tudo fora = upgrade ou orçamento.
- Sustentável para equipe pequena. Sem 24/7 abaixo de Enterprise. HC para Business. 24/7 sempre como add-on.
Enforcement via support_class
Campo support_class no Entitlement: free | basic | flex | business | enterprise | government. Determina metas de SLA, canais disponíveis, prioridades que cliente pode definir, tickets simultâneos.
Detalhes de enforcement em REF-601-02.
Priority Support como Add-On
Move tickets à frente da fila dentro da classe. NÃO altera SLA, horário, canais, quem responde. Disponível para Basic/Flex/Business. Não necessário para Enterprise/Government.
Flex como Ponte
Mensalidade mínima recorrente (SLA ativo) ou ticket avulso (mais caro, sem SLA garantido). Preenche lacuna entre Basic (incluído) e Business (compromisso mensal).
Jira como SLA Engine / Plugin como Display
Jira roda relógios de SLA (motor nativo). Plugin lê estado via webhooks e exibe no portal. Plugin NÃO roda relógios próprios (risco de drift, carga de manutenção de calendários).
Migração de Tiers Legados
| Tier Legado | Nova Classe | Migração |
|---|---|---|
| PADRÃO | Basic | Automática — suporte incluído com produto ativo |
| PLUS | Flex | Automática — modelo híbrido |
| PREMIUM | Business | Comunicação: "HC com SLA reduzido; 24/7 add-on" |
Aviso prévio de 60 dias. Mapeamento claro para clientes.
Comparação com Indústria
| Nível | Atlassian | AWS Support | MIDDAG |
|---|---|---|---|
| Free | Free | Basic | Free |
| Entrada | Standard | Developer | Basic |
| Flexível | — | — | Flex (diferencial único) |
| Premium | Premium | Business | Business |
| Enterprise | Enterprise | Enterprise | Enterprise |
| Government | Atlassian Gov | GovCloud | Government |
Consequências
Positivas:
- Metas sustentáveis para equipe pequena (sem 24/7 abaixo de Enterprise)
- Sistema aplica limites — equipe não negocia SLA
- Flex preenche lacuna entre "incluído" e "compromisso mensal"
- Prompts de upgrade no portal guiam cliente ao nível correto
Negativas:
- Migração de PREMIUM→Business reduz metas (comunicação necessária)
- Flex com SLA condicional (com crédito) adiciona complexidade
- Government requer compliance adicional (licitação, LGPD reforçada)
Referências
- REF-601-01 — SLA Targets Matrix
- REF-601-02 — Service Class Enforcement
- ADR-202 — Entitlement (campo support_class)
- ADR-501 — Service Delivery (ServiceRequest usa SLA)
- Definições de classes de serviço — conteúdo absorvido neste ADR e REFs
- Regras SLA legadas — conteúdo absorvido em REF-601-01