Een WooCommerce-bezorgdatum moet gebaseerd zijn op wat de operatie werkelijk kan uitvoeren. Alleen een kalender tonen en enkele weekdagen uitschakelen is niet genoeg. Beschikbaarheid hangt mogelijk af van postcodegebied, route, dagcapaciteit, tijdslot, cut-off, afhaalcapaciteit en reeds geplaatste of tijdelijk gereserveerde bestellingen.
De kalender is dus de laatste stap van een planningsbeslissing, niet de bron ervan.
Van datumveld naar leverbelofte
Wanneer een klant een datum kiest, ontstaat een verwachting die door webshop, administratie, magazijn, planning en klantenservice moet worden gedeeld. Het gekozen moment moet daarom als een herkenbaar onderdeel van de order worden opgeslagen en naar de betrokken systemen meegaan.
Een goed model onderscheidt:
- de gekozen lever- of afhaaldatum;
- een tijdvenster, als de operatie daarmee werkt;
- de logistieke zone of route waarop de keuze is gebaseerd;
- de status van de reservering vóór en na betaling;
- latere wijzigingen en wie die heeft uitgevoerd.
Een losse tekst in een ordernotitie is daarvoor te zwak. Gebruik gestructureerde ordergegevens die ook via de WooCommerce-API beschikbaar zijn.
Bereken beschikbaarheid met bedrijfsregels
Start bij het afleveradres. Een postcode kan bepalen op welke weekdagen een route een gebied bedient. Daarna vallen gesloten dagen en dagen na de bestellimiet af. Vervolgens controleert het systeem of de dag of het tijdslot nog capaciteit heeft.
Een vereenvoudigde volgorde is:
- normaliseer en valideer het land en de postcode;
- bepaal de passende bezorgzone en toegestane weekdagen;
- pas minimale voorbereidingstijd en dagelijkse cut-off toe;
- sluit handmatig geblokkeerde dagen uit;
- trek definitieve boekingen en actieve tijdelijke reserveringen af;
- toon alleen momenten die op dat moment boekbaar zijn.
Bij afhalen gelden vaak andere regels. Een locatie kan vaste tijdvakken hebben, met eigen capaciteit en sluitingsmoment. Meng bezorg- en afhaalregels daarom niet in één algemeen datumveld.
Reserveer capaciteit tijdens checkout
Twee klanten kunnen vrijwel tegelijk het laatste beschikbare moment selecteren. Als capaciteit pas na betaling wordt gecontroleerd, kunnen beiden dezelfde plek beloofd krijgen. Maak daarom een kortdurende reservering wanneer de klant een moment kiest.
Zo’n hold moet gekoppeld zijn aan de checkout, meetellen in de capaciteit en automatisch verlopen wanneer de aankoop niet wordt afgerond. Wijzigt de klant het moment, dan wordt de oude reservering vrijgegeven of vervangen. De definitieve order neemt de plaats vervolgens gecontroleerd over.
Gelijktijdigheid moet op de server worden afgevangen; een controle in de browser is onvoldoende. De server beslist uiteindelijk of capaciteit beschikbaar is.
Ontwerp een veilige fallback
Een planningsdienst kan tijdelijk niet beschikbaar zijn. Bepaal vooraf wat checkout dan doet. Volledig blokkeren voorkomt een ongeldige belofte, maar kan ook iedere verkoop stoppen. Een fail-open-proces kan de bestelling aannemen met duidelijke melding dat het bezorgmoment handmatig wordt bevestigd.
Welke keuze passend is, hangt af van product, leverbelofte en operationele ruimte. Cruciaal is dat de fallback zichtbaar wordt als taak. Een order zonder definitief moment mag niet stil tussen normale orders terechtkomen.
Laat wijzigingen dezelfde regels volgen
Een klant of medewerker die na aankoop de datum verandert, moet opnieuw door capaciteit, zone en cut-off worden gecontroleerd. Een adreswijziging kan een andere route of bezorgdag vereisen. Trek daarom niet alleen een nieuw adres over de bestaande planning heen.
Bewaar de eerdere en nieuwe keuze, controleer of de order nog gewijzigd mag worden en werk alle betrokken representaties samen bij. Voorkom dat een update vanuit planning daarna als webhook-echo opnieuw dezelfde actie start.
Test meer dan de kalender
- Een postcode op de grens tussen twee zones.
- Het laatste tijdslot door twee gelijktijdige checkouts.
- Een klant die meerdere keren van datum wisselt.
- Een verlaten checkout waarvan de reservering moet verlopen.
- Een order rond het moment waarop de cut-off ingaat.
- Een gewijzigde verzendmethode van bezorgen naar afhalen.
- Een tijdelijk onbereikbare planningsdienst.
- Een adreswijziging naar een andere logistieke zone.
Maak planning uitlegbaar
Klanten hoeven de volledige berekening niet te zien, maar een begrijpelijke reden helpt. “Niet beschikbaar voor dit postcodegebied” of “dit tijdslot is vol” is beter dan een grijze datum zonder uitleg. Ook klantenservice moet kunnen zien waarom een moment wel of niet gekozen kon worden.
De ForaVida-case laat zien hoe webshop, AFAS en routeplanning in één proces worden verbonden. Op Yindle Connect staat hoe validatie en distributie tussen zulke systemen worden ingericht. Voor de algemene architectuur verwijzen we naar webshop en ERP betrouwbaar koppelen.
Veelgestelde vragen over levermomenten
Moet de kalender zelf alle capaciteit kennen?
Nee. De browser vraagt beschikbare momenten op en presenteert ze, maar de server berekent en bevestigt de afspraak. Daarmee blijft dezelfde regel gelden voor checkout, klantenservice en een eventuele andere verkoopinterface. Een gemanipuleerd verzoek kan de capaciteitscontrole niet overslaan.
Wat gebeurt er met een moment bij mislukte betaling?
Laat de tijdelijke reservering niet direct permanent worden, maar houd haar lang genoeg vast voor een normale terugkeer uit de betaalstroom. Bij annulering of verlopen checkout komt capaciteit gecontroleerd vrij. Koppel de uiteindelijke reservering aan de bevestigde orderstatus die in jouw proces als acceptatie geldt.
Hoe ga je om met feestdagen en uitzonderingen?
Gebruik naast terugkerende weekdagregels een beheerbare kalender voor gesloten of afwijkende dagen. Een beheerder moet de reden en scope kunnen vastleggen zonder codewijziging. Controleer bestaande boekingen voordat een dag wordt gesloten en maak getroffen orders als taken zichtbaar.
Monitor de kwaliteit van de leverbelofte
Volg niet alleen hoeveel slots gevuld zijn. Kijk ook naar orders zonder bevestigd moment, verlopen holds, handmatige herplanning en verschillen tussen gekozen en uiteindelijk uitgevoerde dag. Gebruik die signalen om cut-offs, capaciteit of zone-inrichting te verbeteren, zonder besparingspercentages te beloven die niet zijn gemeten.
WooCommerce beschrijft in zijn documentatie over leverdatum en tijdslot de gangbare checkoutinteractie. Voor processen met externe planning en gedeelde capaciteit moet de onderliggende serverbeslissing aanvullend over alle betrokken systemen worden geborgd.
Wil je van een datumveld naar een uitvoerbare leverbelofte? Bespreek jouw capaciteit- en bezorgregels met Yindle.