Anslut en telefonassistent till ett bokningssystem
Planera bokningar, upptagna tider, förlorade svar och ändringar med ett genomarbetat integrationsexempel.
En telefonassistent får bekräfta en tid först när det ansvariga bokningssystemet har bekräftat rätt post. Det kräver avgränsade integrationsfunktioner och svar som visar det verkliga tillståndet. En lista med lediga tider är ingen bokning.
Behåll bokningsreglerna i det ansvariga systemet
I det fiktiva exemplet erbjuder ett programvaruföretag befintliga kunder projektsamtal på 30 minuter för resursen consultation-a. Den som ringer väljer den 19 november 2026 från 14:00 till 14:30 i Europe/Berlin. Assistenten upprepar datum, tid och längd och väntar på ett uttryckligt val.
Bokningstjänsten kontrollerar tillåtna mötestyper, behörigheter och överlappningar vid skrivningen. Även webbplatsen och medarbetarna måste använda samma tilldelningsregel. Senare kalendersynkronisering hindrar inte två bokningskanaler från att samtidigt tilldela samma tid.
Definiera fyra avgränsade funktioner
Exempelfunktion | Uppgift | Svar som behövs |
|---|---|---|
| Hitta lämpliga lediga tider | Intervall med datum och tidszon |
| Boka det uttryckligen valda intervallet | Bekräftad bokning eller konkret avvisningsorsak |
| Klargöra en begärans resultat via dess identifierare | Befintlig bokning, misslyckad begäran eller fortsatt oklart tillstånd |
| Flytta en befintlig bokning till vald tid | Bekräftad ändring eller oförändrad ursprunglig tid |
ElevenLabs beskriver sådana externa funktioner som webhookverktyg. Namn och regler här är vår egen utformning. Servern kontrollerar själv parametrar och behörigheter; ett modellanrop ger inga åtkomsträttigheter. Åtkomstnycklar hör inte hemma i samtalstexten. Att uppge en bokningsidentifierare bevisar inte i sig rätten att ändra bokningen.
Exempel på begäran och svar
Servern tilldelar den stabila identifieraren R-94 till denna bokningsbegäran. När kopplingen mellan den som ringer och rätt konto är klarlagd får bokningsfunktionen dessa verksamhetsdata:
{"requestId":"R-94","resourceId":"consultation-a","start":"2026-11-19T14:00:00+01:00","timeZone":"Europe/Berlin","durationMinutes":30}Detta är inget direkt Google Calendar-anrop. Googles Freebusy-fråga returnerar upptagna intervall; den valda bokningsvägen måste separat säkerställa exklusiv tilldelning. I exemplet skyddas kontroll och reservation mot samtidiga bokningar. Först denna verksamhetsmässiga bekräftelse tillåter ett bokningslöfte:
{"requestId":"R-94","status":"confirmed","bookingId":"B-94"}Assistenten kan nu bekräfta den överenskomna tiden. En skapad kalenderpost bevisar inte i sig att en inbjudan har lästs.
Kontrollera fyra fall fram till det sparade resultatet
Fall | Förväntat systembeteende | Besked under samtalet |
|---|---|---|
Den valda tiden är ledig vid skrivningen | En bokning | Bekräfta den överenskomna tiden |
Tiden har tilldelats under tiden | Ingen ytterligare bokning för samma resurs och tid | Erbjud nya lediga tider |
Bokningssvaret går förlorat | Klargör först det befintliga resultatet med | Bekräftelsen har ännu inte kommit |
Önskad flytt till |
| Ändringen avvisad; ange den ursprungliga tiden |
Samma identifierare och samma data inom samma behörighetsområde ska vid upprepning ge det befintliga resultatet. Ett ändrat önskemål får en ny identifierare. Om resultatet förblir oklart tvingas ingen andra bokning fram med en ny identifierare; ärendet följer den etablerade vägen för utredning.
En flytt får inte ta bort den gamla tiden i förtid. Om integrationen inte stöder ett säkrat byte krävs ett separat flöde i stället för ett automatiskt löfte. Genomarbetade testfall visar före driftsättning om samtal och bokning faktiskt stämmer överens.
Källor
Läs vidare
Alla artiklar
AI & automatisering med ASES
AI-assistenter och automatiserade flöden