Deskhero
Nederlands
Probeer gratis

← Back to articles

SLA-herinneringen automatiseren vóór overtredingen ontstaan

SLA-herinneringen automatiseren vóór overtredingen ontstaan

Geautomatiseerde SLA-herinneringen moeten een ticket onder de aandacht brengen zolang er nog tijd is om te handelen, en vervolgens duidelijk maken dat een ticket te laat is. De juiste configuratie hangt af van de helpdesk. Sommige platforms bieden native waarschuwingen voor naderende deadlines en overschrijdingen, terwijl een aangepaste workflow geplande controles en expliciete escalatiestappen nodig kan hebben.

Begin met de klok, niet met de melding:

  • Definieer afzonderlijke doelstellingen voor de eerste reactie en de oplossing.
  • Bepaal of doelstellingen gebruikmaken van kalendertijd of kantooruren.
  • Kies welke ticketstatussen de oplossingsklok pauzeren.

Pro-tip: Test elke SLA-status met voorbeeldtickets voordat je vertrouwt op livewaarschuwingen. Neem gevallen op die bijna verlopen, zijn overschreden, gepauzeerd, opnieuw toegewezen en al voltooid zijn.

Belangrijkste punten

Betrouwbare herinneringen beginnen met nauwkeurige deadlines. De timing van waarschuwingen, ontvangers en escalatieprocedures komt pas nadat het beleid zelf correct is.

Punt Details
Definieer beide klokken Houd de eerste reactie en de oplossing afzonderlijk bij, omdat ze door verschillende gebeurtenissen worden voltooid.
Houd rekening met werktijd Gebruik een bedrijfsschema wanneer nachten en weekenden niet mogen meetellen voor de doelstelling.
Configureer pauzestatussen Pauzeer de oplossingsdoelstelling zolang het ticket wacht op de klant of een andere externe partij.
Kies ontvangers bewust Zorg ervoor dat waarschuwingen voor naderende deadlines en overschrijdingen iemand bereiken die actie kan ondernemen voor het ticket.
Test vóór de uitrol Controleer deadlines, pauzegedrag en de bezorging van meldingen met gecontroleerde tickets.
Gebruik eerst native SLA-functies Een helpdesk met ingebouwd beleid, bedrijfsschema's, waarschuwingen, filters en rapportage voorkomt een afzonderlijke pollingworkflow.

Gezaghebbende documentatie en handleidingen om hierna te raadplegen

Bekijk voor een platformspecifiek voorbeeld de documentatie van Jira over geautomatiseerde opvolging. Hierin worden zowel geplande regels als een aanpak op basis van SLA-drempels beschreven, inclusief de aanbeveling om eerst te testen met een kleine queryscope voordat je deze uitbreidt.

Inhoudsopgave

Stapsgewijs automatisering voor SLA-herinneringen opbouwen

Schrijf precies op wat elke SLA meet voordat je een waarschuwing configureert. Een doelstelling voor de eerste reactie en een oplossingsdoelstelling zijn verschillende klokken. Bepaal welke ticketgebeurtenis elke klok start, welke gebeurtenis deze voltooit en of de deadline kalendertijd of een bedrijfsschema volgt.

Configureer vervolgens het pad van de herinnering.

  1. Definieer het beleid. Koppel groepen en prioriteiten aan doelstellingen voor de eerste reactie en de oplossing. Voeg een vangnetbeleid toe voor tickets die niet aan een specifiekere regel voldoen.
  2. Stel de werkkalender in. Voeg de openingstijden en tijdzone toe die op de doelstelling van toepassing zijn. Als de verplichting doorlopend geldt, gebruik je kalendertijd.
  3. Configureer het pauzegedrag. Selecteer statussen die de oplossingsklok stoppen zolang het team op informatie wacht. Controleer of de klok voor de eerste reactie kan worden gepauzeerd, want veel systemen behandelen deze anders.
  4. Schakel meldingen in. Bepaal wie de statussen voor naderende deadlines en overschrijdingen ontvangt en welke ondersteunde kanalen de helpdesk gebruikt.
  5. Voeg een operationele reactie toe. Leg vast wat de ontvanger moet doen, zoals reageren, de prioriteit wijzigen, het ticket opnieuw toewijzen of een teamleider inschakelen. De melding en de corrigerende actie hoeven niet dezelfde technische regel te zijn.

