Sådan bygger du en AI-bookingagent, der kvalificerer opkaldere, før den booker


De fleste guides til AI-telefonagenter stopper ved det punkt, hvor agenten tager telefonen og siger hej. Den del er nem. Det svære er at få agenten til at stille de spørgsmål, din bedste disponent ville stille, og kun at booke opgaven, når svarene er værd at booke.
Gør du det forkert, har du bare automatiseret din støj. Kalenderen fyldes med lejere, der ikke kan godkende arbejdet, opkaldere uden for dit serviceområde og folk, der er tre måneder fra at beslutte noget som helst. Hver eneste af dem optager en tid, som en rigtig opgave kunne have brugt.
I denne guide bygger vi en AI-bookingagent, der kvalificerer først og booker bagefter. Det er et samtaleflow koblet til en live Cal.com-kalender, og det tager omkring et kvarter. Hvis du kun er kommet for prompterne, er de alle samlet i promptoversigten sidst i guiden.
Videoen herunder viser den samme opbygning fra start til slut på skærmen. Følg med i den, hvis du hellere vil se end læse. De skriftlige trin og prompterne på denne side matcher videoen, så du kan have siden åben i en anden fane og kopiere fra den undervejs.
Hvert indgående opkald, der ikke får en kvalificerende samtale, ender på en af to måder. Enten booker det en opgave, der aldrig ville blive til noget, hvilket brænder en tid og en teknikers køretid af. Eller også tager ingen telefonen hurtigt nok, og opkalderen går videre til næste navn på listen.
Begge dele koster det samme. Det første spilder kapacitet, du allerede har betalt for. Det andet giver omsætningen til en konkurrent, hvis telefon blev besvaret. En agent, der kvalificerer, løser begge problemer, fordi den svarer ved første ring og nægter at booke de opkald, der ikke bør bookes.
Når du opretter en ny stemmeagent, har du to valg: en enkeltprompt-agent eller en samtaleflow-agent.
En enkeltprompt-agent er én samlet blok instruktioner, som modellen læser og improviserer ud fra. Den er hurtig at sætte op og fin til et lineært manuskript, som at læse åbningstider og en adresse op.
Et samtaleflow er et kort over opkaldet, node for node, med eksplicitte forgreninger. Opkalderens svar i hver node afgør, hvilken node der kommer bagefter. Sammenligningen af agenttyper i dokumentationen gennemgår alle fordele og ulemper.
Til kvalificering skal du bruge flowet. Kvalificering er en beslutning, og en beslutning kræver forgreninger, du kan se, teste og rette. Hvis du ikke kan pege på den node, hvor en lejer bliver afvist, har du ikke et kvalificeringstrin – du har et håb om, at modellen husker dine instruktioner.
Start fra bunden i stedet for fra en skabelon, hvis dine kvalificeringskriterier er specifikke for din virksomhed, hvilket de næsten altid er.
Du behøver ikke trække hver eneste node ud i hånden. Conductor er den AI-copilot, der er indbygget i Retell: Du beskriver det opkald, du vil have, den foreslår noder og forgreninger, og du gennemgår det hele, før noget går live.
Brug prompt 1 fra promptoversigten sidst i guiden. Beskrivelsen gør et reelt stykke arbejde, så skriv den som en specifikation frem for et ønske.
Conductor vender tilbage med opklarende spørgsmål, før den bygger. Svar konkret på dem. Når du angiver dit præcise serviceområde og nævner Cal.com som bookingværktøj, kan den placere afvisningsforgreningen og bookingnoden korrekt i stedet for at gætte. Bed om pladsholdere til alt, der kræver legitimationsoplysninger, du ikke har forbundet endnu.
Læs hver node, før du accepterer den. Conductor foreslår, og du godkender – på samme måde, som du ville gennemgå en pull request. Det er det trin, folk springer over, og det er her, en manglende forgrening er billigst at fange.
Her er den fejl, der er værd at lære udenad. Du kan skrive »hvis opkalderen siger, at de lejer, så afslut opkaldet« og få et flow med en afvisningssti, der kun udløses, hvis en opkalder tilfældigvis selv nævner, at de lejer, mens de svarer på noget andet.
Det er ikke et kvalificerende spørgsmål. Det er held.
Det, du ikke eksplicit beder om, får du ikke pålideligt. Hvis ejer eller lejer afgør, om du sender en bil ud, skal der være en node, hvis eneste opgave er at stille det spørgsmål direkte. Det samme gælder serviceområdet. Prompt 7 i oversigten tjekker, om de noder findes, og prompt 8 tilføjer dem.
Booking kræver en rigtig kalender bagved, og det er det ene trin, copiloten ikke kan klare for dig, fordi det kræver dine legitimationsoplysninger.
I Cal.com åbner du Settings, finder fanen API keys og opretter en ny nøgle. Sæt en udløbsdato, der passer til, hvor længe du forventer at bruge den. I Retell går du til Integrations, tilføjer Cal.com og indsætter nøglen. Kontoen vises som forbundet, når det er lykkedes.
Det er hele den manuelle del af opbygningen.
Åbn booking-subflowet. Inde i det skal du bruge to funktioner: én, der tjekker ledighed, og én, der booker.
Begge kræver dit event type-ID fra Cal.com. Du finder det i URL'en til det bookinglink, du vil have agenten til at bruge. Det er tallet i URL'en, og det skal ind i feltet til event type-ID på hver funktion.
Tilføj først funktionen til at tjekke ledighed, indsæt event type-ID'et, og gem. Tilføj derefter funktionen til at booke møder med det samme event type-ID, udfyld de resterende felter, og gem. Den komplette liste over Cal.com-funktioner dækker også ombooking og aflysning, når du får brug for det.
Når begge rigtige funktioner er på plads, kører du prompt 3 fra oversigten, så Conductor kobler noderne om til at pege på den live integration.
Kør et testopkald inde fra dashboardet, og spil en opkalder, der burde kvalificere sig.
Det, du holder øje med, er ikke, om agenten lyder godt. Det er, om rækkefølgen holder. I et korrekt forløb spørger agenten, hvad der er galt, spørger om reparation eller udskiftning, spørger om ejer eller lejer, bekræfter serviceområdet, spørger om, hvor presserende det er, og tilbyder derefter tider.
Tre tjek fanger de almindelige fejl, og prompt 4, 5 og 6 i oversigten er løsningerne:
Tilbyder den rigtige tider? Hvis agenten siger, at intet er ledigt, mens din kalender er åben, kender den som regel ikke dagens dato og tjekker derfor et tidsvindue i fortiden.
Kan den håndtere en dato, den ikke allerede har hentet? Bed om en dag uden for de tider, den først tilbød. Et flow, der tjekkede én gang og aldrig kigger igen, insisterer på, at dagen er optaget, selv når den er ledig.
Indsamler den navn og e-mail før booking? Cal.com afviser en booking uden dem. Hvis intet spørger om dem, fejler bookingen, efter at opkalderen allerede har valgt en tid, hvilket er det værst tænkelige sted at fejle.
Kør også afvisningsstierne. En lejer uden godkendelse og en opkalder uden for serviceområdet skal begge få opkaldet afsluttet høfligt, uden at der forsøges en booking. Bekræft det i stedet for at gå ud fra det.
Udgiv agenten, køb derefter et telefonnummer, og tildel det. Det samme nummer fungerer til både indgående og udgående opkald.
Den vane, der er værd at opbygge, er at læse opkaldshistorikken. Hvert opkald efterlader en udskrift og et resumé, så du kan se, hvad opkalderen ville, og hvordan agenten håndterede det. I testopkaldet til denne opbygning viser registreringen en tagreparation booket for et hul i et eksisterende tag på en lejebolig i Long Island City, med udlejers tilladelse noteret.
Det er den kontekst, din tekniker har brug for, før bilen kører, og ingen har tastet den ind. Prompt 9 i oversigten omdanner de samme oplysninger til strukturerede felter, dit CRM kan læse, ved hjælp af analyse efter opkald.
Læs udskrifterne fra de første uger grundigt. De fortæller dig, hvilket spørgsmål agenten stiller dårligt, hvilken forgrening ingen når frem til, og hvilken afvisning du har glemt at bygge.
Når kvalificeringen holder, er de nyttige tilføjelser en ekstra kalender, så forskellige opgavetyper sendes til forskellige teknikere, og dynamiske variabler, så en agent, der besvarer et opkald fra en kendt kunde, allerede ved, hvem der ringer, i stedet for at spørge fra bunden.
Rækkefølgen betyder noget. En agent, der booker de forkerte opkaldere hurtigere, er værre end ingen agent. Kvalificering først, derefter volumen.
Der er to måder at bygge dette flow på. Du kan beskrive det for Conductor og godkende det, den foreslår, eller du kan placere noderne selv og indsætte instruktionsteksten i hver enkelt. Begge sæt findes her sammen med en samlet specifikation, der springer de fire problemer over, som denne opbygning oprindeligt løb ind i.
Hvis du kun kopierer én ting fra denne side, så kopier denne. Den giver Conductor alle fire krav på én gang i stedet for at lade dig opdage dem som fejl senere.
Før du bygger: Forbind først Cal.com under siden Integrations i dashboardet (API-nøgle, cal.com vs. cal.eu). Byg noderne til at tjekke ledighed og booke møder direkte med Retells indbyggede Cal.com-integrationsværktøjer. Brug ikke tilpassede pladsholderfunktioner.
Global prompt: Inkluder »Dags dato og klokkeslæt er {{current_time}}. Fortolk altid relative datoer – i dag, i morgen, næste mandag, om et par dage – ud fra denne faktiske dato. Gæt aldrig en dato.«
Ledighedsnode: Forespørg altid et standardvindue på 14 dage fra i dag, uanset hvor vagt eller specifikt opkalderens første svar er. Hvis opkalderen senere nævner en dato uden for det aktuelt hentede vindue, så kør tjekket igen med et vindue, der inkluderer datoen, før du siger, at den ikke er ledig.
Før bookingnoden: Indsaml opkalderens fulde navn og e-mail, som begge er obligatoriske felter i Cal.com-bookingkaldet. Kald ikke bookingfunktionen, før begge er indsamlet.
Den ene blok forhindrer fire separate fejl: pladsholderfunktioner, der ikke peger på noget rigtigt, en agent, der ikke kender dagens dato, et ledighedsvindue, der er for snævert til at besvare opkalderens egentlige spørgsmål, og en booking, der fejler, fordi ingen spurgte om navn og e-mail.
Skriv dem én ad gangen, og læs, hvad Conductor foreslår, før du accepterer. Prompt 4 til 6 er løsningerne på de tre fejl i trin 5, hvis du hellere vil støde på dem og løse dem undervejs.
1. Opsæt flowets grundstruktur
Byg et samtaleflow for et HVAC- og tagfirma. Hils på opkalderen, og spørg, om de har brug for en reparation eller en komplet systemudskiftning. Forgren ud fra svaret. Hvis opkalderen siger, at de lejer og ikke kan godkende arbejdet, eller at de er uden for vores serviceområde, så afslut opkaldet høfligt uden at booke. Ellers spørg, om de vil have det udført inden for de næste par uger, eller om de bare indhenter tilbud, og gå derefter videre mod at booke en aftale.
2. Udskift pladsholderne med din rigtige kalender
Kan funktionerne til at tjekke ledighed og booke møder erstattes med min faktiske Cal.com-integration?
3. Peg flowet mod de funktioner, du har opsat i hånden
Jeg har tilføjet Cal.com-integrationsfunktionerne. Brug venligst dem, og sæt dem ind i stedet for pladsholder-undernoderne.
4. Agenten siger, at intet nogensinde er ledigt
Hver gang jeg vil booke en aftale, virker ledigheden aldrig – den siger, at der ikke er nogen ledige tider de næste par dage. Hvorfor?
5. Ledighedsvinduet er for snævert
Jeg testede det, og AI'en sagde, at der kun var ledighed frem til fredag, men i dag er det onsdag, og kalenderen lader mig booke næste mandag. Hvorfor tilbyder agenten ikke det?
6. Bookingen fejler i sidste trin
Vi fik mandagsbookingen, men så fejler bookingen, tror jeg, fordi der er nogle oplysninger, der skal indsamles først.
7. Tjek, om kvalificeringen faktisk findes
Jeg kan ikke se nogen kvalificering i flowet. Har vi bygget nogen cases til det?
8. Tilføj et eksplicit kvalificeringslag
Vi har brug for endnu et lag kvalificeringsspørgsmål for at finde ud af, om de lejer eller ejer. Ejer er fint, lejer betyder, at vi skal have godkendelse fra udlejeren. Det samme gælder placering: uden for Queens, NY er et nej.
9. Indfang leaddata ved afslutningen
Tilføj et trin med analyse efter opkald, der registrerer, om opkalderen kvalificerede sig, om det var en reparation eller en udskiftning, hvor presserende de sagde, det var, og et resumé på én linje til teknikeren.
Indsæt hver blok i den tilsvarende node i stedet for at prompte efter den.
Prompt på agentniveau, sat øverst i flowet
Du er bookingassistent for et servicefirma, der håndterer opkald om HVAC- og tagreparationer. Din opgave er hurtigt at forstå, hvad opkalderen har brug for, vurdere, om det er værd at sende en tekniker ud, og i så fald booke en aftale på stedet. Hold det kort og naturligt, som en venlig disponent, ikke som et manuskript, der læses op. Find aldrig på ledighed, brug kun det, som kalenderværktøjet returnerer.
Dags dato og klokkeslæt er {{current_time}}. Fortolk altid relative datoer ud fra denne faktiske dato. Gæt aldrig en dato.
Node 1, hilsen og første spørgsmål
Hils på opkalderen, og spørg, hvad der er galt med deres HVAC- eller tagproblem. Spørg derefter: »Er det noget, du gerne vil have repareret, eller overvejer du en komplet systemudskiftning?« Vent på svaret, før du går videre.
Node 2, forgreningsbetingelser. De sættes på overgangene ud af node 1, ikke på en selvstændig node:
Node 3, afvisning
Forklar høfligt, at dette falder uden for, hvad vi kan planlægge lige nu – enten fordi de lejer uden ejerens godkendelse, eller fordi de er uden for vores serviceområde. Foreslå, at de taler med deres ejendomsadministrator eller kontakter os igen, hvis det ændrer sig. Tak dem, og afslut opkaldet høfligt. Tilbyd ikke at booke noget.
Node 4, spørgsmål om hast
Spørg: »Vil du gerne have det udført inden for de næste par uger, eller indhenter du bare tilbud lige nu?« Brug svaret til at fastsætte, hvor presserende det er, men fortsæt mod booking, medmindre de tydeligt siger, at de ikke er klar til at booke.
Node 5, indsaml kontaktoplysninger. Denne node ligger mellem spørgsmålet om hast og bookingnoden, og det er det trin, de fleste opbygninger glemmer:
Bed om opkalderens fulde navn og e-mailadresse, så vi kan sende en bekræftelse. Hold det kort, ét spørgsmål ad gangen om nødvendigt. Gå ikke videre til booking, før du har begge dele.
Bookingnoden, hvor Cal.com-funktionerne ligger
Når begge spørgsmål er besvaret, og opkalderen ikke er blevet afvist, så kald Check Availability. Læs 2 eller 3 ledige tider op i en naturlig sætning, ikke som en liste. Vent på, at opkalderen bekræfter én af dem mundtligt, og kald derefter Book Appointment med den tid. Kald aldrig Book Appointment før en mundtlig bekræftelse.
Udtræksfelter efter opkaldet. Fire felter, der er værd at registrere ved hvert opkald: qualified som boolean, true hvis booket og false hvis afvist eller afslået. repair_or_replacement som en vælger, taget fra det første svar. urgency som en vælger med denne uge, denne måned eller kun tilbud, taget fra det andet svar. Og summary_for_tech som tekst, én eller to sætninger om problemet skrevet til den, der møder op.
Kør disse som simuleringer, før du sætter agenten på et rigtigt nummer. Conductor beder dig først bekræfte omfanget, fordi simuleringskørsler faktureres.
Kan du køre et simuleret testopkald, hvor opkalderen siger, at de lejer ejendommen og ikke kan godkende arbejdet? Jeg vil bekræfte, at agenten afslår at booke og afslutter opkaldet i stedet for at fortsætte mod booking.
Det samme, men for en opkalder uden for vores serviceområde. Kan du simulere det og bekræfte, at opkaldet afsluttes uden booking?
Hvis et live opkald booker en person, der burde være blevet afvist, kan disse to diagnosticere det:
Jeg testede et opkald som lejer, der ikke kan godkende arbejdet, men agenten fortsatte og forsøgte at booke alligevel. Hvorfor afviser den ikke på det svar?
Jeg ringede fra uden for vores serviceområde, og den tilbød stadig at booke. Hvorfor udløses afvisningsforgreningen ikke?
Omkring et kvarter for opbygningen i denne guide, fra en tom konto til en udgivet agent med et telefonnummer. Afsæt mere tid til test. Selve flowet opsættes ud fra én prompt, men det er testopkaldene, der fanger datohåndtering, ledighedsvinduer og manglende bookingfelter, der tager den reelle tid.
Nej. Hele flowet bygges ved at beskrive det i almindeligt sprog og godkende det, copiloten foreslår. De eneste manuelle trin er at indsætte en Cal.com-API-nøgle og kopiere et event type-ID fra en URL.
En enkeltprompt-agent læser én blok instruktioner og improviserer. Et samtaleflow er et eksplicit kort, node for node, med forgreninger, du kan inspicere og teste. Brug en enkelt prompt til et lineært manuskript og et samtaleflow, når opkaldet indebærer en beslutning, hvilket kvalificering altid gør.
Ja. Cal.com bruges her, fordi dets booking-API er nemt at opsætte. Det samme mønster – en funktion til at tjekke ledighed efterfulgt af en funktion til at booke møder – gælder for andre kalenderintegrationer.
Der er typisk to årsager. Agenten kender ikke den aktuelle dato og tjekker derfor et vindue, der allerede er passeret. Eller den tjekkede et snævert vindue én gang og tjekkede aldrig igen, da opkalderen nævnte en anden dag. Prompt 4 og 5 i promptoversigten løser hvert tilfælde.
De når frem til en afvisningsnode, der afslutter opkaldet høfligt uden at booke noget. Den sti skal bygges eksplicit. Det er ikke nok at beskrive reglen i din første prompt, og det er netop det, prompt 7 og 8 er der for at fange.
See how much your business could save by switching to AI-powered voice agents.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Et demonummer fra Retell Clinic Office

Start building smarter conversations today.


