Wait Time Management Service

The Wait Time Management service is a feature that holds an order and fires it into the POS based on certain set rule.

The intent of this feature is to provide a way to manage orders at high traffic (e.g. store opening) so to not overwhelm the kitchen.

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

Store Locator	Cart Confirmation	Store Confirmation
Open	Open

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

How this works is that each Mobile Order is given a fixed Processing Time defined in the Restaurant document above. Every time the Wait Time Service receives an order, it estimates, based on past orders, if the kitchen is busy. If it is busy, the service holds the order in a queue to be inserted to the POS later. Else, it inserts the order immediately, and increase the busyness of the kitchen.

We measure kitchen “busyness” by checking recent orders being made to the kitchen. Since each order has a Processing Time we can estimate at any point in time, the Time to Clear Kitchen (TCK). This is the time needed for the kitchen to complete all mobile orders. We consider a kitchen to be busy when the next order Processing Time + TCK is larger than the Busy Kitchen Threshold set above; in other words, the kitchen is busy when we cannot squeeze another order without TCK exceeding the Busy Kitchen Threshold.

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 cleared. 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

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.

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.

Note that as time passes, the estimated TCK ticks down.

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.