Als de helpdesk geen native SLA-drempels heeft, kan een geplande workflow openstaande tickets controleren en hun deadlines vergelijken met de huidige tijd. LOW/CODE documenteert een pollingvoorbeeld van 15 minuten, maar het juiste interval hangt af van de kortste doelstelling, API-limieten, kantooruren en hoeveel vertraging het team kan verdragen. Sla een waarschuwingsstatus op, zodat latere runs dezelfde melding niet opnieuw versturen.

Drempels kiezen die niet leiden tot waarschuwingsmoeheid

Een nuttige waarschuwing laat de ontvanger genoeg tijd om te reageren. Een procentuele drempel kan werken in een aangepast systeem, maar een vaste waarschuwingsperiode is vaak gemakkelijker te begrijpen voor beleidsregels met verschillende looptijden.

  • Ruim op tijd: Houd het ticket zichtbaar in normale wachtrijweergaven zonder een waarschuwing te versturen.
  • Bijna verlopen: Informeer de verantwoordelijke gebruiker of groep zolang de doelstelling nog haalbaar is.
  • Overschreden: Markeer het ticket als te laat en volg het gedocumenteerde escalatieproces van het team.

Kopieer niet zonder controle een universele drempel van 80 procent. Bij een doelstelling van één uur laat deze 12 minuten over, terwijl er bij een doelstelling van drie dagen meer dan een halve dag overblijft. Meet hoeveel tijd het team daadwerkelijk nodig heeft om actie te ondernemen.

Herhaalde herinneringen zorgen snel voor ruis. Native helpdeskwaarschuwingen moeten een statusovergang melden in plaats van bij elke schermvernieuwing. Een aangepaste pollingworkflow moet registreren dat de melding voor een naderende deadline of overschrijding is verzonden en die status alleen resetten wanneer het beleid daadwerkelijk opnieuw begint.

Drempels kiezen die niet leiden tot waarschuwingsmoeheid: overzichtsdiagram

Wat SLA-waarschuwingen moeten zeggen en waar ze naartoe moeten

Een waarschuwing moet het ticket identificeren, de deadline tonen en duidelijk maken welke reactie wordt verwacht. Voeg geen klantgegevens toe die de ontvanger niet nodig heeft.

  • Ticket-ID en link, zodat de ontvanger het juiste gesprek kan openen.
  • Type doelstelling, zoals eerste reactie of oplossing.
  • Deadline of duur van de overschrijding in een ondubbelzinnige tijdzone.
  • Huidige status, prioriteit, groep en toegewezen persoon wanneer deze velden van invloed zijn op het eigenaarschap.
  • Eén volgende stap, zoals reageren, opnieuw toewijzen of een teamleider vragen het ticket te beoordelen.

Gebruik kanalen die het supportteam al in de gaten houdt. Meldingen in de app en per e-mail zijn vaak voldoende wanneer ze de toegewezen persoon of verantwoordelijke groep betrouwbaar bereiken. Als een afzonderlijk paging- of berichtensysteem nodig is, controleer dan of de helpdesk de integratie ondersteunt voordat je het proces daarop baseert.

Pro-tip: Toon een precieze deadline of aftelling. Een concreet tijdstip is gemakkelijker te prioriteren dan een vage waarschuwing.

Wat SLA-waarschuwingen moeten zeggen en waar ze naartoe moeten: overzichtsdiagram

SLA-timers nauwkeurig houden met pauzestatussen

Een herinnering is slechts zo betrouwbaar als de klok ervan. Oplossingsdoelstellingen worden doorgaans gepauzeerd zolang een ticket op de klant wacht, maar de exacte statussen moeten aansluiten op de werkelijke workflow van het team.

  • Selecteer expliciete pauzestatussen en documenteer waarom elke status de klok stopt.
  • Hervat de klok wanneer het ticket een pauzestatus verlaat.
  • Test tickets die meer dan één keer een pauzestatus in- en uitgaan.
  • Controleer of doelstellingen voor de eerste reactie en de oplossing dezelfde pauzeregels volgen.

