Agentic commerce börjar i er produktdata och behörighet

En återförsäljare hör av sig och frågar om er kundportal kan ta emot en beställning som en AI-tjänst har förberett. Kunden har redan klistrat in ett artikelnummer i en chatt och vill ha rätt avtalspris, rätt lagerstatus och en order som landar i affärssystemet.

Ni har produktwebb, kundportal och affärssystem. Det som avgör är vilken data en agent får läsa, och vilket anrop den får göra när någon ska betala.

Agentic commerce börjar i behörighet och datakällor. Själva chatten kommer senare.

Vad agentic commerce är i praktiken

Agentic commerce är köp där en programvaruagent tolkar ett behov, söker och jämför alternativ och kan genomföra delar av köpet. Uppdraget och reglerna sätter kunden eller ert företag.

En chatbot svarar på en fråga. En agent utför en uppgift. Den kan hitta en reservdel till en viss maskin, kontrollera att delen passar och förbereda beställningen till kundens avtalspris.

Tänk på en inköpsansvarig som ger en assistent en kravlista, en budget och en beloppsgräns. Assistenten gör arbetet. Inget köp sker utanför de ramarna.

Branschen saknar en gemensam definition. Olika aktörer använder begreppet både om en rekommendation och om en hel betalning. Agenten kan använda tillåtna uppgifter som tidigare sökningar, köphistorik och kontodata, och fatta beslut inom de ramar som har angetts.

Tre nivåer räcker när ni ska fatta beslut. På den första nivån föreslår agenten en produkt. På den andra förbereder agenten ett köp som en människa godkänner. På den tredje genomför agenten köpet själv, inom belopp, sortiment och behörighet som ni har satt.

Resten av texten går igenom vilka delar av verksamheten som berörs. Ni ser också vilka beslut som behöver vara fattade innan något byggs.

Så ändras kundresan när en agent handlar

Huvudflödet har fem steg. Kunden gör något idag. Agenten gör något annat. Företaget måste kunna visa en bestämd sorts data, annars gissar agenten.

Agenten läser det som finns i era data. En snygg produktsida hjälper en människa. Den räcker sällan när en agent ska välja artikel.

Säg att en underhållsansvarig skriver en fri fråga om en pump i fabrik två. Agenten måste träffa rätt artikel via attribut, kompatibilitet och dokument. Saknas flöde, anslutning eller vilken modell pumpen sitter i, blir träffen en gissning.

Jämförelsen kräver samma sak i maskinläsbar form. Specifikationer som bara ligger i en pdf som ingen har strukturerat går inte att ställa mot kundens krav på ett tillförlitligt sätt.

Priset är ett eget steg. Kunden loggar in och ser sitt avtal. Agenten måste hämta priset för just det kundsegmentet, via ett stabilt API. En prislista som gäller alla ger fel offert till en avtalskund.

Vid köpet fyller kunden i kassan och godkänner. Agenten får lägga ordern inom givna ramar, och bara efter ett autentiserat anrop. Många agenter stannar vid en färdig order som en människa godkänner. Vid köp med avtal är det ofta ett rimligt arbetssätt.

Steget efter köp glöms ofta. Kunden frågar om leveransstatus, returrätt och faktura. Agenten behöver orderdata som går att läsa, annars hittar den på ett svar.

De fem stegen är ett huvudflöde. Ett bolag med få kunder och enkla produkter kan ha en kortare väg, med pris och köp i samma steg.

Var agentic commerce redan syns i handeln

Produktsökning via AI-tjänster är redan en väg in till era produkter. Först avgör produktdata om ni finns med i svaret, sedan avgör behörigheterna vad agenten får göra.

Fyra lägen syns redan i handeln, och vart och ett ställer egna krav på data och mandat.

Vid ett enkelt katalogköp jämför agenten produkter mot mått, material och pris. Den behöver attribut som går att filtrera och ett pris som är aktuellt när frågan ställs.

Vid återbeställning av förbrukningsmaterial använder agenten kundspecifikt pris, minimiorder och leveransvillkor. Saknas minsta orderkvantitet kan agenten föreslå en rad som affärssystemet senare avvisar.

