AI i PMS og eventsystemer: hva betyr det egentlig?

Alle leverandører sier de har AI nå. Det gjør spørsmålet mindre interessant enn det pleide å være — det egentlige spørsmålet er om det er en ekte agent med verktøytilgang, eller et forslag med et fancy navn.

AI i PMS og eventsystemer: hva betyr det egentlig?

AI i PMS og eventsystemer: hva betyr det egentlig?

Vi skrev i markedsgjennomgangen vår at AI ikke lenger er en forskjell — det er en forventning. Alle leverandører sier de har det nå. Det gjør spørsmålet «har dere AI» ganske verdiløst å stille i en demo, fordi svaret alltid er ja. Det interessante spørsmålet, som de fleste av oss ikke helt vet hvordan vi skal stille ennå, er: hva slags AI, og hva forandrer det faktisk i en vanlig driftsuke?

Dette innlegget er et forsøk på å svare konkret på det, uten verken å overselge eller avfeie det. Begge deler er fristende, og begge deler er upresise.

To helt ulike ting kalles «AI» akkurat nå

Det aller meste av forvirringen kommer av at bransjen bruker ett ord om to ganske forskjellige ting.

Den første typen er det vi kan kalle forslags-AI. Den leser noe (en e-post, en forespørsel, en historikk) og foreslår noe tilbake — et utkast til tilbud, en anbefalt pris, et svar på et spørsmål. Et menneske ser forslaget og bestemmer om det skal brukes. Dette er nyttig, og det er der mesteparten av det som selges som «AI-funksjoner» i dag faktisk befinner seg.

Den andre typen er AI-agenter. Forskjellen er ikke at de er «smartere» — det er at de har tilgang til å gjøre noe, ikke bare foreslå det. En agent kan hente belegg fra systemet, sjekke en romblokk, opprette et utkast til kontrakt, eller sende en oppfølging, fordi den har verktøytilgang inn i de faktiske systemene, ikke bare inn i en samtaleboks. Det er denne andre typen som faktisk endrer noe strukturelt, og det er også den som stiller helt andre krav til systemet den kobles til.

Vi skrev i forrige innlegg om API-tilgang at en AI-agent bare er så nyttig som verktøyene den får lov til å bruke, og at Model Context Protocol (MCP) er den åpne standarden som lar en agent kalle systemene deres som strukturerte, autentiserte verktøy. Det er verdt å gjenta kort her, fordi det er selve limet mellom de to typene AI: uten et ordentlig API og en måte å eksponere det på for en agent, er «AI-agent» bare et forslag med et fancy navn — den kan aldri komme forbi steget der et menneske må taste inn resultatet manuelt uansett.

Hvorfor agenter faktisk er en game changer!

Det er lett å bli skeptisk til begrepet «game changer», siden det brukes om alt fra ekte gjennombrudd til helt marginale justeringer. Så la oss være konkrete om hvorfor dette faktisk er annerledes denne gangen, spesifikt for PMS- og eventdrift.

Det aller meste av tiden som går tapt i denne bransjen, går ikke tapt fordi noen tar en dårlig beslutning. Den går tapt i overgangene — mellom en e-post og et system, mellom et regneark og en telefonsamtale, mellom det salg vet og det resepsjonen vet. En forslags-AI hjelper deg med selve oppgaven, men noen må fortsatt bære informasjonen mellom systemene. En agent med ordentlig verktøytilgang kan faktisk lukke gapet: den leser en e-post, oppretter en lead direkte i systemet, sjekker tilgjengelighet, og legger et strukturert utkast klart — uten at et menneske var limet mellom de fire trinnene. Mennesket kommer inn for å godkjenne, ikke for å utføre alle mellomstegene selv.

Det er denne forskyvningen — fra «AI som hjelper deg gjøre oppgaven» til «AI som gjør oppgaven, og du godkjenner resultatet» — som er den reelle endringen. Det er ikke at agenten er mer imponerende i en demo. Det er at den fjerner et helt lag med koordineringsarbeid som tidligere krevde et menneske i hvert eneste steg.

