Telefonsvarardetektering för röst-AI: designa varje samtalsutfall

Telefonsvarardetektering (AMD, answering machine detection) är steget som avgör om det var en person, ett röstbrevlådemeddelande eller en automatisk telefonmeny som svarade på ett utgående samtal. När du driftsätter röst-AI bör vart och ett av de svaren vara ett eget samtalstillstånd med en definierad åtgärd, loggpost och omringningsregel.

Många utgående samtal hamnar i en röstbrevlåda eller en telefonmeny, inte hos en person. När detekteringen ligger i en separat uppringare som skruvats fast framför agenten blir de samtalen rester som någon får sortera efter kampanjen. Den här guiden bygger in dem från början, så att utvecklare vet vad de ska konfigurera och driftansvariga vet vad som hamnar i CRM:et.

Vad avgör telefonsvarardetektering egentligen?

Den avgör vem eller vad som svarade, tillräckligt tidigt för att agenten ska kunna ändra sitt beteende under samma samtal. I Retell kommer det beslutet från två separata detektorer:

• Röstbrevlådedetektering känner igen ett röstbrevlådemeddelande och lägger sedan antingen på eller lämnar ett meddelande.
• IVR-detektering känner igen en automatisk telefonmeny och avslutar samtalet om IVR Hangup är aktiverat.

Båda körs på utgående telefonsamtal (och på webbsamtal, vilket är hur du testar dem). De påverkar inte inkommande samtal, eftersom det då är en person som ringer dig. Detekteringen körs bara under de första 3 minuterna efter att samtalet kopplats upp, och det fönstret går inte att konfigurera. Tid i en telefonmeny eller i samtal med en person räknas in i fönstret.

Två andra utfall ligger nära AMD. Telefoner som filtrerar okända uppringare kan be agenten om namn och anledning till samtalet innan personen bestämmer sig för att svara. Och vissa samtal kopplas aldrig upp (inget svar, upptaget, avvisat, blockerat), så detekteringen körs aldrig. En komplett design täcker alla dessa.

Varför behandla röstbrevlåda och IVR som samtalstillstånd i stället för efterarbete?

Eftersom rätt åtgärd måste ske under samtalet, och utfallet styr nästa försök. Om agenten först efter samtalet får veta att den nådde en maskin går tre saker fel:

1. Agenten levererar hela sin inledning till ett hälsningsmeddelande, eller pratar över det.
2. CRM:et registrerar ett ”genomfört” samtal som inte nådde någon.
3. Omringningslogiken kan inte skilja på ”lämnade ett meddelande för en timme sedan” och ”kom aldrig fram”, så den ringer antingen för ofta eller ger upp om personer som går att nå.

Ett samtalstillstånd kopplar ihop en detekteringssignal med en åtgärd och en utfallskod.

Vilka samtalstillstånd behöver en utgående röstagent?

Minst de här åtta. Kolumnerna för detektering och loggning beskriver dokumenterat beteende i Retell. Omringningskolumnen är en regel som ditt team sätter i sin egen uppringare eller backend.

När ska agenten lämna ett röstmeddelande i stället för att lägga på?

Lämna ett meddelande när det gör nytta även om ingen ringer tillbaka, och lägg på när ett senare försök skulle göra jobbet bättre. Påminnelser, förfrågningar om återuppringning och deadlines passar bra för ett meddelande. Säljinledningar, och allt du inte vill att en familjemedlem eller kollega ska höra på högtalare, gör det oftast inte.

Retell ger dig två typer av meddelanden:

• Statisk mening: fast text med dynamiska variabler, till exempel Hej {{first_name}}, det här är kliniken som bekräftar din tid. Ring oss gärna tillbaka.
• Prompt: instruktioner som agenten använder för att generera meddelandet, till exempel att sammanfatta varför den ringde och be om en återuppringning.

Oavsett vilket väntar agenten på sin tur att tala, så att meddelandet inte börjar ovanpå hälsningen. Håll koll på standardinställningarna: nya tomma agenter i dashboarden startar med röstbrevlådedetektering aktiverad och inställd på att lägga på, men befintliga agenter, importerade konfigurationer och överföringsagenter behåller sina inställningar, och agenter som skapas via API behöver voicemail_option uttryckligen inställt. API:t accepterar också en valfri detection_prompt som beskriver vad som ska räknas som röstbrevlåda.

För formuleringar av meddelanden, se 5 bästa metoderna för röstmeddelanden med AI-röstagenter.

Vad ska agenten göra när den når en telefonmeny?

Avgör först om menyn är en återvändsgränd eller en väg vidare. Om en påminnelsekampanj till konsumenter hamnar i ett företags växel är numret troligen fel, så aktivera IVR Hangup och logga ivr_reached. Om personen du behöver nå sitter bakom en meny, som hos försäkringsbolag, leverantörer eller faktureringslinjer, navigera menyn i stället och låt IVR Hangup vara avaktiverat, eftersom det skulle avsluta samtalet vid detektering.

För navigering använder single-prompt- och multi-prompt-agenter verktyget Press Digit, och conversation flow-agenter använder Press Digit-noden. Några dokumenterade inställningar är viktiga:

• Pause Detection Delay anger hur länge agenten väntar efter att menyn pausat innan den trycker. Standardvärdet är 1 000 ms och värden från 0 till 5 000 ms accepteras. Höj det för långsamma menyer.
• Agenten kan trycka 0 till 9, * och #, var för sig eller som en sekvens, till exempel ett anknytningsnummer.
• I ett flöde skriver du övergångar för både lyckade och misslyckade utfall, som att nå rätt avdelning, att menyn upprepas tre gånger, fel företag eller ett meddelande om stängt eller röstbrevlåda.

Den sista övergången är viktig på grund av 3-minutersfönstret. En röstbrevlåda som nås efter en lång meny, eller efter att någon har överfört samtalet, kanske inte utlöser röstbrevlådedetektering, så flödet måste själv känna igen den.

Om lägg på vid röstbrevlåda är aktiverat men ett samtal ändå inte läggs på har systemet troligen klassificerat hälsningen som en IVR. Aktivera IVR Hangup för att täcka det fallet. Läs mer om menyer på Navigera IVR.

Vad ska loggas för varje samtalsutfall?

Logga plattformens orsak till att samtalet kopplades ner och mappa den till ett utfallskodsfält som dina egna system äger. Retell erbjuder tre nivåer:

• call_status: registered, not_connected, ongoing, ended eller error.
• disconnection_reason: det specifika utfallet från tabellen ovan.
• in_voicemail i call_analysis: om samtalet nådde en röstbrevlåda.

Webhooken call_ended innehåller alla samtalsfält utom call_analysis, som kommer med call_analyzed. Samtal som aldrig kopplas upp hoppar över call_started men skickar ändå båda. Webhooks skickas om upp till 3 gånger om inget 2xx-svar kommer inom 10 sekunder, så deduplicera på händelse plus call_id.

För mer detaljerade utfallskoder, lägg till fält för extrahering efter samtal. Ett väljarfält fungerar bra för en utfallskod, och IVR-dokumentationen från Retell innehåller färdiga fältdefinitioner som reached_human, ivr_outcome och ivr_path. Retell fyller inte i anpassade extraheringsfält för samtal som inte kopplades upp eller saknade konversation, så bygg utfallskoden utifrån disconnection_reason först och använd extraheringsfält för att lägga till detaljer.

Driftansvariga kan följa måttet Voicemail Rate i analysdashboarden och visa voicemail_reached-samtal per agentversion i ett diagram, vilket visar om en ny version skickar fler samtal till röstbrevlådan. För att skicka utfallskoder till en post i CRM:et, se arbetsflödet från CRM till röst-AI.

Vem äger omringningsregeln?

Det gör din uppringare eller backend. Dokumentationen från Retell beskriver ingen automatisk omringning och anger att Retell inte begränsar hur ofta din agent ringer ett nummer. Batchsamtal har ingen inställning för fördröjning per samtal och kontrollerar inte do-not-call-flaggan; Create Phone Call API kontrollerar den bara med honor_internal_dnc: true.

Retell ger dig däremot underlaget för en omringningspolicy:

• Contacts registrerar varje utgående telefonsamtal som en konversation, inklusive röstbrevlåda och obesvarade samtal. En karenstid på last_conversation_timestamp täcker därför även uppringningsförsök.
• List contact conversations returnerar nedkopplingsorsaken för varje samtal, så att du kan räkna försök per utfall, till exempel ”två röstmeddelanden lämnade den här veckan, stopp”.
• Do-not-call-detektering avslutar samtalet med user_requested_dnc och markerar kontakten. Behandla det som ett permanent stopp.

Fråga juristerna vilka regler för samtalsfrekvens som gäller för din bransch och region innan du sätter taken.

Var uppmärksam på en bieffekt. Operatörer kan flagga ett nummer som spam när det ringer många korta samtal under en kort period, och samtalen misslyckas då som dial_failed. En kampanj som lägger på vid varje röstbrevlåda skapar exakt det mönstret, så anpassa takten och registrera dina nummer. Checklistan för utgående telefonnummer tar upp verifiering och varumärkt nummerpresentation.

Hur testar du telefonsvarardetektering före lansering?

Testa varje tillstånd i tabellen före den första riktiga kampanjen. Retell stöder två testomgångar:

1. Webbsamtal: spela upp ett inspelat röstbrevlådemeddelande eller en menyprompt i ett webbsamtal. Agenten använder samma detektering och åtgärder, utan att nå en riktig röstbrevlåda eller meny.
2. Telefonsamtal: ring riktiga utgående testsamtal, som även testar operatörens ljudväg.

En kort testuppsättning:

• Ett vanligt röstbrevlådemeddelande, med lämna meddelande aktiverat och med lägg på aktiverat
• Ett meddelande från ett företag om att det har stängt för dagen
• En knappsatsmeny, inklusive ett felaktigt val och en upprepad meny
• En samtalsfiltrering i telefonen som frågar efter namn och anledning
• En person som svarar med en lång paus
• Varje test hamnar med förväntad disconnection_reason och rätt utfallskod i ditt CRM

Bygg in samtalstillstånd i dina utgående kampanjer

AMD fungerar bäst när det är en del av arbetsflödet, inte ett filter framför det. Retell samlar röstbrevlådedetektering, IVR-hantering, samtalsfiltrering och nedkopplingsorsaker på samma plattform som agenten, så att varje utfall kan ha sin egen åtgärd och loggpost. För att köra de här samtalstillstånden över en kontaktlista, börja med batchsamtal i Retell.