Agentna trgovina može biti operativno prihvatljiv prodajni kanal samo kada trgovac može isporučiti točan katalog, važeće uvjete i provjerljiv status narudžbe. Protokol poput UCP-a može povezati trgovinu s AI površinama, ali ne rješava vlasništvo nad podacima, podršku pojedine platforme ni stvarnu potražnju kupaca. Zato odluka počinje provjerom poslovnog procesa, a ne integracije.
Agentna trgovina opisuje kupovni proces u kojem AI površina ili agent može pomoći kupcu pri pronalasku, usporedbi i pokretanju kupnje. Za trgovca to otvara još jednu prodajnu površinu, ali ne stvara novi izvor poslovne istine.
UCP, odnosno Universal Commerce Protocol, opisan je kao protokol za povezivanje trgovine s AI površinama. Za kontekst protokola korisno je proučiti Shopifyjev pregled UCP-a i Googleov vodič za UCP . Ti izvori sami ne odgovaraju na poslovno pitanje može li pojedini trgovac danas prodavati na određenoj AI površini.
Potrebno je odvojiti tri razine:
Prve dvije razine mogu stvoriti priliku. Treća određuje može li trgovac kupcu prikazati podatak pouzdan tijekom narudžbe.
Kod klasične web trgovine kupac često vidi podatke koje trgovac sam prikazuje i održava na vlastitoj stranici. Kod agentne trgovine isti podatak može proći kroz više koraka: iz ERP-a ili drugog izvora, preko kataloga i integracije, do AI površine i konačnog kupovnog tijeka. Svaka nejasnoća u tom lancu postaje poslovni rizik.
Točnost podataka za agentnu trgovinu zato treba promatrati kroz tri pitanja:
ERP je često službeni izvor za artikle, zalihe, cijene, poreze, kupce, narudžbe i isporuku. Ne mora svaki kanal čitati izravno iz ERP-a. Arhitektura ipak mora prepoznati službenu transakciju i pravilo sinkronizacije. Katalog, PIM, web trgovina, integracijski sloj ili tržište mogu imati vlastitu ulogu, ali ne bi smjeli ostaviti nejasnoću oko izvora istine.
Posebno je važno razlikovati podatak za prikaz od podatka za potvrdu narudžbe. Naziv proizvoda i opis mogu imati duži ciklus objave. Cijena, raspoloživost, pravo kupca na određeni uvjet, rok isporuke i status narudžbe često zahtijevaju strožu provjeru u trenutku odluke.
Nijedan protokol ne može preuzeti poslovnu odgovornost umjesto trgovca. Za svaki uvjet prodajnog kanala potrebno je imenovati vlasnika koji može odobriti promjenu, objasniti pravilo i riješiti iznimku.
Izraz vlasnik uvjeta prodajnog kanala ne mora označavati jednu osobu za sve podatke. U praksi je korisnije raspodijeliti odgovornost prema poslovnoj odluci:
Jednako je važno odrediti donositelja odluke pri sukobu podataka. Ako kanal prikazuje raspoloživost, a ERP naknadno odbije rezervaciju, operativni vlasnik mora imati unaprijed utvrđen postupak. Ako AI površina zatraži podatak koji katalog nema, tim treba znati smije li se polje izostaviti, nadopuniti ili treba blokirati ponudu.
Najkorisniji početak nije potpuna inventura svih polja. Počnite s minimalnim obećanjem koje kanal daje kupcu: prepoznati proizvod, prikazati uvjete, zaprimiti narudžbu, potvrditi njezin ishod i pružiti podršku nakon kupnje.
Za svaki korak zabilježite ulaz, vlasnika, pravilo, odredište i postupak pri iznimci.
Provjerite postoji li jednoznačan identifikator artikla za kanal, točan naziv, opis, varijanta, mjera, relevantne slike i podaci potrebni za ispunjenje narudžbe. Nije svako polje jednako kritično, ali identitet artikla mora biti stabilan.
Pitanja za provjeru:
Cijena bez konteksta često nije dovoljan poslovni podatak. Potrebno je razjasniti valutu, porezni prikaz, popuste, količinska pravila, pravo pojedinog kupca na uvjet, rok valjanosti i trošak dostave ako je relevantan za potvrdu.
Ne pretpostavljajte podršku svakog prodajnog kanala za svaki model cijene. Provjerite podršku konkretne platforme i platnog tijeka. Ako kanal ne može prenijeti potreban uvjet, sigurna poslovna odluka može biti ograničiti ponudu, preusmjeriti kupca u drugi tijek ili ne aktivirati kupnju u tom kanalu.
Raspoloživost nije isto što i fizičko stanje zalihe. Može ovisiti o rezervacijama, skladištu, prioritetu kupca, roku nabave i sposobnosti isporuke na određenu adresu. Definirajte što kanal smije prikazati, kada treba ponovno provjeriti podatak i kada narudžbu treba odbiti ili poslati na ručnu obradu.
Za plaćanje je potrebna zasebna provjera podrške trgovca, platnog sustava i tržišta ili AI površine. Protokol može opisivati način povezivanja, ali operativni model plaćanja, povrata, identifikacije kupca i podrške ostaje predmet konkretne provjere.
Narudžba treba imati jedinstveni identifikator kroz kanal i službeni sustav obrade. Time se mogu pratiti prihvat, odbijanje, izmjena, isporuka, otkazivanje i povrat.
Definirajte koje statuse kanal može prikazati i koju informaciju svaki status prenosi kupcu. Status "zaprimljeno" nije isto što i potvrđena raspoloživost, a status "poslano" nije isto što i isporučeno. Ako sustavi koriste različite statuse, zabilježite pravila preslikavanja i vlasnika svakog prijelaza.
Zamislimo proizvođača s B2B katalogom rezervnih dijelova. Katalog ima artikle i opise, ERP vodi zalihe i narudžbe, a cijene ovise o ugovorenom kupcu. Tvrtka razmatra izlaganje dijela ponude kroz AI površinu povezanu protokolom.
Procjena ne bi trebala krenuti pitanjem "možemo li se povezati?" nego ovim redoslijedom:
Negativan odgovor ne mora završiti inicijativu. Moguć je uži početni opseg: samo standardni artikli, samo kupci s jednostavnijim uvjetima, samo upit umjesto kupnje ili dodatna poslovna pravila prije aktivacije. Takva odluka je bolja od širenja kanala s nejasnim obećanjem.
Agentna trgovina ne uklanja potrebu za ljudskom odlukom kod iznimaka. AI površina može drugačije formulirati upit kupca, a kanal može imati vlastita ograničenja prikaza, identiteta ili plaćanja. Proces se ne smije oslanjati samo na tekst odgovora ili dojam korisničkog sučelja.
Podrška protokolu također ne potvrđuje regionalnu dostupnost, podršku pojedinog tržišta, uvjete platnog sustava ni ponašanje pojedine platforme. Za svaku planiranu kombinaciju trgovca, AI površine, tržišta i plaćanja potrebna je zasebna provjera prije javne aktivacije.
Postoji i poslovni kompromis. Stroža provjera prije potvrde može povećati broj koraka u tijeku kupnje, ali smanjuje rizik pogrešnog obećanja. Širi katalog može povećati vidljivost, ali povećava opseg podataka i iznimaka koje treba održavati. Odluku treba donositi prema vrijednosti narudžbe, promjenjivosti uvjeta i sposobnosti tima za obradu iznimaka.
Koristite ovaj popis kao kriterij odluke, ne samo kao tehnički zadatak.
Ako ova pitanja otkriju nejasan izvor podataka ili neimenovanog vlasnika uvjeta, prvo uredite proces. ORKA pristup povezuje svakodnevnu suradnju, ERP službene transakcije i specijalizirano inženjerstvo Trueforcea oko jasne poslovne odgovornosti. Za strukturiranu procjenu početnog stanja koristan je Screening poslovnog procesa .