Suporte de software que resolve: SLA, prioridades e o que esperar do seu fornecedor

Software entregue não é projeto encerrado. É operação começando. E suporte ruim — aquele em que o ticket some na fila, a resposta demora três dias úteis, o bug volta no mês seguinte — é o que transforma um projeto bem-sucedido em cliente perdido para a concorrência.

A diferença entre suporte que resolve e suporte de teatro não é tamanho de equipe nem ferramenta cara. É estrutura, prioridade clara e cultura de quem opera.

O ciclo de vida real de um problema

Quando um cliente reporta um bug ou comportamento estranho, o tempo total até resolução tem quatro momentos distintos — e a maioria dos fornecedores otimiza apenas o primeiro:

• Tempo até a primeira resposta. O famoso "olá, recebemos seu chamado e estamos analisando". Importante, mas só o começo.
• Tempo até o diagnóstico. Aqui está o que descobrimos sobre o problema, qual é a causa raiz provável, e qual a abordagem de correção.
• Tempo até a correção em produção. O bug foi corrigido, o deploy passou, o usuário pode usar normalmente de novo.
• Tempo até o post-mortem. Análise do que aconteceu, por que aconteceu, e o que mudamos no sistema para não voltar.

Suporte de baixa qualidade é rápido no primeiro momento e lento (ou inexistente) nos três seguintes. Suporte real otimiza os quatro. O segundo e o terceiro são o que define se o cliente vai voltar a confiar.

Severidade real, não inflada artificialmente

Não dá pra tratar tudo como urgência. Quando tudo é P0, nada é P0 — o time fica sempre apagando incêndio e nunca evolui o sistema. Um sistema honesto de severidade tem 4 níveis bem definidos:

P0 — Crítico. Sistema fora do ar para todos os usuários, pagamento não processa, dado sendo perdido ou corrompido. Acordamos quem precisar acordar, hora do dia ou da noite. Resposta em minutos, mitigação (mesmo que paliativa) em até 1 hora, correção definitiva em até 24 horas.

P1 — Alto. Funcionalidade importante quebrada, mas existe workaround conhecido. Algumas transações falham, algumas telas erram, mas o sistema continua operando para a maioria. Resposta em até 4 horas úteis, correção em até 1 dia útil.

P2 — Médio. Bug visível mas não bloqueante. Erro de exibição, cálculo arredondando errado em caso raro, mensagem confusa. Resposta em até 1 dia útil, correção na próxima janela planejada de deploy.

P3 — Baixo. Sugestão de melhoria, ajuste cosmético, ideia para feature futura. Entra no backlog priorizado da próxima sprint, sem prazo apertado.

O cliente define a severidade junto com a gente no momento do report. Não precisa "confirmar com gerente" antes de tratar como P0. Quando há discordância, vence o lado mais conservador.

Plantão (on-call): quem atende fora de horário comercial

Software importante precisa de gente disponível 24 por 7 para incidente P0. Mas plantão mal estruturado queima a equipe em poucos meses e termina em renúncia coletiva. Como organizamos:

• Rotação semanal previsível. Cada engenheiro fica de plantão uma semana a cada quatro a seis semanas. Calendário público, todo mundo sabe quem está respondendo.
• Compensação clara. Hora de plantão é paga ou compensada em folga. Noite acordada vira folga compensatória no dia seguinte. Saúde mental conta tanto quanto disponibilidade.
• Runbooks por cenário. O engenheiro de plantão não precisa decorar o sistema inteiro. Tem guia operacional de "banco não responde", "gateway timeout", "fila acumulada" — com passos numerados.
• Escalonamento automático. Se P0 não tem resposta em 5 minutos, o sistema escala automaticamente para o próximo na lista. Sem dependência de notificação única.
• Pós-incidente no dia seguinte. Análise técnica honesta, sem busca de culpado, focada em melhoria do sistema. O bug aconteceu — agora a pergunta é como evitar a próxima geração desse mesmo bug.

Bug em produção é tempo até a solução. Tudo o resto é teatro.

Métricas que importam de verdade

Você só melhora o que mede com rigor. Para suporte operacional, três números são suficientes para diagnosticar saúde do atendimento:

MTTR (Mean Time To Recovery). Quanto tempo, em média, leva entre o incidente começar e o sistema voltar ao normal. Bom é abaixo de 1 hora para P0. Excelente é abaixo de 15 minutos. Acima de 4 horas é sinal de processo quebrado.

MTBF (Mean Time Between Failures). Quanto tempo entre incidentes significativos. Subir esse número significa que cada bug corrigido está realmente sumindo de vez, não retornando em forma mutada. Cair esse número é sinal vermelho.

