Een beller kiest voor een terugbelverzoek, hangt op en belt vijf minuten later opnieuw. Er was niets dat bewees dat het eerste verzoek veilig in de wachtrij stond. Als Dynamics 365 beide pogingen accepteert, bestaan er twee beloften voor hetzelfde probleem.
Het directe antwoord is eenvoudig. Houd het oorspronkelijke terugbelverzoek actief en behandel de volgende poging als mogelijk duplicaat. Kies daarvoor het bereik van de controle, bepaal wat de klant bij de tweede oproep hoort en test het hele terugbelprofiel voordat je het breed activeert.
Het eerste verzoek blijft de belofte
Een terugbelverzoek is geen gewone uitgaande oproep. Het bewaart de plaats van de klant in de wachtrij. Volgens de actuele Microsoft handleiding blijft het verzoek in de wachtrij totdat het vooraan staat en een servicemedewerker beschikbaar is. Het systeem belt eerst de klant, kan informatie verzamelen of een controle uitvoeren en verbindt daarna met de medewerker.
Dubbele verzoeken zijn dus meer dan rommel in een rapport. Ze kunnen de vraag groter laten lijken, twee uitgaande oproepen starten en twee dossiers opleveren voor één behoefte. Een veilige basisregel is één actieve belofte voor één telefoonnummer binnen het gekozen bereik.
Een nummer bewijst niet altijd dat het om dezelfde persoon of kwestie gaat. Collega's kunnen een zakelijk nummer delen en één klant kan vanaf twee nummers bellen. Voor zulke gevallen is een zichtbare uitzonderingsroute nodig.
Kies eerst waar de controle geldt
Het terugbelprofiel heeft twee bereiken. Alleen de huidige wachtrij blokkeert een tweede verzoek wanneer het nummer al in die wachtrij staat. Alle wachtrijen zoekt breder naar een actief verzoek.

