Zo legt u uw proces voor het afhandelen van notificaties helder uit aan klanten

Als beheerde dienstverlener (MSP) moet u uw proces voor het afhandelen van notificaties helder en effectief aan uw klanten kunnen uitleggen. Doet u dat niet, dan krijgen klanten al snel het idee dat zij onvoldoende worden geholpen of dat uw inspanningen tekortschieten (ook wanneer u de beste praktijken uit de sector volgt met een competent en volledig uitgerust team dat problemen tijdig oplost).

Deze gids biedt een kader om uw proces voor het afhandelen van notificaties zo te communiceren dat uw klanten het begrijpen. Zo stelt u realistische verwachtingen en behoudt u het vertrouwen tijdens incidenten.

Op zoek naar een uitgebreide gids over dit onderwerp? Bekijk onze video: Zo legt u uw proces voor het afhandelen van notificaties helder uit aan klanten.

Wat is het verschil tussen notificaties en incidenten?

Een incident is een onderbreking van de IT-diensten die u aan uw klanten levert of voor hen beheert. Incidenten zijn meestal ongepland en lopen uiteen van problemen zoals een verminderde internetverbinding door een uitgevallen verbinding tot een volledige uitval van een bestandsserver door een systeemcrash. Cybersecurity-incidenten zoals datalekken onderbreken de dienstverlening niet altijd acuut of direct maar kunnen wel tot andere negatieve gevolgen leiden.

Een notificatie ontstaat als gevolg van een incident en wordt naar uw technische team gestuurd zodat zij ervan op de hoogte zijn. Een notificatie kan worden gegenereerd door monitoringsystemen of cybersecurityplatformen en kan worden verstuurd bij de eerste keer dat een incident optreedt (bijvoorbeeld wanneer een server niet meer reageert) of wanneer bepaalde drempelwaarden worden bereikt (bijvoorbeeld een bepaald aantal mislukte aanmeldpogingen voor een gebruiker). Notificaties kunnen ook door mensen worden aangemaakt, in de vorm van een supportticket, en ongebruikelijke activiteit of storingen in uw infrastructuur aan het licht brengen die geautomatiseerde systemen mogelijk missen.

Wat is het proces voor het afhandelen van notificaties?

Het proces voor het afhandelen van notificaties (of alert triage) bepaalt hoe u notificaties instelt en erop reageert. Een effectief proces zorgt ervoor dat er verstandige drempelwaarden worden ingesteld en dat notificaties worden geprioriteerd en waar nodig geëscaleerd, zodat niets over het hoofd wordt gezien en kritieke incidenten voorrang krijgen op kleine ergernissen.

Voor uw MSP-team is het doel van dit proces om zicht te houden op de omgeving zonder alert fatigue te veroorzaken. Voor uw klanten moet dat begrijpelijk worden gemaakt: u moet de technische redenen kunnen ontrafelen waarom uw triageproces is ingericht zoals het is ingericht. Wanneer er dan onvermijdelijk een ernstig incident plaatsvindt, zijn zij gerustgesteld omdat zij weten dat het voorrang heeft gekregen op ander lopend werk en dat uw team er al bovenop zit.

Het proces voor het afhandelen van notificaties helder uitleggen

Technologie kan helpen om de paraatheid van uw team aan klanten te laten zien. U kunt monitoringsoftware demonstreren en dashboards en meldingen in actie tonen. Beleid voor monitoring en alarmering (inclusief escalatieniveaus) kunt u delen via het documentatieplatform van uw MSP en uw helpdesksoftware ondersteunt heldere communicatie met klanten en statusupdates over een incident.

Kwartaalgesprekken (QBR’s) zijn een uitgelezen moment om rapportages te tonen die zijn gegenereerd uit monitoring- en helpdeskgegevens en zo aan te tonen dat uw proces voor het afhandelen van notificaties effectief is geweest.

Wanneer u dit proces uitlegt, moeten de volgende vragen duidelijk worden beantwoord voor uw klanten:

• Wat gebeurt er als er iets misgaat?
• Hoe snel reageert u?
• Hoe weet ik zeker dat er geen problemen tussen wal en schip vallen?

Geen van deze antwoorden mag abstract aanvoelen. Het moeten concrete antwoorden zijn op basis van uw beleid, die in de praktijk worden waargemaakt zodra dat nodig is.

Vereiste 1: leg de lifecycle van een notificatie uit in begrijpelijke taal

