Så bygger du en AI-bokningsagent som kvalificerar uppringare innan den bokar
11
MIN READ
October 2, 2026
De flesta guider om AI-telefonagenter slutar där agenten svarar och säger hej. Den delen är enkel. Det svåra är att få den att ställa de frågor som din bästa ordermottagare skulle ställa, och att bara boka jobbet när svaren är värda att boka.
Gör du fel här har du bara automatiserat bruset. Kalendern fylls med hyresgäster som inte kan godkänna arbetet, uppringare utanför ditt serviceområde och personer som är tre månader från att bestämma sig för något. Var och en av dem tar en tid som ett riktigt jobb kunde ha använt.
Den här guiden bygger en AI-bokningsagent som kvalificerar först och bokar sedan. Det är ett konversationsflöde kopplat till en aktiv Cal.com-kalender, och det tar ungefär femton minuter. Om du bara kom hit för prompterna finns alla samlade i promptindexet nära slutet.
Videon nedan visar samma bygge från start till mål på skärmen. Följ med i den om du hellre tittar än läser. De skriftliga stegen och prompterna på den här sidan matchar videon, så du kan ha sidan öppen i en andra flik och kopiera från den medan du bygger.
Varje inkommande samtal utan kvalificering slutar på ett av två sätt. Antingen bokas ett jobb som aldrig skulle bli av, vilket bränner en tid och en teknikers körtid. Eller så svarar ingen tillräckligt snabbt och uppringaren går vidare till nästa namn på listan.
Båda kostar samma sak. Det första slösar kapacitet som du redan har betalat för. Det andra ger intäkterna till en konkurrent som svarade i telefon. En agent som kvalificerar löser båda, eftersom den svarar vid första signalen och vägrar boka de samtal som inte borde bokas.
När du skapar en ny röstagent har du två val: en agent med en enda prompt eller en agent med konversationsflöde.
En agent med en enda prompt är ett block med instruktioner som modellen läser och improviserar utifrån. Den går snabbt att sätta upp och fungerar bra för ett linjärt manus, som att läsa upp öppettider och en adress.
Ett konversationsflöde är en karta över samtalet, nod för nod, med tydliga förgreningar. Uppringarens svar i varje nod avgör vilken nod som kommer härnäst. Jämförelsen av agenttyper i dokumentationen går igenom alla för- och nackdelar.
För kvalificering vill du ha flödet. Kvalificering är ett beslut, och ett beslut kräver förgreningar som du kan se, testa och åtgärda. Om du inte kan peka på noden där en hyresgäst avvisas har du inget kvalificeringssteg, bara en förhoppning om att modellen kommer ihåg dina instruktioner.
Börja från noll i stället för från en mall om dina kvalificeringskriterier är specifika för ditt företag, vilket de nästan alltid är.
Du behöver inte dra ut varje nod för hand. Conductor är AI-copiloten som är inbyggd i Retell: du beskriver samtalet du vill ha, den föreslår noder och förgreningar, och du granskar innan något går live.
Använd prompt 1 från promptindexet i slutet av guiden. Beskrivningen gör verklig nytta, så skriv den som en specifikation snarare än en önskan.
Conductor återkommer med förtydligande frågor innan den bygger. Svara konkret. Att ange ditt exakta serviceområde, och att nämna Cal.com som bokningsverktyg, är det som gör att den kan placera diskvalificeringsgrenen och bokningsnoden rätt i stället för att gissa. Be om platshållare för allt som kräver inloggningsuppgifter som du inte har kopplat ännu.
Läs varje nod innan du godkänner den. Conductor föreslår, du godkänner, på samma sätt som du skulle granska en pull request. Det här är steget som många hoppar över, och det är här en saknad förgrening är billigast att upptäcka.
Här är felet som är värt att ta till sig. Du kan skriva ”om uppringaren säger att hen hyr, avsluta samtalet” och få ett flöde med en diskvalificeringsväg som bara aktiveras om en uppringare råkar nämna att hen hyr medan hen svarar på något annat.
Det är ingen kvalificeringsfråga. Det är tur.
Det du inte uttryckligen ber om får du inte på ett tillförlitligt sätt. Om ägare eller hyresgäst avgör om du skickar ut en bil behöver det finnas en nod vars enda uppgift är att ställa just den frågan direkt. Samma sak gäller serviceområdet. Prompt 7 i indexet kontrollerar om de noderna finns, och prompt 8 lägger till dem.
Bokning kräver en riktig kalender i bakgrunden, och det här är det enda steget som copiloten inte kan göra åt dig, eftersom det kräver dina inloggningsuppgifter.
I Cal.com öppnar du Settings, hittar fliken API keys och skapar en ny nyckel. Ange ett utgångsdatum som motsvarar hur länge du räknar med att använda den. I Retell går du till Integrations, lägger till Cal.com och klistrar in nyckeln. Kontot visas som anslutet när det har gått igenom.
Det är hela den manuella delen av bygget.
Öppna underflödet för bokning. I det behöver du två funktioner: en som kontrollerar tillgänglighet och en som bokar.
Båda behöver ditt event type ID från Cal.com. Du hittar det i URL:en till bokningslänken som du vill att agenten ska använda. Det är numret i URL:en, och det ska in i fältet för event type ID i varje funktion.
Lägg till funktionen för att kontrollera tillgänglighet först, klistra in event type ID och spara. Lägg sedan till funktionen för att boka möten med samma event type ID, fyll i övriga fält och spara. Den fullständiga listan över Cal.com-funktioner täcker även ombokning och avbokning när du behöver det.
När båda riktiga funktionerna är på plats kör du prompt 3 från indexet så att Conductor kopplar om noderna till den aktiva integrationen.
Kör ett testsamtal direkt i dashboarden och spela en uppringare som borde kvalificera sig.
Det du ska hålla utkik efter är inte om agenten låter bra, utan om ordningen håller. I en korrekt körning frågar agenten vad som är fel, frågar om reparation eller byte, frågar om ägare eller hyresgäst, bekräftar serviceområdet, frågar hur brådskande det är och erbjuder sedan tider.
Tre kontroller fångar de vanligaste felen, och prompt 4, 5 och 6 i indexet är lösningarna:
Erbjuder den riktiga tider? Om agenten säger att inget är ledigt trots att kalendern är öppen vet den oftast inte dagens datum, så den kontrollerar ett tidsfönster i det förflutna.
Hanterar den ett datum som den inte redan har hämtat? Be om en dag utanför de tider den först erbjöd. Ett flöde som kontrollerade en gång och aldrig tittar igen påstår att dagen är upptagen även när den är ledig.
Samlar den in namn och e-post innan bokningen? Cal.com avvisar en bokning utan dem. Om ingen frågar misslyckas bokningen efter att uppringaren redan har valt en tid, vilket är det sämsta tänkbara stället att misslyckas på.
Kör diskvalificeringsvägarna också. En hyresgäst utan godkännande och en uppringare utanför serviceområdet ska båda få samtalet avslutat artigt, utan att någon bokning görs. Kontrollera det i stället för att anta det.
Publicera agenten, köp sedan ett telefonnummer och tilldela det. Samma nummer fungerar för både inkommande och utgående samtal.
Vanan som är värd att bygga upp är att läsa samtalshistoriken. Varje samtal lämnar en transkription och en sammanfattning, så att du ser vad uppringaren ville och hur agenten hanterade det. I testsamtalet för det här bygget visar posten en takreparation bokad för ett hål i ett befintligt tak, på en hyresfastighet i Long Island City, med hyresvärdens tillstånd registrerat.
Det är den kontext som din tekniker behöver innan bilen åker, och ingen har skrivit in den. Prompt 9 i indexet gör om samma information till strukturerade fält som ditt CRM kan läsa, med hjälp av analys efter samtal.
Läs transkriptionerna ordentligt de första veckorna. De visar vilken fråga agenten ställer dåligt, vilken förgrening ingen når och vilken diskvalificering du glömde att bygga.
När kvalificeringen håller är de mest användbara tilläggen en andra kalender, så att olika typer av jobb dirigeras till olika tekniker, och dynamiska variabler, så att en agent som svarar en känd kund redan vet vem som ringer i stället för att fråga från början.
Ordningen spelar roll. En agent som bokar fel uppringare snabbare är sämre än ingen agent alls. Kvalificering först, sedan volym.
Det finns två sätt att bygga det här flödet. Du kan beskriva det för Conductor och godkänna det som den föreslår, eller så placerar du noderna själv och klistrar in instruktionstexten i var och en. Båda uppsättningarna finns här, tillsammans med en enda specifikation som undviker de fyra problem som det här bygget ursprungligen stötte på.
Om du bara kopierar en sak från den här sidan, kopiera den här. Den ger Conductor alla fyra kraven på en gång i stället för att du upptäcker dem som buggar senare.
Innan du bygger: koppla först Cal.com under sidan Integrations i dashboarden (API-nyckel, cal.com eller cal.eu). Bygg noderna för att kontrollera tillgänglighet och boka möten direkt med de inbyggda Cal.com-integrationsverktygen i Retell. Använd inte anpassade platshållarfunktioner.
Global prompt: inkludera ”Dagens datum och tid är {{current_time}}. Tolka alltid relativa datum, som idag, imorgon, nästa måndag eller om ett par dagar, utifrån det faktiska datumet. Gissa aldrig ett datum.”
Tillgänglighetsnod: fråga alltid efter ett standardfönster på 14 dagar från idag, oavsett hur vagt eller specifikt uppringarens första svar är. Om uppringaren senare nämner ett datum utanför det hämtade fönstret, kör kontrollen igen med ett fönster som inkluderar det innan du säger att det inte är ledigt.
Före bokningsnoden: samla in uppringarens fullständiga namn och e-postadress, som båda är obligatoriska fält för bokningsanropet till Cal.com. Anropa inte bokningsfunktionen förrän båda har samlats in.
Det enda blocket förhindrar fyra separata fel: platshållarfunktioner som inte pekar på något verkligt, en agent som inte vet dagens datum, ett tillgänglighetsfönster som är för smalt för att besvara uppringarens faktiska fråga och en bokning som misslyckas för att ingen frågade efter namn och e-post.
Skriv in dem en i taget och läs vad Conductor föreslår innan du godkänner. Prompt 4 till 6 åtgärdar de tre felen i steg 5, om du hellre stöter på dem och löser dem under tiden.
1. Skapa grundstrukturen för flödet
Bygg ett konversationsflöde för ett HVAC- och takföretag. Hälsa på uppringaren och fråga om hen behöver en reparation eller ett byte av hela systemet. Förgrena utifrån svaret. Om uppringaren säger att hen hyr och inte kan godkänna arbetet, eller befinner sig utanför vårt serviceområde, avsluta samtalet artigt utan att boka. Fråga annars om hen vill få det gjort inom de närmaste veckorna eller bara samlar in offerter, och gå sedan vidare mot att boka ett möte.
2. Byt ut platshållarna mot din riktiga kalender
Kan check-availability och book-appointment ersättas med min faktiska Cal.com-integration?
3. Peka flödet mot funktioner som du har kopplat för hand
Jag har lagt till Cal.com-integrationens funktioner. Använd dem och ersätt platshållarna i undernoderna med dem.
4. Agenten säger att inget någonsin är ledigt
Varje gång jag vill boka ett möte fungerar tillgängligheten aldrig, den säger att det inte finns några lediga tider de närmaste dagarna. Varför är det så?
5. Tillgänglighetsfönstret är för smalt
Jag testade och AI:n sa att det bara fanns lediga tider till och med fredag, men idag är det onsdag och kalendern låter mig boka nästa måndag. Varför erbjuder inte agenten det?
6. Bokningen misslyckas i sista steget
Vi fick måndagsbokningen, men sedan misslyckas bokningen. Jag tror att det beror på information som måste samlas in först.
7. Kontrollera om kvalificeringen faktiskt finns
Jag ser ingen kvalificering i flödet, har vi byggt några fall för det?
8. Lägg till ett uttryckligt kvalificeringslager
Vi behöver ytterligare ett lager med kvalificeringsfrågor för att ta reda på om de hyr eller äger. Att äga är okej, att hyra innebär att vi behöver godkännande från hyresvärden. Samma sak gäller plats: utanför Queens, NY är ett nej.
9. Fånga leaddata innan samtalet avslutas
Lägg till ett steg för analys efter samtal som registrerar om uppringaren kvalificerade sig, om det gällde en reparation eller ett byte, hur brådskande hen sa att det var och en sammanfattning på en rad till teknikern.
Klistra in varje block i motsvarande nod i stället för att prompta fram den.
Prompt på agentnivå, anges högst upp i flödet
Du är en bokningsassistent för ett hemserviceföretag som hanterar samtal om HVAC- och takreparationer. Din uppgift är att snabbt förstå vad uppringaren behöver, avgöra om det är värt att skicka ut en tekniker och i så fall boka ett besök på plats. Håll det kort och naturligt, som en vänlig ordermottagare, inte som ett manus som läses upp. Hitta aldrig på tillgänglighet, använd bara det som kalenderverktyget returnerar.
Dagens datum och tid är {{current_time}}. Tolka alltid relativa datum utifrån det faktiska datumet. Gissa aldrig ett datum.
Nod 1, hälsning och första fråga
Hälsa på uppringaren och fråga vad som har hänt med hens HVAC- eller takproblem. Fråga sedan: ”Är det här något du vill få reparerat, eller funderar du på att byta hela systemet?” Vänta på svaret innan du går vidare.
Nod 2, förgreningsvillkor. De här placeras på kanterna ut från nod 1, inte på en egen nod:
Nod 3, diskvalificering
Förklara artigt att detta ligger utanför vad vi kan boka just nu, antingen för att hen hyr utan ägarens godkännande eller befinner sig utanför vårt serviceområde. Föreslå att hen stämmer av med sin fastighetsförvaltare eller hör av sig igen om det ändras. Tacka och avsluta samtalet artigt. Erbjud inte att boka något.
Nod 4, fråga om hur brådskande det är
Fråga: ”Vill du få det här gjort inom de närmaste veckorna, eller samlar du bara in offerter just nu?” Använd svaret för att ange hur brådskande det är, men fortsätt mot bokning om inte uppringaren tydligt säger att hen inte är redo att boka.
Nod 5, samla in kontaktuppgifter. Den här ligger mellan frågan om hur brådskande det är och bokningsnoden, och det är steget som de flesta byggen glömmer:
Be om uppringarens fullständiga namn och e-postadress så att vi kan skicka en bekräftelse. Håll det kort, en fråga i taget om det behövs. Gå inte vidare till bokning förrän du har båda.
Bokningsnod, där Cal.com-funktionerna finns
När båda frågorna är besvarade och uppringaren inte har diskvalificerats, anropa Check Availability. Läs upp 2 eller 3 lediga tider i en naturlig mening, inte som en lista. Vänta tills uppringaren muntligt bekräftar en av dem och anropa sedan Book Appointment med den tiden. Anropa aldrig Book Appointment före en muntlig bekräftelse.
Extraktionsfält efter samtal. Fyra fält som är värda att registrera i varje samtal: qualified som boolesk variabel, true om mötet bokades och false om uppringaren diskvalificerades eller tackade nej. repair_or_replacement som väljare, hämtad från det första svaret. urgency som väljare med alternativen den här veckan, den här månaden eller bara offert, hämtad från det andra svaret. Och summary_for_tech som text, en eller två meningar om problemet skrivna för den som åker ut.
Kör de här som simuleringar innan du kopplar agenten till ett riktigt nummer. Conductor ber dig först bekräfta omfattningen, eftersom simuleringskörningar debiteras.
Kan du köra ett simulerat testsamtal där uppringaren säger att hen hyr fastigheten och inte kan godkänna arbetet? Jag vill bekräfta att agenten avböjer att boka och avslutar samtalet i stället för att fortsätta mot bokning.
Samma sak men för en uppringare utanför vårt serviceområde. Kan du simulera det och bekräfta att samtalet avslutas utan bokning?
Om ett riktigt samtal bokar någon som borde ha avvisats hjälper de här två dig att hitta felet:
Jag testade ett samtal som hyresgäst som inte kan godkänna arbetet, men agenten fortsatte och försökte boka ändå. Varför diskvalificerar den inte det svaret?
Jag ringde från en plats utanför vårt serviceområde och den erbjöd ändå att boka. Varför aktiveras inte diskvalificeringsgrenen?
Ungefär femton minuter för bygget i den här guiden, från ett tomt konto till en publicerad agent med ett telefonnummer. Räkna med mer tid för testning. Själva flödet skapas utifrån en enda prompt, men det är testsamtalen som fångar datumhantering, tillgänglighetsfönster och saknade bokningsfält som tar den verkliga tiden.
Nej. Hela flödet byggs genom att du beskriver det med vanligt språk och godkänner det som copiloten föreslår. De enda manuella stegen är att klistra in en API-nyckel från Cal.com och kopiera ett event type ID från en URL.
En agent med en enda prompt läser ett block med instruktioner och improviserar. Ett konversationsflöde är en uttrycklig karta, nod för nod, med förgreningar som du kan granska och testa. Använd en enda prompt för ett linjärt manus och ett konversationsflöde när samtalet innebär ett beslut, vilket kvalificering alltid gör.
Ja. Cal.com används här eftersom dess boknings-API är enkelt att koppla. Samma mönster, en funktion för att kontrollera tillgänglighet följd av en funktion för att boka möten, gäller för andra kalenderintegrationer.
Det finns två vanliga orsaker. Agenten vet inte dagens datum, så den kontrollerar ett fönster som redan har passerat. Eller så kontrollerade den ett smalt fönster en gång och kontrollerade aldrig igen när uppringaren nämnde en annan dag. Prompt 4 och 5 i promptindexet åtgärdar respektive fall.
De hamnar i en diskvalificeringsnod som avslutar samtalet artigt utan att boka något. Den vägen måste byggas uttryckligen. Det räcker inte att beskriva regeln i din första prompt, och det är just det som prompt 7 och 8 finns till för att fånga upp.
See how much your business could save by switching to AI-powered voice agents.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Ett demonummer från Retell Clinic Office
Start building smarter conversations today.
