Loyaliteit voorbij de stempelkaart
Waarom de meeste loyaliteitsprogramma's in de horeca ondermaats presteren, en wat er verandert wanneer loyaliteit zich in dezelfde database bevindt als al het andere.

De meeste loyaliteitsprogramma's in de hospitality zijn nikszeggende statistieken.
De opzet is bekend. Een klant meldt zich aan voor het programma. De klant spaart punten of stempels met uitgaven. De klant verzilvert uiteindelijk een beloning. Het programma rapporteert ledengroei, verzilveringspercentages en een stijging van de gemiddelde besteding. Het bestuur keurt verdere investeringen goed. Het programma loopt door.
Het probleem is dat vrijwel geen van deze programma's daadwerkelijk het gedrag stimuleert waar het verdienmodel van afhangt. Leden geven ongeveer hetzelfde uit als niet-leden. Het verzilveringspercentage is laag omdat het sparen van voldoende punten voor een waardevolle beloning langer duurt dan leden bereid zijn te wachten. De "exclusieve aanbiedingen" die naar leden worden gestuurd, zijn niet echt exclusief: het zijn dezelfde aanbiedingen die het marketingteam openbaar communiceert. Het niveausysteem is voornamelijk voor de bühne: de meeste exploitanten beschikken over data die aantonen dat "Gold-leden" met dezelfde bezoekfrequentie net zoveel uitgeven als "Silver-leden".
Dit is geen mislukking van de strategie. Het is een mislukking van de dataintegratie. Echte loyaliteit vereist dat data op één plek samenkomen, en in de meeste hospitality-stacks is dat niet het geval.
Waarom gefragmenteerde stacks structureel onderpresteren op het gebied van loyaliteit
Prestaties op het gebied van loyaliteit zijn afhankelijk van de betrouwbaarheid van drie integraties: de integratie tussen de POS en het loyaliteitssysteem (zodat punten correct worden berekend op het moment van aankoop), de integratie tussen het loyaliteitssysteem en de CRM (zodat segmentatie gerichte aanbiedingen op basis van niveau mogelijk maakt) en de integratie tussen het loyaliteitssysteem en het marketingplatform (zodat getriggerde communicatie correct wordt verzonden bij loyaliteitsgebeurtenissen).
In een gefragmenteerde stack zijn alle drie deze integraties onbetrouwbaar op manieren waar de leverancier van het loyaliteitssysteem geen invloed op heeft.
De POS-integratie werkt meestal via een nachtelijke batchverwerking. Een klant rekent af op vrijdagavond. De punten verschijnen zaterdagochtend – of soms pas zondag – in het loyaliteitssysteem. De klant bekijkt de app, ziet de uitgave van gisteren niet terug, neemt aan dat het systeem kapot is en verliest het vertrouwen in het programma. Vertrouwen in een loyaliteitsprogramma is de enige voorwaarde waaronder het daadwerkelijk herhaald gedrag stimuleert. Zodra het vertrouwen is geschaad, is het programma slechts nog decoratie.
De CRM-integratie is meestal een eenrichtingssynchronisatie: loyaliteitsdata stromen naar de CRM, maar de gedragsdata van de CRM (browsegeschiedenis, e-mailinteractie, ondersteuningstickets) stromen niet terug naar het loyaliteitssysteem. Hierdoor is de loyaliteitssegmentatie beperkt: er kan worden gesegmenteerd op bestedingsniveau, maar niet op "leden die in geen 60 dagen zijn langsgekomen EN onze laatste drie e-mails hebben geopend".
De marketingintegratie is het meest kwetsbaar. Een loyaliteitsgebeurtenis (puntenlimiet bereikt, niveau verhoogd, beloning verloopt) moet een marketingcommunicatie activeren. De trigger start in het loyaliteitssysteem. De integratie stuurt deze door naar het marketingplatform. Het marketingplatform plant de verzending in. Als er ook maar één stap misgaat (en in een jaar lang verzenden gaat er altijd wel iets mis), wordt de communicatie niet verzonden, verzilvert het lid niks en lijdt de verzilveringsstatistiek hieronder – de enige statistiek die echt telt voor de ROI van het programma.
Dit alles is het gevolg van de achterliggende architectuur. De gefragmenteerde stack veroorzaakt het prestatieprobleem bij loyaliteit. Hoe geavanceerd de software van een loyaliteitsleverancier ook is, dit probleem valt daarmee niet op te lossen.
Wat een geünificeerde architectuur doet met de rekenregels van loyaliteit
Wanneer loyaliteit zich in dezelfde database bevindt als POS, CRM, marketing en boekingen, verdwijnen de architecturale oorzaken van onderprestatie.
Punten worden atomair berekend binnen de POS-transactie. De kassa verwerkt de bestelling. Binnen dezelfde databasetransactie werkt de loyaliteitsengine het puntenbedrag bij in één enkele, alles-of-niets-stap. Daarbij wordt gecontroleerd waar elke toekenning vandaan kwam, zodat dezelfde aankoop nooit dubbel wordt geteld. Het saldo van de klant wordt bijgewerkt nog voordat de kassabon wordt afgedrukt. De trigger voor behaalde punten wordt vanuit dezelfde transactie geactiveerd.
Er is geen vertraging. Er is geen integratie. Het is onmogelijk dat de bestelling wordt afgerond maar de punten niet aankomen. De app van de klant toont het nieuwe saldo binnen enkele seconden na het verlaten van de zaak. Vertrouwen in het programma wordt opgebouwd door nauwkeurigheid, en de architectuur maakt onnauwkeurigheid onmogelijk.
Ook de CRM-segmentatie is geünificeerd. "Leden die in geen 60 dagen zijn langsgekomen en onze laatste drie e-mails hebben geopend" is één query over loyaliteitslidmaatschap, boekingen en e-mailinteractiehistorie. Geen integratie. Geen dataverloop. De segmentatie kan elk veld uit elk operationeel systeem bevatten, omdat alle operationele systemen zich in dezelfde database bevinden.
De marketingtriggers worden rechtstreeks geactiveerd door loyaliteitsgebeurtenissen. Behaalde punten, een lid dat stijgt in niveau, een verzilverde beloning, een automatisch toegekende beloning, een succesvolle aanbeveling, punten die bijna verlopen, de verjaardag van een lid: al deze gebeurtenissen zijn volwaardige triggers die direct door de workflow-engine kunnen worden gebruikt. De e-mail over verlopende beloningen wordt verzonden op het moment dat de punten daadwerkelijk verlopen, niet wanneer de nachtelijke batchtaak voor het laatst heeft gedraaid.
De verschuiving van puntenprogramma's naar CLV-cohorten
De grotere kans die geünificeerde loyaliteit biedt, is niet alleen een betere uitvoering van het bestaande programma. Het is een fundamentele verandering in wat loyaliteitsprogramma's kunnen meten.
In de meeste hospitalitygroepen rapporteert het loyaliteitsprogramma over programmastatistieken: ingeschreven leden, behaalde punten, verzilveringspercentage en gemiddelde besteding per lid. Deze statistieken beschrijven de activiteit van het programma. Ze beschrijven niet de impact op de organisatie.
De statistiek die er echt toe doet, is de klantwaarde op de lange termijn (customer lifetime value). Concreet: hoeveel meer geeft een lid bij ons uit, verspreid over alle bezoeken en over meerdere jaren, vergeleken met een vergelijkbaar niet-lid? Dit is de vraag waarop elke CFO antwoord wil voor elk loyaliteitsprogramma dat hij financiert. In een gefragmenteerde stack is deze vraag niet te beantwoorden: de benodigde data staan verspreid over te veel systemen voor een betrouwbare cohortanalyse.
In mDOS telt een vooraf berekend snapshot van de lifetime value de POS-uitgaven van elke gast op (het uitbreiden van het snapshot naar overnachtingen, dineren, OTA's en channel managers staat op de reporting-roadmap; het universele gastprofiel bevat deze stromen al voor dezelfde gast, dus het is een aggregatiewijziging, geen integratieproject). De drempelwaarde van het 75e percentiel identificeert "klanten met een hoge LTV" als een opvraagbaar segment. Productaffiniteitsrapportages stellen vervolgens de vraag: wat zijn de populairste artikelen die door klanten met een hoge LTV worden besteld? Welke gerechten correleren met herhaalgedrag? Welke locaties behouden klanten het beste? Welke marketingflows converteren klanten naar het cohort met een hoge LTV?
Dit zijn andere vragen dan "hoeveel punten hebben we vorige maand uitgegeven". Het zijn de vragen die de manier veranderen waarop een loyaliteitsprogramma wordt gefinancierd, ontworpen en geëvalueerd. Het programma is niet langer een puntenmotor, maar wordt een CLV-motor. En de taak van het marketingteam is niet langer "inschrijvingen stimuleren", maar "cohortprogressie stimuleren".
Hoe dit er operationeel uitziet
Voor een Commercieel Directeur die een groep met meerdere merken leidt, verandert geïntegreerde loyaliteit de operationele werkelijkheid op specifieke manieren.
De productaffiniteitsrapportage toont welke menu-artikelen klanten met een hoge LTV daadwerkelijk bestellen. Deze gegevens voeden de menu-engineering: de F&B Director weet welke gerechten uitgelicht moeten worden, welke geschrapt kunnen worden en welke in komende campagnes gepromoot moeten worden. Beslissingen worden genomen op basis van daadwerkelijk cohortgedrag in plaats van onderbuikgevoel.
Dankzij de aan CLV gekoppelde segmentatie kan het marketingteam flows bouwen die gericht zijn op specifieke cohortprogressies. Een flow die gericht is op "klanten die in 90 dagen twee keer zijn langsgekomen en meer dan de mediaan hebben uitgegeven", kan hen een incentive bieden die specifiek is ontworpen om hen naar het cohort met een hoge LTV te laten doorgroeien. De flow draait continu. Het effect versterkt zichzelf.
De trigger voor een niveau-upgrade wordt geactiveerd op het moment dat een klant een drempelwaarde overschrijdt. Zo komt de feestelijke communicatie aan tijdens dezelfde dienst waarin de klant de drempel bereikte, en niet pas drie dagen later wanneer de batch-synchronisatie is bijgewerkt. Het emotionele moment wordt gegrepen. De klant voelt zich gewaardeerd.
De trigger voor verlopende beloningen wordt betrouwbaar geactiveerd omdat het een database-event is, geen integratie. Leden die hun beloning nog niet hebben verzilverd, krijgen op het juiste moment een herinnering. Het verzilveringspercentage stijgt aantoonbaar.
Het aantal loyaliteitsgeschillen daalt naar nul: er is geen situatie mogelijk waarin de bestelling wel bestond maar de punten niet, dus valt er niets te betwisten. De klantenservice wint de uren terug die voorheen werden besteed aan het uitzoeken van puntenverschillen. Medewerkers hoeven het programma niet langer te verdedigen. Het programma wordt betrouwbaar, wat de basisvoorwaarde is voor al het andere.
De zakelijke dimensie
Voor exploitanten met meerdere locaties en B2B-omzet (de meeste pubgroepen, hotelgroepen en restaurantketens in stadscentra) moet het loyaliteitsmodel verder reiken dan individuele leden en zich uitstrekken tot zakelijke accounts. Bedrijven die regelmatig boeken, moeten ook waarde opbouwen: dinervergoedingen, overnachtingen, evenementenarrangementen en zakelijke puntenpools.
mDOS lost dit op via zakelijke puntenpools die individuele ledenactiviteit samenvoegen tot een gedeeld zakelijk saldo. Een lid van het Acme Corp-account spaart punten tijdens een verblijf; de punten worden bijgeschreven op zowel het persoonlijke saldo als de zakelijke pool. De beheerder van het zakelijke account kan vervolgens namens elk willekeurig lid punten uit de pool verzilveren, of pool-saldo toewijzen aan specifieke evenementen of overnachtingen.
Dit is het type functionaliteit dat verouderde loyaliteitsplatformen niet ondersteunen, of slechts als een onhandige toevoeging bieden. In mDOS is het een volwaardige kernfunctionaliteit omdat het zakelijke account, het individuele lid, de boeking en het loyaliteitsgrootboek zich in dezelfde database bevinden. De relatiegraaf is opvraagbaar, de toewijzingslogica is helder en de audit trail is volledig.
Wat dit betekent voor de CFO
De CFO die een loyaliteitsprogramma financiert, wil drie dingen: betrouwbare gegevens over de prestaties van het programma, bewijs dat het programma voor incrementele omzet zorgt en operationele discipline die voorkomt dat het programma een boekhoudkundige of financiële aansprakelijkheid wordt.
Geïntegreerde loyaliteit levert alle drie.
De prestatiegegevens zijn betrouwbaar omdat er geen integratie-afwijking is. De loyaliteitscijfers in het dashboard zijn exact dezelfde cijfers als door het POS zijn geregistreerd. De cohortanalyse is zuiver omdat de LTV-cijfers rechtstreeks afkomstig zijn uit het POS-grootboek waarin de uitgaven van de klant zijn vastgelegd, zonder integratie-afwijkingen tussen wat de kassa heeft verwerkt en wat het dashboard rapporteert. De boekhoudkundige aansluiting is zuiver omdat elke toegekende en elke verzilverde punt in één enkel grootboek staat met een volledige audit trail.
Voor overnemende partijen die mDOS beoordelen als IP, is de loyaliteitsarchitectuur een discreet signaal van technische kwaliteit. De meeste horeca-SaaS behandelt loyaliteit als een randsysteem: een eenvoudig bewerkingsscherm boven op een lijst met punten met beperkte bedrijfslogica. mDOS behandelt het als een transactionele functionaliteit met dezelfde atomiciteitsgaranties als de betalingsengine. De diepgang hier is maatgevend voor de diepgang elders.
De loyaliteitsengine draait atomair binnen de POS-transactie met volledige CLV-cohortanalyse. Technische documentatie is beschikbaar onder een wederzijdse NDA.
Bekijk mDOS voor uw eigen bedrijf
Een gesprek van 30 minuten met een van onze experts, afgestemd op wat u als eerste wilt aanpakken.
About the author
Ross Crawford is the founder of Mr Digital and mDOS, and a Fellow of the Chartered Institute of Marketing (FCIM).
- Fellow of the Chartered Institute of Marketing (FCIM)


