Unified commerce betekent dat elk verkoopkanaal dezelfde commerciële gegevens leest en schrijft: één productrecord, één voorraadstand per locatie, één ordergeschiedenis, één klantprofiel en één set prijzen en acties. De webshop, de kassa in de winkel, het aanbod op bol en het scherm van de klantenservice zijn weergaven van die gegevens, geen losse kopieën die met syncs en spreadsheets gelijk worden gehouden.
Omnichannel beschrijft wat de klant ervaart: online kopen en in de winkel ophalen, overal retourneren, dezelfde prijs op elk scherm. Unified commerce beschrijft de achterkant die die beloftes ook op drukke dagen waarmaakt. Een omnichannel-ervaring kun je een tijd draaien op losjes gekoppelde systemen; unified commerce is het punt waarop die systemen het niet meer met elkaar oneens zijn. Wil je eerst de basis van kanaalstrategie, lees dan ons eerdere artikel over omnichannel vs multichannel.
Unified commerce gedefinieerd, record voor record
De meeste definities blijven abstract ("één platform", "één overzicht"). Het is nuttiger om de gegevens te benoemen die gedeeld moeten worden, omdat je dat kunt toetsen. Een bedrijf draait unified commerce als deze vijf records elk één eigenaar hebben en elk kanaal die versie gebruikt:
- Productrecord: identificatie (SKU, GTIN, variant-ID), titels, beschrijvingen, kenmerken, afbeeldingen en categorie, één keer beheerd en naar elk kanaal gepubliceerd.
- Voorraadrecord: voorraad per locatie (magazijn, winkel, dropshipping via de leverancier), met reserveringen, zodat een stuk dat in de winkel is verkocht niet ook online wordt verkocht.
- Orderrecord: elke order uit elk kanaal op één plek, met status, fulfilmentlocatie en retourgeschiedenis.
- Klantrecord: één profiel per persoon over online accounts, loyaliteitsprogramma, kassabonnen en contact met de klantenservice.
- Prijs- en actierecord: adviesprijs, kanaalprijzen en lopende acties, met regels voor waar elke prijs geldt.
Betalingen worden vaak als zesde record genoemd: online en in de winkel via dezelfde provider, zodat een terugbetaling naar de oorspronkelijke betaalmethode kan, waar het retour ook binnenkomt. De rode draad: geen enkel kanaal heeft een eigen kopie van deze gegevens.
Unified commerce vs omnichannel: beleving tegenover architectuur
De twee termen gaan over verschillende lagen. Daarom gebruiken leveranciers ze door elkaar, en daarom raken kopers in de war.
Omnichannel tegenover unified commerce
| Wat het is | Een belofte aan de klant | Een eigenschap van de systemen |
|---|---|---|
| Waar je het beoordeelt | Aan de voorkant: kan ik op mijn telefoon beginnen en in de winkel afronden? | Aan de achterkant: ziet de kassa dezelfde order, voorraad en klant als de webshop, op het moment dat het nodig is? |
| Hoe data beweegt | Vaak losse systemen, verbonden met koppelingen die data heen en weer kopiëren | Minder kopieën, zodat er minder gelijk te houden is |
| Hoe het misgaat | Verschillen, zoals online uitverkocht maar wel ophalen in de winkel aangeboden | Minder vaak, maar groter, omdat één storing elk kanaal raakt |
Kort gezegd: elk bedrijf met unified commerce kan omnichannel-klantreizen bieden, maar niet elk omnichannel-bedrijf is unified. De meeste middelgrote retailers zitten ertussenin: productdata en online orders zijn gedeeld, winkelvoorraad en klantprofielen niet.
Waarom Forrester de term onduidelijk noemt
Analisten zijn het niet eens over het label. In een blog uit oktober 2024 met de titel "Unified Commerce Is Not A Thing" stellen Forrester-analisten Emily Pfeiffer en Lauren Cevallos dat leveranciers uit allerlei categorieën de term voor verschillende dingen gebruiken: functies bundelen in één platform, meerdere platforms koppelen of gewoon de functies van hun eigen product opsommen. Een veelgebruikte definitie van leveranciers is volgens hen in feite omnichannel in andere woorden.
Gartner publiceerde in juni 2024 juist een quick answer, "What Is Unified Retail Commerce, and Why Does It Matter?", met drie pijlers: unified, experience-led en composable. De praktische les uit beide: als een leverancier "unified commerce" zegt, vraag dan welke van de vijf records het platform echt deelt en welke je zelf moet koppelen.
Kassa, orderbeheer, betalingen: wat de meeste suites bundelen
Een unified commerce platform is software die meerdere van de vijf records zelf beheert en daarmee meer dan één kanaal bedient. De gebruikelijke bouwstenen:
- Webshop en checkout voor web en app.
- Kassasysteem (POS) voor winkels, op dezelfde product-, voorraad- en klantdata als de webshop.
- Orderbeheer dat orders naar een magazijn of winkel stuurt en retouren uit elk kanaal afhandelt. Zie order management voor de onderdelen.
- Voorraadbeheer met voorraad per locatie en realtime voorraadinzicht voor elk kanaal.
- Klantdata en loyaliteit in één profiel.
- Betalingen online en in de winkel.
- Productdata, die de meeste platforms alleen bewaren in de vorm die hun eigen webshop nodig heeft. Marktplaatsen, feeds en B2B-catalogi vragen meestal meer velden.
Weinig bedrijven halen alle zeven bij één leverancier. Dat is minder een tekortkoming dan een ontwerpkeuze, en daarover gaat het volgende deel.
Twee routes: één suite of een gekoppelde stack met gedeelde records
Er zijn twee manieren om bij gedeelde records uit te komen. Geen van beide is automatisch beter; de juiste hangt af van hoeveel kanalen en systemen je al hebt.
Route 1: één commerce-suite
Webshop, kassa, orders, voorraad en klanten draaien op het platform van één leverancier met één database. Er zit geen synclaag tussen, wat een hele categorie fouten wegneemt. De prijs is afhankelijkheid: je accepteert het datamodel van de suite, de kassahardware en het tempo waarin de leverancier vernieuwt.
- Past als: je vooral via je eigen webshop en eigen winkels verkoopt, met een handvol vestigingen.
- Let op: marktplaatsen als bol en B2B-kanalen die de suite niet zelf bedient, en productdata die voor die kanalen te mager is.
Route 2: een gekoppelde stack met één eigenaar per record
Elk record heeft een bronsysteem: een ERP voor voorraad en financiën, een ordermanagementsysteem voor orders, een PIM voor productdata, een CDP of CRM voor klanten. Al het andere leest via API's en events uit die bronnen. Dat is de headless en composable aanpak, toegepast op de backoffice.
- Past als: je via veel kanalen verkoopt (marktplaatsen, B2B-portalen, meerdere landen) of al een ERP hebt dat je niet gaat vervangen.
- Let op: koppelingen die volgens een schema kopiëren in plaats van bij elke wijziging. Een nachtelijke voorraadsync is niet unified, wat het architectuurplaatje ook zegt.
Route 2: één eigenaar per record
B2B-verkopers komen vaak bij route 2 uit omdat hun inkopers zoveel contactpunten gebruiken: volgens de B2B Pulse van McKinsey gebruiken B2B-kopers gemiddeld tien kanalen (McKinsey, 2024).
Productidentiteit: de sleutel waar elk unified systeem op draait
Gesprekken over unified commerce gaan over voorraad en klanten, omdat klanten daar de fouten merken. Zelden wordt gezegd dat al die records aan elkaar hangen via een productcode. Als de kassa een jas kent als barcode 8712345678906, de webshop als variant 4471 en je bol-account als eigen referentie RJ-NAVY-M, kan er niets worden gedeeld tot die drie aan één product zijn gekoppeld.
Google maakt die afhankelijkheid expliciet. Voor lokale voorraadadvertenties en gratis lokale vermeldingen vraagt de specificatie voor lokale voorraadgegevens een winkelcode die overeenkomt met je Bedrijfsprofiel, een beschikbaarheid per winkel en dezelfde product-ID's in je productdata en je lokale voorraaddata. Kloppen de ID's niet, dan kan Google de winkelvoorraad niet aan het product koppelen.
Het productrecord moet bovendien compleet genoeg zijn voor het veeleisendste kanaal, niet alleen voor de webshop. De kassa heeft een barcode en een prijs nodig. Een marktplaats wil kenmerken, een categorie en een GTIN. Een Google-vermelding vraagt een afbeelding, beschikbaarheid en een beschrijving. Eén record per product dat aan al die eisen voldoet, is het idee achter een single source of truth.
Eén regenjas retour in de winkel, gevolgd door vijf records
Een klant bestelt een marineblauwe regenjas in maat M in de webshop en brengt hem acht dagen later terug naar een winkel. Dit moet elk record doen om dat retour goed te laten verlopen:
- Product: de winkel scant de barcode op het label. De kassa moet die herleiden naar hetzelfde product en dezelfde variant als de online orderregel. Zonder gedeelde code wordt het retour verwerkt als onbekend artikel.
- Order: de kassa vindt de online order via het e-mailadres van de klant of het ordernummer en controleert de retourtermijn.
- Betaling: het geld gaat terug naar de oorspronkelijke betaalmethode, bijvoorbeeld iDEAL, wat alleen kan als de winkel bij de online transactie kan.
- Voorraad: de jas komt bij de winkelvoorraad, en de online beschikbaarheid voor die winkel wordt bijgewerkt, zodat de volgende klant hem kan reserveren.
- Klant: het retour verschijnt in het klantprofiel, zodat de klantenservice en de volgende e-mailcampagne ervan weten.
In een multichannel-bedrijf gaat stap 1 of 2 mis en stuurt de winkel de klant weg. In een omnichannel-bedrijf op losse systemen werken alle vijf de stappen, maar zet een medewerker of een sync ze achteraf recht. In een unified bedrijf gebeuren ze in één transactie.
Tien vragen voor een leverancier van unified commerce
Gebruik ze in een demo of een offerte-aanvraag. Elke vraag gaat over een record in plaats van een functie, waardoor vage antwoorden snel opvallen.
Tien vragen voor een leverancier van unified commerce
Klantprofiel eerst, nachtelijke syncs en drie andere valkuilen
- Beginnen bij het klantprofiel. Eén klantbeeld is het zichtbaarste doel, maar het hangt af van schone orders, en die hangen af van schone productcodes. Wie bovenaan begint, koppelt klanten aan orders met producten die niemand kan identificeren.
- Geplande syncs unified noemen. Van een nachtelijke export naar een export per uur gaan, laat nog steeds een uur waarin winkel en webshop het oneens zijn.
- Productdata migreren in plaats van beheren. De catalogus wordt één keer naar het nieuwe platform gekopieerd en binnen een paar maanden weer op drie plekken bewerkt.
- Marktplaatsen en B2B vergeten. Een suite die webshop en winkels samenbrengt maar niet bol, Amazon of het B2B-portaal, laat de grootste kanalen buiten het model.
- Het label kopen. Zoals Forrester opmerkt, dekt de term heel verschillende producten. Een platform dat alleen de voorkant samenbrengt, lost voorraad en retouren niet op.
De volgorde die meestal werkt: eerst gedeelde productcodes en een compleet productrecord, dan voorraad per locatie, dan orders en retouren, dan klantprofielen. Een multi-channel catalogus op basis van één productrecord is het fundament dat de andere lagen nodig hebben.
Productcontent vanuit één record naar webshops en Merchant Center
WISEPIM is geen kassasysteem, ordermanagementsysteem of commerce-suite. Het beheert het productrecord in beide routes: het importeert je catalogus, vult en verbetert beschrijvingen, kenmerken, vertalingen en categorieën met AI, controleert de volledigheid per kanaal met Quality Guard en zet hetzelfde record via de koppelingen in je webshops en Google Merchant Center. Met de optionele auto-sync gaat een opgeslagen product ongeveer 30 seconden later naar gekoppelde winkels zoals Shopify, WooCommerce, Lightspeed en CCV Shop, zodat je kanalen qua content en codes niet uit elkaar lopen terwijl jij aan voorraad, orders en klanten werkt.
