Forbind en telefonassistent med et aftalesystem
Planlæg bookinger, optagne tider, manglende svar og ændringer med et gennemarbejdet integrationseksempel.
En telefonassistent må først bekræfte en aftale, når det autoritative bookingsystem har bekræftet den rigtige registrering. Det kræver afgrænsede integrationsfunktioner og svar, der viser den faktiske tilstand. En liste over ledige tider er ikke en booking.
Bevar bookingreglerne i det autoritative system
I det fiktive eksempel tilbyder en softwarevirksomhed sine eksisterende kunder projektsamtaler på 30 minutter for ressourcen consultation-a. Den, der ringer, vælger den 19. november 2026 fra 14:00 til 14:30 i Europe/Berlin. Assistenten gentager dato, tid og varighed og venter på det udtrykkelige valg.
Bookingtjenesten kontrollerer tilladte aftaletyper, rettigheder og overlap ved skrivning. Også hjemmeside og medarbejdere skal bruge samme tildelingsregel. Senere kalendersynkronisering forhindrer ikke to bookingkanaler i samtidig at tildele den samme tid.
Definér fire afgrænsede funktioner
Eksempelfunktion | Opgave | Nødvendigt svar |
|---|---|---|
| Find egnede ledige tider | Intervaller med dato og tidszone |
| Book det udtrykkeligt valgte interval | Bekræftet booking eller konkret afvisningsgrund |
| Afklar en anmodnings udfald via dens identifikator | Eksisterende booking, mislykket anmodning eller fortsat uklar tilstand |
| Flyt en eksisterende booking til en valgt tid | Bekræftet ændring eller uændret oprindelig aftale |
ElevenLabs beskriver sådanne eksterne funktioner som webhookværktøjer. Navne og regler her er vores eget design. Serveren kontrollerer selv parametre og rettigheder; et modelkald giver ingen adgangsrettigheder. Adgangsnøgler hører ikke hjemme i samtaleteksten. At oplyse en bookingidentifikator er ikke i sig selv bevis for retten til at ændre bookingen.
Udfyld anmodning og svar
Serveren tildeler den stabile anmodningsidentifikator R-94 til dette bookingønske. Når koblingen mellem den, der ringer, og den rigtige konto er afklaret, modtager bookingfunktionen disse forretningsdata:
{"requestId":"R-94","resourceId":"consultation-a","start":"2026-11-19T14:00:00+01:00","timeZone":"Europe/Berlin","durationMinutes":30}Det er ikke et direkte Google Calendar-kald. Googles Freebusy-forespørgsel returnerer optagne intervaller; den valgte bookingvej skal særskilt sikre eksklusiv tildeling. I eksemplet er kontrol og reservation beskyttet mod samtidige bookinger. Først denne forretningsmæssige bekræftelse tillader et bookingløfte:
{"requestId":"R-94","status":"confirmed","bookingId":"B-94"}Assistenten kan nu bekræfte det aftalte tidspunkt. En oprettet kalenderpost beviser ikke i sig selv, at en invitation er læst.
Kontrollér fire tilfælde frem til det gemte resultat
Tilfælde | Forventet systemadfærd | Besked i samtalen |
|---|---|---|
Den valgte tid er ledig ved skrivning | Én booking | Bekræft den aftalte tid |
Tiden er blevet tildelt i mellemtiden | Ingen yderligere booking for samme ressource og tid | Tilbyd nye ledige tider |
Svaret på bookingen går tabt | Afklar først det eksisterende udfald med | Bekræftelsen afventes stadig |
Den ønskede flytning til |
| Ændringen afvist; oplys den oprindelige aftale |
Gentagelse med samme anmodningsidentifikator og samme data inden for samme rettighedsområde skal give det eksisterende udfald. Et ændret ønske får en ny identifikator. Er udfaldet fortsat uklart, gennemtvinges ingen ny booking med en ny identifikator; sagen følger den etablerede afklaringsvej.
En flytning må ikke fjerne den gamle aftale for tidligt. Understøtter integrationen ikke et sikret skift, kræves et særskilt forløb frem for et automatisk løfte. Gennemarbejdede testtilfælde viser før ibrugtagning, om samtale og booking faktisk stemmer overens.
Kilder
Læs videre
Alle artikler
AI & automatisering med ASES
AI-assistenter og automatiserede arbejdsgange