Bedrijfsschema's lossen een ander probleem op. Ze sluiten gesloten uren uit van de doelstelling zelf, terwijl pauzestatussen tijd uitsluiten op basis van de ticketstatus. Configureer en test beide. Een weekend mag niet meetellen voor een doelstelling op basis van kantooruren, en een ticket dat op een werkdag op de klant wacht, moet gepauzeerd blijven, ook wanneer het team geopend is.

Testen en bijstellen voordat je de automatisering vertrouwt

Gebruik gecontroleerde tickets om de volledige levenscyclus te testen. Historische gegevens kunnen helpen om realistische doelstellingen vast te stellen, maar een test met een live status is beter om de bezorging van meldingen en wijzigingen in deadlines te controleren.

  1. Dek elk beleid af. Maak een testticket voor elke combinatie van groep en prioriteit die een ander SLA-beleid kan selecteren.
  2. Gebruik korte tijdelijke doelstellingen. Bevestig de statussen voor naderende deadlines en overschrijdingen zonder uren of dagen te wachten en zet daarna de echte waarden terug.
  3. Test pauzestatussen. Pauzeer en hervat de oplossingsklok en controleer of de deadline zoals verwacht verandert.
  4. Controleer de ontvangers. Test een toegewezen ticket en een niet-toegewezen ticket, zodat de juiste personen elke melding ontvangen.
  5. Bekijk het dossier. Controleer of het ticket toont welk beleid van toepassing was en wanneer elke klok werd gehaald of gemist.

Controleer na de lancering onterechte waarschuwingen en gemiste overdrachten. Als waarschuwingen nauwkeurig zijn maar toch worden genegeerd, ligt het probleem mogelijk eerder bij eigenaarschap of personeelsbezetting dan bij de timing van de drempel.

Hoe Deskhero SLA-herinneringen afhandelt

Deskhero beschikt over speciale SLA-beleidsregels. Deze staan los van de algemene automatiseringsregels, die niet gepland of tijdgebaseerd zijn.

  • Eigenaren en beheerders kunnen SLA-beleidsregels rangschikken die overeenkomen met ticketgroepen en prioriteiten. De eerste overeenkomende beleidsregel stelt de doelstellingen voor de eerste reactie en de oplossing vast.
  • Elk beleid kan een genoemd wekelijks bedrijfsschema met een eigen tijdzone gebruiken of kalendertijd tellen.
  • De oplossingsklok wordt gepauzeerd in statussen die in de werkruimte zijn geselecteerd. De klok voor de eerste reactie wordt niet gepauzeerd.
  • Deskhero markeert een ticket als risicovol tijdens de laatste 60 minuten vóór de volgende deadline en markeert het als overschreden zodra de deadline is verstreken.
  • Elke vijf minuten wordt op de achtergrond een controle uitgevoerd. Daarbij worden meldingen in de app en een e-mailsamenvatting naar de toegewezen persoon verzonden, of naar groepsleden wanneer het ticket niet is toegewezen. Gebruikers kunnen per groep bepalen via welke kanalen ze SLA-meldingen ontvangen.

De ticketlijst bevat een SLA-kolom en SLA-filters, het dashboard licht risicovolle en overschreden tickets uit en de tijdlijn van het ticket registreert beleids- en klokgebeurtenissen. Statistics biedt weergaven voor SLA-behalen zodra de workflow actief is.

Wat je moet bijhouden zodra je waarschuwingen actief zijn

De eerste vraag is of de herinneringen overschrijdingen voorkomen. Vergelijk risicovolle tickets met het aantal tickets dat later de doelstelling mist en onderzoek vervolgens de gevallen die door waarschuwingen niet zijn hersteld.