- Bevestig het verzoekLeg nummer, wachtrij, aankomsttijd en status vast.
- Kies het bereikBepaal of één of alle wachtrijen worden vergeleken.
- Bescherm de bellerKies beëindigen of blijven wachten bij de tweede poging.
- Stel capaciteit inBeperk actieve verzoeken en bepaal herhaaluitkomsten.
- Bewijs de uitkomstControleer eigenaar, bereikbaarheid en rapportage van één verzoek.
De smalle controle past wanneer elke wachtrij een echt andere belofte beheert. Een factuurvraag en een reparatieverzoek kunnen naast elkaar bestaan. De brede controle past wanneer klanten door menu's bladeren voor een sneller antwoord, terwijl verschillende wachtrijen uiteindelijk bij hetzelfde team uitkomen.
Kies niet automatisch de breedste instelling. Bekijk een steekproef van herhaalde oproepen en bepaal of ze over dezelfde onopgeloste vraag gingen. Als mensen vooral van menu wisselen, is een brede controle logisch. Bij veel gedeelde nummers is alleen het telefoonnummer te grof.
| Operationele situatie | Handig bereik | Ervaring bij de tweede oproep | Te controleren bewijs |
|---|---|---|---|
| Eén wachtrij bezit de vraag volledig | Huidige wachtrij | Meld dat er al een verzoek actief is | Nummer, wachtrij en status |
| Meerdere menu's bereiken hetzelfde team | Alle wachtrijen | Bewaar het eerste verzoek en stop een nieuw verzoek | Aankomsttijd, eerste wachtrij en eigenaar |
| Gedeeld gezinsnummer of bedrijfsnummer | Begin smal | Laat de beller bij twijfel in de live wachtrij | Identiteit en reden van contact |
| Andere vraag met een eigen eigenaar | Huidige wachtrij | Sta een tweede belofte alleen toe bij voldoende capaciteit | Vraagtype en verantwoordelijke team |
Bepaal wat de tweede beller hoort
Dynamics 365 kan de klant informeren en de oproep beëindigen, of informeren en de klant in de live wachtrij laten. Beëindigen is passend wanneer het oorspronkelijke verzoek aantoonbaar geldig is en er geen andere dringende behoefte speelt. Blijven wachten is verstandiger wanneer identiteit, urgentie of onderwerp onzeker is.
De boodschap moet alleen zeggen wat bekend is. Meld dat er een actief verzoek bestaat en leg uit of de beller kan blijven wachten. Geef geen exact tijdstip als capaciteit en bezetting die belofte niet dragen.
Het profiel kan ook het maximum aantal actieve terugbelverzoeken per wachtrij beperken. Zodra de limiet is bereikt, stopt het systeem met aanbieden en blijft de gewone wachtrij actief. Het aanbod keert terug wanneer capaciteit vrijkomt. Zo accepteert het team geen beloften die het niet kan nakomen.
Test het volledige profiel
Duplicaatdetectie werkt alleen wanneer een overflowactie de directe terugbelervaring start. Test daarom hetzelfde nummer in dezelfde wachtrij, hetzelfde nummer in een andere wachtrij, een ander nummer van dezelfde klant en een gedeeld nummer van twee personen.
Controleer welk verzoek actief blijft, welke boodschap de tweede beller hoort, of wachten doorgaat en hoe de rapportage telt. Test ook geen antwoord, mislukte oproep en antwoordapparaat. Microsoft documenteert aparte herhaalinstellingen voor die uitkomsten en een minimale wachttijd van vijf minuten.
Controleer de telefonie. Inkomende oproep en terugbelnummer moeten hetzelfde telefonieplatform gebruiken. Microsoft waarschuwt dat een combinatie van Azure Communication Services en Teams de oproep kan verhinderen en het verzoek automatisch kan sluiten.
Dit telt extra zwaar omdat customer first callback na activering niet kan worden uitgeschakeld. Het eerste opgeslagen profiel wordt bovendien toegepast op wachtrijen die directe terugbelactie al als overflow gebruiken. Maak eerst een inventaris en oefen de profielkeuze. De documentatie voor directe terugbelactie beschrijft ook de eerdere stroom waarbij eerst een medewerker werd toegewezen.
Houd de oorspronkelijke belofte zichtbaar
Een duplicaatcontrole helpt alleen als het eerste verzoek zichtbaar blijft. De team inbox kan eigenaar en notities tonen, terwijl AI Calls het echte resultaat moet bewaren in plaats van te sluiten na alleen een kiespoging.
Gebruik de installatiegids voor AI Calls om uren, fallback en klantrecordgedrag vast te leggen. De gids voor gespreksuitkomsten onderscheidt beantwoord, geverifieerd, overgedragen, gemist en mislukt. Het bredere supportmodel wijst een eigenaar toe aan urgente herhaalde oproepen, terwijl automatiseringsregels vervolgwerk zichtbaar houden.
Meet niet alleen hoeveel duplicaten zijn gestopt. Bekijk herhaalde oproepen tijdens het wachten, het oudste actieve verzoek, succesvolle verbinding, oplossing en klachten over een verloren belofte. Minder duplicaten is alleen goed als de eerste klant werkelijk wordt geholpen.
Veelgestelde vragen
Hoe vindt Dynamics 365 een dubbel terugbelverzoek
Het systeem vergelijkt het telefoonnummer met actieve verzoeken wanneer de directe terugbelactie vanuit overflow start. De controle kan in de huidige of alle wachtrijen gelden.
Moet de controle over alle wachtrijen lopen
Alleen wanneer die wachtrijen dezelfde operationele belofte vertegenwoordigen. Begin smal bij aparte diensten of veel gedeelde telefoonnummers.
Wat gebeurt er bij de tweede oproep
Vertel dat er al een verzoek actief is. Beëindig de oproep als dat zeker klopt, of laat de klant wachten wanneer identiteit, urgentie of onderwerp onzeker is.
Wat moet voor activering worden getest
Test beide bereiken, beide klantuitkomsten, capaciteit, herhaalstatussen, telefonieplatform, rapportage en de wachtrijen die het eerste profiel erven.
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







