Odoo 19 introduserte et AI-lag som går lenger enn tekstgenerering. Det kan hjelpe brukere med å finne informasjon, tolke poster, åpne visninger, klassifisere dokumenter, støtte helpdesk-arbeid, svare besøkende på nettstedet og velge kontrollerte handlinger. Odoo 19.4 viderefører denne retningen med automatisk modellvalg, stemmeinteraksjon, lagrede samtaler, rikere rekordkort i live chat og MCP-tilkobling.

Det nyttige spørsmålet er ikke om Odoo har AI. Det er hvilken agent som får bruke hvilken informasjon og hvilke verktøy i en bestemt situasjon. Odoo skiller disse hensynene gjennom agenter, ferdigheter, kilder og serverhandlinger.

Start med standardassistenten Ask AI

Standardassistenten Ask AI er tilgjengelig fra kommandopaletten og AI-knappen gjennom hele Odoo-grensesnittet. Ifølge den offisielle Odoo AI-dokumentasjonen kan den svare på spørsmål på naturlig språk, åpne visninger, forbedre innhold, oppsummere chatter og foreslå neste steg basert på konteksten.

Standardassistenten Ask AI kan ikke endre databaseposter. Den kan hjelpe en bruker med å forstå og navigere i informasjon, men Odoo skiller bevisst denne hjelpen fra verktøy som utfører skrivinger. Dette er en viktig standard, fordi et flytende svar ikke stille skal bli til en regnskaps-, salgs- eller drifts­transaksjon.

Tilpassede agenter definerer en bestemt jobb

En tilpasset Odoo AI-agent har en systemprompt, svarstil, én eller flere ferdigheter og valgfrie kilder. Den offisielle dokumentasjonen for AI-agenter beskriver en agent som en naturlig språkhjelper med et definert formål og tilgang til Odoo-verktøy.

I den tidligere Odoo 19-dokumentasjonen kalles samlinger av instruksjoner og verktøy topics. Odoo 19.4 gir dem navnet ferdigheter. Formålet er det samme: hver ferdighet forklarer konteksten, reglene og arbeidsflyten for en oppgave, mens verktøyene er de faktiske funksjonene agenten kan kalle.

Denne strukturen støtter agenter som er laget for ulike situasjoner i stedet for én assistent med bred og tvetydig myndighet. Eksempler inkluderer:

  • En salgsassistent som finner muligheter, forklarer pipelinedata og utarbeider oppfølgingsmeldinger.
  • En supportagent som svarer fra godkjente Knowledge-artikler og eskalerer usikre saker.
  • En dokumentagent som klassifiserer en opplasting og velger en godkjent mappe eller etikett.
  • En feltserviceassistent som oppsummerer oppgavehistorikk og forbereder en kundeoppdatering.
  • En live chat-agent som svarer på vanlige spørsmål og oppretter et CRM-lead etter å ha samlet inn nødvendige detaljer.

Kilder avgjør hva en agent kan referere til

Odoo-agenter kan bruke PDF-er, weblenker, Documents-filer og Knowledge-artikler som indekserte kilder. Alternativet Begrens til kilder begrenser agenten til aktive opplastede kilder. Dette er nyttig for kundevendte svar, fordi organisasjonen kan definere materialet agenten forventes å bruke, i stedet for å tillate brede, udokumenterte svar.

Kildebegrensning forbedrer kontrollen, men kvaliteten på kildene betyr fortsatt noe. Dokumenter bør ha eiere, gjennomgangsdatoer og en prosess for å fjerne utdaterte priser, retningslinjer eller instrukser. Motstridende kilder kan skape inkonsekvente svar selv når hvert dokument teknisk sett er godkjent.

Slik fungerer Odoo AI Live Chat

Odoo kan tilordne en AI-agent til en regel for live chat-kanal. Den offisielle dokumentasjonen for AI Live Chat sier at en agent kan svare på vanlige spørsmål, be om mer informasjon, kvalifisere samtaler og eskalere til en menneskelig operatør.

Det leverte live chat-mønsteret oppretter ikke bare et lead etter første melding. Instruksjonene definerer når eskalering er passende, samler inn manglende kontaktinformasjon, bekrefter kjente detaljer og kaller opprettingsverktøyet for lead én gang. Dette viser hvorfor arbeidsflytinstruksjoner er like viktige som språkmodellen.

Odoo 19.4 kan også vise rike, klikkbare kort når en agent nevner støttede Odoo-poster i live chat. Dette kan gjøre et produkt, en avtale eller en annen støttet post enklere for besøkende å forstå og åpne.

En selskaps spesifikk chatbot er et designmønster, ikke en enkelt avkrysningsboks

En flerbedriftsorganisasjon kan ønske at hver bedrifts nettside har en chatbot som bare svarer om den bedriften. Odoo har byggeklossene for dette designet, men grensen må konfigureres eksplisitt.

Et praktisk mønster er:

  • Bruk et eget nettsted og en egen Live Chat-kanal eller kanalregel for hver kundevendt bedriftsopplevelse.
  • Opprett en egen AI-agent for hver bedrift, i stedet for én agent med en prompt som prøver å utlede hvilken bedrift det gjelder.
  • Gi hver agent bare den bedriftens godkjente Knowledge-artikler, dokumenter, retningslinjer og weblenker.
  • Aktiver Begrens til kilder, slik at svarene holder seg innenfor det bedrifts spesifikke kildesettet.
  • Tildel bare ferdighetene og verktøyene som trengs for den kanalen, som informasjonsgjenfinning eller kontrollert lead-oppretting.
  • Sørg for at et lead, en sak eller en avtale som opprettes, får den tiltenkte bedriftskonteksten og ansvarlige teamet.
  • Test spørsmål på tvers av selskaper, tvetydige merkenavn og forsøk på å hente informasjon om et annet selskap.

