Automatic acceptance fits a delivery channel when the restaurant can reliably prepare the orders it receives, the channel’s hours and menu match the kitchen’s operation, and someone owns the exceptions. If staff routinely need to reject orders or adjust timing during a rush, keep acceptance manual until you have a dependable way to control that demand.
The setting deserves a separate decision for each location and channel. An order can be accepted on a marketplace before it reaches the POS or kitchen screen. Ask exactly when the customer receives confirmation, what the kitchen sees, and what staff can do if the restaurant cannot fulfill the order.
Compare acceptance by channel and location
Start with a list of every delivery source at each restaurant: marketplace accounts, direct ordering, and any orders staff enter manually. Note which device or screen receives each order and whether an integration sends it to the POS. A single brand can have different hours, menus, and staffing at two locations, so avoid making one policy for the whole business by default.
Manual acceptance gives an employee a chance to review an incoming order before committing. That can help when items run out or capacity changes quickly. It also creates a task that can be missed when the counter is busy. Automatic acceptance removes that review step, but someone still needs to monitor incoming work and act when something goes wrong.
Use the following matrix as a starting point. The recommended setting depends on the assumptions in each row, not on the channel name alone. Confirm which actions are actually available in the channel and POS combination before adopting the rule.
| Situation | Starting decision | Exception owner | Next action |
|---|---|---|---|
| Stable hours and menu; kitchen has spare delivery capacity | Consider auto-accept | Shift lead | Monitor order volume and pause or switch to manual if the available controls allow it |
| Rush demand regularly exceeds kitchen capacity | Keep manual acceptance until a reliable capacity control is agreed | Manager on duty | Review timing and channel controls before changing the setting |
| Store is closed or temporarily unable to cook | Pause or close the channel using its supported process | Opening or closing lead | Verify the channel is no longer taking orders and escalate any order received |
| Order cannot be fulfilled after acceptance | Follow the channel’s supported exception process | Manager on duty | Resolve the order through the appropriate channel; record the outcome |
For example, a marketplace may offer a pause control while a POS connection sends orders onward. Do not assume that pausing one screen pauses every source, or that a rejection in the POS automatically updates the marketplace. Put the actual steps beside each channel in the shift instructions.
Compare the paths, not just the number of tablets. Fleksa’s restaurant integrations directory distinguishes live connections from connections available on request. Otter describes a tablet-based Order Manager that consolidates online and manual orders, with automatic acceptance, printing, and POS connections. For either approach, ask what happens for your exact channel, location, and POS. A guide to direct POS integration and middleware can help you assess the connection itself.
Match acceptance to kitchen capacity and hours
An accepted order is a promise to do work. Before turning on automatic acceptance, decide how much delivery work the kitchen can absorb alongside dine-in, pickup, and other orders. Look at the busiest periods, not just an average day. A small order with several customizations can take more attention than its item count suggests.
Hypothetical capacity example: During a 15-minute rush window, a kitchen estimates it can prepare 12 comparable meals without disrupting its timing. It expects six dine-in meals and two pickup meals in that window. That leaves capacity for four comparable delivery meals. This is a planning estimate, not a guarantee: unusually complex orders or a staff absence can reduce the remainder.
Under those assumptions, auto-accept is reasonable only if the restaurant has a practical way to keep incoming delivery work within that remaining capacity. If the channel cannot limit demand or be paused quickly enough, use manual acceptance for that period. Confirm whether preparation times can be changed, who can change them, and whether a change affects new orders, existing orders, or both. Longer quoted times may help communicate a delay, but they do not by themselves stop orders from arriving.
Check the boundaries of the day as carefully as the rush. Does the delivery channel stop accepting orders at the kitchen’s actual cutoff, or at the dining room’s closing time? How are scheduled orders handled if they are placed while the restaurant is closed? Who checks special hours and reopens a paused channel? Ask the vendor to demonstrate the behavior for each combination you plan to use.
Also separate supported actions from work staff must perform elsewhere. If an item sells out, ask whether it can be marked unavailable from the POS, from a channel dashboard, or only by another process. If it must be changed in several places, assign that task before the shift gets busy. The same applies to pausing a store and changing its hours.
Simulate the exceptions before a live pilot
Ask the vendor to walk through the order path with your actual configuration: source channel, location, POS, and kitchen output. A simulation should not charge a card, send a guest message, or dispatch a courier. Use a safe test environment or a clearly hypothetical walkthrough if those effects cannot be prevented. Never use private customer data for the exercise.
- Normal order: Give the simulated order a unique test identifier. Match it from the source to the POS and kitchen result. Check the items, modifiers, totals, acceptance status, and timing shown at each step.
- Surge: Walk through what the shift lead does when incoming work exceeds capacity. Show where preparation time can be changed or the channel paused, and what happens to orders already accepted.
- Paused store: Simulate a pause or closure and check whether a new order can still enter. Identify which screen shows the status and who confirms it.
- Rejected or unfulfillable order: Show how staff handle an order they cannot make. Establish whether rejection, cancellation, or another action is supported at each point, and how the channel and kitchen are updated.
Record the expected result and the result shown in the simulation, including any manual step. If an action is unsupported, write down the alternative and its owner rather than assuming the integration will handle it. For example, if staff must use a marketplace dashboard to resolve an accepted order, note who has access and where the instructions are kept.
A live service pilot is different from practice. Once the simulated checks are satisfactory, a manager can choose a limited service period and monitor real orders under the restaurant’s normal procedures. Tell staff which channels are included, who is watching them, and when the team will return to manual acceptance if the available controls permit it. Do not treat a successful simulation as proof that every rush will go smoothly.
Set the rule and name the escalation owner
Write a short policy that a new shift lead can use without interpreting a vendor brochure. It should name the location, channel, hours, acceptance setting, capacity trigger, and person authorized to change the setting or pause the channel. Include the fallback when a control is unavailable.
A useful rule might read: “Use automatic acceptance for this channel during the staffed delivery window. The shift lead watches incoming orders. If the kitchen cannot take more work, the lead uses the channel’s confirmed pause process and tells the manager. If the pause cannot be confirmed, the manager follows the channel’s support process.” Replace that wording with the steps your team has actually established.
Give missed exceptions a path to a person, not just a dashboard. The shift lead can monitor the order queue; the manager on duty can resolve an unfulfillable order or contact channel support; the owner or integration administrator can investigate a recurring configuration problem after service. Name a backup for each role. At shift change, hand over paused channels, unavailable items, and orders still awaiting resolution.
Review the rule after a busy service or menu change. Count the manual interventions your team recorded and ask whether they were manageable. Frequent pauses, uncertain order status, or repeated unfulfillable orders are reasons to reconsider the setting. A channel can remain manual while another uses automatic acceptance; the goal is a reliable commitment to each guest, not uniform settings.
Bring your location and channel list, POS details, and these test cases to a Fleksa demo. Ask which connections and exception actions are available for your setup, then agree on the next decision with your manager. Start with the Fleksa restaurant POS system or check the Uber Eats integration for a relevant channel.
Frequently asked questions
Does auto-accept mean the order reached the kitchen?
Not necessarily. Acceptance and delivery to the POS or kitchen are separate events. Match a simulated source order to the kitchen result and decide who investigates if the expected result does not appear.
Can a restaurant turn off auto-accept during a rush?
That depends on the channel and setup. Ask where the setting is controlled, who has access, and whether the change affects orders already accepted. Document an alternative if the setting cannot be changed quickly.
Who handles an order the restaurant cannot fulfill?
Assign the manager on duty or another named person to use the channel’s supported resolution process. Confirm how the order status is updated and how kitchen staff learn the outcome.
