Existe uma armadilha clássica.
Você chama de "pacote mensal"...
mas continua vendendo emergências.
E aí está o problema: se o cliente paga todo mês, mas você continua trabalhando como bombeiro, não criou serviço recorrente. Só mudou a forma de cobrar.
Um bom pacote mensal de suporte de TI tem escopo, limites, rotina, evidência e preço. Não precisa ser enorme. Precisa ser claro.
1) Defina qual problema o cliente compra
O cliente não compra "monitoramento".
Compra menos surpresas.
Não compra "patches".
Compra computadores que não ficam semanas sem manutenção.
Não compra "relatório mensal".
Compra evidência de que alguém está cuidando da operação.
Antes de listar ferramentas, escreva a promessa do pacote em uma frase:
``text Ajudamos a manter seus equipamentos visíveis, mantidos e atendidos todo mês, com suporte remoto e evidência clara do que foi feito. ``
Essa frase obriga você a separar valor de tarefas soltas.
A SBA recomenda revisar mercado, custos e forma de venda ao construir uma oferta. Seus guias de marketing e vendas e pesquisa de mercado apontam para uma regra básica: não basta colocar preço; você precisa saber para quem vende, o que o cliente compara e qual valor ele entende.
Dica prática: se o pacote é explicado como "horas incluídas", o cliente vai medir você por horas. Explique como continuidade, manutenção e suporte com limites claros.
2) Comece com um pacote base, não com três planos confusos
No início, você quer vender tudo.
Suporte ilimitado, visitas, antivírus, backups, monitoramento, servidores, câmeras, impressoras, e-mail, redes, Wi-Fi, usuários, consultoria...
E depois isso vai te cobrar.
Comece com um pacote base que você consiga cumprir sem inventar processo toda semana:
- inventário inicial de endpoints;
- monitoramento básico de disponibilidade e saúde;
- alertas críticos com responsável;
- revisão mensal de patches;
- suporte remoto em horário comercial;
- canal único para solicitações;
- relatório mensal curto;
- recomendações para o mês seguinte.
Isso já parece gerenciado, mas ainda é controlável.
Dica prática: não venda "tudo incluído" se ainda não sabe quanto cada cliente consome. Venda uma base clara e deixe extras bem definidos.
3) Coloque limites antes que o cliente coloque por você
Limites não são mau atendimento.
São operação saudável.
Seu pacote deve definir:
| Limite | O que definir |
|---|---|
| Endpoints | quantos computadores, servidores ou dispositivos entram |
| Horário | quando você atende e quando algo é emergência |
| Canal | onde solicitações são abertas |
| Escopo | o que entra e o que é cotado separadamente |
| Tempo de resposta | expectativa inicial por prioridade |
| Visitas | se estão incluídas, limitadas ou separadas |
| Projetos | migrações, cabeamento, novos servidores e mudanças grandes ficam fora |
Se você não escreve, o cliente assume.
E quase sempre assume mais do que você pensava.
Dica prática: use uma frase simples: "Este pacote cobre operação recorrente. Projetos, compras, instalação física e mudanças maiores são cotados separadamente".
4) Calcule preço a partir de custos, não de medo
O medo diz: "cobre pouco para ele aceitar".
Os números dizem outra coisa.
A SBA explica que calcular custos ajuda a estimar rentabilidade e ponto de equilíbrio. Seu guia de custos iniciais e sua calculadora de ponto de equilíbrio são úteis porque obrigam você a olhar custos fixos, custos variáveis e o volume necessário antes de vender abaixo da operação.
Para um pacote de suporte de TI, separe:
- tempo técnico esperado;
- ferramentas por endpoint;
- administração e acompanhamento;
- suporte não faturável;
- margem desejada;
- risco de urgências;
- tempo de relatório e revisão mensal.
Você não precisa de um modelo financeiro perfeito. Precisa evitar o preço que deixa você ocupado e sem margem.
Dica prática: antes de passar preço, calcule quantas horas reais pode dedicar ao cliente sem perder dinheiro. Se o pacote não aguenta 2 ou 3 incidentes normais, está mal desenhado.
5) Use endpoints como unidade operacional
Para uma nova empresa de TI, contar endpoints é ouro.
Porque dá uma unidade concreta:
- quantos computadores você monitora;
- quantos podem pedir suporte;
- quantos precisam de patches;
- quantos geram alertas;
- quantos aparecem em relatórios.
Isso não significa que tudo precisa ser cobrado só por endpoint. Mas significa que o endpoint ajuda a organizar escopo e carga.
Exemplo simples:
| Tamanho | Pacote inicial razoável |
|---|---|
| 10 endpoints | monitoramento, suporte remoto básico, revisão mensal e relatório curto |
| 25 endpoints | o anterior + política de alertas, janela de patches e revisão semanal leve |
| 50 endpoints | o anterior + acompanhamento mais formal, prioridades e relatório executivo |
O ponto não é copiar números exatos. O ponto é que o pacote cresce com a operação.
Dica prática: se o cliente não sabe quantos computadores tem, o primeiro entregável é inventário. Sem inventário, qualquer preço é aposta.
6) Inclua suporte remoto, mas não deixe sem regras
Suporte remoto pode economizar horas.
Também pode comer o mês inteiro.
Defina desde o início:
- qual horário cobre;
- qual canal inicia a solicitação;
- que tipo de problema entra;
- quando vira visita;
- quando vira projeto;
- qual evidência fica no fechamento.
Aqui um RMM ajuda o técnico a não entrar às cegas. Antes de conectar, ele pode revisar inventário, alertas, patches pendentes e contexto do endpoint.
Dica prática: não diga "suporte ilimitado" se na verdade quer dizer "suporte remoto para incidentes operacionais normais em horário comercial". São coisas bem diferentes.
7) Transforme o relatório mensal em parte do produto
O relatório não é enfeite.
É prova de valor.
Seu relatório mensal deve responder:
- quantos endpoints estão sob suporte;
- quais alertas relevantes apareceram;
- quais patches ficaram pendentes ou falharam;
- quais sessões ou tickets foram atendidos;
- quais riscos precisam de decisão do cliente;
- o que você recomenda para o próximo mês.
A CISA, em seu guia para pequenas empresas, organiza ações por papel e responsabilidade. Para seu pacote, isso vira algo concreto: o cliente deve saber o que cabe a você, o que cabe a ele e quais decisões não podem ficar vagas.
Dica prática: feche o relatório com 3 pontos: "feito", "pendente" e "decisão necessária". Isso evita relatórios bonitos que ninguém usa.
8) Exemplo de pacote mensal básico
Você pode começar com algo assim:
```text Pacote Suporte TI Base
Inclui:
- Até 25 endpoints validados
- Inventário inicial e revisão mensal
- Monitoramento básico de disponibilidade e saúde
- Alertas críticos com acompanhamento
- Revisão mensal de patches
- Suporte remoto em horário comercial
- Canal único de solicitações
- Relatório mensal executivo
Não inclui:
- Projetos de infraestrutura
- Cabeamento ou visitas não programadas
- Compra de hardware/software
- Migrações
- Suporte fora de horário
- Usuários ou endpoints não registrados
```
Isso não substitui contrato jurídico. Mas dá uma base comercial clara.
Dica prática: adicione uma linha de "mudanças de escopo". Cada endpoint, usuário, local ou serviço novo deve atualizar o pacote.
FAQ: primeiro pacote mensal de suporte de TI
Devo cobrar por endpoint ou por cliente?
Você pode combinar os dois. Um preço base por cliente cobre coordenação, relatórios e operação mínima; o número de endpoints ajusta a carga técnica. O importante é que o escopo não fique aberto.
Quantas horas devo incluir?
Inclua as horas que consiga sustentar com margem. Mas evite vender só horas. Defina atividades recorrentes, limites de suporte e regras para trabalho adicional.
E se o cliente quiser suporte ilimitado?
Esclareça o que isso significa. Você pode oferecer solicitações ilimitadas dentro de certo escopo, horário e tipo de incidente, mas projetos, visitas, mudanças maiores e fora de horário devem ficar separados.
O que deve ter no primeiro relatório mensal?
Endpoints monitorados, alertas relevantes, patches, tickets ou sessões, riscos e próximos passos. Deve ser curto, claro e útil para decidir.
Como o Lunixar RMM ajuda nesse pacote?
Ajuda a conectar inventário, monitoramento, alertas, gerenciamento de patches, suporte remoto e relatórios para que o pacote não dependa de planilhas soltas ou memória.
Feche o pacote antes de vender
Um pacote mensal de suporte de TI não se improvisa depois da venda.
Ele é desenhado antes.
Promessa clara. Escopo claro. Limites claros. Evidência mensal. E uma operação que você consiga repetir sem se queimar.
Lunixar RMM se encaixa nesse fluxo porque conecta inventário, monitoramento de dispositivos, alertas, gerenciamento de patches e conexão remota em uma única console. Se você está montando seu primeiro pacote mensal, pode testar o Lunixar RMM por 14 dias, sem cartão, com até 5 dispositivos e acesso completo.
Você também pode continuar com estes guias:
