
Use este modelo
Para prestadores de serviços geridos, os SOPs são o sistema operativo do negócio. Com a Trupeer, pode poupar horas na documentação para MSP começando com um modelo gratuito de SOP para MSP, personalizando-o com as suas diretrizes de marca e usando o nosso criador de SOP com IA para transformar cada procedimento num vídeo walkthrough claro.
O que é um modelo de SOP para MSP e em que difere?
Um procedimento padrão de um MSP é o método escrito para uma tarefa que a sua equipa executa repetidamente em ambientes de clientes: restaurar uma caixa de correio, desativar um colaborador que saiu, reconstruir um endpoint, tratar um relatório de phishing.
O conteúdo técnico sobrepõe-se quase na totalidade com um IT SOP interno. São adicionadas duas coisas, e ambas decorrem do facto de estar a trabalhar ao abrigo de um acordo comercial no património de outra entidade.
Cada procedimento tem uma componente comercial. Em algum ponto do trabalho, passa do que o contrato cobre para o que deve ser faturado ou orçamentado, e a pessoa que está nessa linha é um técnico no meio de um ticket.
E cada procedimento tem transições fora da sua organização. Passos que exigem que o cliente aprove, forneça acesso, esteja presente ou tome uma decisão, e essas pessoas não respondem aos seus níveis de serviço.
Um SOP interno não tem esse problema. Ignore ambos e terá procedimentos tecnicamente excelentes e silenciosamente caros, que é o tema da maior parte desta página.
Onde se perdem margens em MSP: dentro do ticket
Pergunte a um responsável por um MSP para onde vai a margem e ouvirá falar de salários, ferramentas ou clientes que exigem demasiado suporte. São reais e visíveis, por isso são geridos.
A fuga que não é visível acontece dentro de tickets legítimos.
Um engenheiro pega num pedido dentro do âmbito, resolve-o corretamente e, enquanto está com sessão iniciada, nota que há outra coisa errada. A estrutura do Teams do cliente está um caos, ou as regras da firewall são uma década de exceções acumuladas. Gastam noventa minutos a corrigir porque obviamente precisava de correção e registam isso no mesmo ticket.
Nada disso é má conduta. É um bom engenheiro a fazer uma boa ação. É também trabalho não faturado num contrato de preço fixo e, como está dentro de um ticket dentro do âmbito, nenhum relatório alguma vez o mostrará.
Pergunte aos engenheiros porquê e a resposta é consistente. Ninguém lhes disse onde está a linha. A descrição do serviço é um documento comercial na pasta do contrato, e os runbooks não dizem nada sobre se.
Assim, o limite comercial é decidido dezenas de vezes por semana por quem quer que esteja a tratar do ticket. Esse é um problema de conceção do procedimento, não um problema de disciplina.
Como personalizar este modelo na Trupeer
Passo 1: Abrir a secção de Modelos
Vá à secção de Modelos no menu principal.

Passo 2: Selecionar e abrir um modelo
Clique em qualquer modelo com que queira trabalhar para o abrir.

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

