Incidentbeheer begint bij een eenvoudige afspraak: als een klant, gebruiker of collega een probleem meldt, hoort die melding op één plek terecht te komen. Bij ons is dat Zoho Desk. Een mail wordt een ticket, een interne melding kan handmatig worden vastgelegd en reacties blijven bij het ticket staan. Zo werken we niet vanuit losse inboxen of herinneringen, maar vanuit één gesprekslijn.
Dat klinkt administratief, maar het is vooral praktisch. Een ticket bevat de melding, de contactgegevens, de status, de communicatie en de keuzes die onderweg gemaakt zijn. Als er later iemand anders moet meekijken, hoeft die niet eerst het halve kantoor af te lopen om te reconstrueren wat er is gezegd.
Waarom dit in een SLA thuishoort. Een van de belangrijkste redenen om een SLA (Service Level Agreement, ofwel servicelevelovereenkomst) met ons af te sluiten, is de zekerheid dat er iemand klaarstaat als er iets misgaat. Software valt nu en dan om, ook goede software. Het verschil zit in hoe snel er iemand naar kijkt, hoe duidelijk je hoort wat er gebeurt en hoe zeker je weet dat het probleem echt wordt opgelost. Paraat staan om problemen op te lossen is een kernonderdeel van onze dienstverlening, en dit artikel beschrijft hoe we dat doen.
Vier niveaus voor één eerste oordeel. De eerste medewerker die een melding ziet, classificeert het ticket. Dat is geen definitief oordeel voor de eeuwigheid, maar wel de start van rustig en passend handelen. We gebruiken vier basisniveaus:
| Niveau | Wanneer |
|---|---|
| Critical / Kritiek | Een probleem in een product waardoor de meerderheid van de gebruikers het product niet kan gebruiken. |
| Severe / Ernstig | Een probleem dat belangrijke processen verstoort en waarvoor geen bruikbaar alternatief beschikbaar is. |
| Small / Gering | Een kleine fout of onvolkomenheid met beperkte impact op het gebruik. |
| Change request / RFC | Een verzoek om functionaliteit die nog niet bestaat, of om een wijziging in functionaliteit die technisch gezien goed werkt. |
In Zoho Desk maken we die classificatie zichtbaar in het onderwerp en de prioriteit. Dat is bewust eenvoudig gehouden. Het belangrijkste is niet dat het systeem er indrukwekkend uitziet, maar dat iedereen snel ziet wat voor soort melding voorligt.
De extra beveiligingsvraag
Naast de gewone impactvraag stellen we bij elk incident een tweede vraag: kan dit invloed hebben op de vertrouwelijkheid, integriteit of beschikbaarheid van gegevens van een klant of van Bronscode?
Als het antwoord daarop "mogelijk" is, behandelen we het als een potentieel beveiligingsincident en escaleren we direct. Dat doen we niet omdat elk vermoeden meteen een ramp is, maar omdat de eerste minuten en uren belangrijk zijn. Goedbedoeld zelf onderzoek kan sporen veranderen, gegevens verder blootstellen of de situatie onduidelijker maken.
Daarom geldt bij mogelijke beveiligingsincidenten: meld wat je ziet en onderneem daarna geen eigen actie totdat het incident is geclassificeerd en er een responsplan ligt. Niet verder klikken, niets verwijderen, geen snelle patch "om alvast iets te doen". Eerst bepalen wat er aan de hand kan zijn, wie moet meedoen en welke communicatie passend is.
Kernpunt: bij een mogelijk beveiligingsincident: melden wat je ziet, en dan geen eigen actie tot er een classificatie en een responsplan is.
Datalekken als bijzonder incident. Een datalek, waarbij persoonsgegevens of andere vertrouwelijke gegevens mogelijk bij onbevoegden terechtkomen, is een bijzondere vorm van een incident. Het begint als elk ander ticket, maar we behandelen het met extra zorg. We beoordelen eerst wat er is gebeurd, welke gegevens het betreft en wiens gegevens dat zijn. Daarna informeren we jou als klant zo snel mogelijk, ook als nog niet alles bekend is, zodat je op tijd kunt bepalen wat je zelf moet doen en welke verplichtingen jij hebt. We houden vast wat we weten en doen, en we nemen maatregelen om verdere blootstelling te voorkomen.
Communicatie is bijna net zo belangrijk als de oplossing
Een respons op een ticket kan verschillende vormen hebben: een snelle oplossing, een verduidelijkende vraag, een bevestiging dat we ermee bezig zijn, een telefoongesprek of een bericht dat een oplossing is uitgerold. Wat passend is, hangt af van de classificatie, de verwachte oplostijd en de afspraken met de klant.
We vinden communicatie bijna net zo belangrijk als het oplossen zelf. Niet omdat praten bugs oplost, helaas, maar omdat stilte het probleem voor de melder groter maakt. Een klant wil weten dat de melding gezien is, wat de volgende stap is en of er iets van hem of haar nodig is.
Als communicatie via een ander kanaal loopt dan het ticket, vatten we die samen in Zoho Desk. Zo blijft de digitale ticketgeschiedenis leidend. Op kantoor hebben we daarnaast de Bronsprinter: een kleine printer die van elk nieuw supportticket een fysiek bonnetje maakt. Dat bonnetje hangen we echt op en geven we door aan wie eraan gaat werken. Een leuke side-note, maar wel een die werkt.
Toewijzen, oplossen en pas sluiten als het klopt
Na classificatie wordt een ticket toegewezen op basis van productkennis, urgentie en beschikbare capaciteit. Een kleine tekstfout vraagt een andere route dan een storing in een belangrijk proces. Als een patch nodig is, maken we daar een issue van, reviewen we de wijziging en releasen we volgens de normale productieprocedure. Bij zwaardere incidenten kan die route sneller lopen, maar niet slordiger.
Een ticket mag pas dicht als duidelijk is dat het probleem is opgelost. Soms bevestigt de klant dat zelf. Soms is het uit de situatie duidelijk. Als dat niet helder is, vragen we eerst door. Voor een RFC is afsluiten anders: dan is het voldoende om uit te leggen dat we het verzoek meenemen en het op de juiste plek voor productwerk vastleggen.
Opvolgen en verbeteren. Wekelijks kijken we naar opgeloste en openstaande tickets, zodat patronen en gemiste opvolging niet ongemerkt blijven liggen. Hoe we terugkerende oorzaken daarna aanpakken, lees je in ons artikel over continu verbeteren: bij incidenten betekent dat dat zwaardere meldingen in de maandelijkse kwaliteitsdag terugkomen en elke verbetering een eigenaar krijgt, zodat dezelfde brand minder snel terugkomt.