Een klant komt om 17.57 uur in de wachtrij. De servicedesk sluit om 18.00 uur. Drie minuten mogen niet veranderen in onzichtbaar wachten terwijl niemand meer kan opnemen.
Behandel het sluiten van de wachtrij en het uitloggen van alle medewerkers als twee live routinggebeurtenissen. Bepaal eerst wat je de klant eerlijk kunt aanbieden, configureer voor elke gebeurtenis een aparte overflowplaybook en test de overgang met een gesprek dat al wacht. De klant heeft een betrouwbare volgende stap nodig. Het team moet kunnen bewijzen dat het werk nog een eigenaar heeft.
Microsoft beschrijft hiervoor twee scenario's in Dynamics 365 Contact Center. Het eerste start wanneer een wachtrij buiten openingstijden komt terwijl er gesprekken wachten. Het tweede start wanneer alle aan de wachtrij toegewezen servicemedewerkers zijn uitgelogd. In beide gevallen kan een beheerder een ingestelde overflowactie uitvoeren in plaats van de klant te laten staan.
Behandel sluiting als gebeurtenis en niet alleen als rooster
Openingstijden bepalen of nieuw werk een wachtrij mag binnenkomen. Ze beslissen niet vanzelf wat er gebeurt met werk dat vlak voor sluiting binnenkwam. Een gesprek kan open blijven terwijl de mensen die het moeten aannemen verdwijnen.
- Wachtend werk zit in de testStart voor sluiting en bewijs wat er met een bestaand gesprek gebeurt.
- De trigger is explicietScheid gepland sluiten van het uitloggen van alle toegewezen medewerkers.
- De bestemming kan antwoordenControleer of terugbellen, voicemail of de andere wachtrij echt beschikbaar is.
- De klant hoort de waarheidLaat boodschap en reactietijd aansluiten op de werkelijke bezetting.
- Herstel heeft een eigenaarBenoem wie mislukte acties, diagnose en achtergebleven gesprekken bekijkt.
Volgens Microsoft volgt conversation orchestration veranderende omstandigheden gedurende de hele levenscyclus. Ondersteunde overflowvoorwaarden zijn onder meer openingstijden, aanmeldstatus, beschikbaarheid, wachttijd en positie. De aparte functiebeschrijving noemt twee triggers voor bestaand wachtend werk: de wachtrij gaat buiten openingstijden of alle toegewezen vertegenwoordigers loggen uit.
Een geplande sluiting is voorspelbaar. Een lege bezetting kan ook midden op de dag ontstaan door een fout rooster of massaal uitloggen. Houd de triggers apart, zodat een operator kan zien wat er gebeurde en de juiste reactie kan kiezen.
Een gedeelde supportinbox helpt daarna. Het routingsysteem kan het gesprek verplaatsen, maar het ontvangende team heeft nog steeds de geschiedenis, status en oorspronkelijke instaptijd nodig.
Kies eerst de belofte aan de klant
Begin niet bij het overflowmenu. Begin bij de zin waarop de klant moet kunnen vertrouwen.
Voor spraak kan dat een terugbelafspraak, gecontroleerde voicemail of overdracht naar een beschikbare wachtrij zijn. Voor berichten kan het een bemande wachtrij of een duidelijke ontvangstbevestiging met reactietermijn zijn. Microsoft noemt voicemail, terugbellen en een alternatieve wachtrij als voorbeelden. De beste keuze hangt af van de werkelijke capaciteit van de bestemming.
| Trigger | Belofte aan de klant | Passende uitweg | Te bewaren bewijs |
|---|---|---|---|
| De wachtrij sluit | Je blijft niet wachten in een gesloten lijn | Terugbellen, voicemail of open wachtrij | Triggertijd, actie en nieuwe eigenaar |
| Iedereen logt uit | Je verzoek blijft actief ondanks het bezettingsgat | Beschikbare wachtrij of beheerst terugbellen | Aanmeldstatus, resultaat en hersteleigenaar |
| De uitwijkbestemming is niet beschikbaar | We sturen je niet naar een volgende doodlopende weg | Eerlijk bericht en toegewezen opvolging | Mislukte route, klantmelding en handmatige taak |
| De playbook start niet | Een persoon herstelt het wachtende werk | Controle door supervisor en handmatige overdracht | Diagnose, correctie en hertest |
Dit is een operationele beslissing. Als de alternatieve wachtrij tegelijk sluit, verplaats je alleen de stilte. Wordt voicemail pas de volgende werkdag bekeken, zeg dat dan.
Bouw een playbook per fouttoestand
De actuele configuratiehandleiding voor conversation orchestration van Microsoft beschrijft begeleide templates voor een wachtrij buiten openingstijden en voor alle gebruikers die zijn uitgelogd. De functie staat momenteel beschreven als productieklare preview voor spraak en berichten, met vereisten voor licenties, rollen, unified routing, kanaal, workstream en wachtrij.
Bouw een smalle playbook met één trigger, heldere voorwaarden en één uitkomst. Selecteer de bedoelde wachtrijen en controleer dat de playbook actief is, niet alleen als concept opgeslagen. Bekijk ook andere actieve playbooks voor dezelfde wachtrijen. Een eerdere actie kan bepalen of een volgende regel nog werk heeft om te verwerken.
Natuurlijke taal is de manier van schrijven, niet de uiteindelijke beheersing. Microsoft zet een gepubliceerde instructie om in een gestructureerde runtimevorm. Lees dat resultaat, houd de scope klein en stop niet verschillende triggers en uitwegen in één vage alinea. Een beheerst automatiseringsproces moet uit te leggen zijn aan de supervisor die het bezit.
Test de overgang terwijl iemand wacht
Een test die pas na sluiting begint, mist het gevaarlijke moment. Plaats synthetisch een gesprek in de open wachtrij, laat het ongeassigneerd en ga daarna over de sluitingsgrens.
Test minstens een sluiting met één wachtend gesprek, iedereen die binnen openingstijden uitlogt, een beschikbare en onbeschikbare uitweg, een gelijktijdige wachttijdregel en een klant die tijdens de overgang reageert of verbreekt.
Bewaar per geval de trigger, actie, klantboodschap, bestemming, eigenaar, tijdstippen en eindstatus. Microsoft biedt diagnosegegevens voor gesprekken die door playbooks zijn verwerkt en adviseert status, wachtrijen, kanaal en beschikbaarheidsvoorwaarden te controleren wanneer overflow niet start.
Gebruik eerst synthetische inhoud en herhaal de test na elke wijziging. Die discipline hoort ook bij een overdracht van AI naar een mens. Automatisering werkt alleen wanneer de ontvanger begrijpt waarom het werk kwam en wat er al gebeurde.
Geef herstel aan een bekende eigenaar
Elke automatische route heeft een handmatige herstelroute nodig. Benoem de persoon of rol die wachtende gesprekken na sluiting, mislukte overflowacties en wachtrijen zonder ingelogde medewerkers controleert. Leg vast binnen welke tijd en met welke bevoegdheid.
Reset de leeftijd van het gesprek niet en wis de mislukte route niet. Bewaar instaptijd, klantberichten, poging en bestemming. Dat bewijs maakt onderscheid tussen een configuratiefout en een bezettingsprobleem.
Een klantrecord kan duurzame context bewaren, terwijl supportprocessen de live eigenaar en volgende actie nodig hebben. Toegang tot routingregels en diagnose hoort onder beveiligingscontroles, zeker wanneer teams wachtrijen delen.
DripTell kan kanaaloverstijgende context, eigenaarschap en automatische opvolging zichtbaar houden na een overdracht. Het maakt een onbereikbare bestemming niet bereikbaar. De operationele belofte moet bij de echte bezetting passen.
Veelgestelde vragen
Verplaatst sluitingstijd wachtende gesprekken automatisch
Ga daar niet zonder configuratie van uit. Publiceer de overflowplaybook voor buiten openingstijden en test hem met een gesprek dat al wacht. Microsoft documenteert dit als een apart orchestrationscenario.
Wat is anders wanneer iedereen uitlogt
De wachtrij kan nog binnen openingstijden zijn. De trigger voor alle uitgelogde gebruikers kan direct de ingestelde uitweg starten in plaats van op een gewone wachtrijtimer te wachten. Test hem dus apart.
Kan één playbook spraak en berichten afhandelen
Conversation orchestration ondersteunt beide, maar kanaalcontext en uitwegen verschillen. Maak de scope expliciet en test elk kanaal met de echte bestemming en klantboodschap.
Moet terugbellen altijd de uitweg zijn
Nee. Gebruik het alleen als de terugbelroute capaciteit, eigenaarschap en een eerlijke reactieverwachting heeft. Voicemail of een beschikbare andere wachtrij kan beter zijn. De functiebeschrijving van Microsoft presenteert deze opties zonder universele rangorde.
Hulp nodig bij deze handleiding?Vraag het DripTell-team
Van lezen naar doen
Hulp nodig om dit voor jouw bedrijf toe te passen?
Laat je gegevens achter. We nemen dit artikel als context en beginnen met een bruikbaar antwoord voor je team.
DripTell Editorial
Praktische uitleg, gecontroleerd door het product- en klantworkflowteam van DripTell.
Lees hoe DripTell productclaims controleert, primaire bronnen gebruikt en correcties verwerkt.
Redactioneel en bronnenbeleid