Passo 4: Editar 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: Guardar 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é-visualizar e afinar 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 pretende.
Com um modelo de SOP para MSP pode:
Poupar horas na escrita: Ignore a página em branco com uma estrutura criada para procedimentos de MSP.
Reduzir o MTTR: SOPs claros ajudam qualquer técnico de suporte a qualquer cliente, rapidamente.
Manter-se alinhado com a marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.
Onboarding de técnicos mais rápido: Combine SOPs com vídeos walkthrough para acelerar a integração de novos técnicos.
Estar pronto para auditorias: Secções incorporadas suportam SOC 2, ISO 27001 e auditorias de clientes.
Atingir equipas globais: Traduza SOPs para MSP para 65+ idiomas com um clique.
Porque é que cada procedimento de MSP precisa de um limite de âmbito
A correção é pequena e entra no procedimento, em vez de entrar numa política que ninguém lê.
Cada SOP para MSP afirma, no topo, o que cobre ao abrigo do contrato e onde termina. Não em termos gerais. De forma suficientemente específica para que um engenheiro de nível um, às quatro e trinta numa sexta-feira, consiga dizer de que lado da linha está sem ter de telefonar a ninguém.
A redação que funciona define um limite em vez de uma permissão. "Este procedimento cobre a restauração de uma única caixa de correio a partir de cópia de segurança. Restaurar mais de cinco caixas de correio, ou qualquer restauração que exija um novo trabalho de cópia de segurança, está fora do âmbito e requer uma nota de âmbito."
Isso faz três coisas que uma descrição de serviço não consegue. Leva até à pessoa que está a executar o trabalho no momento em que precisa. Usa o vocabulário da tarefa em vez do do contrato. E dá-lhe uma ação, que é levantar uma nota em vez de fazer um julgamento.
Quando o limite é genuinamente ambíguo, diga-o e indique quem decide. A ambiguidade reconhecida é gerível. A ambiguidade não mencionada torna-se aquilo que o engenheiro mais rápido assumiu.
Como marcar um procedimento como incluído, faturável ou com orçamento obrigatório
Três etiquetas, uma por procedimento, por vezes uma por passo quando um procedimento atravessa o limite.
Etiqueta | Significado | O que o engenheiro faz | Onde corre mal |
|---|---|---|---|
Incluído | Abrangido pelo contrato gerido padrão | Faz. Regista no código do contrato | Procedimentos marcados como incluídos que cresceram em âmbito desde que o contrato foi escrito |
Faturável | Faz, mas é trabalho sujeito a cobrança | Diz ao cliente que é faturável antes de começar, regista no código faturável | Engenheiros a fazê-lo sem informar o cliente, o que torna a fatura uma surpresa |
Orçamento obrigatório | Pára. Isto é trabalho de projeto | Levanta uma nota de âmbito, não prossigas | Engenheiros que prosseguem porque é "só vinte minutos" — e nunca são vinte minutos |
A linha do meio precisa de mais cuidado, porque uma etiqueta faturável sem uma instrução de "dizer ao cliente primeiro" gera faturas contestadas, que custam mais à relação do que o trabalho que foi ganho.
Revise as etiquetas anualmente face à descrição de serviço atual, em vez da que estava em vigor quando os runbooks foram escritos. O âmbito vai-se desviando numa direção e, procedimentos marcados como incluídos há três anos, muitas vezes descrevem agora um trabalho consideravelmente maior do que o contrato cobre.
Dependências do lado do cliente e os tickets que envelhecem
O segundo campo que a maioria dos procedimentos de MSP não tem é um marcador em cada passo que exige alguém fora da sua organização.
Marque-o e indique uma janela de resposta esperada. Aprovação do cliente para desativar um colaborador que saiu, acesso físico para uma troca de hardware, uma decisão sobre se deve restaurar ou investigar.
Depois, dê ao engenheiro uma instrução: estacionar o ticket em vez de esperar por ele. Isso parece administrativo e move dois números. A idade do ticket deixa de ser inflacionada por tempo que nunca foi seu, e os engenheiros deixam de manter trabalho a meio nas suas cabeças.
Seja específico na redação: "Requer autorização do cliente. Esperado dentro de um dia útil. Estacione o ticket e defina um lembrete em vez de o manter em aberto."
Quando um cliente é repetidamente lento na mesma dependência, isso aparece como um padrão nos tickets estacionados e deve constar na revisão trimestral como uma restrição de serviço, em vez de constar nos tempos de atendimento dos seus engenheiros.
Modelo gratuito de SOP para MSP: a estrutura para copiar
Copie daqui. Os campos marcados com um asterisco são as adições específicas para MSP.
Cabeçalho. Número do procedimento e título, escrito com o verbo em primeiro. Responsável. Data da última verificação, ou seja, quando alguém o executou pela última vez. Etiqueta de âmbito: incluído, faturável ou orçamento obrigatório. Código de faturação, quando faturável. Tempo estimado do engenheiro. Aplicabilidade ao cliente, ou seja, todos os clientes ou exceções nomeadas.
Limite de âmbito. Um ou dois parágrafos: o que cobre e as condições específicas em que se torna faturável ou exige um orçamento.
Gatilho. O pedido ou evento que inicia este procedimento.
Não executar se. Condições em que o procedimento está incorreto, incluindo onde se aplica uma divergência do cliente.
Pré-requisitos. Acesso, ferramentas, autorização do cliente, informação necessária. Marque todos os itens do lado do cliente.
Passos. Numerados, uma ação por cada, com o resultado esperado. Marque qualquer passo que exija ação do cliente com a janela de resposta esperada.
Verificação. Como sabe que o resultado aconteceu, incluindo quaisquer efeitos atrasados, como replicação ou sincronização durante a noite.
Comunicação com o cliente. O que diz ao cliente, quando e com que palavras. Esta é uma secção que os SOPs internos não precisam de todo.
Escalonamento. Quem, por que via, e em que ponto.
Divergências. Um apontador para o registo de divergências do cliente em vez de uma lista, uma vez que é no registo que vivem as diferenças por cliente.
Copie daqui. O último ponto importa estruturalmente: este procedimento existe uma vez, como padrão, e a variação por cliente pertence no registo descrito nos nossos modelos de documentação para MSP. Copiar o procedimento por cliente é o que torna uma biblioteca impossível de manter.
O MSP que estava a oferecer 285 horas por mês
A Barrowden Technology prestava serviços geridos para vinte e seis clientes com catorze engenheiros, em contratos de preço fixo com trabalho de projeto faturado separadamente.
A margem bruta nos contratos geridos tinha descido de cinquenta e oito por cento para quarenta e quatro ao longo de dois anos. Aumentos salariais e ferramentas explicaram aproximadamente um terço da queda. O resto ficou sem explicação.
O diretor-geral analisou um mês de registos de tempo, mil oitocentas e quarenta horas de engenheiro, e reviu uma amostra de duzentas linha a linha face à descrição do serviço.
Trinta e uma das duzentas descrições de trabalho estavam fora do âmbito do contrato e nunca tinham sido orçamentadas ou faturadas. Extrapolado para o mês, isso dá cerca de duzentas e oitenta e cinco horas, a um custo interno de cerca de trinta e oito libras por hora, ou seja, aproximadamente dez mil oitocentas libras por mês e algo perto de cento e trinta mil por ano.
Quase todos os casos tinham começado dentro de um ticket legítimo dentro do âmbito. A entrada individual mais elevada foi de noventa minutos a reconstruir a estrutura do canal do Teams de um cliente, registada num ticket que começou como um problema de permissão de uma única caixa de correio.
Todos os engenheiros entrevistados disseram a mesma coisa. Não sabiam onde estava a linha, nunca tinham lido a descrição de serviço 6 páginas e os runbooks não diziam nada sobre isso.
A mudança foram três campos em cada runbook: a etiqueta de âmbito, o código de faturação e a frase do limite de âmbito. Os passos do lado do cliente foram marcados com janelas de resposta esperadas e uma instrução para estacionar.
Nos dois trimestres seguintes, o trabalho fora do âmbito nas entradas amostradas caiu de cerca de quinze por cento para cerca de quatro. A receita faturável fora dos contratos geridos aumentou em aproximadamente seis mil e duzentas libras por mês, que é o mesmo trabalho que passou a ser pago em vez de ser recusado. A margem dos contratos geridos recuperou para cinquenta e três por cento.
O efeito secundário foi o único que ninguém previu. A idade média dos tickets diminuiu, porque os tickets à espera dos clientes passaram a ser estacionados em vez de ficarem nas filas dos engenheiros com aspeto de estarem ativos.
Quais SOPs é que um MSP deve escrever primeiro, e porquê
Não os interessantes. Escreva os procedimentos onde o volume de tickets é alto, ou onde o limite de âmbito é genuinamente pouco claro, porque são nesses dois locais que um procedimento se paga a si próprio.
Por volume, normalmente são pedidos de passwords e acessos, processamento de novos colaboradores e de colaboradores que saíram, restaurações de caixas de correio e de ficheiros, reconstrução e transição de endpoints, implementação de impressoras e periféricos, e problemas de VPN ou acesso remoto.
Por ambiguidade de âmbito, é tudo o que envolve outro fornecedor, tudo o que toca num sistema que o cliente adicionou sem lhe dizer, migrações de dados de qualquer dimensão, tudo o que um cliente descreve como uma "alteração rápida" e resposta a incidentes de segurança, onde o limite entre resposta ao abrigo do contrato e remediação de projeto é simultaneamente pouco claro e caro.
A resposta a incidentes de segurança vale a pena ser escrita cedo por uma segunda razão. É o procedimento mais provável de ser executado sob pressão por quem estiver disponível e é também o que os clientes mais frequentemente pedem para ver. Combine-o com um método de procedimento para qualquer remediação planeada na infraestrutura do cliente.
Dez a quinze procedimentos que cubram a lista de volumes é uma biblioteca funcional. Tentar quarenta primeiro é a razão pela qual estes projetos estagnam.
Como escrever um procedimento de SOP para MSP, passo a passo
Registe alguém a executar a tarefa num ambiente real de cliente, ao ritmo normal, sem interrupções.
Escreva os passos a partir da gravação e, depois, elimine todos os passos que sejam navegação em vez de ação ou decisão. Adicione o resultado esperado a cada um dos que permanecerem.
Agora escreva o limite de âmbito e escreva-o com alguém que compreenda o contrato, em vez de o fazer sozinho. Este é o passo que os engenheiros não conseguem fazer sem ajuda e que as pessoas comerciais não conseguem fazer sem ajuda, e demora cerca de dez minutos por procedimento com ambos presentes na sala.
Marque os passos do lado do cliente e dê a cada um uma janela de resposta esperada.
Defina a etiqueta de âmbito e, quando relevante, o código de faturação.
Depois, peça a alguém que não tenha feito a tarefa para a seguir num ambiente de um cliente diferente. Esse último detalhe importa, porque um procedimento que só funciona no património para o qual foi escrito não é um procedimento padrão.
O que é que a ISO 9001 e as auditorias de clientes esperam de um SOP?
A ISO 9001 não prescreve um modelo. Pede que a informação documentada necessária para a operação dos processos esteja disponível, seja adequada, suficiente e controlada, o que na prática significa que cada procedimento tem um identificador, uma versão, um responsável, uma aprovação e um mecanismo que impede o uso de cópias ultrapassadas.
Para um MSP, o teste mais frequente não é a sua própria certificação, mas as auditorias dos seus clientes. Clientes empresariais e qualquer pessoa com um quadro de segurança vão pedir para ver procedimentos específicos, mais frequentemente provisionamento e revogação de acessos, resposta a incidentes, gestão de alterações, verificação de cópias de segurança e restauro, e como trata as credenciais deles.
O que esses avaliadores procuram é pouco glamoroso. Evidência de que o procedimento é seguido e não apenas escrito, o que significa tickets que o referenciam e uma data da última verificação recente. Um responsável nomeado. E um histórico de versões que mostra que muda.
Dois pontos práticos. Mantenha as versões voltadas para o cliente dos procedimentos de segurança separadas das internas, para as poder partilhar sem expor toda a sua biblioteca. E tenha cuidado ao partilhar procedimentos que contenham especificidades de outro cliente, o que é um risco real quando o detalhe da divergência está no procedimento em vez de estar num registo separado.
Nada aqui é aconselhamento de conformidade e os requisitos variam consoante a norma, o quadro e o contrato do cliente. Confirme as especificidades com quem detém a sua certificação.
Como é que os SOPs para MSP se relacionam com a sua biblioteca padrão
O SOP é um tipo de documento dentro da estrutura mais ampla. A distinção que vale a pena manter clara é entre o método e o património.
O método é padrão, existe uma vez e é seu. Procedimentos, formatos de relatório, padrões de construção. Um cliente a sair não leva isto consigo.
O património é por cliente e, em grande parte, é deles. Registos de ativos, credenciais, diagramas e o registo de divergências que regista onde o ambiente deles difere do seu padrão.
Os procedimentos referenciam o património em vez de o conterem. Quando um procedimento precisa de um valor específico do cliente, aponta para o registo. Essa regra única é o que permite que um procedimento sirva trinta clientes e os nossos modelos de documentação para MSP cobrem o registo e a biblioteca mais ampla. Quando um procedimento precisa de uma referência rápida no ponto de trabalho, um job aid é muitas vezes melhor do que alongar o SOP.
Posso obter um modelo de SOP para MSP em Word ou Excel?
O Word ou o Google Docs servem para o próprio procedimento, e a estrutura acima é colada diretamente. Bloqueie o bloco do cabeçalho para que os autores não possam omitir a etiqueta de âmbito, já que é o campo mais provável de ser ignorado por quem está a escrever a velocidade.
O Excel serve para o registo do procedimento, que é a lista de todos os SOPs com responsável, etiqueta de âmbito, código de faturação, data da última verificação e volume mensal de tickets. Duas colunas nessa folha fazem o trabalho: a proporção de procedimentos verificados nos últimos seis meses e a contagem por etiqueta de âmbito, que lhe diz à primeira vista quanto da sua biblioteca é ambígua do ponto de vista contratual.
O PDF serve para as versões que partilha com clientes durante uma auditoria, exportadas a partir da cópia em direto em vez de serem mantidas separadamente. Para a estrutura geral de SOP fora do contexto de MSP, o nosso SOP template cobre isso.
Gerar o SOP a partir de uma gravação em vez de um modelo
A razão pela qual as bibliotecas de procedimentos de MSP continuam a ser pequenas não é discordância sobre o que escrever. É que escrever um runbook significa que um engenheiro faz screenshot e descreve uma tarefa que poderia ter concluído quatro vezes no mesmo período.
A Trupeer AI remove esse custo. O engenheiro executa a tarefa uma vez em câmara e o resultado é um procedimento formatado com passos e ecrãs já capturados, que ele verifica em vez de escrever. Quinze procedimentos passam a ser duas semanas em vez de um trimestre — a diferença entre uma biblioteca que existe e uma que está sempre prestes a existir.
Registe. Dê marca. Traduza. Trupeer.
O criador de SOP cobre os próprios procedimentos e, quando o resultado vai para um cliente, os kits de marca significam que chega com aspeto de ser da sua empresa em vez de uma exportação genérica. O documentação técnica mantém os procedimentos e os registos do património juntos. As instruções de configuração estão no guia de configuração do template de documento.
Perguntas Frequentes
Existe um modelo gratuito de SOP para MSP em Word?
A estrutura acima é colada diretamente no Word ou no Google Docs, incluindo a etiqueta de âmbito e os campos de dependência do cliente que os modelos gerais de SOP não têm. Não há download com acesso restrito e não há formulário. Bloqueie o cabeçalho quando o guardar como o seu template, porque a etiqueta de âmbito é o campo que fica em branco.
Existe um modelo gratuito de SOP para MSP em Excel?
O Excel é melhor para o registo do que para o procedimento. Uma linha por SOP com responsável, etiqueta de âmbito, código de faturação, data da última verificação e volume mensal de tickets. Ordene por volume de tickets para ver quais procedimentos merecem atenção e conte por etiqueta de âmbito para perceber quanto da sua biblioteca nunca teve o seu limite comercial definido.
Existe um modelo gratuito de SOP para MSP em PDF?
Exporte a partir da sua cópia em direto quando um cliente pedir para ver um procedimento durante uma auditoria e mantenha a versão de trabalho editável. Uma biblioteca de procedimentos em PDF tem o mesmo problema que qualquer conjunto de documentos congelados: não consegue dizer ao leitor que está desatualizada.
Onde posso encontrar um modelo geral de SOP em Word?
Se quiser a estrutura padrão sem os campos específicos para MSP, o nosso SOP template cobre isso, e o IT SOP template cobre operações técnicas, incluindo como decidir quais procedimentos valem a pena escrever.
O que é um modelo de procedimento padrão passo a passo?
É o formato de SOP mais comum: ações numeradas, uma por linha, cada uma com o resultado que deve ver. Serve para tarefas lineares com um início e fim conhecidos, que é a maior parte do trabalho de MSP. É o formato errado para diagnóstico, em que a próxima ação depende do que acabou de encontrar, e nesses casos é melhor como uma árvore de decisão.
Quantos SOPs é que um MSP precisa?
Dez a quinze a cobrir os seus maiores volumes de tickets, além de resposta a incidentes e tudo o que o limite de âmbito não esteja claro. Para além de cerca de trinta, a manutenção torna-se a restrição e será melhor ter menos procedimentos mantidos verdadeiramente atuais do que uma grande biblioteca que ninguém confia.
Quem deve escrever SOPs para MSP?
Um engenheiro que executa a tarefa, com o limite de âmbito acordado em conjunto com quem detém o contrato. Essa combinação é incomum e é exatamente o ponto, porque um procedimento tecnicamente correto sem limite comercial é o que gera a fuga no exemplo trabalhado.
Como é que impedimos os engenheiros de fazer trabalho fora do âmbito?
Diga-lhes onde está a linha no momento em que estão em cima dela, o que significa no procedimento e não numa descrição de serviço. Depois, dê-lhes uma ação que não seja uma decisão de julgamento: levantar uma nota de âmbito. A maior parte do trabalho fora do âmbito é feita por pessoas conscienciosas que não conseguem dizer, e a correção é informação em vez de imposição.