The Wait Time Management service is a feature that holds an order and fires it into the POS based on certain set rule.
How does it look?
At several places through in order flow, we show warnings to tell users that a restaurant is “busy” and that they may need to wait in the queue if they still need to make an order.
Store Locator | Cart Confirmation | Store Confirmation |
|---|---|---|
 |  |  |
Suppose that the user still wants to make the order, they can do it according to the normal flow. But, at the last step, instead of getting the order confirmation directly, they will see the queue information page. This page will refresh every 30 seconds with the new position and estimated waiting time.
...
The user have the option to Exit Queue, which cancels their order and refunds their payment.
How to decide whether a restaurant is “Busy”?
Virtual Queue Strategy
At the time of writing, the only strategy we support now is the “Virtual Queue” strategy. This strategy is parameterised by two numerical values per Restaurant Document in Sanity, namely Processing Time and Busy Kitchen Threshold
...
At the time of writing, we don’t yet have visibility on orders made through channels other than the Mobile App. Hence, note that the Kitchen Capacity
Example
Here is an example to illustrate this point. Let’s assume the above Wait Time Parameters such that Processing Time = 180, and Busy Kitchen Threshold = 500.
Inserting into a Kitchen that is not processing any Mobile Order
Up to 10:30:00, the queue was empty and the kitchen is clear (off mobile orders). At 10:30:00 a user attempts to complete an order. Since the kitchen is not busy 0 + 180s < 500s, the order is inserted immediately. Notice that the
Order Timestamp | Action | Resulting Order Status | Resulting Kitchen State |
|---|---|---|---|
10:30:00 | User attempts to insert | Inserted immediately | queue: [] (i.e. empty) TCK: 180s |
10:30:30 | - | - | queue: [] TCK: 150s |
Inserting into a Kitchen that is processing Mobile Order, but have spare capacity
At 10:31:00, although the kitchen is estimated to still be processing order-1 (120s to go), the additional 180s still hasn’t hit the 500s Busyness Threshold. Hence, order-2 is still inserted immediately. The same goes with order-3 also inserted at 10:31:00.
Order Timestamp | Action | Resulting Order Status | Resulting Kitchen State |
|---|---|---|---|
10:31:00 | User attempts to insert | Inserted immediately | queue: [] TCK: 120s + 180s = 300s |
10:31:00 | User attempts to insert | Inserted immediately | queue: [] TCK: 480s |
Attempting insert into a busy kitchen
However, when a user attempts to insert order-4 180s + 480s is larger than the 500s limit, causing order-4 to be added to the queue. The same goes with order-5. Note that since the order is not ind the kitchen, TCK is not affected yet.
...
Order Timestamp | Action | Resulting Order Status | Resulting Kitchen State |
|---|---|---|---|
10:31:00 | User attempts to insert | Queued, since 180 + 480 > 500 | queue: TCK: 480s |
10:31:00 | User attempts to insert | Queued, since 180 + 480 > 500 | queue: TCK: 480s |
10:32:00 | - | - | queue: TCK: 420s |
10:33:00 | - | - | queue: TCK: 360s |
Inserting from Queue
At 10:33:40, finally TCK reaches 320s, which means that it can receive 180s and still be equal to 500s. In this case, the Service inserts the order-4 into the kitchen, and removes it from the queue. Same goes with order-5 at 10:36:40 , when the kitchen has “freed up” time to handle the next order in the queue.
...