
Gebruik deze sjabloon
Voor managed service providers is documentatie niet alleen een leuke extra - het is het product. Met Trupeer kun je uren besparen op het schrijven van MSP-documentatie door te beginnen met gratis MSP-documentatiesjablonen, ze aan te passen met je brand guidelines en klantdocumentatie om te zetten in video walkthroughs die elke technicus kan gebruiken.
Wat is MSP-documentatie, en waardoor verschilt het?
MSP-documentatie is alles wat een managed service provider opschrijft om de technologie van andere organisaties te beheren: asset registers, netwerkdiagrammen, credentials, runbooks, escalatiepaden, klant-specifieke bijzonderheden en de rapporten en reviews die de klant ziet.
Twee dingen maken het structureel anders dan interne IT-documentatie, en bijna elk sjabloon negeert beide.
Je documenteert omgevingen die je niet bezit. De klant heeft een claim op een deel van wat je schrijft en geen claim op de rest, en die lijn is commercieel, contractueel en op de dag dat de relatie eindigt van belang.
En je documenteert dezelfde procedure tegelijk voor veel omgevingen. Een intern team schrijft één backup restore-runbook. Een MSP schrijft er één en moet die vervolgens waarheidsgetrouw houden voor dertig of veertig omgevingen die op manieren verschillen die niemand zich volledig herinnert.
Het tweede probleem is degene die de marge van een MSP stilletjes opvreet, en daarom begint deze pagina hier. Voor de versie voor één omgeving dekt ons IT-documentatiesjabloon de algemene situatie.
Waarom veertig kopieën van één runbook het echte probleem zijn
Bijna elke MSP begint op dezelfde manier. Bouw een goede set runbooks. Onboard een klant. Kopieer de runbooks naar de map of ruimte van die klant, zodat de engineer die de ticket behandelt alles op één plek heeft. Herhaal.
Het is een begrijpelijke reflex en het levert een langzame ramp op. Na vier jaar met dertig of zo klanten heb je ruim duizend documenten, waarvan de meeste bijna identiek zijn, en geen manier om te zien welke kopie actueel is.
Het probleem is niet dat de documenten slecht zijn. Elke kopie was correct toen die werd gemaakt. Het probleem is dat verbeteringen aan de methode nu dertig keer moeten worden toegepast, en dat ze vijf of tien keer worden toegepast voordat iemand aan iets urgents wordt getrokken.
Wat engineers daarna doen, is het dure deel. Zodra een technicus twee keer is “gebrand” door een runbook dat niet overeenkomt met de omgeving, stopt hij met het lezen van runbooks. Ze werken dan vanuit de basisprincipes, wat langzamer, minder consistent en volledig onzichtbaar is in je rapportage, omdat de ticket nog steeds wordt afgesloten.
Daarom moet de documentatiestructuur van een MSP de standaardupdate op één plek mogelijk maken. Alles hieronder volgt daaruit.
Zo pas je dit sjabloon aan in Trupeer
Stap 1: Open het gedeelte Templates
Ga in het hoofdmenu naar het gedeelte Templates.

Stap 2: Selecteer en open een sjabloon
Klik op een willekeurig sjabloon waarmee je wilt werken om het te openen.

Stap 3: Breid de sjabloonweergave uit
Indien nodig, breid de sjabloonweergave uit om de volledige indeling en details duidelijk te zien.

Stap 4: Bewerk het sjabloon
Klik op Edit om te beginnen met het aanpassen van het geselecteerde sjabloon.

In de editor kun je:
Nieuwe secties toevoegen
Opmaakregels definiëren of bijwerken
Een logo toevoegen en de positie en gerelateerde instellingen aanpassen
Stap 5: Sla je aangepaste sjabloon op
Nadat je alle noodzakelijke wijzigingen hebt gemaakt, klik je op Save om het bijgewerkte sjabloon op te slaan als je eigen sjabloon.

