Koble en telefonassistent til et bookingsystem
Planlegg bookinger, opptatte tider, tapte svar og endringer med et gjennomarbeidet integrasjonseksempel.
En telefonassistent skal først bekrefte en avtale når det autoritative bookingsystemet har bekreftet riktig registrering. Det krever avgrensede integrasjonsfunksjoner og svar som viser den faktiske tilstanden. En liste over ledige tider er ikke en booking.
Behold bookingreglene i det autoritative systemet
I det fiktive eksemplet tilbyr en programvarebedrift eksisterende kunder prosjektsamtaler på 30 minutter for ressursen consultation-a. Den som ringer, velger 19. november 2026 fra 14:00 til 14:30 i Europe/Berlin. Assistenten gjentar dato, tid og varighet og venter på et eksplisitt valg.
Bookingtjenesten kontrollerer tillatte avtaletyper, rettigheter og overlapp ved skriving. Også nettstedet og medarbeiderne må bruke samme tildelingsregel. Senere kalendersynkronisering hindrer ikke to bookingkanaler i å tildele samme tid samtidig.
Definer fire avgrensede funksjoner
Eksempelfunksjon | Oppgave | Nødvendig svar |
|---|---|---|
| Finne egnede ledige tider | Intervaller med dato og tidssone |
| Booke det eksplisitt valgte intervallet | Bekreftet booking eller konkret avslagsgrunn |
| Avklare utfallet av en forespørsel via identifikatoren | Eksisterende booking, mislykket forespørsel eller fortsatt uklar tilstand |
| Flytte en eksisterende booking til ønsket tid | Bekreftet endring eller uendret opprinnelig avtale |
ElevenLabs beskriver slike eksterne funksjoner som webhookverktøy. Navn og regler her er vår egen utforming. Serveren kontrollerer selv parametre og rettigheter; et modellkall gir ingen tilgangsrettigheter. Tilgangsnøkler hører ikke hjemme i samtaleteksten. Å oppgi en bookingidentifikator beviser ikke i seg selv retten til å endre bookingen.
Fyll ut forespørsel og svar
Serveren tildeler den stabile forespørselsidentifikatoren R-94 til dette bookingønsket. Når koblingen mellom den som ringer, og riktig konto er avklart, mottar bookingfunksjonen disse forretningsdataene:
{"requestId":"R-94","resourceId":"consultation-a","start":"2026-11-19T14:00:00+01:00","timeZone":"Europe/Berlin","durationMinutes":30}Dette er ikke et direkte Google Calendar-kall. Googles Freebusy-spørring returnerer opptatte intervaller; den valgte bookingveien må sikre eksklusiv tildeling separat. I eksemplet er kontroll og reservasjon beskyttet mot samtidige bookinger. Først denne forretningsmessige bekreftelsen tillater et bookingløfte:
{"requestId":"R-94","status":"confirmed","bookingId":"B-94"}Assistenten kan nå bekrefte det avtalte tidspunktet. En opprettet kalenderpost beviser ikke i seg selv at en invitasjon er lest.
Kontroller fire tilfeller frem til lagret resultat
Tilfelle | Forventet systematferd | Beskjed i samtalen |
|---|---|---|
Den valgte tiden er ledig ved skriving | Én booking | Bekreft den avtalte tiden |
Tiden er blitt tildelt i mellomtiden | Ingen ny booking for samme ressurs og tid | Tilby nye ledige tider |
Svaret på bookingen går tapt | Avklar først det eksisterende utfallet med | Bekreftelsen avventes fortsatt |
Ønsket flytting til |
| Endringen avslått; oppgi den opprinnelige avtalen |
Samme forespørselsidentifikator og samme data innenfor samme rettighetsområde skal ved gjentakelse gi det eksisterende utfallet. Et endret ønske får en ny identifikator. Er utfallet fortsatt uklart, tvinges ingen ny booking frem med en ny identifikator; saken følger den etablerte avklaringsveien.
En flytting må ikke fjerne den gamle avtalen for tidlig. Støtter ikke integrasjonen et sikret bytte, trengs en egen arbeidsflyt fremfor et automatisk løfte. Gjennomarbeidede testtilfeller viser før oppstart om samtale og booking faktisk samsvarer.
Kilder
Les videre
Alle artikler
KI og automatisering med ASES
KI-assistenter og automatiserte prosesser