Menu
CASE 01, GEANONIMISEERD

Een Belgisch zomerfestival

Twee weekends achter elkaar, dezelfde weide, een vaste ploeg vrijwilligers achter de tap; voor het eerst draaide cashless hier helemaal op wallet-passen.

  • ± 11.500bezoekers per weekend
  • 6bars
  • 40verkooppunten
  • € 250.000verwerkt
  • 60%vooraf betaald
SITUATIE

Van een schatting op zondagavond naar een cijfer dat klopt

De editie ervoor draaide nog op papieren muntjes: twee kassa's aan de ingang verkochten strips, elke bar nam ze zomaar aan, en pas op zondagavond werd er geteld wat er nog in de bakken over was. Tijdens het weekend zelf had niemand zicht op wat er per bar omging.

De opdracht die wij kregen was kort: hou de rij aan de ingang leeg en toon tijdens het weekend zelf wat er gebeurt. Een polsbandje viel meteen af, want de bestelling voor twee weekends moest te vroeg en te duur vastliggen.

WAT ER DRAAIDE

Eén pas, zes bars en een keuken die volgt op een tabletscherm

De code op de ticketmail activeerde de pas van elke bezoeker, waarna opladen kon: thuis op voorhand, of pas terwijl hij in de rij stond te wachten. Aan elke tap scande een vrijwilliger, tikte het te betalen bedrag in en rekende af; per bar bleef er een apart overzicht, de organisatie zelf keek enkel naar de som van alles.

ZO LIEP EEN BESTELLING VIA QR MENU
  1. 01De gast scant een code op de tafel of bij de foodtruck.
  2. 02Zonder app te installeren opent meteen het menu van dat punt.
  3. 03Hij stelt zijn bestelling samen en betaalt met het saldo op zijn pas.
  4. 04In de keuken duikt de bestelling op met een eigen nummer erbij.
  5. 05Zodra dat nummer klaarstaat, krijgt de gast een melding en haalt hij af.

Zes van de veertig verkooppunten liepen op deze manier via QR Menu. Doordat opladen al bij de ticketmail begon, stond 60% van het bedrag op de rekening nog voor de eerste bezoeker was binnengekomen.

WAT WE LEERDEN

Niet het afrekenen haperde, wel het inloggen ervoor

Al vanaf de openingsavond liep afrekenen aan de tap zonder haperen. De stap ervóór was het probleem: pas aan de bar ontdekten bezoekers dat inloggen nodig was om hun saldo te bekijken of bij te laden. Met vijftienduizend toestellen op dezelfde zendmast is dat scherm alles behalve een randzaak.

  • 01

    Een login vertraagt onzichtbaar

    In plaats van bij de kassa ontstond de vertraging nu op het scherm van de gast. Geen rapport houdt die wachttijd bij, maar wie achter de tap stond, voelde hem elk uur weer terugkomen.

  • 02

    Vooraf laden lost meer op dan de app zelf

    Bij de 60% die al vooraf betaalde, kwam die hindernis nooit boven water. De rest botste er allemaal op, meestal precies op het slechtste moment.

  • 03

    De pas zelf hoort het antwoord te zijn

    Saldo bekijken en bijladen horen zonder omweg in de wallet-pas zelf te zitten. Wat daarbuiten valt, is een extra stap te veel.

WAT DAARNA VERANDERDE

Vandaag is de pas pass-native: saldo en bijladen zitten rechtstreeks in de wallet-pas, en een device-cookie haalt het inlogscherm weg tussen dorst en eerste rondje.

Dit blijft één editie, op één locatie, bij één publiek; we trekken er niet meer conclusies uit dan wat er echt in zit.

ONZE EERLIJKE GRENS

Voor wie dit past, en voor wie (nog) niet

Dit festival groeide intussen door naar 20.000 tot 30.000 bezoekers, en stapte toen over naar een grotere partij; onze crew op locatie is vandaag simpelweg niet uitgebouwd voor die schaal.

Waar wij wél sterk staan, ligt tussen ongeveer 3.000 en 5.000 bezoekers per dag. Dat verbergen we niet: het is precies het publiek waarvoor deze site bedoeld is.

Word jij onze volgende case?

Beschrijf ons kort je locatie en je publiek. We laten je eerlijk weten of het past, en wat we er zelf nog niet van weten.

Boek een demo