Houd het behalen van de doelstelling voor de eerste reactie en het behalen van de oplossingsdoelstelling afzonderlijk bij. Bekijk ook het aantal tickets dat momenteel binnen de waarschuwingsperiode moet worden afgehandeld, het aantal tickets dat al is overschreden en welke beleidsregels of combinaties van groep en prioriteit de meeste missers veroorzaken.

Combineer de percentages met operationele context. Een sterk totaalpercentage kan één wachtrij verbergen die herhaaldelijk deadlines overschrijdt. Een plotselinge daling kan het gevolg zijn van een gewijzigd bedrijfsschema, een nieuw toegevoegde prioriteit of een tekortkoming in het eigenaarschap, in plaats van trager werk.

Overlappende SLA's beheren zonder botsende waarschuwingen

Een ticket kan zowel een doelstelling voor de eerste reactie als een oplossingsdoelstelling hebben. Behandel ze als afzonderlijke klokken, omdat een reactie alleen de eerste klok voltooit. De oplossingsdoelstelling loopt door totdat het ticket de gebeurtenis bereikt die deze doelstelling vervult.

De ticketinterface moet tonen welke openstaande deadline als eerste komt en tegelijk de details voor beide doelstellingen behouden. Filters en rapportage moeten ook onderscheid maken tussen eerste reactie en oplossing, zodat één gezonde metric geen problemen in de andere verbergt.

Wanneer klanten verschillende verplichtingen hebben, gebruik je afzonderlijke beleidsregels die overeenkomen met stabiele ticketvelden, zoals groep en prioriteit. Plaats specifieke beleidsregels vóór het vangnetbeleid en test vervolgens een ticket tegen elke betekenisvolle combinatie. Vermijd verborgen contractniveaus die gebruikers niet op het ticket kunnen zien of controleren.

Klaar blijven voor audits wanneer SLA's automatisch verlopen

Houd bij welk beleid van toepassing was, welke deadlines zijn berekend en wanneer elke klok is gehaald of gemist. Als door een wijziging van groep, prioriteit of schema een deadline opnieuw wordt berekend, moet ook die wijziging traceerbaar zijn.

Documenteer beleidswijzigingen buiten de inbox voor meldingen. Noteer wie de wijziging heeft goedgekeurd, wanneer deze van kracht werd en of deze van toepassing is op bestaande tickets. Zo zijn latere vragen van klanten gemakkelijker te beantwoorden en worden stille wijzigingen in de betekenis van een SLA-rapport voorkomen.

Controleer voor contractuele beoordelingen het gedrag van het platform in plaats van ervan uit te gaan dat elke zichtbare gebeurtenis een auditlog is. De tijdlijn van Deskhero's tickets registreert de toepassing van het SLA-beleid en de klokresultaten, terwijl het onderdeel Statistics het behalen van de doelstellingen rapporteert. Organisaties met formele bewaartermijnen moeten controleren of deze gegevens aan hun eigen verplichtingen voldoen.

SLA-berichten schrijven voor gebruikers, managers en klanten

Interne waarschuwingen en updates aan klanten dienen verschillende doelen. Houd elk bericht gericht op wat de lezer vervolgens kan doen.

Waarschuwingen voor gebruikers moeten beginnen met de ticketlink, het type doelstelling, de deadline en de onmiddellijke actie. Vermijd een alinea met beleidsachtergrond wanneer de gebruiker aan het ticket moet werken.

Beoordelingen voor managers moeten patronen binnen een groep, prioriteit of beleidsregel tonen. Eén gemist ticket vereist actie, terwijl herhaalde missers vragen om een beslissing over personeelsbezetting of proces.

Communicatie naar klanten moet nauwkeurig en specifiek zijn. Als het team vertraging verwacht, kan een door een persoon gecontroleerde update een realistisch tijdstip voor het volgende contact aangeven. Stel interne waarschuwingslabels niet bloot en beloof geen oplostijd die het team niet kan waarmaken.

SLA-automatisering koppelen aan de tools die je al gebruikt

Begin met native SLA-functies wanneer die het vereiste beleid, de kalenders, pauzestatussen, waarschuwingen, filters en rapportage afdekken. Native deadlines blijven doorgaans betrouwbaarder afgestemd op ticketwijzigingen dan een parallel spreadsheet.

