Pacing first. Without it the whole thing overbooks and we cannot use it at all.
Bookings today handle the resource-based case well: a person, a chair, a room, with service duration and buffers. A restaurant is a different shape and we want to get it right rather than approximate it.
Two things a restaurant needs that do not exist yet.
Pacing. A kitchen cannot seat thirty covers in the same fifteen minutes even when tables are free. The industry answer is a cap per time bucket, both covers and parties, so availability reflects what the kitchen can actually deliver.
A waitlist. When a slot is full, taking a name and offering it the moment something opens is worth more than showing nothing.
There is also table joining, where two small tables become one booking, and seating duration that varies by party size.
What we would like to know before building: is pacing the blocker, or is it the waitlist? They are separable and we would rather ship the one that matters first than both badly.
If you run a restaurant or a venue, what does your current system do that ChatinFlow would need to match on day one? Concrete answers help more than feature names.
2 คำตอบ
Waitlist for us. We are small enough that pacing is not the issue. ---
เข้าสู่ระบบเพื่อตอบและบันทึกฉบับร่างของคุณ