Horeca
Een ogenschijnlijk eenvoudige vraag over een eigen online bestel- en leveringskanaal groeide uit tot een product-discoverytraject. Voor er iets gebouwd of gekozen werd, onderzocht Simply Dom de gewenste klantbeleving, bestaande oplossingen, mogelijke architecturen en de operationele gevolgen — inclusief de redenen waarom verschillende voor de hand liggende pistes afvielen.
De situatie
De vraag kwam rechtstreeks uit de praktijk. Een horeca-ondernemer wilde meer controle over zijn eigen online bestel- en leveringskanaal, met eigen chauffeurs, maar zonder een klantbeleving op te geven die grote platformen intussen normaal hebben gemaakt.
Eén element was daarbij bijzonder concreet: de klant moest zijn bestelling tijdens de levering echt kunnen volgen. Niet een status “onderweg”, niet alleen een geschatte levertijd, maar zien waar de levering zich bevindt.
Op het eerste gezicht een softwarevraag: welke oplossing biedt dit? De eerste research maakte al snel duidelijk dat die formulering te simpel was.
Het zakelijke vraagstuk
Er bestaan veel systemen voor online bestellen, en evenveel systemen voor dispatch, routes en chauffeurs. Opvallend veel leveranciers gebruiken daarbij woorden als “live tracking” of “real-time delivery”. Alleen betekenen die woorden niet overal hetzelfde.
Soms kan de zaakvoerder zijn chauffeurs live volgen, maar de klant niet. Soms krijgt de klant statusupdates zonder kaart. Soms bestaat de gewenste ervaring alleen wanneer een externe koerierspartner de levering uitvoert. En soms biedt een platform bijna alles wat nodig is — behalve precies het onderdeel waarvoor het onderzoek begon.
De moeilijkheid zat dus niet in leveranciers vinden; die waren er genoeg. De moeilijkheid was aantonen welke combinatie de gevraagde ervaring werkelijk kon leveren, met eigen chauffeurs, een werkbare dagelijkse operatie en voldoende controle over het klantkanaal.
De gemaakte keuzes
De eerste stap was de gewenste ervaring precies definiëren. “Live tracking” werd niet als featurelabel aanvaard; de vraag werd concreter: moet de eindklant op een kaart een bewegende positie van de chauffeur kunnen zien terwijl de bestelling onderweg is? Dat werd de toetssteen.
Daarna werden de lagen van het probleem uit elkaar gehaald. Enerzijds het commerciële klantkanaal: assortiment, bestelling, betaling, klantgegevens en communicatie. Anderzijds de uitvoering: orders toewijzen, chauffeurs aansturen, routes, status en locatie.
Die opsplitsing maakte verschillende architecturen zichtbaar: één platform dat alles doet, een bestelplatform gekoppeld aan gespecialiseerde last-milesoftware, een bestaande oplossing met een externe leveringspartner, of meer maatwerk rond systemen die elk afzonderlijk al bewezen onderdelen aanbieden.
Niet elke piste kreeg evenveel tijd. Wanneer een kernvoorwaarde niet aantoonbaar ondersteund werd, viel ze af. Dat was belangrijker dan een lange shortlist produceren.
Mijn rol
Mijn rol was die van product discovery en opportunity validation: de oorspronkelijke vraag ontleden, de gewenste klantbeleving uitschrijven, bestaande bestelplatformen en last-mileoplossingen afzonderlijk onderzoeken, en controleren wat leveranciers werkelijk bedoelen wanneer ze “live tracking” schrijven.
Daarbij werd expliciet geregistreerd waar iets bewezen was, waar alleen een marketingclaim bestond en waar nog een open vraag zat.
Ook de operationele en commerciële kant werd meegenomen. Wat ziet de eindklant, wat ziet de chauffeur, wat moet de zaakvoerder kunnen doen? Hoe komt een bestelling van het ene systeem in het andere, en waar ontstaat een extra handeling? Wie bezit de klantrelatie? En hoeveel afhankelijkheid verschuift er werkelijk wanneer je één marktplaats vervangt door meerdere softwareleveranciers?
De vraag of het voordeel groot genoeg is om die extra complexiteit te verantwoorden, bleef daarbij bewust open: die kan pas ernstig beantwoord worden zodra vaststaat welke architectuur überhaupt kan wat gevraagd wordt.
De research werd vervolgens opnieuw gechallenged — niet om zoveel mogelijk oplossingen over te houden, maar om sneller afscheid te nemen van oplossingen die bij nader onderzoek niet deden wat ze op het eerste gezicht leken te doen.
De uitvoering
Het resultaat van die eerste discovery was geen software, en dat was ook niet de bedoeling. Er lag een veel scherper probleembeeld: een uitgeschreven klantflow, een aparte flow voor chauffeur en operationele aansturing, een vergelijking van mogelijke platformcategorieën, en een overzicht van oplossingen die op essentiële punten afvielen — met de reden waarom.
Daarnaast lag er een eerste architectuurbeeld van welke systemen samen zouden kunnen werken, en vooral een lijst van vragen die in een volgende researchronde nog bewezen moesten worden.
Daardoor werd ook duidelijk waar verder onderzoek wél zin had: niet twintig leveranciers opnieuw aanschrijven, maar een beperkte groep pistes gericht testen op de voorwaarden die werkelijk beslissend waren. Pas daarna kunnen technische haalbaarheid, operationele werkbaarheid en economics samen beoordeeld worden.
Stand van zaken — augustus 2026
De tweede researchronde heeft het speelveld vooral kleiner gemaakt.
Platformen voor online bestellen, dispatch en chauffeursondersteuning zijn er genoeg. Alleen blijkt “live tracking” geen eenduidige term. Bij verschillende oplossingen kan de uitbater zijn chauffeurs volgen, maar de klant niet. Elders krijgt de klant statusupdates zonder de bewegende positie van de chauffeur op een kaart te zien. En in sommige modellen bestaat die ervaring alleen wanneer een externe bezorgpartner de rit uitvoert. Die pistes zijn afgevallen.
Tegelijk werd de operationele vraag scherper. Meerdere horecamerken moeten via een eigen direct kanaal kunnen werken, met een gedeelde ploeg eigen chauffeurs. Orders moeten juist terechtkomen, chauffeurs moeten aangestuurd kunnen worden, en de klant moet tijdens de levering dezelfde duidelijkheid krijgen die hij van grote platformen gewend is.
Uit de vergelijking blijft één concrete piste over: een direct bestelplatform gekoppeld aan dispatch- en chauffeursfunctionaliteit. Op papier komt die combinatie het dichtst bij wat gezocht wordt. Maar het element waarvoor de opdracht begon, staat nog niet vast: kan de eindklant bij een levering met eigen chauffeurs werkelijk de positie van zijn chauffeur op een kaart zien bewegen?
Daarnaast moet nog blijken hoe meerdere merken binnen dezelfde werking behandeld worden, hoe de dagelijkse flow er in de praktijk uitziet, welke licenties nodig zijn en wat het totaal kost.
De volgende stap blijft daarom bewust klein: een demo van het echte systeem, bevestiging van die kritieke flow, en een concrete offerte. Geen implementatie, geen maatwerk, geen businesscase op basis van marketingclaims. Pas met die elementen op tafel kan beoordeeld worden of dit technisch en operationeel klopt, en of het financieel steek houdt.
De case is nog niet af. Maar wat nog bewezen moet worden, is intussen exact benoemd.
Bewust niet gedaan
Geen “ja, dat kan” omdat ergens op een website “live tracking” stond. Geen platform aanbevolen zonder te controleren wie die tracking werkelijk kon zien. Geen maatwerk voorgesteld omdat bestaande oplossingen niet onmiddellijk perfect aansloten. Geen softwarestack gekozen vóór duidelijk was hoe ze dagelijks gebruikt moest worden. En geen businesscase gebouwd rond functies die nog niet aangetoond waren.
Er moest op dat moment nog niets verkocht worden.
De eerste winst zat daar al: minder onzekerheid.
Sommige opties vielen daardoor af, andere werden interessanter, en de oorspronkelijke vraag werd veel scherper dan ze bij het begin was.
Dat is precies wat product discovery moet doen.