Hvordan skille ekte agent-funksjonalitet fra AI pyntet på toppen

Gitt at alle sier de har AI, er det verdt å ha noen konkrete spørsmål klare når dere evaluerer en leverandør, i stedet for å stole på hvor overbevisende demoen var:

Kan AI-funksjonen faktisk utføre en handling i systemet — opprette, endre, sende — eller foreslår den bare noe dere fortsatt må taste inn selv et annet sted? Hvis svaret er det siste, er det en forslags-funksjon, ikke en agent, og det er greit, men det er ikke det samme løftet.

Hvilket API ligger under? Be om å se det, ikke bare bli fortalt at det finnes. Vi har skrevet mer utfyllende om dette tidligere, men kort sagt: uten en dokumentert, versjonert API-spesifikasjon er det vanskelig å tro på at en agent faktisk har den tilgangen leverandøren sier.

Hva skjer når agenten tar feil? Dette er kanskje det viktigste spørsmålet av alle. Enhver leverandør kan vise deg agenten når den fungerer perfekt i en demo. Spør heller: hvordan ser det ut når den misforstår en forespørsel, og hvor i prosessen fanges feilen opp — før noe sendes til en gjest, eller etterpå?

Er det menneske i løkken der det faktisk betyr noe? Ikke bare som en generell forsikring i en salgspresentasjon, men konkret: hvilke handlinger krever godkjenning, og hvilke skjer automatisk? Det er en reell forskjell mellom «foreslår en pris, dere godkjenner» og «sender bekreftelse til gjest automatisk», og dere bør vite nøyaktig hvor den grensen går for hver funksjon dere vurderer å skru på.

Det som avgjør om dere faktisk får noe ut av det — internt, ikke hos leverandøren

Her er noe som lett drukner i AI-samtalen, men som vi mener er like viktig som selve teknologien: en agent er bare så god som dataene og prosessene den får jobbe med. Vi har skrevet om nøyaktig dette i innlegget om implementering — ryddige data, tydelige rutiner og en organisasjon som faktisk vet hvordan ting skal gjøres, er en forutsetning for at automatisering skal fungere, ikke noe som kommer på plass av seg selv fordi systemet er smart.

Konkret betyr det: hvis prisstrukturen deres i dag lever i hodet på én erfaren selger og aldri har vært skrevet ned konsekvent, kan ikke en revenue-agent gjette seg til den logikken bedre enn dere selv har klart å formulere den. Hvis romkodene deres ikke stemmer med den fysiske bygningen etter en ombygging for tre år siden, arver agenten akkurat den samme forvirringen som resten av systemet har levd med siden da. AI løser ikke rot. Den gjør rotet raskere.

Det er også verdt å tenke gjennom, internt, hvor mye tillit dere faktisk er komfortable med å gi fra dere først. De fleste vi snakker med vil starte med lavrisiko-oppgaver — la en agent lage utkast til tilbud, men ikke sende dem, i noen måneder — før de gradvis lar den ta over flere av mellomstegene selv. Det er en fornuftig rekkefølge, og det er heller ingen skam i å gå sakte frem her, selv om en selger prøver å fortelle dere at konkurrentene deres allerede har skrudd på alt.

Så, for å oppsumere

Alle vil si de har AI. Det gjør spørsmålet mindre interessant enn det pleide å være, og flytter samtalen dit den faktisk bør være: er dette en agent med reell verktøytilgang, eller et forslag med et fancy navn? Hva skjer når den tar feil? Og — kanskje det viktigste dere selv kan gjøre noe med akkurat nå, uavhengig av hvilken leverandør dere ender opp med — er dataene og rutinene deres egentlig klare til at noe skal automatiseres på toppen av dem?

Relaterte innlegg

Klar for å se Veisla i praksis?

Book en demo, så viser vi hvordan plattformen passer akkurat din drift.