I en reservdelsportal är kompatibilitet avgörande. Rätt del ska identifieras utifrån modell och serienummer. Attribut för passning, ersättningsartikel och dokument behöver ligga på artikeln, med samma behörighet som kunden har i portalen.

I support hämtar agenten orderstatus och dokument. Ordern, följesedeln och fakturan måste gå att läsa med kundens behörighet. Annars blir svaret en gissning.

Gemensamt för lägena är att agentens räckvidd sätts av vad den får läsa och vad den får skriva. En chattyta kan vara enkel. Auktoriteten ligger i prislogik, attribut, orderdata och roller.

Varför headless och komponerbara plattformar avgör agentens räckvidd

Headless betyder att kundgränssnittet står skilt från handelns motor. De två pratar via API:er. Samma produktdata, prissättning och orderflöde kan då användas av webb, kundportal, app och en agent.

Komponerbar arkitektur går ett steg längre. Produktsök, offertflöde och orderflöde är separata byggstenar. Varje byggsten kan exponeras för sig.

En webbplats där produktinformationen bara finns som HTML är svår för en agent att läsa säkert. Texten kan ändra ordning, och ett kampanjblock kan se ut som en specifikation. Ett stabilt API ger samma svar varje gång, med samma fältnamn.

Ägarskapet avgör om svaret går att lita på.

PIM äger texter, attribut, dokument och relationer mellan artiklar. Hur den informationen modelleras beskrivs på sidan om produktinformation. Agenten får läsa den under upptäckt och jämförelse. Den får inte hitta på ett attribut som saknas i källan.

Affärssystemet äger pris, lager, kundavtal och order. Kopplingarna för de flödena beskrivs under integrationer mot affärssystemet. Ett pris som hämtas från en kopia i webbsystemet kan ge fel avtalspris i agentens svar. Kopian kan vara en dag gammal, eller gälla fel kundgrupp.

Webben eller kundportalen äger inloggning, roller och behörigheter. Agenten ska arbeta i en autentiserad session för just den kunden. En generell roll ser sortiment och priser som kunden inte ska se.

Orderanropet är ett eget beslut. Det körs efter godkännande, en gång, med en idempotensnyckel. Ett upprepat anrop med samma nyckel ska ge samma order.

De gränserna är det arkitekturen står och faller med.

Vem som bär ansvaret när en agent lägger order

Riksbanken beskriver att AI-agenter kan få rätt att genomföra betalningar enligt regler eller preferenser, utan att konsumenten godkänner varje transaktion. Samtidigt varnar Riksbanken för att användaren kanske inte förstår vilka befogenheter som lämnats, och att agenten kan utföra felaktiga eller oönskade transaktioner.

Vid köp med avtal måste agenten följa kundens inköpspolicy. Den ska kontrollera beloppsgränser, attest, kreditvillkor, avtal och vem som får lägga order.

Ett spår som går att granska kan se ut så här. Agenten föreslår en order utifrån kundens uppdrag. Systemet kontrollerar avtalspris, lager och behörighet i affärssystemet och i kundkontot. Belopp under gränsen går vidare. Belopp över gränsen kräver attest av en människa. Orderanropet görs en gång med en idempotensnyckel, så att ett upprepat anrop inte skapar en dubblett. Varje steg loggas.

Loggen är lika viktig som funktionen. När en order blir fel måste ni kunna visa vad agenten läste, vilket pris som gällde och vem som godkände. Utan den kedjan blir reklamationen en ordstrid. Hur en order ska gå från portal till affärssystem beskrivs i orderhantering i e-handeln.

Den agent som kan visa varför en order tilläts, stoppades eller eskalerades är den ni kan stå för. Hur självständig agenten är i övrigt är en annan fråga.

Vad upplägget kräver och när ni bör vänta