Waar native ondersteuning beperkt is, hebben teams communityplug-ins en in forums beschreven workarounds gebruikt. Controleer de onderhoudsstatus en versiecompatibiliteit voordat je van deze aanpak afhankelijk wordt.

Een afzonderlijke workflow kan geschikt zijn wanneer meerdere systemen één escalatiekanaal moeten voeden. Bepaal eerst wat de bron van waarheid is. Dubbele SLA-berekeningen in een helpdesk en een integratielaag kunnen uiteenlopen, vooral rond tijdzones, kantooruren, pauzestatussen en opnieuw toewijzen.

Redactioneel standpunt: de waarschuwing is niet het doel, de actie wel

Een melding dat een deadline nadert is alleen nuttig wanneer duidelijk is wie verantwoordelijk is. De ontvanger heeft toestemming, context en tijd nodig om het ticket verder te brengen.

Nauwkeurigheid van de klok komt op de eerste plaats. Een verkeerd bedrijfsschema of een onjuiste pauzeconfiguratie leidt tot zelfverzekerde maar misleidende waarschuwingen. Corrigeer de deadlineberekening voordat je de formulering van het bericht aanpast of kanalen toevoegt.

Bouw dit in deze volgorde op: beleidsdoelstellingen, bedrijfsschema's, pauzegedrag, ontvangers van meldingen, operationele reactie en rapportage. Door deze volgorde blijft de herinnering gekoppeld aan een deadline die iedereen begrijpt.

Je SLA-herinneringen laten werken zonder migratieproject

Deskhero maakt verbinding met Gmail of Microsoft 365 via tweerichtingssynchronisatie, zodat teams hun bestaande supportadres kunnen behouden en tegelijk gedeelde ticketafhandeling en SLA-beleidsregels kunnen toevoegen.

Deskhero

Configureer doelstellingen voor de eerste reactie en de oplossing per groep en prioriteit, voeg indien nodig een wekelijks bedrijfsschema toe en kies welke statussen de oplossing pauzeren. Deskhero toont vervolgens de volgende deadline, licht tickets uit die binnen één uur moeten worden afgehandeld, informeert de verantwoordelijke gebruikers en registreert de SLA-resultaten.

Voor de gratis proefperiode van 30 dagen is geen creditcard nodig. Koppel één mailbox, configureer een kleine set beleidsregels en test de volledige SLA-levenscyclus voordat je de configuratie uitbreidt naar meer groepen.

Bronnen

Veelgestelde vragen

Wat is het verschil tussen een SLA, een SLO en een SLI?

Een SLA is een serviceverplichting tussen partijen. Een SLO is een doelstelling voor de prestaties van een service en wordt vaak intern gebruikt om binnen die verplichting te blijven. Een SLI is de gemeten waarde die wordt gebruikt om de doelstelling te evalueren.

Wat geldt als een SLA-waarschuwing voor een overschrijding?

Een waarschuwing voor een overschrijding geeft aan dat een openstaande deadline voor de eerste reactie of de oplossing is verstreken. Een waarschuwing voor een naderende deadline is anders, omdat het team nog tijd heeft om de doelstelling te halen.

Wat betekent een SLA van 4 uur?

Dit betekent dat de actie die in het beleid wordt genoemd, zoals de eerste reactie of de oplossing, binnen vier uur moet plaatsvinden volgens de berekening van dat beleid. De klok kan kalendertijd of een bedrijfsschema gebruiken.

Waarin verschilt een SLA van een KPI?

Een SLA beschrijft een serviceverplichting. Een KPI meet prestaties en kan worden gebruikt om veel doelen te monitoren die geen contractuele deadlines zijn.

Kan Deskhero SLA-herinneringen automatiseren zonder aangepaste code?

Ja. Deskhero heeft ingebouwde SLA-beleidsregels, een vaste waarschuwingsperiode voor naderende deadlines, detectie van overschrijdingen, meldingen in de app en per e-mail, ticketfilters, dashboardweergaven en SLA-rapportage. Deze functies staan los van de algemene automatiseringsregels.