Automatische retries bij warm-transfers in Famulor

Een warm-transfer kan correct geconfigureerd zijn en toch mislukken omdat de ontvanger bezet is, de oproep mist of de beller doorstuurt naar de voicemail. De update van Famulor van 23 september 2026 voegt een specifiek hulpmiddel toe: een warm-transfer tool kan automatisch opnieuw dezelfde collega bellen bij geselecteerde uitkomsten die voor een retry in aanmerking komen. De oorspronkelijke beller blijft verbonden en de geconfigureerde fallback neemt het over zodra het maximale aantal pogingen is bereikt. Dit is geen garantie dat een transfer zal slagen. Het is een gecontroleerd retry-mechanisme voor situaties waarin een nieuwe poging redelijk is.

Deze handleiding legt uit hoe je de functie configureert, welke uitkomsten een nieuwe poging triggeren, wanneer retries stoppen en hoe je het volledige traject test vóór ingebruikname. Dit is gebaseerd op de Famulor changelog van 23 september 2026 en de huidige documentatie over ingebouwde tools en telefoontransfers.

Belangrijkste punten

• Retry bij geen antwoord is per warm-transfer tool in te schakelen en staat standaard uit. Bestaande tools behouden hun eerdere gedrag totdat je dit inschakelt.
• Famulor kan opnieuw proberen na geen antwoord, een bezet signaal, tijdelijke onbereikbaarheid of gedetecteerde voicemail. Een succesvolle verbinding, expliciete weigering, permanente fout of het verbreken van de verbinding door de beller stopt de retries.
• De retry-vertraging accepteert waarden van 5 tot 120 seconden. Het maximum aantal pogingen accepteert 0 tot 100 en is inclusief de eerste oproep; 0 betekent doorgaan zolang de beller verbonden blijft, binnen de geldende limieten voor gespreksduur en tegoed.
• Een fallback blijft essentieel. Deze wordt geactiveerd wanneer het aantal pogingen is uitgeput of de fout niet voor een retry in aanmerking komt.

Wat automatische warm-transfer retries oplossen

Een warm-transfer verschilt van een cold-transfer doordat de AI-assistent eerst contact opneemt met de ontvanger, context verstrekt en de wachtende beller pas doorverbindt nadat de ontvanger akkoord gaat. De telefoontransfer-documentatie van Famulor maakt expliciet onderscheid tussen toestemming om de briefing te horen en toestemming om de beller door te verbinden. De ontvanger weet daarom waarom het gesprek wordt doorverbonden voordat beide partijen worden samengevoegd.

Automatische retries lossen een kleiner probleem binnen die reeks op: de geselecteerde collega blijft de juiste bestemming, maar is tijdelijk onbereikbaar. In plaats van het transfertraject na de eerste mislukte poging te verlaten, kan de assistent wachten gedurende een geconfigureerd interval en dezelfde collega opnieuw bellen. Het oorspronkelijke gesprek blijft actief terwijl dit gebeurt.

Dit patroon is vooral relevant voor on-call teams, 24/7 ondersteuning en kleine operaties waar geen gelijkwaardige tweede ontvanger beschikbaar is. Het is geen vervanging voor load balancing of afdelingsroutering, omdat het gedocumenteerde gedrag de zelfde collega opnieuw probeert te bereiken.

Voor de bredere reeks van in de wacht zetten, briefing, goedkeuring en het terugkoppelen van informatie naar de beller, lees je de bestaande handleiding over warm-transfer uitkomsten en consultatienotities. Dit artikel richt zich uitsluitend op het nieuwe retry-segment tussen een mislukte poging en de fallback. Voor een bredere vergelijking van overdrachtstypes, zie de handleiding voor het overdragen van een AI voice-agent gesprek naar een mens.

Vier beslissingen vóór de configuratie

Verduidelijk deze punten voordat je de schakelaar omzet:

1. Ontvanger: Is dezelfde collega nog steeds de juiste bestemming bij een volgende poging? Zo niet, gebruik dan andere routering of een fallback-pad.
2. Wachttijd: Hoe lang kan een beller redelijkerwijs verbonden blijven voordat een terugbelverzoek of een andere optie beter is?
3. Limiet voor pogingen: Hoeveel oproepen passen bij de urgentie, verwachte beschikbaarheid en telefoniekosten van deze workflow?
4. Fallback: Wat moet er gebeuren als niemand opneemt? Het gesprek voortzetten, een terugbelverzoek vastleggen, het gesprek beëindigen of een cold-transfer naar een alternatief nummer uitvoeren?

