Branded framework · UptimePilot
UptimePilot Automation Ladder
Van handmatig naar self-healing in zes stappen — het implementatietraject dat mkb-MSPs doorlopen om routine-incidenten autonoom af te handelen.
Het MSP Automation Maturity Model beschrijft vijf niveaus — van volledig reactief naar self-healing. De UptimePilot Automation Ladder beschrijft hoe je er daadwerkelijk komt. Niet als theoretisch stappenplan, maar als implementatietraject dat is opgebouwd uit de meest voorkomende valkuilen en versnellers in de Nederlandse mkb-MSP markt. De Ladder heeft zes stappen — Stap 0 tot en met Stap 5 — en begint vóór de eerste policy is geschreven.
In één zin: de UptimePilot Automation Ladder is een zes-stappentraject — baselining, signaallaag, eerste policies in assisted mode, expansie, autonoom L1, en self-healing — waarmee mkb-MSPs van handmatige incidentafhandeling naar gecontroleerde self-healing groeien.
1. Ladder vs. Maturity Model
Het MSP Automation Maturity Model beantwoordt de vraag: op welk niveau opereert mijn MSP nu? Het is een diagnostisch instrument. Het geeft een eerlijk beeld van de huidige situatie en helpt vergelijken met de sector.
De UptimePilot Automation Ladder beantwoordt een andere vraag: hoe kom ik van mijn huidige niveau naar Level 5? Het is een prescriptief kader. Geen analyse van waar je bent — een beschrijving van wat je doet om er te komen.
De twee zijn complementair. Het Maturity Model vertelt je welke stap van de Ladder relevant is. De Ladder vertelt je wat die stap inhoudt in de praktijk.
| Kenmerk | Maturity Model | Automation Ladder |
|---|---|---|
| Perspectief | Diagnostisch | Prescriptief |
| Vraag | Waar ben ik? | Hoe kom ik er? |
| Eenheid | Niveaus (1–5) | Stappen (0–5) |
| Aanvangspunt | Meting | Implementatie |
| Bruikbaar voor | Zelfevaluatie | Implementatieplan |
2a. Stap 0 — Baselining
Meten wat er werkelijk speelt
Vóórdat er een policy wordt geschreven, wordt in kaart gebracht welke incidenten het meeste tijd kosten, hoe vaak ze voorkomen, en welke klantomgevingen het meest vatbaar zijn.
Stap 0 is het fundament van alles wat volgt. Niet de meest zichtbare stap — maar de stap die bepaalt of de rest effectief is. Veel MSPs weten dat ze te veel tijd kwijt zijn aan tickets. Weinigen weten welke tickettypes het meest voorkomen en hoelang afhandeling per type duurt. Die analyse is Stap 0.
Concrete acties
- Inventarisatie van tickethistorie: welke incidenttypes komen voor, met welke frequentie, en hoelang duurt afhandeling per type?
- Klantprofiel-analyse: welke klantomgevingen genereren het hoogste volume aan herhalende incidenten?
- Top-10 kandidaten identificeren: de tien incidenttypes die samen de grootste tijdsbesparing opleveren als ze worden geautomatiseerd.
- Monitoringkwaliteit beoordelen: produceert de huidige monitoring bruikbare signalen, of is er sprake van alert fatigue die de baselining vertekent?
Resultaat van deze stap
Een gedocumenteerd top-10 van automatiseringskandidaten met frequentie, tijdsduur en prioritering. Dit document stuurt alle volgende stappen.
2b. Stap 1 — Signaallaag
Detectie die werkt als basis voor actie
Monitoring is geconfigureerd om bruikbare signalen te produceren — niet alleen alertvolume. Elke alert is kandidaat voor een policy.
Op Stap 1 is monitoring geen eindpunt maar een beginpunt. Het doel is niet meer alerts — het doel is betere signalen. Een signaal is bruikbaar als het (a) een specifieke conditie beschrijft, (b) een herleidbaar patroon heeft, en (c) een actie impliceert die altijd hetzelfde is. Als aan die drie criteria wordt voldaan, is een alert klaar om een policy te worden.
Concrete acties
- Alert-configuratie aanpassen op basis van de top-10 uit Stap 0: ruis reduceren, relevante signalen versterken.
- Elke alert koppelen aan een incidentcategorie: is dit een bekende conditionele situatie, of een uniek geval?
- Drempelwaarden valideren: levert de huidige configuratie false positives op die engineers afleiden van echte incidenten?
- Signaalstructuur documenteren: voor elke alert uit de top-10, welke informatie heeft een engineer nodig om te handelen? Die informatie moet in het signaal zitten.
Resultaat van deze stap
Geconfigureerde monitoring met lage false-positive rate voor de top-10 incidenttypes. Elke alert heeft een duidelijk gedefinieerde conditie die bruikbaar is als policy-input.
2c. Stap 2 — Eerste policies
Assisted mode: het systeem stelt voor, een engineer keurt goed
De vijf hoogste prioriteiten uit de top-10 worden omgezet in policies. Het systeem detecteert, stelt de remediatie-actie voor, maar handelt pas als een engineer goedkeurt.
Stap 2 introduceert het policy-mechanisme in een modus die vertrouwen opbouwt zonder risico. In assisted mode voert het systeem niets uit zonder menselijke goedkeuring — maar het doet al het voorwerk. De engineer ziet: het gesignaleerde probleem, de voorgestelde actie, en waarom die actie past bij de conditie. In de praktijk duurt beoordeling seconden, niet minuten. En na vier weken weet je precies welke policies consistent worden doorgestuurd zonder aanpassing — die zijn klaar voor Stap 3.
Concrete acties
- Voor elk van de vijf geselecteerde incidenttypes: schrijf de policy (conditie → actie → verificatie).
- Activeer assisted mode: systeem detecteert, stelt actie voor, wacht op goedkeuring.
- Vier weken monitoren: foutrate meten, aanpassingen bijhouden, vertrouwen documenteren.
- Na vier weken evalueren: welke policies worden consistent doorgestuurd zonder aanpassing? Die zijn kandidaat voor autonome uitvoering.
Resultaat van deze stap
Vijf actieve policies in assisted mode. Gedocumenteerde foutrate per policy. Inzicht in welke policies klaar zijn voor Stap 3.
2d. Stap 3 — Expansie
Bewezen policies autonoom, nieuwe policies in assisted mode
Policies die vier weken in assisted mode hebben gedraaid met een foutrate onder de vijf procent, worden overgeschakeld naar autonome uitvoering. Tegelijkertijd worden nieuwe incidenttypes in assisted mode geïntroduceerd.
Op Stap 3 draait de organisatie in twee parallelle modi. De bewezen top-5 handelt autonoom af. Vijf nieuwe kandidaten zitten in assisted mode. Dat parallelisme is bewust: het laat zien dat autonoom werken werkt — terwijl nieuwe policies veilig worden gevalideerd. De engineers merken de eerste echte tijdsbesparing: routine-incidenten worden afgehandeld zonder dat ze erbij betrokken zijn.
Concrete acties
- Stap 3a: policies met aangetoond vertrouwen overschakelen naar autonome uitvoering.
- Stap 3b: vijf nieuwe incidenttypes uit de resterende top-10 in assisted mode activeren.
- Rapportage inrichten: welke incidenten worden autonoom afgehandeld, hoelang duurt afhandeling, wat is de MTTR-verbetering?
- Klantencommuncatie voorbereiden: klanten informeren over welke incidenten autonoom worden afgehandeld en hoe de audit-trail werkt.
Resultaat van deze stap
Tien actieve policies — vijf autonoom, vijf in assisted mode. Eerste meetbare MTTR-verbetering. Engineers voeren minder routine-L1-werk uit.
2e. Stap 4 — Autonoom L1
Engineers vrij voor L2/L3 en klantwerk
De volledige top-10 van incidenttypes is gedekt. Bekende L1-incidenten worden autonoom afgehandeld. Engineers besteden hun tijd aan L2/L3-escalaties, klantprojecten en policy-beheer.
Stap 4 is de operationele kanteling. Engineers verwerken geen routinetickets meer — die worden autonoom afgehandeld. Wat overblijft zijn de incidenten die daadwerkelijk menselijke beoordeling vereisen: onbekende patronen, complexe escalaties, en klantspecifieke situaties. De tijdsbesparing is nu structureel en meetbaar.
Concrete acties
- Resterende incidenttypes uit de top-10 afronden: alle tien zijn in de policy-laag gedekt.
- After-hours protocol herzien: welke incidenten vereisen nog stand-by? Voor de gedekte L1-types is dat niet meer nodig.
- Maandelijkse policy-review instellen: welke nieuwe patronen komen op? Welke policies moeten worden aangepast?
- Engineercapaciteit heroriënteren: welke L2/L3-verbeteringen of klantprojecten worden nu mogelijk met de vrijgekomen tijd?
Resultaat van deze stap
Volledig autonome L1-afhandeling voor de top-10 incidenttypes. Meetbare reductie van after-hours piketbelasting. Engineers werken structureel op hoger niveau.
2f. Stap 5 — Self-healing
Continue optimalisatie, engineers op strategisch werk
De policy-scope groeit continu. Het systeem identificeert nieuwe automatiseringspatronen. Engineers werken aan policykwaliteit, uitzonderingsbeheer en klantspecifieke uitbreidingen.
Stap 5 is geen eindbestemming maar een operationele toestand. De L1-loop is gesloten — bekende incidenten worden autonoom afgehandeld zonder dat een engineer betrokken hoeft te zijn. Wat er daarna overblijft is kwalitatief ander werk: policies verfijnen, scope uitbreiden, uitzonderingen analyseren, en klanten in staat stellen hun eigen infrastructuurgedrag beter te begrijpen. Het team is kleiner geworden niet doordat er mensen zijn ontslagen, maar doordat de beheerslast per engineer structureel is gedaald.
Concrete acties
- Maandelijkse policy-expansie: welke nieuwe incidenttypes zijn kandidaat? Welke bestaande policies kunnen worden uitgebreid?
- Uitzondering-analyse: welke incidenten escaleert het systeem structureel? Wat vertellen die over hiaten in de policy-scope?
- Klant-rapportage verfijnen: policies zijn zichtbaar voor klanten — hoe vertaal je autonoom handelen naar begrijpelijke rapportage?
- Capaciteitsgroei zonder personeelsgroei: met elke nieuwe klant schaalt de policy-laag mee zonder lineaire engineercapaciteit toe te voegen.
Resultaat van deze stap
Operationeel self-healing voor bekende L1-incidenttypes. Policy-scope groeit per kwartaal. Klanten ervaren hogere uptime met minder zichtbare interventie.
3. Wat verandert per stap
De tabel toont de kernverandering per stap op vier dimensies: wie de beslissing neemt, hoe snel incidenten worden afgehandeld, welke belasting after-hours bestaat, en waar engineers hun tijd aan besteden.
| Stap | Beslissing | MTTR (richtwaarde) | After-hours | Engineerwerk |
|---|---|---|---|---|
| 0 — Baseline | Handmatig | >4 uur | Crisis | Meten en prioriteren |
| 1 — Signaallaag | Handmatig | 1–4 uur | Stand-by | Alert-triage |
| 2 — Eerste policies | Assisted | <30 min | Gereduceerd | Policy-review |
| 3 — Expansie | Gemengd | <15 min | Minimaal | Policy-uitbreiding |
| 4 — Autonoom L1 | Autonoom (L1) | <5 min | Zeldzaam | L2/L3 en projecten |
| 5 — Self-healing | Autonoom | <2 min | Geen routine | Policy-optimalisatie |
Indicatieve ranges op basis van patronen in mkb-MSP omgevingen. Werkelijke tijden variëren op basis van infrastructuurhomogeniteit, incidenttype en policykwaliteit.
4. Typische doorlooptijden
De snelheid waarmee een MSP de Ladder doorloopt hangt primair af van drie variabelen: de homogeniteit van de klantinfrastructuur, de kwaliteit van de monitoringsignalen bij aanvang, en de bereidheid van engineers om autonome uitvoering te accepteren.
Stap 0 → Stap 1
2–4 weken
Baselining en monitoring-configuratie. Sneller bij MSPs met bestaande monitoringtooling en gestructureerde tickethistorie. Langzamer bij gefragmenteerde systemen.
Stap 1 → Stap 2
2–4 weken
Eerste vijf policies schrijven en activeren in assisted mode. Bottleneck is de precisie van de conditiedefinitie — een te brede conditie triggert te veel; een te smalle conditie mist echte incidenten.
Stap 2 → Stap 3
4–8 weken
Vier weken assisted mode, twee tot vier weken expansie. De vaststelling van het vertrouwen in Stap 2 is het kritieke pad. Organisaties die te snel doorschakelen verliezen vertrouwen bij engineers en klanten.
Stap 3 → Stap 4
4–8 weken
Resterende top-10 afronden en after-hours protocol herzien. Sneller bij MSPs met uniforme klantomgevingen.
Stap 4 → Stap 5
Doorlopend
Stap 5 is geen eindpunt maar een toestand. De policy-scope groeit per kwartaal. Er is geen "klaar"-moment — alleen een continue expansie van de autonome afhandelingslaag.
Totaal Stap 0 → Stap 4: drie tot zes maanden in een gemiddelde mkb-MSP omgeving. Stap 5 volgt daarna als doorlopende operationele toestand — geen eindpunt, wel een structureel ander soort werk.
5. Veelgestelde vragen
Moet ik bij Stap 0 beginnen, ook als ik al monitoring heb?
Ja. De baselining van Stap 0 is niet hetzelfde als "monitoring installeren". Het gaat om het in kaart brengen van welke incidenttypes het meest frequent voorkomen, hoelang afhandeling duurt, en welke klantomgevingen het meest vatbaar zijn. Zonder die baseline is het onmogelijk om policies op te bouwen die daadwerkelijk de hoogste tijdsbesparing opleveren. Monitoring hebben is een voorwaarde voor Stap 1 — de analyse van wat die monitoring oplevert is Stap 0.
Hoe lang duurt een typische doorloop van Stap 0 naar Stap 4?
In omgevingen met een relatief uniforme klantinfrastructuur en een duidelijke top-10 van herhalende incidenten: drie tot zes maanden voor de eerste autonome uitvoering op Stap 4. De grootste vertraging zit niet in de techniek maar in het opbouwen van vertrouwen — zowel intern (engineers die autonome uitvoering moeten accepteren) als extern (klanten die begrijpen wat er autonoom wordt uitgevoerd en waarom dat veilig is). Stap 2 en 3 zijn bewust ontworpen om dat vertrouwen te laten groeien aan de hand van behaalde resultaten.
Wat is het verschil tussen de Automation Ladder en het MSP Automation Maturity Model?
Het MSP Automation Maturity Model beschrijft vijf niveaus en helpt je bepalen op welk niveau je MSP nu opereert. De UptimePilot Automation Ladder beschrijft het traject dat je doorloopt — de stappen die je neemt om van je huidige niveau naar Level 5 te komen. Het model is diagnostisch. De ladder is prescriptief. Ze verwijzen naar hetzelfde eindpunt maar vanuit een ander perspectief: waar sta je nu versus hoe kom je daar.
Kan ik stappen overslaan als mijn organisatie al verder is?
In theorie wel. In de praktijk levert overslaan bijna altijd problemen op — niet omdat de techniek het niet aankan, maar omdat de governance-basis ontbreekt. Stap 2 (eerste policies) is de fundering voor Stap 3 en 4. Wie direct naar Stap 4 springt zonder die fundering, bouwt autonome uitvoering op basis van aannames die nooit zijn gevalideerd. De stappen zijn ontworpen om vertrouwen op te bouwen aan de hand van bewijs — niet om zo snel mogelijk klaar te zijn.
Wat gebeurt er na Stap 5?
Stap 5 is geen eindpunt maar een operationele toestand. Daarna verschuift het werk naar het continu verfijnen van policies, het uitbreiden van de policy-scope naar nieuwe incidenttypes, en het beheren van uitzonderingen. In de praktijk functioneert Stap 5 als een ongoing optimalisatiecyclus: het systeem identificeert patronen, stelt policy-aanpassingen voor, een engineer beoordeelt, en de scope groeit. Er is altijd een volgende iteratie.
Hoe weet ik of assisted mode (Stap 2) klaar is voor de overstap naar autonoom (Stap 3)?
Drie signalen: ten eerste, de foutrate op uitgevoerde remediaties in assisted mode is structureel onder de vijf procent over ten minste vier weken. Ten tweede, engineers sturen de voorgestelde actie in meer dan negentig procent van de gevallen door zonder aanpassing. Ten derde, klanten rapporteren geen onverwachte gevolgen van uitgevoerde remediaties. Zijn alle drie aanwezig? Dan is het vertrouwen technisch én organisatorisch aangetoond — en is de overstap naar autonome uitvoering gerechtvaardigd.
UptimePilot begeleidt het hele traject
De Automation Ladder is het implementatiepad dat UptimePilot met mkb-MSPs doorloopt. Van baselining en signaallaag tot de eerste autonome remediaties en doorlopende policy-expansie. Elke stap wordt ondersteund door tooling, governance en begeleiding — zodat de overgang naar autonoom werken gecontroleerd en verifieerbaar verloopt.
Plan een gesprek