När köparen är en agent: vad det kräver av din produktdata

Det finns en tyst förskjutning i vem som handlar. Kunden formulerar fortfarande behovet, men allt oftare är det en agent som utför köpet: söker, jämför leveranstider, kontrollerar lagersaldo och lägger ordern. Kunden godkänner. Agenten gör jobbet.

Det låter futuristiskt tills man inser vad det innebär praktiskt. En agent bläddrar inte. Den klickar inte. Den bryr sig inte om din hero-bild eller hur kassan är designad. Den ställer frågor till din data och tar det svar den får.

Vad en agent faktiskt frågar efter

Ta ett konkret uppdrag: ”svarta träningsskor, storlek 38, under 1 000 kronor, i lager, levererade före fredag.”

För att svara på det behöver agenten fem saker, och den behöver dem strukturerat:

• produktattribut som går att filtrera på — färg, storlek, kategori, inte bara i en löptext
• lagersaldo i realtid, inte ett cachat värde från i natt
• pris inklusive de rabatter som faktiskt gäller kunden
• leveransfönster och ledtider, uttryckta som data
• retur- och garantivillkor som går att läsa maskinellt

Saknas något av det får agenten gissa. Och en agent som måste gissa väljer hellre en butik som svarar tydligt.

Det är inte en designfråga längre

Den vanligaste reflexen är att se det här som ännu ett gränssnitt att optimera. Det är fel reflex. Tyngdpunkten flyttar från UX till protokoll, från sidor till API:er — och det som avgör om du syns är inte hur butiken ser ut, utan hur läsbar den är.

Ett sätt att tänka på det: det är ungefär som SEO, fast i stället för att ranka sidor rankar du datakvalitet. Fullständighet, färskhet, förutsägbarhet. En butik vars API svarar likadant varje gång blir vald oftare än en som ibland svarar långsamt och ibland fel.

Det gör frågan obekväm för många. Produktdata har länge fått vara ungefärlig så länge sidan såg bra ut. En agent ser aldrig sidan.

Var det brukar gå fel

I praktiken är det sällan API:t som saknas. Det är underlaget bakom det.

Attribut som bara finns i produktbeskrivningen går inte att filtrera på. Lagersaldon som synkas på schema är inte realtid, oavsett vad integrationen heter. Fraktregler som ligger i ett separat system kan inte svara på ”levererat före fredag”. Och kundunika priser som räknas fram i kassan finns inte förrän någon lagt något i varukorgen — vilket en agent inte gör förrän den redan bestämt sig.

Det är samma frågor som avgör om produktdatan håller och om integrationen mot affärssystemet är byggd för att svara i realtid. Agentisk handel skapar inte de problemen. Den gör dem synliga.

Tre saker att göra nu

Gör datan maskinläsbar. Flytta det som ligger i löptext till attribut. Sätt kompletthetsregler per kanal så att en halvfärdig produkt inte publiceras. Det är arbete som lönar sig oavsett om agenterna kommer i år eller om tre.

Se över vad som är realtid och vad som bara ser ut som det. Lagersaldo och pris är de två som kostar mest när de glider.

Publicera villkoren strukturerat. Frakt, retur, garanti. En agent som inte hittar returvillkoren behandlar det som en risk, inte som en detalj.

Människan finns kvar bakom agenten

Det är värt att avsluta där, för det glöms lätt bort. Agenter ersätter inte kunder. De utför arbetet åt dem.

Förväntningarna är fortfarande mänskliga: begripliga priser, ärliga leveranstider, villkor som går att lita på. Skillnaden är att de numera måste uttryckas så att en maskin kan kontrollera dem — och att en butik som slarvar med det inte får en andra chans, för den blir aldrig presenterad från början.

Vi har skrivit ihop vår research på området i en rapport: vad agentisk handel är, hur köpflödet ser ut när agenten utför det, och vad som krävs av en plattform för att svara på tilltal. Den finns att ladda ner här.