Para fornecedores de serviços geridos, a documentação não é apenas “bom ter” - é o produto. Com a Trupeer, pode poupar horas na criação de documentação para MSP começando com modelos gratuitos de documentação para MSP, personalizando-os com as suas diretrizes de marca e transformando a documentação do cliente em percursos em vídeo que qualquer técnico pode utilizar.

O que é a documentação de MSP e o que a torna diferente?

A documentação de MSP é tudo o que um fornecedor de serviços geridos regista para operar a tecnologia de outras organizações: registos de ativos, diagramas de rede, credenciais, runbooks, percursos de escalonamento, particularidades específicas do cliente, e os relatórios e revisões que o cliente vê.

Duas coisas tornam-na estruturalmente diferente da documentação interna de TI, e quase todos os modelos ignoram ambas.

Está a documentar patrimónios que não possui. O cliente tem uma pretensão sobre parte do que escreve e não tem sobre o resto, e essa linha é importante comercial, contratual e no dia em que a relação termina.

E está a documentar o mesmo procedimento em muitos patrimónios ao mesmo tempo. Uma equipa interna escreve um único runbook de restauro de cópia de segurança. Um MSP escreve um e depois tem de o manter verdadeiro em trinta ou quarenta ambientes que diferem de formas que ninguém se lembra totalmente.

O segundo problema é o que silenciosamente come a margem de um MSP, por isso é onde esta página começa. Na versão para um único património, o nosso modelo de documentação de TI cobre o caso geral.

Porque é que quarenta cópias de um runbook é o problema real

Quase todos os MSP começam da mesma forma. Crie um bom conjunto de runbooks. Faça o onboarding de um cliente. Copie os runbooks para a pasta ou espaço desse cliente para que o engenheiro que trabalha no ticket tenha tudo num só lugar. Repita.

É um instinto razoável e produz uma catástrofe lenta. Após quatro anos com trinta e tal clientes, tem mais de mil documentos, a maioria quase duplicados entre si, e sem forma de saber qual cópia é a atual.

O problema não é que os documentos sejam maus. Cada cópia estava correta quando foi criada. O problema é que as melhorias ao método agora têm de ser aplicadas trinta vezes, e são aplicadas cinco ou dez vezes antes de alguém ser puxado para algo urgente.

O que os engenheiros fazem a seguir é a parte cara. Depois de um técnico ser “queimado” duas vezes por um runbook que não correspondia ao ambiente, deixa de ler runbooks. Passa a trabalhar a partir de princípios base, o que é mais lento, menos consistente e completamente invisível nos seus relatórios, porque o ticket continua a ser encerrado.

Por isso, a estrutura de documentação de um MSP tem de tornar a atualização padrão possível num único local. Tudo o que vem abaixo decorre disso.

Como personalizar este modelo na Trupeer

Passo 1: Abra a secção de Modelos

Vá à secção de Modelos no menu principal.

Passo 2: Selecione e abra um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expanda a vista do modelo

Se necessário, expanda a vista do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Edite o modelo

Clique em Editar para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guarde o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Guardar para guardar o modelo atualizado como seu.

Passo 6: Pré-visualize e ajuste o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o quer.

Com modelos de documentação de MSP pode:

• Poupar horas na escrita: Ignore a página em branco com estruturas criadas para operações de MSP.

• Reduzir o MTTR: Uma documentação clara ajuda qualquer suporte técnico a qualquer cliente, rapidamente.

• Manter-se fiel à marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.

• Onboarding de técnicos mais rápido: Novos técnicos ganham ritmo rapidamente com documentação clara em formato de vídeo.

• Manter-se pronto para auditorias: Secções integradas suportam SOC 2, ISO 27001 e auditorias de clientes.

• Atingir equipas globais: Traduza a documentação de MSP para 65+ idiomas com um clique.

Uma excelente documentação de MSP é o que torna um negócio de serviços geridos escalável. Use estes modelos para captar claramente e de forma consistente cada cliente, cada sistema e cada procedimento.

Documente o padrão uma vez, registe apenas a diferença

Uma biblioteca de padrões. Uma cópia de cada documento. Versão gerida, propriedade sua, e o único local onde o método existe.

