Een IT-dienstverlener moet volledig transparant zijn over incidenten en storingen die jouw bedrijfsvoering raken. Dat betekent: tijdig melden, duidelijk communiceren over de oorzaak en impact, en proactief informeren over de voortgang van de oplossing. Transparantie is geen gunst, maar een basisvereiste van een betrouwbare IT-partner. In dit artikel beantwoorden we de meest gestelde vragen over wat je mag verwachten als het misgaat.
Wat mogen organisaties verwachten bij een IT-storing?
Als je te maken krijgt met een IT-storing, mag je van jouw IT-dienstverlener verwachten dat hij direct in actie komt, jou actief informeert en werkt aan een snelle oplossing. Je hoeft niet zelf achter informatie aan te gaan. Een professionele IT-partner neemt de regie en houdt jou op de hoogte, ook als er nog geen definitieve oplossing is.
Concreet betekent dit dat je recht hebt op een eerste reactie binnen de afgesproken responstijd, een duidelijke inschatting van de impact op jouw systemen en een realistische verwachting over wanneer de storing verholpen is. Hoe snel en volledig jouw IT-dienstverlener reageert, zegt veel over de kwaliteit van de samenwerking.
Goede afspraken over responstijden en communicatie leg je vast in een servicecontract of SLA. Als je dat nog niet hebt, is een storing een goed moment om daar alsnog over in gesprek te gaan. Weet je niet precies wat er in zo’n contract thuishoort? Dan is het slim om dat samen met jouw IT-partner door te nemen voordat er iets misgaat.
Hoe snel moet een IT-dienstverlener een storing melden?
Een IT-dienstverlener moet een storing bij jou melden zodra hij er zelf van op de hoogte is, en dat in de meeste gevallen binnen dertig minuten tot een uur na ontdekking. Bij kritieke storingen die jouw bedrijfsprocessen direct lamleggen, geldt: hoe sneller, hoe beter. Wachten op een volledig beeld voordat je communiceert, is een veelgemaakte fout.
De eerste melding hoeft niet compleet te zijn. Het gaat erom dat jij weet dat er iets aan de hand is, dat jouw IT-dienstverlener ermee bezig is en wanneer je een volgende update kunt verwachten. Dat geeft jou de ruimte om intern te schakelen en eventuele gevolgen te beperken.
Daarna volgen tussentijdse updates op vaste momenten, ook als er weinig nieuws is. Geen nieuws is namelijk geen reden om stil te blijven. Een korte melding als “We zijn er nog mee bezig en verwachten binnen twee uur uitsluitsel” is veel waardevoller dan stilte.
Welke informatie hoort bij een goede incidentmelding?
Een goede incidentmelding bevat minimaal vier elementen: wat er precies is misgegaan, welke systemen of gebruikers er last van hebben, wat de verwachte impact is op jouw werkzaamheden en wat de IT-dienstverlener doet om het op te lossen. Zonder die vier punten kun je als ontvanger niet goed inschatten wat je moet doen.
Naast deze basisinformatie hoort er ook een tijdlijn in te zitten. Wanneer is de storing ontdekt? Wanneer is er voor het eerst actie ondernomen? En wanneer verwacht de IT-dienstverlener de storing te hebben verholpen? Die tijdlijn helpt jou om te bepalen of er intern actie nodig is, bijvoorbeeld het informeren van klanten of het activeren van een noodprocedure.
Na afloop van een incident hoort er ook een afsluitende melding te komen. Daarin legt jouw IT-dienstverlener uit wat de oorzaak was, hoe de oplossing eruitziet en welke stappen worden genomen om herhaling te voorkomen. Dat laatste, de zogenoemde root cause analysis, is een teken van professionaliteit en serieuze kwaliteitsborging.
Wat is het verschil tussen transparantie en te veel informatie delen?
Transparantie betekent dat je alle informatie deelt die voor jou relevant is om de situatie te begrijpen en de juiste beslissingen te nemen. Te veel informatie delen betekent dat je overladen wordt met technische details die niets toevoegen aan jouw begrip of handelingsvermogen. Het verschil zit in de relevantie voor de ontvanger.
Als jouw IT-dienstverlener je vertelt dat er een “failover naar de secundaire node heeft plaatsgevonden vanwege een TCP-timeout op poort 443”, dan is dat technisch correct maar voor de meeste mensen volkomen onbegrijpelijk. Wat je wilt weten is: werkt mijn e-mail nog? Kan mijn team gewoon doorwerken? Hoe lang duurt dit?
Goede communicatie bij storingen is afgestemd op jouw niveau en jouw behoeften. Technische details zijn relevant voor de IT-afdeling of voor het evaluatiegesprek achteraf, niet voor de eerste melding midden op een werkdag. Een IT-dienstverlener die dat onderscheid maakt, toont niet alleen technische kennis maar ook communicatieve volwassenheid.
Hoe herken je een IT-partner die transparant omgaat met storingen?
Een transparante IT-partner meldt storingen proactief, communiceert helder en neemt verantwoordelijkheid, ook als het zijn eigen fout betreft. Je herkent zo’n partner aan het feit dat je zelden zelf hoeft te bellen om te vragen wat er aan de hand is, omdat hij jou al heeft geïnformeerd voordat jij het merkt.
Concrete signalen van transparantie zijn:
- Proactieve meldingen zonder dat jij eerst contact hoeft op te nemen
- Duidelijke en begrijpelijke communicatie, zonder onnodig jargon
- Eerlijke inschatting van hersteltijden, ook als die langer zijn dan gewenst
- Een evaluatie na elk significant incident met concrete verbeterpunten
- Vastgelegde afspraken over communicatie in jouw servicecontract
Naast deze signalen is het ook waardevol om te kijken hoe een IT-dienstverlener omgaat met fouten die hij zelf heeft gemaakt. Erkent hij die direct en werkt hij aan een oplossing? Of verdwijnt hij in de verdediging? Dat tweede is een waarschuwingssignaal dat je serieus moet nemen.
Bij Symbis werken we als managed IT-partner met heldere afspraken over incidentcommunicatie, zodat jij altijd weet waar je aan toe bent. Wil je weten hoe wij omgaan met storingen en wat je van ons mag verwachten? Neem contact op en we vertellen je er graag meer over.
Veelgestelde vragen
Wat moet ik doen als mijn IT-dienstverlener mij niet proactief informeert tijdens een storing?
Neem zelf direct contact op en vraag expliciet om een statusupdate, een inschatting van de impact en een verwachte hersteltijd. Documenteer tegelijkertijd alle communicatiemomenten, zodat je achteraf een duidelijk beeld hebt van hoe de dienstverlener heeft gehandeld. Gebruik dit als aanleiding om in gesprek te gaan over het vastleggen van concrete communicatieafspraken in je SLA, zodat dit in de toekomst niet opnieuw voorkomt.
Wat hoort er minimaal in een SLA te staan over incidentcommunicatie?
Een goede SLA beschrijft minimaal de maximale responstijd per prioriteitsniveau (bijvoorbeeld kritiek, hoog, medium en laag), de frequentie van tussentijdse updates en de verplichting tot een afsluitend incidentrapport met root cause analysis. Daarnaast moet er staan via welk kanaal communicatie plaatsvindt — denk aan e-mail, telefoon of een ticketsysteem — en wie binnen jouw organisatie als contactpersoon fungeert. Zonder deze afspraken op papier heb je geen stevige basis om je IT-partner op aan te spreken.
Hoe vaak mag ik tussentijdse updates verwachten tijdens een langdurige storing?
Bij een kritieke storing die jouw bedrijfsprocessen direct raakt, mag je minimaal elk uur een update verwachten, zelfs als er inhoudelijk weinig nieuws is. Bij minder urgente storingen is een update elke twee tot vier uur een redelijke standaard. Het belangrijkste is dat de frequentie vooraf is afgesproken en dat jouw IT-dienstverlener zich daaraan houdt, zodat jij intern kunt blijven schakelen zonder zelf steeds te hoeven bellen.
Wat is een root cause analysis en waarom zou ik daar als klant om vragen?
Een root cause analysis (RCA) is een gestructureerde analyse die na een incident in kaart brengt wat de werkelijke oorzaak was, hoe het incident zich heeft ontwikkeld en welke maatregelen worden genomen om herhaling te voorkomen. Als klant geeft dit jou inzicht in de kwaliteit en betrouwbaarheid van de IT-omgeving die voor jou wordt beheerd. Vraag hier standaard om na elk significant incident — een IT-partner die dit weigert of structureel achterwege laat, neemt kwaliteitsborging niet serieus genoeg.
Kan ik mijn IT-dienstverlener aansprakelijk stellen als hij niet communiceert volgens de afgesproken SLA?
Ja, als er aantoonbaar is afgeweken van de afspraken in de SLA, heb je in principe grond om de dienstverlener hierop aan te spreken en eventueel aanspraak te maken op een compensatieregeling, zoals een servicekrediet of korting op de factuur. Zorg er wel voor dat je de afwijkingen goed documenteert met tijdstempels en communicatielogboeken. Raadpleeg bij grotere schade een juridisch adviseur om te beoordelen welke stappen passend zijn in jouw specifieke situatie.
Hoe onderscheid ik bij het selecteren van een nieuwe IT-partner de écht transparante aanbieders van de rest?
Vraag tijdens het selectieproces expliciet naar een concreet voorbeeld van hoe de aanbieder een recent incident heeft afgehandeld: wat was de storing, hoe en wanneer is er gecommuniceerd en wat stond er in het eindrapport? Een transparante IT-partner kan dit zonder aarzeling beantwoorden en toont je bij voorkeur een geanonimiseerd incidentrapport als bewijs. Vage antwoorden, het ontbreken van gestructureerde incidentrapportages of het ontwijken van de vraag zijn directe waarschuwingssignalen.
Wat zijn veelgemaakte fouten van organisaties zelf bij het omgaan met IT-storingen?
Een veelgemaakte fout is het ontbreken van een intern escalatieproces: wie belt er met de IT-partner, wie informeert de medewerkers en wie neemt beslissingen over noodprocedures? Zonder die rolverdeling verlies je kostbare tijd. Daarnaast wachten veel organisaties te lang met het opvragen van een SLA of het bespreken van communicatieafspraken — dat doe je het best vóór een storing, niet erna. Tot slot wordt de waarde van het afsluitende incidentrapport onderschat; gebruik dit actief als input voor verbetergesprekken met je IT-partner.