Checklist de go-live MSP: do onboarding ao suporte

O agente já aparece em verde.

Os endpoints estão reportando.

O cliente quer começar hoje.

Mas operações ainda não está pronta.

Baixe o checklist de go-live para clientes MSP em XLSX. Ele inclui 34 critérios, decisão automática, evidências, bloqueios, exceções e abas em espanhol, inglês e português.

O go-live não deveria acontecer quando alguém diz “já terminou”. Ele deve acontecer quando o MSP e o cliente conseguem demonstrar que o serviço está pronto para sair do projeto de onboarding e entrar na operação diária.

1) Defina o que significa “pronto” antes de chegar ao go-live

Instalar o agente é um marco. Não é o critério completo de saída.

Um cliente está pronto para o suporte quando escopo, pessoas, acessos, cobertura da frota, controles técnicos e procedimentos operacionais correspondem ao que foi acordado. Se essa definição aparecer somente na reunião final, cada equipe chegará com uma ideia diferente de conclusão.

O NIST recomenda documentar o nível de serviço, as responsabilidades e as expectativas quando uma empresa contrata serviços gerenciados. Também lembra que terceirizar o trabalho não transfere a responsabilidade que o cliente mantém sobre seus sistemas e dados.

Transforme essa orientação em critérios observáveis:

• o escopo assinado corresponde ao serviço que entrará em operação;
• contatos autorizados e substitutos estão identificados;
• endpoints esperados foram conciliados;
• acessos e controles essenciais foram verificados;
• pendências têm responsável, data e tratamento;
• MSP e cliente aprovaram a transição.

Conecte esses critérios à sua matriz de responsabilidades MSP–cliente e ao SLA. O checklist não substitui nenhum dos dois. Ele confirma que ambos já podem ser executados.

2) Separe bloqueios reais das pendências que podem continuar

Um go-live sem nenhuma pendência quase nunca existe.

A pergunta útil não é “está tudo perfeito?”, mas “há algo que impeça a prestação segura do serviço dentro do escopo?”.

Classifique cada controle como bloqueante ou não bloqueante:

Não use “pendente” como esconderijo. Um bloqueio precisa de correção. Uma exceção precisa de autoridade, impacto compreendido e data de revisão. Um item não aplicável precisa de justificativa.

O modelo retorna PRONTO somente quando todos os controles bloqueantes estão prontos, não se aplicam ou têm uma exceção aprovada.

3) Concilie a frota: esperado, descoberto e realmente gerenciado

O contrato diz 60 endpoints.

A planilha do cliente lista 57.

O RMM mostra 54 agentes, e quatro não reportam há dias.

Isso não é um detalhe para “ver depois”. É uma diferença de escopo que afetará monitoramento, suporte, patches e cobrança.

Parta do checklist de onboarding de endpoints e concilie:

1. endpoints esperados por local ou departamento;
2. dispositivos descobertos;
3. agentes instalados e reportando;
4. máquinas offline ou inacessíveis;
5. exclusões confirmadas;
6. proprietário e finalidade de cada ativo duvidoso.

Depois verifique se os dispositivos estão agrupados, etiquetados e associados ao cliente correto. Um console cheio de agentes sem classificação ainda não representa uma operação organizada.

No Lunixar RMM, inventário, último estado reportado, alertas e resultados de patches podem fazer parte das evidências. A conciliação e o aceite do escopo continuam sendo decisões do processo MSP–cliente.

4) Verifique acessos, segurança e recuperação por resultados

Uma caixa marcada não prova que o controle funciona.

Antes do go-live, verifique pelo menos:

• acessos administrativos autorizados e protegidos com MFA onde houver suporte;
• contas temporárias ou do provedor anterior com responsável e prazo;
• escopo do acesso remoto e ações que exigem aprovação;
• status conhecido do antivírus ou da proteção de endpoints;
• linha de base de patches e janelas de manutenção;
• alertas críticos tratados ou aceitos como exceção;
• backups, retenção e uma restauração representativa;
• contatos para incidentes e continuidade.

A orientação conjunta da CISA e de outras autoridades para proteger MSPs e seus clientes destaca a coordenação de controles como MFA, registros, backups, acesso remoto e resposta a incidentes. O valor está em ambas as partes saberem o que existe, quem atua e como o resultado é comprovado.

Não guarde senhas, segredos ou códigos de recuperação dentro do checklist. Vincule a evidência e registre onde o segredo é gerenciado, não o próprio segredo.

5) Transforme riscos herdados em decisões visíveis

O novo MSP herda situações desconfortáveis.

Um servidor sem suporte. Uma aplicação que não pode ser reiniciada. Uma conta compartilhada. Um backup que nunca foi restaurado.

