Quatro coisas, por escrito: tempos de resposta por nível de severidade, horário de cobertura definido, monitorização proactiva e relatórios mensais. Os nossos contratos comprometem-se com 2 horas para suporte remoto, 4 horas presencial e 1 hora para incidentes críticos — e digo-lhe por experiência: se um fornecedor não aceita pôr números destes num contrato assinado, não tem um SLA. Tem uma promessa. E promessas são aquilo sobre que se discute às 7 da manhã no dia em que o servidor caiu.
O coração de um SLA é aborrecido e preciso: o que conta como crítico (sistemas parados, negócio parado), o que conta como normal, e com que rapidez o fornecedor responde a cada caso — remota e presencialmente. Nós escrevemos os nossos como 2h remoto / 4h presencial / 1h crítico, dias úteis das 08h00 às 18h00 e sábados de manhã. Os números exactos variam por contrato; o essencial é que existam, no papel, com consequências quando falham.
A maioria das disputas que já vi entre empresas e fornecedores de TI reduz-se a uma lacuna que ninguém definiu: são 21h00, algo avariou, e cada lado tem uma suposição diferente sobre de quem é o problema. Um SLA a sério define a janela de cobertura e as regras fora dela — existe canal de emergência, a que custo, para que tipo de incidente. Ambiguidade aqui sai cara.
O suporte moderno corre um agente em cada posto de trabalho e servidor — a indústria chama-lhe RMM — a vigiar discos, backups, actualizações e falhas em tempo real. Corremos isto em todos os contratos que temos, e a diferença prática é gritante: a maioria dos problemas é resolvida antes de alguém nos ligar. Sem monitorização, todos os problemas começam com um telefonema, o que significa que todos os problemas começam tarde. Faça duas perguntas a qualquer fornecedor: o que exactamente monitorizam, e em que alertas actuaram no mês passado?
Quem aplica as actualizações de segurança, e com que frequência? Quem verifica os backups — e testa mesmo um restauro, em vez de admirar um visto verde? O que acontece quando um colaborador reporta um email de phishing? Se as respostas forem "disponível como serviço adicional", o contrato está a proteger o fornecedor, não a si.
Todos os meses os nossos clientes recebem um relatório: tickets resolvidos, tempos de resposta cumpridos, estado dos sistemas, o que recomendamos a seguir. Não é marketing — é a forma de o cliente verificar o SLA sem confiar na palavra de ninguém. Um fornecedor que resiste a relatórios está a pedir-lhe que pague por fé.
Os conselhos genéricos sobre SLAs ignoram três realidades locais. Energia: os cortes são a causa mais comum de incidentes por cá, por isso a monitorização de UPS e os procedimentos de encerramento limpo pertencem ao contrato. Conectividade: o suporte remoto vale o que vale a ligação, por isso tem de haver um compromisso presencial real por trás. E presença: "4 horas presencial" não significa nada vindo de um fornecedor cujo técnico mais próximo está noutro país. Pergunte onde está, de facto, a equipa.
Se quiser ver como estruturamos os nossos — os mesmos termos descritos acima — os detalhes estão na página de gestão de TI.
Para suporte empresarial em Maputo: até 2 horas remotamente e 4 horas presencial dentro do horário de cobertura, e até 1 hora para incidentes críticos. Existem compromissos mais rápidos, mas verifique se o fornecedor tem mesmo técnicos locais para os cumprir.
Remote Monitoring and Management: um agente instalado em cada computador e servidor que reporta o estado — discos, backups, actualizações, falhas — em tempo real, permitindo ao fornecedor resolver a maioria dos problemas antes de interromperem a sua equipa.
Sim. Mesmo uma empresa de 10 pessoas depende de email, ficheiros e facturação. Um SLA básico por escrito, com monitorização, custa tipicamente menos do que o tempo parado de um único incidente grave.
Conversa inicial gratuita · proposta em 48 horas · sem compromisso
fale connosco