Deze beslissingen zijn onderling afhankelijk. Een korte vertraging in combinatie met veel pogingen kan alsnog leiden tot een lange wachttijd. De limiet op 0 instellen is mogelijk, maar maakt eindeloze retries geen goede klantervaring. Famulor stelt dat bestaande limieten voor gespreksduur en tegoed van kracht blijven.

Hoe je automatische warm-transfer retries configureert

1. Open de juiste warm-transfer tool

Open de warm-transfer tool die de beoogde collega belt. Controleer de bestemming, het uitgaande werkpleknummer, de wachtmuziek, het wachtbericht, de briefing en de ring-timeout. Famulor documenteert een ring-timeout voor warm-transfers van 5 tot 120 seconden, met 30 seconden als standaard.

Checkpoint: De ontvanger ontvangt al een nuttige briefing en wordt pas verbonden na expliciete goedkeuring. Vermijd het wijzigen van de ontvanger, briefing en retry-gedrag in dezelfde test als je wilt achterhalen wat een resultaat heeft veroorzaakt.

2. Schakel Retry bij geen antwoord in

Zet Retry bij geen antwoord aan voor die tool. Omdat de optie tool-specifiek is, kan een noodoverdracht opnieuw proberen terwijl een standaard afdelingstransfer na één poging direct naar de fallback gaat.

Volgens de documentatie van de ingebouwde tools gedragen deze uitkomsten zich als volgt:

Het onderscheid is belangrijk. Famulor toont provider-neutrale foutcodes zoals no_answer, busy, declined en destination_forbidden, plus of een retry zinvol is. Een mislukte transfer moet niet automatisch als retry-waardig worden beschouwd.

3. Stel retry-vertraging en maximum aantal pogingen in

Stel Retry-vertraging in tussen 5 en 120 seconden. Kies daarna Maximum aantal pogingen tussen 0 en 100. De eerste oproep telt mee voor dit aantal. Een waarde van 3 betekent dus maximaal drie oproepen in totaal, niet drie retries na de eerste oproep.

Een waarde van 0 blijft proberen zolang de beller verbonden blijft. Dit overschrijdt de limieten voor gespreksduur of tegoed niet. Voor veel productie-workflows is een eindig getal makkelijker uit te leggen, te testen en te koppelen aan een duidelijke fallback.

Checkpoint: Noteer de verwachte maximale wachttijd. Deze is inclusief overgaande periodes en de vertragingen tussen pogingen; het opzetten van een gesprek kan extra tijd kosten. Beloof geen exacte overdrachtstijd tenzij je dit hebt gemeten in je eigen telefonie-omgeving.

4. Configureer de fallback

De fallback wordt uitgevoerd nadat alle pogingen zijn uitgeput of na een niet-retry-waardige fout. Famulor documenteert drie algemene opties: laat de assistent doorgaan en alternatieven aanbieden, zeg gedag en beëindig het gesprek, of voer een cold-transfer uit naar een fallback-nummer zonder briefing.

Een nuttige fallback toont geen interne foutcode wanneer de beller alleen een volgende stap nodig heeft. Bied een terugbelverzoek aan, leg een bericht vast, bied een ander kanaal aan of routeer naar een nummer dat daadwerkelijk bemand is. Bepaal ook welke details naar de volgende ontvanger worden doorgestuurd.

5. Controleer de toegewezen tool in Flows

In Flow Builder worden de retry-vertraging en het aantal pogingen niet onderhouden als afzonderlijke instellingen van de warm-transfer node. De huidige documentatie zegt dat de node zijn toegewezen warm-transfer tool gebruikt. Wijzig het retry-gedrag op die tool en test vervolgens het volledige flow-pad.

Praktisch voorbeeld: noodlijn voor vastgoedbeheer

Een bewoner belt 's nachts over een vermoedelijk waterlek. De AI-assistent verzamelt het adres, het terugbelnummer en een beknopte beschrijving, en start vervolgens een warm-transfer naar de on-call technicus volgens de escalatieregels van de vastgoedbeheerder.

Een realistische reeks zou kunnen zijn:

1. De assistent vertelt de bewoner dat hij contact opneemt met de on-call service en speelt het geconfigureerde wachtbericht af.
2. De eerste poging bereikt de voicemail. Omdat Retry bij geen antwoord aanstaat, wordt de fallback nog niet uitgevoerd.
3. Na de geconfigureerde vertraging belt Famulor opnieuw dezelfde on-call technicus terwijl de bewoner verbonden blijft.
4. Als de technicus opneemt, hoort deze de geconfigureerde briefing. De bewoner wordt pas verbonden nadat de technicus expliciet akkoord gaat.
5. Als elke geconfigureerde poging mislukt, volgt de assistent de fallback, bevestigt de vastgelegde details en legt de volgende gedefinieerde stap uit.