Innan någon bygger en agent behöver fyra saker vara på plats. Produktdata med attribut, dokument och relationer ska vara kompletta för de produkter som säljer mest. Integrationen mot affärssystemet ska ha en definierad uppdateringsfrekvens för pris och lager. Roller och behörigheter i kundportalen ska vara tydliga. En namngiven person ska äga reglerna för vad agenten får göra.

Mycket av arbetet ligger i data och processer. AI-funktionen är en mindre del av det arbetet. Förvaltningskostnaden glöms ofta i kalkylen. Versionsbyten i plattform och affärssystem ändrar fält och behörigheter. Glanser Care är ett avtalat ansvar till fast månadskostnad som omfattar versionsuppföljning, kompatibilitet vid uppgraderingar, underhåll av integrationerna mot affärssystemet och buggrättning.

Vänta när katalogen är liten och kunderna beställer via telefon eller säljare. Vänta när data i affärssystemet inte är pålitlig. Vänta när ingen har mandat att besluta om regler för order. En agent ovanpå osäkra saldon ger snabba felsvar.

Ett steg i taget är då ett bättre arbetssätt. Börja med produktinformation och självservice i portalen. Bygg agentlagret när datan håller.

Upplägget ger mindre att visa upp på kort sikt. Det minskar risken för felaktiga order, och det ger er tid att sätta beloppsgränser innan någon kan lägga en order åt en kund.

Testa om en agent hittar och beskriver era produkter rätt

Ni kan köra ett test den här veckan, innan ni bygger något.

Ta fram 20 till 30 neutrala behovsfrågor på svenska, sådana som era kunder faktiskt ställer. En fråga kan gälla vilken pump som passar en fabrik med ett visst flödeskrav. En annan kan gälla vilken reservdel som passar en viss maskinmodell.

Ställ samma frågor till de AI-tjänster som era kunder använder. För varje svar räcker tre kolumner i ett enkelt kalkylark: om tjänsten hittade rätt produkt, om den beskrev produkten rätt med specifikation och pris, och om den rekommenderade den.

Notera kort vad som var fel i varje svar. "Rätt produkt, fel pris" och "saknas helt" kräver olika åtgärder.

Resultatet är ert eget mått på hur väl agenterna hittar er. Om en produkt aldrig dyker upp finns oftast ett datafel: attribut saknas, artikelnamnet är otydligt, eller dokumentet är inte publicerat.

Jämför svaren mot facit i PIM och affärssystem, enligt den ägarfördelning mellan berikat innehåll och transaktionsdata som beskrevs i avsnittet om plattformarnas räckvidd. Börja med de produkter som står för mest omsättning och utöka därifrån när träffarna stämmer.

Vilka svar ni bör kräva från leverantören

Tre frågor räcker för att se om ett upplägg håller.

Hur får en agent läsa ert pris för rätt kundsegment, och kommer priset direkt från affärssystemet eller från en kopia? Svaret visar om ni kan garantera rätt avtalspris vid köp. En kopia som uppdateras på natten räcker inte när avtalet ändrades i morse.

Vilka händelser loggas när en agent lägger eller stoppar en order, och kan ni visa varför beslutet fattades? Svaret avslöjar om spårbarheten finns eller bara lovas. Be att få se ett exempel på en stoppad order, med tidpunkt, regel och användare.

Vad händer med agentens kopplingar när plattformen eller affärssystemet får en ny version? Svaret visar om leverantören tar ansvar för kompatibilitet över uppgraderingar, eller om ansvaret stannar hos er. Fråga vem som testar om pris-, lager- och orderanropen fortfarande svarar efter en release.

Svar som bara nämner AI-verktyg och hoppar över datakällor och loggar är en varningssignal. Svaren ger bättre underlag än en demonstration. En demonstration visar det bästa fallet, med en artikel som redan är perfekt beskriven.

Börja med det agenten ska läsa

Vi tar ansvar för produktwebb, PIM, kundportaler och kopplingen till affärssystemet, så att produktdata, priser och lagersaldon hålls synkroniserade mellan lösningen och affärssystemet.

I en 72-timmarsanalys avsätter ni två timmar och får inom 72 timmar en inventering av funktioner och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan, kostnadsfritt.