Skillnaden mellan unified commerce och omnichannel
Omnichannel beskriver kundupplevelsen: konsekvent prissättning, varumärkesprofilering och service i alla kanaler. Unified commerce beskriver vad som finns under ytan: ett gemensamt operativt register som alla kanaler läser från i realtid.
En återförsäljare kan leverera en övertygande omnichannel-upplevelse med fragmenterade system, under en tid. Personalen kontrollerar en extra skärm. Någon gör en manuell lageravstämning varje morgon. Luckorna täpps till av personal som känner till genvägarna, och modellen håller tills volymen eller antalet kanaler ökar.
Distinktionen är kommersiellt viktig eftersom de två kräver olika investeringar. Förbättringar inom omnichannel handlar främst om front-end och marknadsföring. Unified commerce är ett problem rörande integration och datamodeller, vilket är anledningen till att e-handelsarkitekturer går från plattformar till databaserade ryggrader. Att blanda ihop dessa är anledningen till att återförsäljare finansierar en redesign när deras faktiska problem är att lagersaldona inte stämmer.
De fyra register som unified commerce måste dela
Unified commerce är lättare att avgränsa när det delas upp i de specifika register som alla kanaler måste vara överens om.
- Lager: en siffra för tillgängligt saldo per plats, uppdaterad vid transaktionstillfället istället för enligt schema
- Kund: en identitet som fungerar oavsett om det är gästutcheckning, lojalitetskort, app-inloggning eller köp i butik
- Order: ett orderregister som överlever att skapas i en kanal, levereras från en andra och returneras via en tredje
- Pris och kampanj: en uppsättning regler, inklusive kund- och kanalspecifik prissättning, som tillämpas från samma källa
Mycket få återförsäljare behöver förena alla fyra samtidigt. Arbetsordningen följer vanligtvis var pengarna läcker ut. För de flesta är det lagret först, eftersom felaktiga lagersiffror antingen leder till översäljning eller döljer varor som finns tillgängliga för försäljning.
Varför krånglar returer mellan kanaler så ofta?
Returer blottlägger bristerna eftersom de kör hela kedjan baklänges. En retur kräver att butiken identifierar en order som den inte skapat och bekräftar vad som betalats, inklusive eventuella kampanjer som tillämpades vid köptillfället. Den auktoriserar sedan en återbetalning för en betalning den inte tagit emot, och returnerar varan till ett lager som en annan kanal redan säljer ifrån.
Varje steg läser en unik post. Om någon av dem är inaktuell blir resultatet omedelbart synligt för kunden. Personalen nekar antingen en giltig retur eller godkänner en ogiltig, och båda scenarierna är kostsamma på olika sätt.
Det är också därför returer är en bra diagnostisk metod. En återförsäljare som kan hantera en kanalöverskridande retur i en enda transaktion, utan telefonsamtal eller ett sekundärt system, har på riktigt förenat dessa fyra register. Den som inte kan det har ett omnikanal-gränssnitt ovanpå en fragmenterad grund.
Unified commerce för sju webbutiker
Återförsäljare med flera butiker drabbas hårdast av detta, eftersom varje ytterligare webbutik är en ny plats där lagersaldon eller lojalitetspoäng kan hamna i otakt. Obelink driver sju stycken vid sidan av en fysisk butik. Den nederländska återförsäljaren inom camping och friluftsliv har varit familjägd sedan 1959 och är en av de största i Europa.
De kopplade samman sitt affärssystem (ERP), lagersystem, kassasystem och Adobe Commerce-butiker via Alumio iPaaS istället för att konsolidera till en enda svit. Kundkonton, lagertillgänglighet och omnikanal-orderprocessen körs nu som styrda flöden mellan dessa system. Presentkort och lojalitetspoäng synkroniseras över alla fyra, så att ett saldo som tjänats in i en kanal kan användas i en annan.
Återförsäljaren behöll de system verksamheten byggdes på och ändrade hur de utbyter data, istället för att byta ut dem.
Hur en integrationsplattform möjliggör unified commerce
En integrationsplattform gör unified commerce möjligt utan plattformsbyte genom att hålla det delade registret mellan systemen istället för inuti något av dem. Alumio iPaaS tar emot en lagerförändring från lagret och tillämpar den allokeringslogik som avgör vad varje kanal får sälja. Resultatet publiceras till varje butik och kassasystem som en enda händelse.
På plattformen delas det arbetet upp i fyra delar:
- Transformatorer: omformar en order så att en post som skapats av butiken når affärssystemet i den struktur det förväntar sig, utan att någon behöver underhålla ett mappningsskript
- Lagring: håller mellanliggande tillstånd, så att en kanal som tillfälligt varit oåtkomlig får uppdateringen vid återssändning istället för att missa den
- Övervakning och granskningsloggar: registrerar vilken kanal som tog emot vilken siffra och när, vilket gör en lageravvikelse till en enkel kontroll istället för en diskussion
- Konfiguration: hanterar regler för dirigering och mappning, där Code Transformer täcker det som konfigurationen inte kan uttrycka
Eftersom dessa flöden konfigureras istället för att byggas manuellt för varje kanal, återanvänds den befintliga logiken när en marknadsplats eller en ny landsspecifik butik läggs till, istället för att man behöver börja om från början.
Att bygga unified commerce utan att ersätta det som fungerar
Instinkten när kanaler inte stämmer överens är att konsolidera till färre system. Det är en förståelig reaktion och ibland den rätta, men den behandlar ett dataproblem som ett licensproblem. Systemen är sällan problemet. Avsaknaden av ett delat register mellan dem är det.
Återförsäljare som närmar sig unified commerce som ett integrationsprogram tenderar att se värde snabbare. De kan förena ett register i taget och mäta resultatet. Lager först, sedan kundidentitet, därefter order och slutligen prissättning. Varje steg är användbart i sig och inget av dem kräver ett specifikt lanseringsdatum.
Slutresultatet är en återförsäljare som kan lägga till en kanal, ett land eller en leveransmodell utan att behöva oroa sig för om resten av verksamheten fortfarande hänger ihop.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
