Picnic nabouwen

Een klant kiest een tijdvak, legt producten in een mandje en krijgt de boodschappen aan de deur. In de app zie je een lijst, een zoekfunctie, een mandje en een tijdvakkiezer. Dat is te bouwen.

Maar dat tijdvak is geen keuze uit een lijst: het is de uitkomst van een berekening over wat er nog in de bus past, welke route de bezorger die dag rijdt en of jouw adres onderweg ligt. Zodra iemand een slot kiest, verandert de beschikbaarheid voor iedereen in de buurt.

Er zit nog een laag onder die tijdvakkiezer die je als gebruiker helemaal niet ziet: de dienst stuurt jouw keuze. Een tijdvak dat toevallig goed in de route past, wordt aantrekkelijker gepresenteerd of goedkoper aangeboden dan een tijdvak dat een omweg oplevert. Dat is geen truc maar de kern van het model: de bezorgkosten van een rit staan grotendeels vast, dus alles hangt af van hoeveel adressen er in passen.

Dat verklaart ook waarom dit soort diensten in wijken werkt en niet per klant. De eenheid is niet de bestelling maar de rit. Wie dat omdraait en per klant denkt, bouwt een webshop met een bezorger ervoor en komt uit op een kostenplaatje dat niet uitkomt.

Boodschappen bestellen is geen ontdekkingsproces. Mensen kopen grotendeels elke week hetzelfde en willen dat zo snel mogelijk achter de rug hebben. Dat maakt twee functies belangrijker dan al het andere: zoeken dat werkt met halve woorden en merknamen, en een manier om een vorige bestelling in één handeling te herhalen.

Bladeren door categorieën is daarbij ondergeschikt, hoe verleidelijk het ook is om daar ontwerpaandacht in te steken. Wie een boodschappen-app test, ziet vrijwel altijd hetzelfde: de eerste bestelling duurt lang en is een gedoe, en of iemand terugkomt hangt af van hoe kort de tweede is.

Daar zit meteen de belangrijkste ontwerpopgave: de eerste bestelling zo inrichten dat hij tegelijk een basis legt voor de volgende. Een boodschappenlijst die zichzelf onthoudt, een suggestie op basis van wat er vorige keer in zat, een vast lijstje dat je kunt aanpassen. Dat is geen extraatje maar het model.

Met één bus en vijftig adressen kun je de route met de hand plannen en werkt alles. Bij twee bussen ontstaat de eerste echte puzzel: welke adressen horen bij welke rit, en wat doe je als iemand bestelt nadat de indeling is gemaakt. Herplannen betekent dat de tijdvakken van andere klanten kunnen verschuiven, en dat kan niet zonder ze te informeren.

Het tweede probleem is voorraad die over ritten heen loopt. Twee klanten in verschillende ritten bestellen het laatste product. Wie krijgt het? Dat is geen technische vraag maar een beleidskeuze die je in code moet vastleggen, en het antwoord bepaalt hoe klanten je dienst ervaren.

Het derde is retour en restitutie. Een product dat niet geleverd kon worden, moet uit de rekening, terug in de voorraad en zichtbaar zijn voor de klant voordat hij zelf belt. Dat is een keten van drie systemen die bij de meeste beginnende diensten los van elkaar staan, en waar de meeste klachten vandaan komen.

Boodschappen hebben een dunne marge, en bezorgen kost geld per stop. Dat betekent dat de economie van zo'n dienst volledig bepaald wordt door twee getallen: hoeveel adressen er in een rit passen en hoe groot de gemiddelde bestelling is. Alles wat je in het product doet, doe je uiteindelijk om een van die twee te beïnvloeden.

Dat verklaart keuzes die van buitenaf vreemd lijken. Een minimumbedrag per bestelling is geen drempel maar een voorwaarde. Vaste bezorgdagen per wijk zijn geen gemakzucht maar de enige manier om de rit vol te krijgen. Een assortiment dat kleiner is dan een supermarkt, is geen beperking maar een keuze om het inpakken sneller te maken.

Als je in deze richting iets wilt beginnen, toets dan als eerste of mensen bereid zijn zich naar jouw rooster te voegen. Dat is de aanname waar het model op staat of valt, en het is de goedkoopste om te toetsen: daar heb je geen software voor nodig, alleen een gesprek en een aanmeldpagina.

Wat we in een bouwdag bij zo'n concept maken, is een klikbare doorstroom waarin iemand een tijdvak kiest, producten toevoegt en bevestigt — met echte productdata, op een telefoon, snel genoeg om te testen bij mensen. De tijdvakken zijn niet berekend maar ingesteld: je toetst of de keuze begrepen wordt, niet of het rooster klopt.

Daaromheen zetten we één scenario dat echt is: een product dat niet leverbaar blijkt. Dat is het moment waarop je leert hoe mensen op je dienst reageren, en het is het onderdeel dat in vrijwel elk concept ontbreekt tot het live gaat.

Wat we bewust niet doen is de routeoptimalisatie, de voorraadkoppeling of de bezorgapp. Die zijn te bouwen, maar ze beantwoorden geen vraag die je op dag één hebt. Ze kosten alleen tijd die je nodig hebt om te ontdekken of mensen dit überhaupt willen.