Dit voorbeeld illustreert een workflow; het impliceert geen gegarandeerde beschikbaarheid of responstijden. De vastgoedbeheerder moet definiëren wat als een noodgeval geldt, welke informatie verzameld mag worden en welke toezeggingen de assistent mag doen.

Beperkingen en privacyoverwegingen

Retries creëren extra contactmomenten, maar lossen niet elk overdrachtsprobleem op.

• Geen rotatie van ontvangers: Dezelfde ontvanger wordt opnieuw gebeld. Roterende roosters of escalatie naar meerdere teams vereisen aanvullende routering of een fallback-ontwerp.
• Geen succesgarantie: Bezet, voicemail of geen antwoord kunnen opnieuw voorkomen.
• De beller moet verbonden blijven: Retries stoppen wanneer de beller de verbinding verbreekt.
• Bestaande limieten blijven gelden: Gespreksduur, tegoeden en het geconfigureerde maximum zijn nog steeds van toepassing.
• Toestemming en opname zijn gescheiden: Als gesprekken worden opgenomen of persistente klantgegevens worden opgeslagen, configureer dan de vereiste kennisgevingen en toestemming onafhankelijk. De documentatie over toestemming en transcript-privacy van Famulor maakt expliciet onderscheid tussen toestemming voor opname en toestemming voor het opslaan van een klantprofiel.

Deel alleen de informatie die de ontvanger nodig heeft in de briefing. Als een mislukte warm-transfer consultatie beschikbaar moet worden voor de assistent, gebruikt Famulor een aparte instelling voor het delen van consultatienotities. Die controle is geen onderdeel van automatische retries.

Als je de transfer nog niet hebt aangemaakt in een telefoonassistent, begin dan met het overzicht van no-code AI voice agents en modelleer vervolgens alleen het escalatiepad dat je nodig hebt.

Testmatrix vóór ingebruikname

Test niet alleen het ideale scenario. Een betrouwbare acceptatietest dekt ten minste deze zes gevallen:

Voeg een test toe die het maximum aantal pogingen uitput. Bevestig dat het fallback-bericht begrijpelijk is, geen ongefundeerde beloftes doet en leidt naar een werkende volgende actie. Inspecteer vervolgens de gespreksdetails en mislukte tool-runs in de Historie. Famulor documenteert de status van transferfouten en retry-mogelijkheden in de tool-resultaten en transfer-events.

Veelgestelde vragen

Belt Famulor automatisch een andere collega?

Nee. De gedocumenteerde functie belt opnieuw dezelfde ontvanger. Een alternatief nummer kan een fallback zijn; teamrotatie moet afzonderlijk worden ontworpen.

Telt de eerste oproep mee voor het Maximum aantal pogingen?

Ja. De eerste poging is inbegrepen. Een maximum van 3 betekent in totaal niet meer dan drie oproepen.

Wat betekent een maximum van 0?

Famulor blijft proberen zolang de beller verbonden blijft. Bestaande limieten voor gespreksduur en tegoed blijven van kracht. Gebruik 0 alleen wanneer dat wachtpatroon operationeel en economisch zinvol is.

Werkt dit in Flow Builder?

Ja. Een warm-transfer node gebruikt zijn toegewezen warm-transfer tool en de retry-instellingen staan op die tool.

Conclusie: probeer opnieuw met een duidelijke stopregel

Automatische retries maken een warm-transfer veerkrachtiger wanneer de juiste ontvanger slechts tijdelijk onbereikbaar is. Kwaliteit komt niet voort uit het maximaliseren van pogingen; het komt voort uit het combineren van een geschikte vertraging, een weloverwogen limiet, duidelijke communicatie tijdens het wachten en een werkende fallback.

Begin met één specifiek gedefinieerd transferpad. Test succes, geen antwoord, bezet, voicemail, expliciete weigering, verbreken door beller en uitgeputte pogingen. Breng de retry-logica pas naar productie zodra elk pad resulteert in een duidelijke en nuttige uitkomst.

Over de auteur

Sarah Müller schrijft over de productmogelijkheden van Famulor, Voice AI-workflows en verantwoorde implementatie in echte service-operaties.