Vermijd technisch jargon wanneer u uw monitoringsystemen en notificatiemethoden uitlegt. Behandel de volgende technologieën en begrippen en leg uit hoe u ze gebruikt om op de problemen van klanten te reageren:

• Detectie: leg uit welke monitoringtools u gebruikt om problemen te signaleren.
• Ticketaanmaak: leg uit hoe tickets ontstaan, zowel automatisch vanuit monitoringsystemen als door gebruikers die een probleem melden.
• Triage: beschrijf hoe uw technicus een notificatie valideert en de prioriteit ervan bepaalt.
• Reactie: als de notificatie een incident heeft gedetecteerd, loop dan het proces door waarmee het wordt toegewezen en opgelost.
• Escalatie: zorg dat de klant begrijpt dat een notificatie naar hoger personeel of een externe leverancier gaat wanneer een incident niet snel wordt opgelost. Zo kan het nodig zijn om te escaleren naar Microsoft-support bij een probleem met Microsoft 365 dat niet extern kan worden opgelost.
• Afsluiting en rapportage: gedocumenteerde details en tijden van de oplossing worden opgenomen in rapportages en gebruikt voor latere evaluatie en verbetering

Diagrammen en stroomschema’s die laten zien hoe verschillende notificaties verlopen, helpen hierbij. U kunt bijvoorbeeld tonen hoe een notificatie met aanvankelijk lage prioriteit wordt geëscaleerd zodra drempelwaarden worden bereikt.

Vereiste 2: vertaal SLA’s naar scenario’s

Praktische scenario’s stellen klanten gerust omdat zij een voorbeeld krijgen dat zij op hun eigen bedrijfsprocessen kunnen projecteren om de impact van uw notificatieproces in te schatten.

In plaats van alleen een reactietijd te noemen, plaatst u die in context: “Als uw server om 2 uur ’s nachts offline gaat, genereert ons systeem direct een notificatie en reageert een technicus met bereikbaarheidsdienst binnen 15 minuten. Normaal gesproken verwachten we de server binnen 30 minuten daarna weer online te hebben en lukt dat niet, dan escaleren we binnen het uur naar een technicus op locatie.”

Vereiste 3: maak escalatiepaden duidelijk

Leg uit hoe u voorkomt dat een incident blijft hangen in een wachtrij of bij een technicus die het niet opgelost krijgt. Behandel:

• Wie de eerste reactie verzorgt (niveau 1)
• Wie complexe problemen escaleert (niveau 2/3 of een externe leverancier)
• Hoe klanten en belanghebbenden tijdens een escalatie worden geïnformeerd

Vereiste 4: laat klanten zien wat zij te zien krijgen als er iets misgaat

Laat klanten tijdens de onboarding voorbeelden zien van wat zij tijdens en na incidenten die notificaties hebben veroorzaakt, te zien krijgen. Denk aan rapportages met opgeloste notificaties en uptimecijfers of aan dashboards voor klanten met live gegevens.

Licht bijzondere gevallen uit tijdens QBR’s om de effectiviteit van uw proces voor het afhandelen van notificaties aan te tonen.

Vereiste 5: maak onderscheid tussen notificaties en ruis

Leg uit welke technologie achter uw monitoring en notificaties zit en hoe die uw team in staat stelt efficiënte dienstverlening te bieden waarin uptime voorop staat. Alert fatigue ontstaat wanneer technici worden overspoeld met notificaties over kleine problemen, waardoor zij belangrijke incidenten missen.

Laat uw klanten zien hoe u dat voorkomt en hoe u drempelwaarden, filtering en automatisering inzet om incidenten verstandig te prioriteren op basis van hun ernst.

NinjaOne biedt één oplossing voor monitoring, alarmering, ticketsysteem en documentatie

NinjaOne geeft MSP’s een complete toolchain voor monitoring, alarmering en incidentrespons. Drempelwaarden kunnen per klant worden ingesteld en wanneer er iets gebeurt, worden meldingen verstuurd via sms, e-mail en pushnotificatie, zodat technici nooit achterlopen en meteen met een oplossing aan de slag kunnen.

Tickets in de NinjaOne-helpdesk kunnen automatisch worden aangemaakt op basis van notificaties uit een breed scala aan servers, tools en platformen en er kunnen dashboards worden gegenereerd met uptime- en oplossingscijfers. NinjaOne Documentation kunt u gebruiken om SLA’s, procesdocumentatie, schema’s, rapportages, voorbeelden en andere documenten voor klanten op te slaan die waardevolle context geven aan uw proces voor het afhandelen van notificaties en vertrouwen wekken.