O go-live não apaga esses riscos. Apenas muda quem os vê e quem precisa agir.

Para cada risco aberto, registre:

• descrição e impacto;
• ativo ou serviço afetado;
• tratamento proposto;
• responsável pelo acompanhamento;
• data limite;
• controle compensatório, se houver;
• pessoa que aceita a exceção;
• data de vencimento da aceitação.

Não confunda “o cliente já sabia” com aceite. O aceite precisa estar associado a uma pessoa autorizada e a um escopo específico.

6) Faça uma transição real para a equipe que atenderá os tickets

O projeto de onboarding conhece todos os detalhes.

A central de suporte recebe o primeiro ticket na segunda-feira… e ninguém contou nada para a equipe.

Antes da transição, a equipe de operações precisa conseguir encontrar:

• contatos, locais, horários e canais autorizados;
• escopo contratado e exclusões;
• prioridades e metas do SLA;
• sistemas críticos e dependências;
• acessos e procedimentos de emergência;
• fornecedores externos e responsáveis;
• pendências, exceções e mudanças programadas;
• runbooks para os casos mais prováveis.

Teste o fluxo com um ticket de exemplo. Ele chega à fila correta? A equipe identifica o cliente? Existe contexto para classificá-lo? O escalonamento fora do horário funciona?

O go-live termina quando operações consegue prestar o serviço, não quando a equipe do projeto conclui sua lista.

7) Obtenha aprovação e agende revisões em 7 e 30 dias

A aprovação deve resumir a realidade, não decorar o encerramento.

Inclua:

• controles concluídos;
• bloqueios resolvidos;
• exceções aprovadas;
• pendências não bloqueantes;
• data e hora efetivas do serviço;
• responsável por operações do MSP;
• responsável autorizado do cliente.

Depois agende duas revisões:

1. Em 7 dias: valide tickets, alertas, acessos, endpoints offline e problemas de comunicação.
2. Em 30 dias: revise tendências, pendências, riscos, escopo e próximos projetos usando evidências dos relatórios RMM.

Se o escopo mudar nesse período, atualize o termo e a matriz de responsabilidades. A aprovação inicial não deve congelar uma realidade que já mudou.

8) Baixe o checklist e use-o como termo de saída

O modelo contém 34 controles agrupados em sete fases:

• governança e escopo;
• identidade e acesso;
• frota e RMM;
• segurança e patches;
• backup e continuidade;
• operação do serviço;
• transição e aprovação.

Baixar o checklist de go-live para clientes MSP (.xlsx)

Cada aba de idioma inclui responsáveis, links de evidências, listas de status, indicador de bloqueio, datas, revisores, aceite do cliente, notas e uma decisão de prontidão calculada por fórmula.

Duplique o arquivo para cada cliente. Adapte os critérios ao contrato, ao risco, aos sistemas e aos requisitos regulatórios reais. Guarde a cópia aprovada junto ao contrato, SLA e registro de onboarding.

Perguntas frequentes sobre go-live MSP

O go-live exige que todos os itens estejam concluídos?

Não. Ele exige que todos os itens bloqueantes estejam resolvidos, marcados como não aplicáveis com justificativa ou cobertos por uma exceção aprovada. Pendências não bloqueantes ainda precisam de responsável e data.

Um agente RMM instalado é suficiente para declarar um endpoint pronto?

Não. Confirme reporte, propriedade, agrupamento, política de monitoramento, estado de segurança, linha de base de patches, autorização de acesso e qualquer exceção conhecida.

Quem deve aprovar o go-live?

No mínimo, o responsável por operações do MSP e um responsável autorizado do cliente. Exceções de alto risco podem exigir aprovação adicional de negócio, jurídica, privacidade ou segurança.

Que evidências devem ficar na planilha?

Use links ou referências para tickets, exportações, relatórios, resultados de testes e registros aprovados. Não guarde senhas ou segredos no checklist.

O modelo substitui um contrato ou orientação profissional?

Não. É uma ferramenta operacional. Adapte-a com orientação qualificada quando houver requisitos jurídicos, contratuais, regulatórios, de privacidade ou específicos do setor.

Uma transição limpa faz o primeiro dia de suporte parecer rotina

O cliente não precisa de um lançamento cerimonial.

Ele precisa que o primeiro alerta, ticket, ciclo de patches e escalonamento funcionem como esperado.

O Lunixar RMM pode centralizar inventário de endpoints, estado reportado, alertas, resultados de patches e relatórios. O processo de go-live conecta essas evidências a pessoas, escopo, exceções e aprovação.

Conheça o Lunixar RMM para MSPs e teste até 5 dispositivos por 14 dias, sem cartão.