Depois, por cliente, um documento curto que regista onde esse cliente difere do padrão, e nada mais. Não é uma cópia do runbook com alterações. É uma lista de exceções.

O registo de diferenças do cliente é o truque completo. Se o cliente usa um produto de cópia de segurança diferente, é uma linha. Se a firewall dele é de outro fornecedor, é uma linha. Se o diretor financeiro tiver de aprovar qualquer trabalho fora de horas, é uma linha. Tudo o que não está no registo é padrão por definição, o que significa que um engenheiro lê dois documentos em vez de procurar numa pasta única, na esperança de que a cópia lá dentro seja a atual.

Os registos mantêm-se pequenos. Na prática, um cliente maduro fica algures entre oito e vinte linhas, e o exercício de escrever um registo costuma revelar três ou quatro diferenças que ninguém tinha registado em lado nenhum.

Há um segundo benefício que aparece mais tarde. Uma lista curta de tudo o que não é padrão num cliente é um documento de vendas e de margem muito bom. As diferenças são onde o seu tempo vai parar.

O registo de diferenças do cliente e o que deve incluir

Uma linha por diferença, cinco campos.

O que é diferente. Declarado face ao padrão, para que seja “a cópia de segurança é Datto em vez do nosso Veeam padrão” e não “usa Datto”.

Que documento padrão é afetado. A referência, para que um engenheiro que leia o runbook possa ser direcionado para aqui.

Porquê. Preferência do cliente, herdada de um fornecedor anterior, requisito de conformidade, restrição técnica. Este campo determina se a diferença vale a pena ser removida.

Desde quando, e revisto quando. Uma data. As diferenças herdadas no onboarding muitas vezes persistem durante anos porque ninguém as volta a rever.

Esforço ou risco. Uma nota curta sobre o custo para si. É isto que transforma o registo num documento comercial, além de técnico.

Adicione um cabeçalho com o nome do cliente, a versão da biblioteca de padrões contra a qual este registo foi escrito, e o responsável pela conta. Revise os registos trimestralmente. Diferenças sem motivo e sem custo são candidatas a serem padronizadas, e fazer isso é normalmente o trabalho de documentação com maior retorno que um MSP pode fazer.

Que documentos um MSP precisa, por categoria

A maioria dos MSP é forte na primeira e na quinta linhas e fraca na terceira, o que está exatamente ao contrário, porque a terceira linha é o que torna a segunda linha utilizável.

Dois destes têm os seus próprios modelos que vale a pena usar diretamente. As credenciais e o inventário de licenças têm um lugar natural no nosso registo de aplicações e credenciais, e os runbooks em si seguem a estrutura do nosso modelo de SOP de TI.

Modelos gratuitos de documentação de MSP: a biblioteca de padrões para construir

Copie daqui. Esta é a biblioteca de padrões mínima, e é mais pequena do que a maioria dos MSP espera.

Pack de onboarding. Checklist de descoberta, auditoria do local, captura de ativos, captura de credenciais, preenchimento inicial do registo de diferenças, revisão do primeiro mês. Um documento, executado uma vez por cliente.

Runbooks, um por tarefa recorrente. Restauro de cópia de segurança, criação e desativação de utilizadores, restauro de caixas de correio, reconstrução de endpoint, reposição de palavra-passe, acesso VPN, implementação de impressoras, renovação de certificados, exceção de patch. Comece pelas dez tarefas que geram mais tickets em vez de tentar cobrir tudo.

Escalonamento e on-call. Como um ticket é escalado, quem é contactado em cada nível, o que constitui uma emergência e a regra de autorização fora de horas.

Incidente e mudança. Um formato de revisão pós-incidente e um formato de método do procedimento para mudanças planeadas na infraestrutura do cliente.

Relatórios para o cliente. Relatório mensal, revisão trimestral do negócio e um resultado de auditoria do local. Formato fixo, dados do cliente preenchidos.

Pack de offboarding. O que o cliente recebe, o que você retém, em que formato e até quando. Escrito antes de precisar.

Modelo de registo de diferenças. Os cinco campos acima.

