Incidentmanagement voor digitale platforms: wat je vooraf regelt, bepaalt de schade

Om 09.12 uur valt de checkout uit. Klanten kunnen niet afrekenen, bij de klantenservice loopt de inbox vol en marketing ziet campagnes doorlopen die op dat moment alleen geld kosten. Dan is incidentmanagement geen ver IT-onderwerp meer. Het raakt je omzet, het vertrouwen van klanten en de rust in je team, alle drie op hetzelfde moment.

De vraag is nooit of er een storing komt. Ook prima gebouwde systemen krijgen een release die net verkeerd valt, een database die volloopt, een externe API die ineens drie seconden nodig heeft of een hostingprobleem waar jij niks aan kon doen. Het verschil zit in het halfuur daarna. Weet iedereen wie handelt, wat voorgaat en wat klanten te horen krijgen? Of ontstaat er een wolk van losse berichten, aannames en wachten op de ene persoon die net in een vergadering zit?

Wanneer een technische storing een bedrijfsprobleem wordt

Een incident is zelden gewoon “de site is offline”. Bij een webshop is het een betaling die halverwege afbreekt. Bij een SaaS-platform kan een fout in rechtenbeheer een hele klantorganisatie stilzetten. Bij een uitgever kost een trage site bereik, en daarmee advertentie-inkomsten. En bouw je voor klanten, dan is een storing bij één van hen ook meteen een gesprek over of je het wel onder controle hebt.

Wat het vaak groter maakt, zijn de afhankelijkheden. Een platform is bijna nooit één applicatie op één server. Er hangen hosting, databases, een betaalprovider, mailverkeer, een CRM-koppeling, voorraadbeheer en soms een mobiele app aan vast. De oorzaak zit daarom niet altijd op de plek waar je het symptoom ziet. Een productpagina die traag wordt komt net zo goed door een koppeling die op de achtergrond blijft hangen als door de pagina zelf.

Daarom begint incidentmanagement niet bij code, maar bij overzicht. Welke onderdelen zijn echt bedrijfskritisch? Wat hangt waaraan? Wie kan bij de logs, de infrastructuur en de broncode? Ontbreekt dat, dan gaat het eerste uur van een storing op aan uitzoeken wie welke toegang heeft en waar je moet kijken.

Regie regel je vooraf, niet tijdens de storing

Een werkbare aanpak hoeft niet zwaar te zijn, maar hij moet wel klaarliggen. Een handboek van dertig pagina’s leest niemand om 09.12 uur. Een half A4 met rollen, prioriteiten en telefoonnummers wel.

Eerder zien dan je klanten

Veel organisaties merken een probleem pas als er een mail binnenkomt of de klantenservice aan de bel trekt. Dat is te laat. Monitoring hoort te signaleren dat het platform onbereikbaar is, dat het aantal fouten oploopt, dat pagina’s langzamer worden of dat een belangrijke koppeling stilvalt.

Tegelijk vraagt niet elke melding om dezelfde reactie. Een intern rapport dat een minuut langer doet is iets anders dan klanten die geen bestelling kunnen plaatsen. Koppel je alarmen daarom aan bedrijfsimpact en niet alleen aan technische drempels. Anders krijg je twee problemen in één keer: een team dat alerts wegklikt uit gewoonte, en een echte storing die daar tussenin wegvalt.

Eerst weer open, daarna netjes

Bij een serieus incident is de eerste taak dat klanten weer verder kunnen. Soms betekent dat een release terugdraaien. Soms verkeer omleggen, of een functie die niet in het hoofdproces zit tijdelijk uitzetten zodat de rest overeind blijft.

De echte oorzaak moet je natuurlijk aanpakken, maar dat hoeft niet stap één te zijn. Staat de orderstroom stil, dan telt elke minuut. Een tijdelijke oplossing is prima, op drie voorwaarden: je doet het bewust, je schrijft op wat je hebt gedaan, en er staat een taak klaar om het later goed te regelen. Snel handelen is dus iets anders dan improviseren zonder spoor.

Eén coördinator per incident

Wie aan het debuggen is, kan niet tegelijk interne vragen beantwoorden, klanten bijpraten en beslissen of er opgeschaald wordt. Wijs daarom per incident één coördinator aan. Die bewaakt de prioriteit, haalt de juiste mensen erbij, houdt bij welke acties lopen en zorgt dat wat naar buiten gaat feitelijk blijft.

Dat hoeft geen fulltime rol te zijn en zeker geen nieuwe functie. In kleinere organisaties pakt de technisch verantwoordelijke of een operationeel manager dit er gewoon bij. Belangrijker is dat vooraf vastligt wie mag besluiten om op te schalen, en wie bevoegd is om bijvoorbeeld een release terug te draaien. Die twee vragen kosten anders precies de minuten die je niet hebt.

Communiceren hoort bij het herstel

Stilte tijdens een storing wordt bijna altijd gelezen als “ze hebben geen idee”. Maar elk kwartier een nieuwe technische theorie delen helpt ook niemand. Goede incidentcommunicatie is kort, eerlijk en op tijd.

