Vilka system som behöver integreras i lojalitetsprogrammet
Ett lojalitetsprogram definieras som en kundupplevelse och levereras genom utbyten mellan system. Genom att identifiera dessa utbyten omvandlas lojalitetsprogrammet till ett integrationskrav.
- Lojalitetsplattformen eller motorn: hanterar saldot, nivåregler och utgångslogik som andra system förlitar sig på
- Kassasystemet (POS): läser av saldot innan ett uttag godkänns och skickar tillbaka information om vad som tjänats in och spenderats
- E-handelsplattformen: gör detsamma i kassan och läser av medlemsnivå där det påverkar prissättning eller fri frakt
- Kundappen eller kontosidan: läser av saldo och nivå, så att kunden ser samma siffra som kassan kommer att acceptera
- CRM-systemet eller kunddataplattformen: håller reda på den identitet som saldot är kopplat till, oavsett inloggningar, kort eller telefonnummer som annars kan se ut att tillhöra olika personer
- Affärssystemet (ERP) och ekonomisystemen: tar emot utestående poäng och presentkortsvärde som en skuld
Det finns två typer av utbyten i den listan. Ett uttag kräver svar inom de sekunder kunden står vid kassan, medan skulderapportering och omräkning av nivåer kan ske enligt ett schema. De flesta program är byggda för att helt undvika den första typen.
Vad händer när varje kanal behåller sin egen kopia
De flesta program ger varje kanal en egen kopia av saldot som uppdateras under natten, istället för att koppla lojalitetsplattformen direkt till varje kanal. Det är billigare att bygga, och för ett företag som säljer via en enda kanal fungerar det.
Kostnaden uppstår i en förutsägbar ordning, med början i att kunden står framför en medarbetare som inte kan åsidosätta någonting.
- Nekad vid kassan: en kund får veta att saldot är lägre än vad som visas i appen, medan andra kunder väntar
- Presentkortsvärde använt två gånger: direkt förlust, som oftast skrivs av eftersom det kostar mer att spåra det än vad kortet var värt
- En skuld ingen kan beräkna: enligt redovisningsstandarderna ASC 606 och IFRS 15 ligger outnyttjade poäng kvar i balansräkningen tills de används eller skrivs av, och att beräkna dem innebär att summera system som inte stämmer överens
Den vanliga lösningen är en noggrannare avstämning. Det är värt att vara tydlig med vad avstämning kan och inte kan göra.
Varför nattlig avstämning inte är integrering av lojalitetsprogram
Avstämning sker i efterhand. Den rapporterar att två kanaler godkände samma värde utan att förhindra något av godkännandena, eftersom felet sker inom det tidsfönster som jobbet är till för att stänga.
Båda kanalerna har också rätt utifrån sin egen läsning. Kassasystemet kontrollerar sin kopia och ser värdet, webbutiken kontrollerar sin kopia och ser samma värde, och båda godkänner ett uttag som de hade all anledning att godkänna. Det är därför striktare rutiner vid kassan inte löser problemet, och inte heller en bättre lojalitetsplattform i sig.
Att stänga fönstret innebär att varje kanal frågar systemet som håller saldot i det ögonblick det spelar roll. Byggt för hand innebär det en live-länk per kassa, per butik och per app. Varje länk har sin egen autentisering och sitt eget dataformat, och varje länk måste klara uppgraderingar på båda sidor. En webbutik och en kassa är två länkar. Ett butiksnätverk, flera webbutiker och en app är där e-handelsintegration för flera kanaler slutar vara en uppsättning kopplingar och blir en arkitektur.
Hur en integrationsplattform kopplar ihop ett lojalitetsprogram
En integrationsplattform som tjänst (iPaaS) ändrar vad varje system kopplar upp sig mot. Varje system kopplar upp sig en gång mot plattformen, och plattformen transporterar data mellan dem, i realtid när ett beslut väntar och enligt ett schema när inget väntar.
Verktyg för arbetsflödesautomatisering är det närmaste alternativet, och de flyttar en post mellan applikationer när något inträffar. Vid en inlösen krävs ett svar innan transaktionen slutförs, från det system som innehar saldot.
I Alumio iPaaS tar det arbetet fyra former:
- En livekontroll vid inlösen: en Proxy i realtid skickar saldokontrollen från kassan till systemet som innehar det och returnerar svaret innan köpet slutförs, så att två kanaler inte kan godkänna samma värde
- Intjäning skickas i realtid: en händelsestyrd Route skickar transaktionen till lojalitetsplattformen i samma ögonblick som den avslutas, så att saldot som kontrolleras en timme senare redan reflekterar den
- Identifierare anpassas för att matcha: en Transformer konverterar de konto-, kort- och kontaktreferenser som varje system använder till det format som lojalitetsplattformen förväntar sig, så att en person inte längre registreras som två olika poster
- Rapportering flyttas enligt schema: ett batchflöde för över utestående poäng och presentkortsvärde till affärssystemet för ekonomisk uppföljning, medan detaljerade Logs registrerar vilken kanal som godkände vilken inlösen
Dessa flöden konfigureras snarare än att byggas om för varje kanal, med Code Transformer tillgänglig där konfigurationen inte räcker till för att uttrycka en regel. Inget av detta kräver att lojalitetsprogrammet flyttas till ett enda system, vilket är ett påstående värt att testa.
Integrering av lojalitetsprogram för sju webbutiker och ett butiksnätverk
Camping- och friluftsbranschen är ett bra exempel för att se om ett lojalitetsprogram verkligen kan stanna kvar där det är. Kategorin driver en omfattande butiksverksamhet och ett spritt nätverk av webbutiker i olika länder samtidigt.
Obelink är ett nederländskt familjeföretag som varit verksamt sedan 1959 och är en av Europas största återförsäljare inom camping och friluftsliv, med sju webbutiker i olika europeiska länder vid sidan av sina fysiska butiker. Adobe Commerce används för butiksfronten, RetailVista tillhandahåller molnbaserat affärssystem och kassasystem, och RealtimeWMS används på lagret.
Alumio iPaaS ligger mellan dessa system snarare än inuti något av dem. Presentkortsvärdet synkroniseras mellan affärssystemet, lagret, kassasystemet och webbutiken, så att samma kort är läsbart var kunden än använder det. Skapande av kundkonton och inloggningsdata flyttas genom samma lager, vilket är viktigt här eftersom ett saldo bara är så pålitligt som den kundpost det är kopplat till.
Själva lojalitetsprogrammet flyttades inte. Eftersom varje system ansluter till plattformen snarare än till varandra, kan en komponent som inte längre uppfyller kraven bytas ut utan att man behöver bygga om det som omger den. Den sjunde webbutiken återanvänder flöden som redan är i drift.
Vad integrering av lojalitetsprogram ger en flerkanalig återförsäljare
Ett lojalitetsprogram definieras som ett marknadsföringsinitiativ men ärvs som ett integrationsproblem, eftersom saldot i grunden är ett spenderbart värde snarare än bara en post.
Inom flerkanalig detaljhandel är det problemet uppdelat på tre avdelningar. E-handelschefen eller den ansvarige för omnikanal får höra om det som ett klagomål från en butik. IT-chefen för detaljhandeln underhåller anslutningarna och hanterar varje ny webbutik. Ekonomichefen hanterar det utestående värdet som en skuld. Ingen av dem kan lösa det på egen hand, vilket gör detta till ett integrationsbeslut snarare än en omdesign av programmet.
Genom att koppla samman dessa system på en styrd integrationsplattform kan alla tre arbeta utifrån samma saldo. Det som förändras kommersiellt är vad verksamheten sedan kan göra med det. Ett saldo som alla kanaler kan läsa av är ett saldo som en återförsäljare kan marknadsföra. Det utestående värdet blir en siffra som ekonomiavdelningen kan redovisa.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