Copie para aqui. Dez a quinze runbooks, mais seis documentos fixos, é uma biblioteca funcional. O instinto de escrever primeiro quarenta runbooks é a razão pela qual a maioria dos projetos de documentação de MSP fica travada no segundo mês.

Documentação de MSP interna e externa, e quem é o responsável por cada uma

A distinção que a maioria dos guias faz é entre interna e para o cliente, o que é útil para decidir o tom. A distinção mais importante é a responsabilidade, e isso torna-se real no offboarding.

De forma geral, e variando consoante o contrato e a jurisdição, os dados do cliente são do cliente: registos de ativos que descrevem o equipamento, a topologia de rede, as credenciais, as licenças a que tem direito, a configuração. Você detém-nos como fornecedor de serviços, em vez de os possuir.

O seu método é seu: os runbooks padrão, os formatos de relatório, os seus padrões de construção, o seu modelo de preços, os seus procedimentos internos. Um cliente que sai não tem direito à sua biblioteca de runbooks.

O registo de diferenças fica de forma desconfortável entre os dois, por isso vale a pena nomeá-lo explicitamente no seu contrato. Descreve o ambiente do cliente, o que favorece o “deles”, mas é escrito com base nos seus padrões, o que favorece uma versão com partes ocultas.

Resolva isto por escrito no contrato de prestação de serviços, em vez de o discutir no momento da saída. Esta página não é aconselhamento jurídico e a posição varia consoante o contrato e a jurisdição; por isso, peça ao seu advogado para rever a responsabilidade pela documentação e as cláusulas de devolução. Fazer isto uma vez custa uma hora. Fazer isto durante um offboarding custa consideravelmente mais, como abaixo.

O MSP com 1.360 documentos e nove runbooks desatualizados

A Thornbury IT prestava serviços geridos para trinta e quatro clientes com vinte e dois colaboradores, nove dos quais eram engenheiros. Em cada onboarding, copiavam o conjunto de runbooks para o espaço do novo cliente, o que, ao fim do quarto ano, significava cerca de quarenta documentos por cliente e cerca de trezentos e sessenta no total.

O problema surgiu durante um incidente. Um engenheiro executou um restauro de cópia de segurança falhado para um cliente seguindo o runbook de restauro desse cliente, que fazia referência a uma convenção de nomenclatura de jobs da Veeam. O cliente tinha mudado para outro produto de cópia de segurança catorze meses antes. O runbook padrão tinha sido atualizado. A cópia na pasta desse cliente não tinha sido.

Depois, analisaram os runbooks de restauro de doze clientes. Nove divergiam do padrão atual, e cinco dessas nove diferenças eram simplesmente desatualizações, em vez de alterações deliberadas.

O custo mensurável estava no tempo de atendimento. O tempo médio de atendimento do nível dois em toda a empresa era de quarenta e sete minutos. Para os clientes cujos runbooks estavam desatualizados, era de setenta e um, porque os engenheiros dessas contas tinham deixado de confiar na documentação e tinham de a resolver cada vez.

Separadamente, um cliente tinha saído no terceiro ano e pediu a documentação. A Thornbury enviou a pasta do cliente, que continha os runbooks padrão deles misturados com o registo de ativos e as credenciais do cliente. Ninguém tinha traçado a linha. A discussão sobre o que o cliente tinha direito a receber durou seis semanas e envolveu os advogados de ambas as empresas.

A reconstrução demorou um mês do tempo de uma pessoa. Uma biblioteca padrão, uma única cópia, com versões. Por cliente, apenas um registo de diferenças. O comprimento mediano do registo era de onze linhas.

Os trezentos e sessenta documentos passaram a ser quarenta documentos padrão e trinta e quatro registos, ou seja, setenta e quatro no total. O tempo de atendimento do nível dois convergiu para quarenta e quatro minutos em todas as contas. E o pack de offboarding foi definido no contrato a partir daí: o cliente recebe o registo de ativos, as credenciais, os diagramas e o seu registo de diferenças, e a Thornbury retém a biblioteca padrão.

Existem modelos gratuitos de documentação de MSP no GitHub?

Sim, e vale a pena analisá-los com expectativas realistas.