Zeg wat gebruikers merken, welke onderdelen geraakt zijn, wat er nu gebeurt en wanneer de volgende update komt. Je hoeft de oorzaak nog niet te kennen om iets te kunnen zeggen. “We zien een probleem met inloggen en zijn aan het herstellen, om 10.00 uur laten we weten waar we staan” is beter dan wachten tot het hele verhaal rond is.

Intern werkt het hetzelfde, alleen heeft iedereen iets anders nodig. Sales wil weten wat het wel en niet tegen klanten kan zeggen. De klantenservice wil een status en een antwoord dat ze kunnen voorlezen. Het management wil de impact in euro’s en uren. Geef elke groep precies dat, en niet het volledige technische verhaal waar ze niets mee kunnen.

Heb je veel gebruikers, dan is een losse statuspagina meestal de moeite. Bij een kleinere omgeving is een vaste lijn genoeg, bijvoorbeeld een mail naar de contactpersonen of een vast kanaal in Teams. Wat past hangt af van je aantal klanten en van wat uitval voor hen betekent. Eén ding is niet optioneel: zeg je dat er om 10.00 uur een update komt, dan komt die om 10.00 uur, ook als het nieuws is dat je nog zoekt.

Hosting, development en support moeten aan elkaar vastzitten

Veel storingen duren langer dan nodig doordat de verantwoordelijkheden verdeeld zijn. De ontwikkelaar wijst naar de hoster, de hoster naar een externe koppeling, en de klant zit ondertussen uit te zoeken wie welke toegang heeft. Zolang alles werkt merk je daar niets van. Bij een kritieke storing is het precies de reden dat niemand doorpakt.

Herstel gaat sneller als de partij die de applicatie kent ook in de infrastructuur kan kijken waarop die draait. Dan bekijk je logbestanden, deployments, serverbelasting en koppelingen naast elkaar in plaats van via drie tickets. Dat wil niet zeggen dat één leverancier altijd het antwoord is: in complexe enterprise-omgevingen heb je soms echt specialisten nodig voor losse onderdelen. Maar dan moet wel vastliggen wie de regie heeft zodra er iets misgaat.

Werk je zonder groot intern techteam, dan weegt dat extra zwaar. Een technisch partner die echt verantwoordelijk is, scheelt je de rondgang langs loketten. Bij LJPc zitten ontwikkeling, hosting en support daarom bij elkaar: een melding komt binnen bij mensen die zowel de code als de server kennen. Dat verkort de weg van symptoom naar oorzaak, en het maakt de opvolging na een storing een stuk concreter.

Zet prioriteiten op papier voordat de druk komt

Niet elke storing verdient dezelfde inzet. Maak onderscheid, bijvoorbeeld in drie niveaus: een omzetkritisch proces dat helemaal stilligt, een serieus probleem waar een workaround voor is, en een fout die een klein deel van de gebruikers raakt.

Hang daar concrete afspraken aan. Binnen hoeveel tijd is een melding beoordeeld? Wie bel je buiten kantooruren, en op welk nummer? Wanneer gaat het management mee? En wanneer mag iets gewoon wachten tot maandag? Een SLA helpt daarbij, maar alleen als de afspraken kloppen met hoe je platform er echt uitziet. Bij een SaaS-omgeving hangt dat bijvoorbeeld direct samen met de hosting die je kiest.

Een mooie reactietijd is weinig waard als niemand weet wie bij DNS, de cloudaccounts of het dashboard van de betaalprovider kan. Loop die praktische kant dus ook langs. Zijn de toegangen op orde? Staan de juiste telefoonnummers in de lijst? Zit er kennis in één hoofd die nergens is opgeschreven? Dat soort details bepaalt in de praktijk of een incident beheersbaar blijft.

Van storing naar iets dat beter wordt

Na het herstel komt het stuk dat het vaakst op de lijst blijft staan. Het platform loopt weer, de druk valt weg, iedereen pakt het eigen werk op. Juist dan kun je voorkomen dat hetzelfde over drie maanden opnieuw gebeurt.

Ga na een noemenswaardig incident een half uur met elkaar zitten. Niet om iemand aan te wijzen, maar om het proces te verbeteren. Wanneer begon het eigenlijk? Waarom zagen we het pas op dat moment? Wat ging goed in de communicatie? Welke beslissing bleef hangen, en waarom? En welke maatregel houdt dit scenario weg, technisch of organisatorisch?

Soms zit de oplossing in code of infrastructuur. Soms is het een monitor die er nog niet was, een extra teststap voor livegang of een escalatieschema dat eindelijk klopt. Kleine dingen, maar ze tellen op als je ze consequent doorvoert. Op een bepaald moment merk je dat incidentmanagement geen brandje blussen meer is, maar de manier waarop je platform stap voor stap betrouwbaarder wordt.

Streven naar nul storingen heeft geen zin. Streven naar storingen die je snel ziet, gecontroleerd aanpakt en helder uitlegt wel. Dat geeft je team rust, je klanten vertrouwen en jezelf de ruimte om aan iets anders te werken dan aan de vorige brand.