Stap 6: Bekijk en verfijn het sjabloon
Als je wilt zien hoe je aangepaste sjabloon eruitziet, open dan de Preview.

Vanaf het preview-scherm kun je indien nodig direct doorgaan met het maken van aanpassingen, zodat het sjabloon precies verschijnt zoals jij het wilt.
Met MSP-documentatiesjablonen kun je:
Uren besparen op schrijven: Sla de lege pagina over met structuren die zijn gebouwd voor MSP-activiteiten.
MTTR verlagen: Duidelijke documentatie helpt elke tech support om elke klant snel te helpen.
In lijn blijven met je merk: Pas je logo, fonts en kleuren toe met de brand kit van Trupeer.
Techs sneller onboarden: Nieuwe technici komen snel op gang met duidelijke, op video gebaseerde documentatie.
Klaar blijven voor audits: Ingebouwde secties ondersteunen SOC 2, ISO 27001 en klant-audits.
Bereik globale teams: Vertaal MSP-docs naar 65+ talen met één klik.
Goede MSP-documentatie is wat een managed services-bedrijf schaalbaar maakt. Gebruik deze sjablonen om elke klant, elk systeem en elke procedure duidelijk en consistent vast te leggen.
Documenteer de standaard één keer, registreer alleen de afwijking
Eén standaardbibliotheek. Eén kopie van elk document. Versiebeheerd, eigendom van jou en de enige plek waar de methode bestaat.
Daarna, per klant, één kort document waarin wordt vastgelegd waar die klant afwijkt van de standaard, en niets anders. Geen kopie van het runbook met bewerkingen. Een lijst met uitzonderingen.
Het afwijkingenregister van de klant is de hele truc. Als de klant een ander backupproduct gebruikt, is dat één rij. Als hun firewall een andere leverancier heeft, is dat één rij. Als hun finance director elk werk buiten kantooruren moet goedkeuren, is dat één rij. Alles wat niet in het register staat is standaard volgens definitie, wat betekent dat een engineer twee documenten leest in plaats van één map door te zoeken in de hoop dat de kopie daarin actueel is.
De registers blijven klein. In de praktijk zit een volwassen klant ergens tussen acht en twintig rijen, en het schrijven van één register brengt meestal drie of vier afwijkingen aan het licht die nergens waren vastgelegd.
Er is nog een tweede voordeel dat later zichtbaar wordt. Een korte lijst van alles wat niet-standaard is aan een klant is een heel goed sales- en margedocument. Afwijkingen zijn waar je tijd naartoe gaat.
Het afwijkingenregister van de klant, en wat erin komt
Eén rij per afwijking, vijf velden.
Wat verschilt. Afgezet tegen de standaard, dus “backup is Datto in plaats van onze standaard Veeam” in plaats van “gebruikt Datto”.
Welk standaarddocument het beïnvloedt. De referentie, zodat een engineer die het runbook leest hiernaar kan worden verwezen.
Waarom. Klantvoorkeur, overgenomen van een vorige provider, een compliance-eis, een technische beperking. Dit veld bepaalt of de afwijking de moeite waard is om te verwijderen.
Sinds wanneer, en wanneer beoordeeld. Een datum. Afwijkingen die bij onboarding worden overgenomen blijven vaak jaren bestaan, omdat niemand ze opnieuw bekijkt.
Inspanning of risico. Een korte notitie over wat het je kost. Dit is wat het register ook een commercieel document maakt, naast een technisch document.
Voeg een header toe met de naam van de klant, de versie van de standaardbibliotheek waartegen dit register is geschreven, en de account owner. Beoordeel de registers elk kwartaal. Afwijkingen zonder reden en zonder kosten zijn kandidaten om te standaardiseren, en dat is meestal het documentatiewerk met de hoogste opbrengst dat een MSP kan doen.
Welke documenten heeft een MSP echt nodig, per categorie
Categorie | Documenten | Standaard of per klant | Wie ziet het |
|---|---|---|---|
Klantomgeving | Asset register, netwerkdiagram, licentie-inventaris, credentials | Per klant, en het is de data van de klant | Intern, op verzoek gedeeld |
Procedures | Runbooks, restore-procedures, onboarding- en offboardingstappen | Standaard, met afwijkingen vermeld | Alleen intern |
Klant-specifieke zaken | Afwijkingenregister, contactpersonen, escalatie, goedkeuringsregels, voorwaarden voor buiten kantooruren | Per klant | Intern, deels gedeeld |
Wijzigingen en incidenten | Method of procedure per wijziging, incidentrecords, post-incident reviews | Per gebeurtenis | Intern, selectief gedeeld |
Klantgerichte documenten | Maandrapport, kwartaal business review, site audit, onboarding checklist | Standaardformat, klantdata | Klant |
Commercieel | Service description, SLA, pricing model, contractschema’s | Standaard | Klant |
Interne business | Employee handbook, security policy, tooling standards | Standaard | Intern |
De meeste MSP’s zijn sterk in de eerste en vijfde rij en zwak in de derde, wat precies andersom is, omdat de derde rij is wat de tweede rij bruikbaar maakt.
Twee van deze hebben hun eigen sjablonen die je direct kunt gebruiken. De credentials en licentie-inventaris hebben een natuurlijke plek in onze application and credentials register, en de runbooks zelf volgen de structuur in ons IT SOP-sjabloon.
Gratis MSP-documentatiesjablonen: de standaardbibliotheek om te bouwen
Kopieer vanaf hier. Dit is de minimale standaardbibliotheek, en die is kleiner dan de meeste MSP’s verwachten.
Onboarding pack. Discovery checklist, site audit, asset capture, credential capture, initiële vulling van het afwijkingenregister, review van de eerste maand. Eén document, één keer per klant uitvoeren.
Runbooks, één per terugkerende taak. Backup restore, user create en disable, mailbox restore, endpoint rebuild, password reset, VPN-toegang, printer deployment, certificate renewal, patch exception. Begin met de tien taken die de meeste tickets opleveren, in plaats van te proberen alles te dekken.
Escalatie en on-call. Hoe een ticket escaleert, wie per niveau wordt gebeld, wat een noodsituatie is en de autorisatieregel voor buiten kantooruren.
Incident en change. Een format voor post-incident reviews en een method of procedure-format voor geplande wijzigingen op klantinfrastructuur.
Klantgerichte rapporten. Maandrapport, kwartaal business review en een output van een site audit. Vast format, klantdata ingevuld.
Offboarding pack. Wat de klant ontvangt, wat jij behoudt, in welk format en tegen wanneer. Opgesteld voordat je het nodig hebt.
Sjabloon voor afwijkingenregister. De vijf velden hierboven.
Kopieer naar hier. Tien tot vijftien runbooks plus zes staande documenten is een werkende bibliotheek. De reflex om eerst veertig runbooks te schrijven is de reden dat de meeste MSP-documentatieprojecten in maand twee vastlopen.
Interne en externe MSP-documentatie, en wie wat beheert
Het onderscheid dat de meeste gidsen maken is intern versus klantgericht, wat handig is om de toon te bepalen. Het belangrijkere onderscheid is eigendom, en dat wordt pas echt bij offboarding.
In grote lijnen, en dit verschilt per contract en jurisdictie, is de data van de klant ook van de klant: asset registers die hun apparatuur beschrijven, hun netwerk-topologie, hun credentials, hun licentie-entitlements, hun configuratie. Jij houdt het als service provider, niet als eigenaar.
Jouw methode is van jou: de standaard runbooks, de rapportformats, je build standards, je pricing model, je interne procedures. Een klant die vertrekt heeft geen recht op je runbookbibliotheek.
Het afwijkingenregister zit ongemakkelijk ertussen, daarom is het de moeite waard om het expliciet te benoemen in je contract. Het beschrijft de omgeving van de klant, wat pleit voor hun kant, maar het is geschreven tegen jouw standaarden, wat pleit voor een versie met weggelakte delen.
Leg dit schriftelijk vast in de service agreement in plaats van op het moment van vertrek. Deze pagina is geen juridisch advies en de positie verschilt per contract en jurisdictie, dus laat je advocaat de eigendoms- en retourclausules van de documentatie beoordelen. Eén keer doen kost een uur. Het tijdens offboarding doen kost aanzienlijk meer, zoals hieronder.
De MSP met 1.360 documenten en negen verouderde runbooks
Thornbury IT leverde managed services aan vierendertig klanten met tweeëntwintig medewerkers, waarvan negen engineers. Bij elke onboarding kopieerden ze hun runbook-set naar de ruimte van de nieuwe klant, wat tegen jaar vier betekende dat het ongeveer veertig documenten per klant was en in totaal zo’n duizend driehonderdzestig.
Het probleem kwam aan het licht tijdens een incident. Een engineer voerde een mislukte backup uit voor één klant volgens het restore-runbook van die klant, waarin een Veeam job naming convention werd genoemd. De klant was veertien maanden eerder overgestapt naar een ander backupproduct. Het standaard runbook was bijgewerkt. De kopie in de map van die klant niet.
Daarna bekeken ze de restore-runbooks van twaalf klanten. Negen daarvan verschilden van de huidige standaard, en vijf van die negen verschillen waren simpelweg verouderd in plaats van bewust.
De meetbare kosten zaten in de afhandelingstijd. De gemiddelde afhandelingstijd van tier two binnen het bedrijf was zevenenveertig minuten. Voor de klanten waarvan de runbooks verouderd waren was het eenenzeventig minuten, omdat de engineers op die accounts stopten met het vertrouwen van de documentatie en het elke keer opnieuw uitzochten.
Daarnaast was een klant in jaar drie vertrokken en had gevraagd om hun documentatie. Thornbury stuurde de map van de klant, die hun eigen standaard runbooks bevatte, gemengd met het asset register en de credentials van de klant. Niemand had ooit de grens getrokken. Het argument over waar de klant recht op had duurde zes weken en betrof de advocaten van beide bedrijven.
Het opnieuw opbouwen kostte een maand tijd van één persoon. Eén standaardbibliotheek, één kopie, versiebeheer. Per klant alleen een afwijkingenregister. De mediane registerlengte was elf rijen.
Duizend driehonderdzestig documenten werden veertig standaarddocumenten en vierendertig registers, dus in totaal zevenenzeventig vier. De afhandelingstijd van tier two convergeerde naar vierendertig minuten over alle accounts. En het offboarding pack werd vanaf dat moment gedefinieerd in het contract: de klant ontvangt het asset register, de credentials, diagrammen en hun afwijkingenregister, en Thornbury behoudt de standaardbibliotheek.
Zijn er gratis MSP-documentatiesjablonen op GitHub?
Ja, en ze zijn het bekijken waard met realistische verwachtingen.
Wat je zult vinden zijn community-repositories met runbook-collecties, PowerShell-scriptbibliotheken met ingebouwde documentatie, markdown-gebaseerde documentatiekaders en af en toe een volledige documentatiestructuur die door een MSP is gepubliceerd als recruitment- of marketingactie. Als je zoekt naar MSP-runbooks of IT-documentatie naast markdown of docs-as-code, kom je het grootste deel daarvan tegen.
Wat echt nuttig is in die repositories is structuur en dekking: een lijst met de runbooks die een competente MSP bijhoudt is een goede checklist voor die van jou. Wat zelden nuttig is, is de inhoud, omdat runbooks specifiek zijn voor een tool stack, en een restore-procedure voor iemands anders backupproduct en RMM dichter bij een uitgewerkt voorbeeld ligt dan bij een sjabloon.
Twee waarschuwingen. Controleer de licentie voordat je iets opneemt in een commerciële documentatiebibliotheek, omdat permissive vaak voorkomt maar niet universeel is. En pas nooit een repository aan die echte klantidentifiers, netwerkdetails of iets dat op credentials lijkt bevat, want dat komt in openbare repositories vaker voor dan het zou moeten.
De docs-as-code-aanpak zelf, oftewel markdown in versiebeheer, is op zichzelf een legitieme optie voor een MSP en lost het single-copy-probleem elegant op. Het zwakke punt is dat engineers onder tijdsdruk niet zullen committen aan een repository, waardoor adoptie meestal de beperkende factor is in plaats van tooling.
MSP-documentatiesoftware en het vendor lock-in-probleem
De documentatieplatforms die zich richten op MSP’s zijn goed in de dingen die je niet eenvoudig zelf kunt bouwen: gestructureerde asset-relaties, integratie met je RMM en PSA, het verwerken van credentials met een audit trail en per-klant scheiding met permissies.
De trade-off is dat je documentatie wordt gevormd door hun datamodel, en dat het eruit halen in een bruikbare vorm vaak slechter is dan het verkoopproces suggereert. Export betekent meestal een set records in plaats van de leesbare documenten die je engineers daadwerkelijk gebruiken.
Stel jezelf twee vragen voordat je commit. Kun je alles exporteren, inclusief relaties en bijlagen, in een formaat dat nog steeds bruikbaar is als je nooit een ander product koopt. En kun je één standaarddocument onderhouden dat voor alle klanten geldt, of dwingt het model een kopie per klant af, waardoor exact het probleem van deze pagina opnieuw ontstaat.
Die tweede vraag sluit meer producten uit dan je zou verwachten. Als een platform kopieën per klant afdwingt, houd dan de standaardbibliotheek buiten het platform, in iets eenvoudigers, en gebruik het platform voor klantomgeving-data, waar het echt goed in is. Onze knowledge base template dekt het structureren van die standaardbibliotheek, waar die ook terechtkomt.
Wat gebeurt er met documentatie als een klant vertrekt?
Offboarding is waar de kwaliteit van documentatie zichtbaar wordt, meestal bij mensen die al ontevreden zijn.
Definieer de pack in het contract. Een redelijke positie is dat de klant hun asset register, netwerkdiagrammen, licentie-inventaris, credentials die veilig zijn overgedragen, hun afwijkingenregister en alle documentatie waarvoor ze hebben betaald als deliverable ontvangt. Jij behoudt je standaard runbooks, rapportformats en interne procedures.
Zet een tijdslimiet en een format in dezelfde clausule, omdat “documentatie wordt geleverd” is waar discussies beginnen. Dertig dagen en een gespecificeerd format is normaal.
Doe de credential handover via een goed proces in plaats van via een spreadsheet, en leg vast wat is overgedragen en wanneer, omdat die registratie beide partijen beschermt als er later iets wordt ingezien.
Als het vertrek een overdracht naar een andere provider is in plaats van in-house, is een gestructureerde handover aanzienlijk goedkoper dan een document dump, en onze knowledge transfer SOP legt uit hoe je er één uitvoert.
Kan ik MSP-documentatiesjablonen als PDF krijgen?
PDF is geschikt voor twee van deze en onjuist voor de rest.
Geschikt voor klantgerichte documenten: het maandrapport, de kwartaalreview en de output van de site audit. Dat zijn snapshots van een moment en ze bevriezen is correct, en ze moeten je branding dragen.
Onjuist voor runbooks, het afwijkingenregister en het asset register, die allemaal veranderen en allemaal doorzoekbaar moeten zijn. Een PDF-runbookbibliotheek is een langzamere versie van het probleem in het uitgewerkte voorbeeld hierboven, omdat een PDF een lezer niet kan vertellen dat het verouderd is.
Gebruik voor de standaardbibliotheek wat je engineers daadwerkelijk zullen zoeken onder tijdsdruk, en houd één kopie aan. Voor klantdeliverables genereer je de PDF vanuit die bron in plaats van een aparte versie te onderhouden.
Zo houd je de standaardbibliotheek actueel voor elke klant
De hele structuur hangt af van het feit dat de standaardbibliotheek echt wordt bijgehouden, en de reden dat dat meestal niet gebeurt is dat het bijwerken van een runbook betekent dat iemand screenshots maakt, bijsnijdt en stappen herschrijft voor een tool die ze al weten hoe ze moeten gebruiken.
Trupeer AI haalt het grootste deel daarvan weg. Een engineer voert de taak één keer uit op camera en de output is een opgemaakt runbook met de stappen en schermen al op hun plek, klaar om te reviewen in plaats van om te schrijven. Een refresh van tien runbooks wordt een dag in plaats van een kwartaal.
Leg het vast. Branded het. Vertaal het. Trupeer het.
Voor klantgericht materiaal is branding commercieel belangrijk, en brand kits zorgen ervoor dat het rapport en de gids die een klant ontvangt eruitzien alsof ze van jou komen in plaats van uit een sjabloon. Documentation en technical documentation houden de standaardbibliotheek en de klantomgeving-records bij elkaar, en de SOP creator behandelt de runbooks zelf. Setup-instructies staan in de document template setup guide.
Veelgestelde vragen
Zijn er gratis MSP-documentatiesjablonen in PDF?
De structuren op deze pagina zijn gratis om te kopiëren, en de logische splitsing is om runbooks en registers in iets doorzoekbaars te houden terwijl je klantgerichte rapporten exporteert naar PDF. Er is geen afgeschermde download en geen formulier. Als je een PDF van de standaardbibliotheek voor referentie wilt, genereer die dan vanuit je live kopie in plaats van die apart te onderhouden.
Wat zijn de beste gratis MSP-documentatiesjablonen?
De beste set is de kleinste die je actueel zult houden: tien tot vijftien runbooks die je hoogste ticketvolumes dekken, een onboarding pack, een escalatiedocument, een afwijkingenregister-format en drie klantgerichte rapportformats. Beoordeel elke sjabloonbibliotheek op basis van of die de standaard scheidt van de uitzondering per klant, omdat dat bepaalt of het blijft werken voor dertig klanten.
Waar moet een MSP zijn documentatie bewaren?
Klantomgeving-data hoort in een platform dat integreert met je RMM en PSA en credentials goed afhandelt. De standaardbibliotheek hoort waar engineers die het snelst zullen doorzoeken, wat hetzelfde platform kan zijn of iets eenvoudigers. De doorslaggevende vraag is of het platform je toestaat om één document te onderhouden dat voor alle klanten geldt.
Hoeveel documentatie moet een nieuwe klant krijgen bij onboarding?
Geen van je standaardbibliotheek en alle eigen data van hun omgeving. In de praktijk is de onboarding deliverable die een klant waardeert het asset register, het netwerkdiagram en een simpele samenvatting van wat je hebt gevonden en wat je aanbeveelt. Runbooks sturen bij onboarding is een veelvoorkomende reflex en het geeft je methode weg zonder commercieel rendement.
Bezit de klant de documentatie die we schrijven over hun systemen?
Hun data meestal wel, jouw methode meestal niet, en de grens moet je vastleggen in de service agreement in plaats van die bij vertrek te betwisten. Asset registers, diagrammen, credentials en configuratie beschrijven hun eigendom. Je standaard runbooks en rapportformats zijn jouw intellectuele eigendom. Laat de clausule door je eigen advocaat beoordelen, omdat de positie verschilt per contract en jurisdictie.
Hoe zorgen we dat engineers documentatie niet overslaan?
Maak de standaardbibliotheek eerst betrouwbaar. Engineers slaan documentatie over omdat die eerder fout is geweest, niet omdat ze niet graag lezen. Los het single-copy-probleem op, zorg dat de afhandelingstijden samenkomen en het gedrag verandert vanzelf. Alleen vereisen dat documentatie-updates bij het afsluiten van een ticket worden gedaan werkt pas als de bibliotheek de moeite waard is om bij te werken.