O que vai encontrar são repositórios comunitários de coleções de runbooks, bibliotecas de scripts PowerShell com documentação incorporada, frameworks de documentação baseados em markdown e, ocasionalmente, uma estrutura completa de documentação publicada por um MSP como exercício de recrutamento ou marketing. Procurar runbooks de MSP ou documentação de TI juntamente com markdown ou docs-as-code vai revelar a maior parte disso.

O que é genuinamente útil nesses repositórios é a estrutura e a cobertura: uma lista dos runbooks que um MSP competente mantém é uma boa checklist para a sua própria. O que raramente é útil é o conteúdo, porque os runbooks são específicos para um conjunto de ferramentas, e um procedimento de restauro para o produto de cópia de segurança e RMM de outra pessoa está mais perto de um exemplo trabalhado do que de um modelo.

Duas cautelas. Verifique a licença antes de incorporar qualquer coisa numa biblioteca de documentação comercial, porque permissiva é comum, mas não é universal. E nunca adapte um repositório que contenha identificadores reais de clientes, detalhes de rede ou qualquer coisa que se pareça com credenciais, o que aparece em repositórios públicos com mais frequência do que deveria.

A abordagem docs-as-code em si, ou seja, markdown em controlo de versão, é uma opção legítima para um MSP e resolve o problema da cópia única de forma elegante. A sua fraqueza é que, sob pressão de tempo, os engenheiros não vão comprometer-se com um repositório, pelo que a adoção tende a ser o fator limitante, mais do que a ferramenta.

Software de documentação de MSP e o problema do lock-in do fornecedor

As plataformas de documentação pensadas para MSPs são boas nas coisas que é difícil construir por conta própria: relações estruturadas de ativos, integração com o seu RMM e PSA, tratamento de credenciais com trilho de auditoria e separação por cliente com permissões.

O compromisso é que a sua documentação fica moldada pelo modelo de dados deles, e conseguir extraí-la novamente num formato utilizável é frequentemente pior do que o processo de vendas sugere. Exportar normalmente significa um conjunto de registos, em vez dos documentos legíveis que os seus engenheiros realmente usam.

Antes de se comprometer, vale a pena fazer duas perguntas. É possível exportar tudo, incluindo relações e anexos, num formato que continue a ser utilizável se nunca mais comprar outro produto. E consegue manter um único documento padrão que se aplica a todos os clientes, ou o modelo obriga a uma cópia por cliente, reintroduzindo exatamente o problema de que esta página trata.

A segunda pergunta elimina mais produtos do que esperaria. Quando uma plataforma força cópias por cliente, mantenha a biblioteca padrão fora dela, num formato mais simples, e use a plataforma para os dados do património do cliente, que é o que ela faz realmente bem. O nosso modelo de base de conhecimento cobre a estruturação dessa biblioteca padrão, independentemente de onde ela esteja alojada.

O que acontece à documentação quando um cliente sai?

O offboarding é onde a qualidade da documentação se torna visível, normalmente para pessoas que já estão insatisfeitas.

Defina o pack no contrato. Uma posição razoável é que o cliente recebe o seu registo de ativos, diagramas de rede, inventário de licenças, credenciais transferidas de forma segura, o seu registo de diferenças e qualquer documentação pela qual tenha pago como entregável. Você retém os seus runbooks padrão, formatos de relatório e procedimentos internos.

Defina um prazo e um formato na mesma cláusula, porque “a documentação será fornecida” é onde começam as disputas. Trinta dias e um formato especificado são normais.

Faça a entrega das credenciais através de um processo adequado, e não por uma folha de cálculo, e registe o que foi transferido e quando, porque esse registo protege ambas as partes se algo for acedido mais tarde.

Quando a saída é uma transferência para outro fornecedor em vez de ser “in-house”, um handover estruturado é consideravelmente mais barato do que uma entrega “em massa” de documentos, e o nosso SOP de transferência de conhecimento explica como executar um.

Posso obter modelos de documentação de MSP em PDF?

O PDF é adequado para dois destes e errado para os restantes.

Adequado para documentos para o cliente: o relatório mensal, a revisão trimestral e o resultado da auditoria do local. São instantâneos de um momento e congelá-los está correto, e devem incluir a sua marca.