Taxa de regressão. Quantas vezes um bug que já foi corrigido volta a aparecer (mesmo em forma ligeiramente diferente). Bom é abaixo de 5%. Se for maior, o teste de regressão está furado e merece investimento imediato.

Compartilhamos esses três números com o cliente em relatório mensal. Transparência total — não dá pra esconder se o sistema está degradando.

Post-mortem sem culpado: o documento que evita o próximo

Depois de cada incidente significativo (geralmente qualquer P0 e alguns P1), paramos por 1 a 2 horas para entender o que aconteceu. Não para encontrar culpado — para encontrar fragilidade no sistema. O formato que usamos:

• O que aconteceu. Sequência completa de eventos com timestamps minuto a minuto.
• Quando começou e quando notamos. Geralmente são dois timestamps diferentes — e a distância entre eles é um indicador de qualidade da observabilidade.
• Por que aconteceu. Causa raiz real, não sintoma superficial. Geralmente exige perguntar "por quê?" cinco vezes seguidas até chegar na causa verdadeira.
• Por que não pegamos antes. Onde o nosso radar falhou. Faltou alerta? Faltou teste? Faltou monitoramento? Esse item é o mais valioso.
• O que mudamos para não acontecer de novo. Itens acionáveis, com dono nomeado e prazo definido. Sem isso, o documento é só catarse, não evolução.

Empresas referência em engenharia — Stripe, Cloudflare, GitHub, Google — publicam seus post-mortems publicamente. Não por transparência cosmética: por aprendizado coletivo. Cada incidente bem analisado vira conhecimento que protege a próxima geração de sistemas.

Suporte vs. sustentação vs. evolução

Existe diferença importante entre três coisas que costumam ser misturadas no mesmo contrato (e essa mistura geralmente gera frustração de ambos os lados):

Suporte: resolver problema que apareceu inesperadamente. Bug, queda, comportamento errado, dúvida operacional. Tem SLA com tempos definidos.

Sustentação: manter o sistema saudável ao longo do tempo. Atualização de dependências, ajuste de performance, limpeza de dados antigos, calibragem de monitoramento. Tem ritmo mensal previsível, não tem SLA de "agora".

Evolução: adicionar funcionalidade nova ou redesenhar parte do sistema. Não é bug — é projeto. Tem escopo, orçamento e prazo próprios.

Misturar os três no mesmo contrato é receita certeira para frustração. Separamos e cobramos os três de forma transparente: cliente sabe exatamente o que está pagando, o que esperar de cada um, e como funciona.

Como escolher um fornecedor que tem suporte real

Mesmo que você não contrate a Oryxi, esta seção pode te poupar dores de cabeça. Cinco perguntas que separam fornecedor com suporte de verdade do que só tem suporte no contrato:

• Qual o MTTR médio de vocês no último ano? Se não souberem responder com número específico, não medem — e provavelmente também não resolvem.
• Como funciona o plantão? Quem atende? Em quanto tempo? Quanto custa? Pergunta concreta, resposta precisa.
• Vocês compartilham post-mortems comigo? Se a resposta é vaga ou negativa, alguma coisa está sendo escondida deliberadamente.
• Posso falar direto com quem vai operar o meu sistema? Se você só fala com vendas e gerente de conta, o suporte vai ser ruim — porque o operador real não tem voz.
• Vocês têm runbooks documentados ou a operação está só na cabeça de uma pessoa? Se for o segundo caso, qualquer férias ou demissão vira incidente de operação.

O que entregamos por padrão em todo projeto

Em todo projeto que vai para produção, o cliente recebe — escrito no contrato:

• Acordo de SLA com 4 níveis de severidade e prazos claros de resposta e correção.
• Canal de suporte direto: WhatsApp + e-mail + dashboard de tickets, à escolha do cliente.
• Plantão (on-call) ativo para incidentes P0, 24 horas por 7 dias.
• Relatório mensal com MTTR, MTBF, lista de incidentes do mês e ações tomadas.
• Acesso completo aos runbooks e à documentação operacional.
• Post-mortem compartilhado com o cliente após cada incidente significativo.

Suporte não é favor depois do projeto. Faz parte do contrato, desde o primeiro dia, com obrigações concretas dos dois lados.

Pronto para parar de perder tempo com fornecedor que some?

Software de verdade precisa de gente de verdade do outro lado, todo dia, com prazos claros e responsabilidade nomeada. Em Foz do Iguaçu, atendendo Brasil, Paraguai e Argentina, mantemos sistemas no ar e clientes satisfeitos porque tratamos suporte como engenharia, não como atendimento de loja. Vamos conversar sem compromisso sobre o seu projeto e o que ele precisa pós go-live.