As mentioned in #27, we're working on implementing the ability to temporarily pause orders from coming in. We could turn this on right away with a simple switch, but we're taking our time with it. Currently, order processing is enabled when two things are true: 1) the business is currently open according to its hours and 2) the menu is currently available, which is basically another set of hours particular to just a menu (a feature designed to be used for places with breakfast-only menus, for instance).
Pausing orders manually has a couple of potentially dangerous side effects.
Unavoidable visual alerts— We need manually pausing orders to have an extremely obvious visual indicator that orders have been paused. We actually want this to be site-wide instead of just on the dashboard, because if an employee navigates away from the processor after pausing it, they need to know that they've effectively stopped orders coming in for the restaurant.
Clear consequences— since the order processor will likely be operated by an employee, we need the employee to be trained and understand that pausing orders REALLY pauses orders, i.e. it should not be done casually while they're feeling overwhelmed. That means we need several other indicators and clear explanations of that consequence before we enable the feature, so we don't inadvertently foster friction between business owners and their employees.
Orders that are partially made— Before orders are transacted, they can be in a variety of states. Right now, we stop the process at a few points that are dependent on time. If a menu is unavailable (or becomes unavailable while ordering) you are prevented from adding that item to your order. If an order is in your basket but the business closes before you pay, the checkout process is halted (the button appears disabled with the message "business closed") So, both of these stopping points, from the customer's perspective, are predictable because they're related to hours that are displayed to them ahead of time. The question is, what happens when a business manually stops taking orders while a customer is making that order? My intuition is the customer will be frustrated, which nobody wants, especially not the business. So we'd like the business to be able provide some kind of message as context for why they've paused ordering. That is technically challenging, because users are not subscribed to receive message from restaurants just because they're in the process of ordering from them. So ideally, we'd like the message to appear only at checkout, but disappear in real-time when the restaurant re-enables ordering.
The backup to this feature right now is simply human contact. If orders come in while the restaurant is not taking them for some reason, restaurants can handle cancelling them over the phone. If they've closed for the day, they can change their hours. That would work better from a customer service perspective than a not-fully-fleshed-out solution from the platform at this point.
So, we're going to implement this, definitely, probably fairly soon. But it involves several safeguards being designed and implemented before it is ready to be enabled for end users. We'll update this issue as we implement them.
As mentioned in #27, we're working on implementing the ability to temporarily pause orders from coming in. We could turn this on right away with a simple switch, but we're taking our time with it. Currently, order processing is enabled when two things are true: 1) the business is currently open according to its hours and 2) the menu is currently available, which is basically another set of hours particular to just a menu (a feature designed to be used for places with breakfast-only menus, for instance).
Pausing orders manually has a couple of potentially dangerous side effects.
Unavoidable visual alerts— We need manually pausing orders to have an extremely obvious visual indicator that orders have been paused. We actually want this to be site-wide instead of just on the dashboard, because if an employee navigates away from the processor after pausing it, they need to know that they've effectively stopped orders coming in for the restaurant.
Clear consequences— since the order processor will likely be operated by an employee, we need the employee to be trained and understand that pausing orders REALLY pauses orders, i.e. it should not be done casually while they're feeling overwhelmed. That means we need several other indicators and clear explanations of that consequence before we enable the feature, so we don't inadvertently foster friction between business owners and their employees.
Orders that are partially made— Before orders are transacted, they can be in a variety of states. Right now, we stop the process at a few points that are dependent on time. If a menu is unavailable (or becomes unavailable while ordering) you are prevented from adding that item to your order. If an order is in your basket but the business closes before you pay, the checkout process is halted (the button appears disabled with the message "business closed") So, both of these stopping points, from the customer's perspective, are predictable because they're related to hours that are displayed to them ahead of time. The question is, what happens when a business manually stops taking orders while a customer is making that order? My intuition is the customer will be frustrated, which nobody wants, especially not the business. So we'd like the business to be able provide some kind of message as context for why they've paused ordering. That is technically challenging, because users are not subscribed to receive message from restaurants just because they're in the process of ordering from them. So ideally, we'd like the message to appear only at checkout, but disappear in real-time when the restaurant re-enables ordering.
The backup to this feature right now is simply human contact. If orders come in while the restaurant is not taking them for some reason, restaurants can handle cancelling them over the phone. If they've closed for the day, they can change their hours. That would work better from a customer service perspective than a not-fully-fleshed-out solution from the platform at this point.
So, we're going to implement this, definitely, probably fairly soon. But it involves several safeguards being designed and implemented before it is ready to be enabled for end users. We'll update this issue as we implement them.