Dette kan du gjøre i Manager
AI Marketing Manager
Fra innsikt til gjennomført tiltak. Én plattform for AI-synlighet, søk og oppfølging.
Agent Commerce
En AI-agent kan hjelpe kunden å finne produkter, sammenligne alternativer og forberede et kjøp. For nettbutikken betyr det at produktet må kunne identifiseres riktig, vilkårene må være forståelige og pris og lager må stemme når kunden skal handle. Vi kartlegger hvor dette svikter, retter avtalte mangler og tester en avgrenset kjøpsreise i løsninger butikken faktisk støtter.
En kunde spør etter en vanntett tursko i størrelse 43 som kan leveres før fredag. Butikken har varen, men produktbeskrivelsen gjelder hele serien, lagerstatus vises bare for standardvarianten og leveringstid står på en annen side. Et produktforslag kan dermed se relevant ut uten at den konkrete varen oppfyller behovet.
Agent Commerce handler om sammenhengen mellom det kunden ber om, produktdataene agenten kan bruke og det nettbutikken kan levere. Et avvik mellom produktfeed, produktside og handlekurv kan gi feil pris, feil vare eller et avbrutt kjøp. Flere AI-genererte produkttekster løser ikke slike avvik.
Vi starter med én produktkategori og en konkret kjøpssituasjon. Da kan dere se hvilke problemer som må løses, hvem som må løse dem og om en videre integrasjon er verdt kostnaden.
Å bli nevnt i et AI-svar, få et besøk og motta en ordre er forskjellige hendelser. De krever ulikt arbeid og må måles hver for seg. Vi avklarer hvilket nivå nettbutikken skal arbeide med før vi velger teknologi.
Kunden beskriver et behov, og AI-tjenesten foreslår aktuelle varer. Arbeidet handler om presise produktegenskaper, tilgjengelige produktsider og relevante datakilder. En anbefaling viser at produktet ble foreslått i den observerte situasjonen. Den dokumenterer ikke et kjøp.
Kunden går videre fra AI-tjenesten og fullfører handelen hos dere. Lenken bør lande på riktig produkt og, der det støttes, riktig variant. Vi undersøker om behovet fra anbefalingen fortsatt kan oppfylles, og om trafikken kan knyttes til handlinger og ordre.
En støttet integrasjon kan la agenten utføre deler av handlekurv- eller checkout-flyten. Da må oppdaterte priser, lager, levering og ordrestatus være tilgjengelige i den valgte løsningen. Tilgang, kundens godkjenning og hvem som håndterer betalingen må avklares før en pilot.
Markedsføringsteksten kan si at en vare er «perfekt for tur». Kunden trenger å vite om den er vanntett, passer til bruken og finnes i riktig størrelse. Vi undersøker om slike egenskaper er eksplisitte, konsistente og knyttet til riktig produkt.
Produkt, variant og tilbud må kunne skilles fra hverandre. Vi kontrollerer koblingen mellom varenummer, merke, eventuelle GTIN/MPN, størrelse, farge og produktside. En variant som er utsolgt må ikke arve lagerstatus fra en annen. Manglende produsentidentifikatorer skal ikke erstattes med oppdiktede verdier.
Materiale, mål, kompatibilitet, kapasitet og begrensninger må være forståelige uten at kunden må gjette. For en reservedel kan kompatibilitet være avgjørende; for møbler er mål og leveringsbetingelser sentrale. Vi prioriterer egenskapene som faktisk påvirker valget i den aktuelle kategorien.
Vi kontrollerer at pris, valuta og tilgjengelighet stemmer mellom datakilden, feeden og produktsiden. Frakt, levering og retur må kunne avklares før kunden bestemmer seg. Ved checkout må totalsummen beregnes fra gjeldende betingelser, ikke fra en tidligere produktanbefaling.
Et korrekt utdrag i dag hjelper lite hvis morgendagens pris eller lagerendring ikke følger med. Vi beskriver hvilke systemer som eier opplysningene, hvordan de sendes videre og hvordan mislykkede oppdateringer oppdages. PIM, ERP, nettbutikk og feedverktøy kan ha ulike roller.
Teknologivalget følger kjøpsreisen. Vi avklarer hva den aktuelle tjenesten bruker og støtter, fremfor å behandle ett format som en universalløsning.
Produktsiden forklarer tilbudet for kunden. Product- og Offer-markup kan beskrive det samme maskinlesbart. Markup må samsvare med innholdet, og er verken en produktfeed eller en checkout-integrasjon. Vi undersøker synlig innhold, variantinformasjon og teknisk tilgjengelighet samlet.
En feed overfører katalogopplysninger etter mottakerens krav. OpenAI dokumenterer egne produktfeed-formater og en søknadsprosess for tilgang. En eksisterende Google-feed er et mulig utgangspunkt for datakartlegging, men skal ikke antas å være godkjent for en annen kanal uten kontroll av format og felt.
Agentic Commerce Protocol og Universal Commerce Protocol beskriver integrasjonsmåter for agentbasert handel. UCP omfatter blant annet oppdagelse av støttede funksjoner og checkout. En publisert protokoll betyr ikke at alle butikker eller AI-tjenester støtter den samme kjøpsreisen. Vi sjekker aktuell versjon, butikkstøtte og tilgang før vi anbefaler implementering.
Tursko-eksempelet er en illustrasjon av et mulig oppdrag, ikke et kundecase. Vi velger et produktutvalg med tydelige varianter og et behov kunden kan beskrive. Det gjør feilene synlige før katalogen eller integrasjonen utvides.
«Jeg trenger vanntette tursko i størrelse 43, innenfor budsjettet mitt, levert før fredag.» Vi definerer hvilke opplysninger som må bekreftes for at et produkt skal være et relevant alternativ, og hva som skal skje dersom ingen vare oppfyller kravene.
Er vanntetthet dokumentert? Gjelder lagerstatus størrelse 43? Åpner lenken riktig vare? Kan levering før fredag bekreftes for kundens adresse? Er totalsummen innenfor budsjettet når frakt er lagt til? Ukjent leveringstid skal ikke presenteres som et løfte.
Produktutvalget må ha konsistente data, og de avtalte kjøpssituasjonene må fungere uten uavklarte kritiske feil. Dersom en checkout-integrasjon inngår, må også avbrudd, endringer og gjentatte forespørsler håndteres. Dere får testresultatene og et begrunnet forslag til neste steg.
Arbeidet passer best når kundene har konkrete valg å ta, og produktdataene kan påvirke de valgene. En stor katalog er ikke i seg selv en grunn til å bygge en agentintegrasjon.
Varianter, tekniske spesifikasjoner, kompatibilitet og leveringskrav gir tydelige kjøpssituasjoner å undersøke. En kategori med mange avbrudd eller feilkjøp kan også være et godt utgangspunkt, dersom dere har data som kan belyse problemet.
Hvis pris, lager eller variantkobling allerede er upålitelig, bør rettelsene komme først. Den samme oppryddingen kan gjøre eksisterende produktsider og feeds mer nyttige. Direkte kjøp gjennom en agent vurderes når grunnlaget og plattformstøtten er på plass.
Nettbutikkansvarlig, produkteier og utvikler bør kunne avklare data, tilgang og ordreprosesser. Vi trenger ikke alle systemtilganger ved første samtale, men et pilotprosjekt må ha noen som kan godkjenne rettelser og følge opp feil etter lansering.
Dette får dere
Dere får en oversikt over undersøkte produkter, varianter og datakilder. Hvert funn beskriver avviket, hvilken kjøpssituasjon det rammer og hvor rettelsen må gjøres. Vi avklarer også plattformstøtte og tilgang før integrasjonsarbeid foreslås.
Vi beskriver hvilke opplysninger som skal komme fra hvilke systemer, og retter de avtalte manglene i et avgrenset utvalg. Det kan gjelde variantkobling, attributter, produktinnhold, strukturert data eller eksport. Utvikling og tilgang til tredjepart avklares i oppdraget.
Dere får et løsningsforslag for den valgte kanalen, med krav til dataformat, tilgang, butikkplattform og ordrehåndtering. Vi skiller mellom det som kan gjennomføres nå, det som krever utvikling og det som avhenger av plattformens godkjenning.
Vi dokumenterer hva som er testet, hvilken vare og variant som ble valgt, totalprisen som ble vist og hvor kunden endte. Der en kjøpsintegrasjon er tilgjengelig, testes også ordrestatus og feiltilfeller i et egnet testmiljø.
Dere får en plan for å koble observerbar AI-trafikk og eventuelle integrasjonshendelser til kjøp. Vi beskriver hvilke tall som faktisk er tilgjengelige, hvilke hendelser som må settes opp og hvor attribusjonen er usikker.
Etter kartleggingen eller piloten får dere en anbefaling om å skalere, rette flere avvik eller vente med integrasjon. Anbefalingen knyttes til observerte funn, gjennomføringskostnad og drift, slik at dere kan ta en beslutning uten å bygge om hele nettbutikken.
Avgrens én kjøpsreise. Vi avtaler produktkategori, marked, aktuelle kanaler og hvilket nivå av AI-assistert handel som skal undersøkes.
Dokumenter utgangspunktet. Vi sammenligner produktutvalget på tvers av datakilder, produktsider og eksisterende feeds og registrerer konkrete avvik.
Gjennomfør avtalte rettelser. Vi fordeler innhold, data og utviklingsoppgaver mellom dere, oss og eventuelle leverandører. Arbeid utenfor avtalt omfang avklares før det settes i gang.
Test den faktiske flyten. Vi følger behovet gjennom produktvalg og videre til nettbutikken eller en tilgjengelig testintegrasjon, inkludert avtalte feiltilfeller.
Vurder videre investering. Dere får resultater, gjenstående feil og en anbefaling om neste steg. Omfang og oppfølging avtales ut fra dette.
Vi skiller mellom datakvalitet, observerte produktanbefalinger, identifiserbare besøk og dokumenterte ordre. Datakvalitet måles på det avtalte produktutvalget; kjøpsflyten på testresultater og tilgjengelige hendelser. Trafikk og kjøp vurderes sammen med kostnad, retur og dekningsbidrag der dere har data. Attribusjon fra AI-tjenester kan være ufullstendig. Vi oppgir derfor hvilke observasjoner tallene bygger på, og tilskriver ikke alle endringer i salget til Agent Commerce.
FAQ
Agent Commerce er handel der en AI-agent hjelper kunden med produktvalg eller deler av kjøpsprosessen. Det kan være sammenligning og en lenke til nettbutikken, eller en støttet integrasjon for handlekurv og checkout. Hvor mye agenten kan gjøre, avhenger av den konkrete tjenesten, butikken og kundens godkjenning.
SEO og AI-synlighet arbeider blant annet med å bli funnet og valgt som kilde eller anbefaling. Agent Commerce omfatter også om det anbefalte produktet er riktig og kan kjøpes på de betingelsene kunden forventer. En synlig vare med feil lagerstatus eller variant kan gi trafikk uten en fungerende kjøpsreise.
Oppdraget kan omfatte en dokumentert kartlegging, en prioritert feil- og tiltaksliste, feltkart for produktdata, avtalte rettelser, integrasjonskrav, testprotokoll og måleplan. Omfanget avtales før arbeidet starter. En checkout-integrasjon, tilgang til en ekstern kanal eller omfattende utvikling inngår ikke automatisk.
Det må undersøkes for den aktuelle butikken, løsningen og markedet. Produktfeed-tilgang og kjøpsintegrasjon er forskjellige avklaringer. OpenAI beskriver en godkjenningsprosess for produktfeeds. Vi bekrefter aktuell støtte og tilgang før vi foreslår en pilot, og lover ikke aktivering på vegne av en plattform.
Den kan gi et nyttig utgangspunkt for produktdata, men en annen mottaker kan ha andre formatkrav, felter og regler for tilgang. Vi kartlegger gjenbrukbare data og hva som må tilpasses. Et godkjent oppsett i én kanal betyr ikke automatisk at dataene er godkjent eller komplette i en annen.
Nei. Strukturert data beskriver informasjon på siden, men synkroniserer ikke automatisk katalogen med andre tjenester og utfører ikke checkout. Produktside, markup, feed og butikkens egne data må stemme overens. Feil som ligger i lager- eller priskilden må rettes der.
Vi starter med plattformen dere har. Bedre produktinnhold, variantkoblinger og datakvalitet kan ofte vurderes uten plattformbytte. Muligheten for en bestemt integrasjon må undersøkes separat. En ombygging bør begrunnes i konkrete behov og kostnader, ikke i at Agent Commerce er nytt.
ACP og UCP beskriver protokoller for handel mellom butikker og agentbaserte løsninger. MCP er en måte å gjøre verktøy og data tilgjengelige for AI-systemer på, og kan brukes som en del av en handelsintegrasjon. En MCP-tilkobling alene gir ikke en komplett løsning for betaling, ordre og levering.
Start med informasjon som avgjør om kunden kan velge og kjøpe riktig vare: produktidentitet, variant, relevante egenskaper, pris, tilgjengelighet og betingelser. Hva som er viktigst varierer med kategorien. Kompatibilitet kan være avgjørende for reservedeler, mens mål og leveringsmuligheter ofte er sentrale for møbler.
Vi undersøker hvor opplysningene vedlikeholdes og hvordan endringer sendes videre til sider og feeds. I en kjøpsflyt må gjeldende pris og tilgjengelighet bekreftes på riktig tidspunkt. Piloten bør også prøve hva som skjer når en vare blir utsolgt eller prisen endres etter at kunden fikk en anbefaling.
Ansvarsfordelingen avklares for den valgte løsningen før integrasjonsarbeid starter. Vi beskriver hvilke systemer som oppretter ordren, bekrefter betaling og følger opp kunden, og hvem som håndterer feil, retur og refusjon. Det skal være tydelig hvordan den nye flyten henger sammen med butikkens etablerte prosesser.
Vi tester om riktig variant velges, om totalsum og levering stemmer, og om kunden får en forståelig vei videre. For en checkout-integrasjon omfatter avtalt testing også avbrudd, utløpt kjøpsøkt, avvist betaling og gjentatte forespørsler. Feil skal ikke gi uklare ordre eller utilsiktede dobbeltbestillinger.
Vi avtaler et utgangspunkt og hvilke observasjoner som er tilgjengelige. Relevante mål kan være færre dataavvik, flere kvalifiserte besøk, gjennomførte kjøp og færre feilkjøp. Kostnad og dekningsbidrag må vurderes sammen med omsetning. En teknisk vellykket pilot er ikke i seg selv bevis for økt salg.
Velg ett avgrenset produktutvalg, ett marked og en tydelig kjøpssituasjon. Omfanget må gi plass til relevante varianter og feiltilfeller, men være lite nok til at funn kan rettes og kontrolleres. Vi avtaler utvalget etter at datakilder og ønsket kjøpsreise er avklart.
Butikkplattform, aktuell produktkategori, eksempelprodukter, oversikt over datakilder og en person som kjenner produkt- og ordreprosessene. Eksisterende feed og relevante analysedata er nyttige når de finnes. Tilgang til produksjonssystemer og håndtering av kundedata avklares først når det er nødvendig for det avtalte arbeidet.
Det avhenger av datakvalitet, antall systemer, produktutvalg og om oppdraget inkluderer utvikling. Vi skiller kostnaden for kartlegging og rettelser fra integrasjon og løpende drift. Dere skal få et avgrenset omfang og avklarte leveranser før prosjektet starter, fremfor en pris basert på et uklart løfte om å bli «AI-klar».
Produktidentitet, varianter, egenskaper og sammenhengen mellom pris og lager.
Formater, datakilder, overføring og vedlikehold av katalogdata for ulike mottakere.
UCP, støttede handelsfunksjoner og hva som må avklares før en integrasjon.
Agent Commerce
Oppgi butikkplattform, en aktuell produktkategori og hvor dere ser problemer i dag. Første avklaring er hvilken kjøpsreise som er verdt å undersøke, hvilke data som finnes og hva et avgrenset oppdrag skal levere.
Var dette nyttig?
