Probleem
Eén maat voor alles
Brunch, lunch en diner hadden dezelfde reservatieduur — niet realistisch voor hoe een restaurant werkt.
Resultaat
Flexibel per moment
Beheerders kunnen per dag of tijdstip een andere reservatieduur instellen — zonder technische workarounds.
Compatibiliteit
Zonder breuk
Bestaande reservaties en instellingen bleven intact tijdens de overstap naar het nieuwe systeem.
Probleem
Eén vaste reservatieduur forceerde een restaurant in een te simpel model
Een vaste TijdslotDuur werkte alleen zolang elk moment van de dag ongeveer hetzelfde aanvoelde. Maar een brunch van 90 minuten, een lunch van 120 minuten en een diner van 180 minuten vragen niet dezelfde reserveringslogica.
Praktisch gevolg
- Te weinig flexibiliteit voor verschillende serviceblokken.
- Handmatige workarounds in de instellingen.
- Verwarring zodra bepaalde dagen of uren anders moesten werken dan de standaard.
Analyse
Het model moest meerdere lagen van werkelijkheid kunnen dragen
Restaurants denken niet in één uniforme reservatieduur, maar in serviceblokken met verschillende ritmes.
Een brunch van 90 minuten en een diner van 180 minuten mogen niet door hetzelfde model geforceerd worden.
Met één globaal veld ontstonden handmatige workarounds en verwarring zodra dagen of uren afweken van de standaard.
Het echte probleem zat niet in de UI, maar in het onderliggende model dat te weinig lagen kende.
Restaurants denken in lagen: een globale standaard, afwijkingen per dag en uitzonderingen per tijdstip. Zodra je dat patroon herkent, is één enkel veld simpelweg te beperkt als beslissingsmodel.
Oplossing
De vaste duur blijft bestaan, maar niet langer als enige waarheid
We hebben de vaste duur niet verwijderd, maar in een hiërarchie geplaatst. De volgorde is bewust ontworpen: tijd override eerst, dan dag override, daarna pas de globale standaard.
Prioriteit in de UI
<ol class="mb-0 ps-3">
<li><strong>Tijd Override</strong> - Hoogste prioriteit (bijv. na 21:00 = geen eindtijd)</li>
<li><strong>Dag Override</strong> - Middel prioriteit (bijv. zondag = 90 minuten)</li>
<li><strong>Globale Standaard</strong> - Laagste prioriteit (TijdslotDuur hierboven)</li>
</ol>Servicecontract
public interface ITijdslotService
{
Task<int?> GetTijdslotDuurAsync(string restaurantId, DateTime reservatieTijd);
Task<TijdslotDagOverride> CreateDagOverrideAsync(int instellingId, int weekdag, int? duurMinuten, string omschrijving = null);
Task<TijdslotTijdOverride> CreateTijdOverrideAsync(int instellingId, int vanUur, int vanMinuut, int? totUur, int? totMinuut, int? duurMinuten, string omschrijving = null, int[] alleenOpDagen = null);
}Beslissingsstructuur
Override-hiërarchie in drie lagen
De duur wordt steeds opgelost via de meest specifieke beschikbare regel.
1
TijdOverride
Specifiek tijdslot op specifieke datum — hoogste prioriteit
↓ anders
2
DagOverride
Afwijkende duur voor een specifieke weekdag
↓ anders
3
Globale TijdslotDuur
Vaste standaard als terugvalwaarde
tijdOverride ?? dagOverride ?? globaalDefault
Trade-off
Meer configuratie, maar ook veel eerlijker gedrag
Waarom deze keuze werkt
Het model past beter bij lunch, diner en late service, en voorkomt dat uitzonderingscode zich verspreidt door de rest van de applicatie.
Wat het kost
Meer configuratie in de UI, meer logica rond prioriteit en een grotere kans op foutieve instellingen als de beheerinterface niet duidelijk genoeg is.
Legacy compatibiliteit
Nieuwe logica zonder historische reservaties te breken
De beschikbaarheidslogica houdt een fallback voor oudere reservaties zonder eindtijd. Dat was noodzakelijk, omdat legacy data anders precies de nieuwe flexibiliteit zou ondermijnen.
Fallback snippet
if (reservation.Tot.HasValue)
{
reservationEnd = reservation.Tot.Value;
}
else
{
var duurMinuten = await _tijdslotService.GetTijdslotDuurAsync(
restaurantId,
reservation.Van);
reservationEnd = duurMinuten.HasValue
? reservation.Van.AddMinutes(duurMinuten.Value)
: reservation.Van.AddHours(3);
}Resultaat
Functionele winst in plaats van cosmetische winst
Instellingen sluiten beter aan op de realiteit van lunch, diner en late service.
Beheerders kunnen per dag of per tijdstip afwijken van de standaard zonder extra uitzonderingscode elders.
Oude reservaties zonder eindtijd blijven correct interpreteerbaar dankzij de fallback.
De UI toont de prioriteit expliciet, waardoor het systeem ook beter uitlegbaar wordt aan eindgebruikers.
Lessons learned
Maak reservatieduur niet harder dan de business zelf
Behoud altijd een globale standaard als laatste fallback.
Maak prioriteit expliciet: tijd boven dag boven standaard.
Test legacy records zonder eindtijd mee in je nieuwe model.
Laat de UI de hiërarchie zichtbaar maken in plaats van ze te verbergen in implicit gedrag.
Voorkom configuratie-overload door duidelijke uitleg en begrensde complexiteit.
Takeaway
Een vaste TijdslotDuur volstaat alleen voor simpele scenario’s
Zodra een restaurant anders werkt per dag of per uur, is een hiërarchisch tijdslotsysteem de betere keuze. Niet omdat het slimmer klinkt, maar omdat het eerlijker aansluit op hoe de business echt functioneert.
Veelgestelde vragen
Waarom volstaat één vaste TijdslotDuur niet meer?
Omdat restaurants verschillende serviceblokken hebben met andere verwachtingen rond verblijfsduur. Eén vaste waarde dwingt je dan tot compromissen of uitzonderingen die elders in het systeem beginnen lekken.
Waarom is de hiërarchie tijd > dag > standaard logisch?
Omdat een specifieker signaal zwaarder moet doorwegen dan een generieker signaal. Een exacte tijdsregel moet een dagregel kunnen oversturen, en een dagregel moet de globale standaard kunnen verfijnen.
Waarom is die fallback voor oude reservaties zo belangrijk?
Zonder die fallback zou legacy data de nieuwe logica breken. Zodra oudere records geen eindtijd hebben, moet je de duur nog steeds kunnen afleiden via dezelfde hiërarchie of een veilige standaard.
Is dit systeem niet te complex voor elk restaurant?
Jawel. Voor een heel eenvoudige setup met één vast ritme is dit meestal te veel. Maar zodra serviceblokken echt verschillen per dag of uur, is dit veel eerlijker en onderhoudbaarder dan blijven stapelen op één vaste duur.