Odoo-flerbedriftsposter kan deles eller være selskapsspesifikke. Den flerbedriftsdokumentasjonen forklarer at tilbud, fakturaer og leverandørregninger knyttet til et selskap er begrenset til den relevante bedriftskonteksten, mens enkelte poster som kontakter og produkter kan deles som standard.

Den datamodellen betyr ikke at alle AI-kilder automatisk er isolert. Ikke behandl en systemprompt som «bare diskuter selskap A» som en konfidensialitetskontroll. Separate kildesamlinger, kanaltilordninger, tilgangsrettigheter og kontroller på verktøysiden gir en sterkere grense. Hvis streng juridisk isolasjon kreves, kan separate databaser være mer passende enn en delt flerbedriftskonfigurasjon.

Agenter kan bare utføre oppgaver gjennom tildelte verktøy

Hvis en agent ikke har noen ferdigheter, sier Odoo at den kan gi informasjon, men ikke fullføre oppgaver eller endre databasen. Et verktøy utvider agenten utover samtale. Forhåndskonfigurerte eksempler inkluderer å åpne en visning og opprette et lead, mens installerte apper kan gjøre andre verktøy tilgjengelige.

For automatiserte arbeidsflyter for poster bruker Odoo AI-serverhandlinger. Den dokumentasjonen for AI-serverhandlinger skiller AI-administratoren fra arbeidsverktøyet. AI leser posten og prompten, velger et verktøy og sender oppgitte argumenter. Den vanlige serverhandlingen utfører deretter den reelle forretningslogikken.

Dette gjør at AI kan ta en kontekstuell beslutning, mens deterministisk kode håndhever reglene. For eksempel kan AI klassifisere et leverandørdokument, men det valgte verktøyet bør validere destinasjonen, selskapet, tillatt poststatus og obligatoriske felt før noe skrives.

Nyttige mønstre for oppgaveautomatisering

  • Klassifiser innkommende dokumenter og bruk en godkjent etikett eller mappe.
  • Oppsummer en helpdesk-sak og fyll ut et strukturert triagefelt.
  • Velg en oppfølgingssti basert på en post, mens sending eller godkjenning overlates til en bruker.
  • Opprett en CRM-lead fra live chat når nødvendige kontaktopplysninger er bekreftet.
  • Utkast til en e-post fra gjeldende postkontekst for menneskelig gjennomgang.
  • Trekk ut strukturerte detaljer fra et dokument inn i en kontrollert arbeidsflyt.

Det svakeste mønsteret er å gi én bred agent en samling av kraftige skriveverktøy. Smale agenter er enklere å teste, forklare og revidere.

Hva Odoo 19.4 legger til

De offisielle Odoo 19.4 utgivelsesnotatene legger til flere funksjoner rundt denne agentmodellen:

  • Automatisk valg av den mest passende konfigurerte AI-modellen for en oppgave.
  • Stemmeinteraksjon for å diktere forespørsler til en agent.
  • Lagring av agentsamtaler i opptil 30 dager etter siste melding.
  • MCP-tilkobling for kompatible eksterne verktøy.
  • Rike forhåndsvisningskort for støttede poster nevnt i live chat.
  • Omdøpingen av emner til ferdigheter.

MCP utvider integrasjonsmulighetene, men den utvider også sikkerhetsgjennomgangen. Legitimasjon, eksponerte verktøy, brukerrettigheter, logging og datagrenser bør dokumenteres før en ekstern AI-klient kobles til.

Vurderinger rundt leverandør og prising

Odoo støtter leverandørene OpenAI og Google Gemini. Odoo Online-brukere trenger ikke å legge inn egen API-nøkkel for standardtjenesten, selv om de kan gjøre det for mer kontroll. Odoo.sh og databaser lokalt installert hos kunden trenger leverandørnøkler for AI-funksjoner. Dokumentasjonen for Odoo AI API-nøkkel opplyser at leverandørkostnader kan påløpe når kundeeide nøkler brukes.

En trygg utrullingssjekkliste

  • Velg ett smalt bruksområde med en målbar manuell prosess.
  • Definer godkjente kilder, forbudte temaer og veien for eskalering til menneske.
  • Tildel de minimumsverktøyene som trengs, og håndhev regler inne i hvert verktøy.
  • Test firma-, bruker- og tilgang til poster med vanlige kontoer, ikke bare administratorer.
  • Test feilaktige, ufullstendige, motstridende og på tvers av selskaper spørsmål.
  • Krev gjennomgang for finansielle, kontraktsmessige, destruktive eller eksternt sendte handlinger.
  • Overvåk svar, verktøyanrop, leverandørbruk og hvor ferske kildene er etter lansering.

Den praktiske konklusjonen

Odoo AI er mest nyttig som en samling fokuserte assistenter inne i eksisterende forretningsarbeidsflyter. Live chat, selskapskunnskap, lead-opprettelse, dokumentklassifisering og automatisering basert på poster er troverdige bruksområder fordi Odoo kan kombinere beslutninger i naturlig språk med strukturerte poster og kontrollerte verktøy.

Designet bør aldri basere seg på tillit eller bare en prompt. Skill agenter etter formål, begrens kildene deres, minimer verktøyene deres og hold forretningsregler i deterministiske Odoo-handlinger. Det er dette som gjør en chatbot-demonstrasjon om til en operativ kapasitet som kan støttes.