Inadequado para runbooks, registo de diferenças e registo de ativos, que mudam e que precisam de ser pesquisáveis. Uma biblioteca de runbooks em PDF é uma versão mais lenta do problema do exemplo acima, porque um PDF não consegue dizer ao leitor que está desatualizado.

Para a biblioteca padrão, use o que os seus engenheiros vão realmente procurar sob pressão e mantenha uma única cópia. Para entregáveis ao cliente, gere o PDF a partir dessa fonte, em vez de manter uma cópia separada.

Como manter a biblioteca padrão atualizada em todos os clientes

Toda a estrutura depende de a biblioteca padrão ser realmente mantida, e a razão pela qual normalmente não é é que atualizar um runbook significa alguém tirar screenshots, recortar e reescrever passos para uma ferramenta que já sabe como usar.

A Trupeer AI remove grande parte disso. Um engenheiro executa a tarefa uma vez em câmara e o resultado é um runbook formatado com os passos e os ecrãs já no lugar, pronto para rever em vez de escrever. Uma atualização de dez runbooks passa a ser um dia, em vez de um trimestre.

Registe. Dê marca. Traduza. Trupeer.

Para material para o cliente, a marca é importante comercialmente, e os kits de marca fazem com que o relatório e o guia que o cliente recebe pareçam ter vindo de si, e não de um modelo. Documentação e documentação técnica mantêm a biblioteca padrão e os registos do património do cliente juntos, e o criador de SOP cobre os próprios runbooks. As instruções de configuração estão no guia de configuração do modelo de documento.

Perguntas Frequentes

Existem modelos gratuitos de documentação de MSP em PDF?

As estruturas nesta página são gratuitas para copiar, e a divisão sensata é manter os runbooks e os registos num formato pesquisável enquanto exporta os relatórios para o cliente em PDF. Não há download bloqueado e não há formulário. Se quiser um PDF da biblioteca padrão para referência, gere-o a partir da sua cópia em direto, em vez de o manter separadamente.

Quais são os melhores modelos gratuitos de documentação de MSP?

O melhor conjunto é o mais pequeno que vai manter atualizado: dez a quinze runbooks que cubram os seus maiores volumes de tickets, um pack de onboarding, um documento de escalonamento, um formato de registo de diferenças e três formatos de relatório para o cliente. Avalie qualquer biblioteca de modelos pela forma como separa o padrão da exceção por cliente, porque é essa parte que determina se sobrevive a trinta clientes.

Onde deve um MSP guardar a sua documentação?

Os dados do património do cliente pertencem a uma plataforma que se integra com o seu RMM e PSA e que trata as credenciais corretamente. A biblioteca padrão pertence onde os engenheiros a vão pesquisar mais rapidamente, o que pode ser a mesma plataforma ou algo mais simples. A pergunta decisiva é se a plataforma lhe permite manter um documento único que se aplica a todos os clientes.

Quanto deve um novo cliente receber de documentação no onboarding?

Nenhuma da sua biblioteca padrão e todos os dados do património dele. Na prática, o entregável de onboarding que o cliente valoriza é o registo de ativos, o diagrama de rede e um resumo simples do que encontrou e do que recomenda. Enviar runbooks no onboarding é um instinto comum e dá o seu método sem retorno comercial.

O cliente é o proprietário da documentação que escrevemos sobre os sistemas dele?

Os dados dele, normalmente sim; o seu método, normalmente não, e o limite deve ser escrito no contrato de prestação de serviços em vez de ser discutido no momento da saída. Os registos de ativos, diagramas, credenciais e configuração descrevem a propriedade dele. Os seus runbooks padrão e formatos de relatório são a sua propriedade intelectual. Peça para que a cláusula seja revista pelo seu próprio advogado, porque a posição varia consoante o contrato e a jurisdição.

Como evitamos que os engenheiros saltem a documentação?

Torne a biblioteca padrão confiável primeiro. Os engenheiros ignoram a documentação porque já esteve errada antes, não porque não gostam de ler. Resolva o problema da cópia única, faça com que os tempos de atendimento convirjam e o comportamento muda por si. Exigir atualizações de documentação apenas no encerramento do ticket só funciona uma vez que a biblioteca valha a pena ser atualizada.