Track an accepted order as a fulfillment incident when your restaurant cannot provide it substantially as accepted and must cancel it or agree on a significant change. Give each incident one primary cause, record its final outcome, and assign someone to check that the guest and payment issues are resolved.
That definition keeps the analysis narrower than a list of every cancellation. A guest who changes their mind is useful to record, but that order belongs in a separate category unless the restaurant’s inability to fulfill it prompted the cancellation. The goal is to see where the promise made at checkout differed from what the restaurant could actually deliver.
Classify stock, capacity, and address causes
Start with the order as accepted: its items, quantities, promised time or window, fulfillment method, delivery address if relevant, and any special instructions. Then record what made the original order impractical. Use the same categories across direct orders and marketplace orders, even if the information comes from different screens.
- Stock: An ingredient, menu item, or required packaging was unavailable. Note whether staff knew about the shortage before acceptance and whether a substitute was possible.
- Capacity: The kitchen, pickup process, or delivery arrangement could not handle the order within a workable time. Record whether the issue was equipment, staffing, order volume, or another constraint.
- Address: The delivery location was outside the service area, incomplete, inaccessible, or otherwise unsuitable for the available delivery arrangement. An address question that staff quickly clarify without changing fulfillment need not become an incident.
- Other fulfillment issue: Use this for a cause that does not fit the three categories, such as a menu configuration error. Describe it rather than forcing it into the wrong bucket.
Choose the primary cause that first made the accepted order impossible to fulfill as promised. Add a contributing cause if needed. For example, a missing ingredient may be the primary cause while a menu item left available online is a contributing cause. This prevents one order from being counted twice in the main cause totals.
The person who discovered the problem supplies the initial facts. A shift lead checks the classification and outcome; the owner reviews patterns. If a delivery partner or ordering channel supplies part of the explanation, record who reported it and mark uncertain details as unconfirmed. A short note is more useful than an invented reason.
Compare accepted orders with resolved outcomes
Set a reporting period and count all accepted orders from the same channels in that period. Then count fulfillment incidents within that group. An order received but rejected before acceptance is a separate operational measure. So is a cancellation requested by the guest for a reason unrelated to fulfillment.
For a hypothetical week, assume a restaurant accepted 100 online orders. Staff could fulfill 93 as accepted. Seven became fulfillment incidents: four were canceled and three went ahead with a substantial change agreed with the guest. All seven have a known final outcome. The table shows how the incident count and cause count fit together.
| Primary cause | Canceled | Changed and fulfilled | Total incidents |
|---|---|---|---|
| Stock | 2 | 2 | 4 |
| Capacity | 1 | 1 | 2 |
| Address | 1 | 0 | 1 |
| Total | 4 | 3 | 7 |
The fulfillment incident rate is 7 out of 100 accepted orders, or 7%. The cancellation portion is 4%; the substantial-change portion is 3%. These are order counts, not measures of revenue, refunds, or the number of items affected. A changed order should appear once, even if several items were substituted.
Define a substantial change before using the log. A replacement for a main item, a material delay the guest must accept, or a change from delivery to pickup can qualify. A routine clarification that leaves the order and promised service intact usually does not. Apply the rule consistently and make a note when the choice is borderline.
Keep unresolved orders visible rather than guessing their final outcome. If you review a week before every incident is closed, show the open count separately and update the totals when outcomes are known. Also check whether a platform report uses the same meaning of accepted, canceled, and completed before comparing it with your own log.
The trade-off matters: offering a substitute may preserve a meal, but it still requires guest agreement and staff time. A cancellation may be the right outcome when no acceptable alternative exists. Tracking both shows the workload that a cancellation-only report misses.
Record guest contact and refunds
For each incident, record who owns the next action, when contact was attempted, the channel used, and whether the guest agreed to a change or the order was canceled. Keep the note factual: “called; guest agreed to later pickup” is more useful than “guest satisfied.” Follow your restaurant’s rules for access to guest details and avoid copying more personal information than staff need.
Record payment status separately from the order outcome. A canceled order can have a refund pending; a changed order can require a price adjustment. Note the amount to be adjusted, the amount actually processed, the responsible person, and the date or status of confirmation. A requested refund is not the same as a completed refund, and a refund is not the same as a lost sale.
For a practice scenario, imagine a guest ordered a meal containing an unavailable item. A staff member selects “stock,” proposes a replacement, and records that the guest agrees. If the replacement has a different price, the practice record should show the required adjustment and who would confirm it. The scenario can check whether the log captures the decision; it cannot establish that a live payment or guest contact worked.
Run that practice with sample data and simulated actions only. Do not send a guest message, process a real card payment, or dispatch a courier. If you later run a live service pilot, use actual orders under normal operating procedures and check real outcomes separately. Ask each provider how staff can see payment and refund status, what appears in reports, and which actions must be completed in another system.
Use an incident log to prevent recurrence
A spreadsheet or shared shift log can work if staff can update it promptly and a lead reviews it. Give every incident an order reference and one row. Include acceptance time, channel, fulfillment method, primary and contributing causes, discovery time, agreed change or cancellation, contact status, payment status, owner, and closure date. Add a short prevention note once the cause is understood.
At the end of each shift, the lead should check open guest and payment actions. At a regular owner review, group closed incidents by primary cause, time of day, channel, and menu item. Look at both frequency and disruption: one recurring sold-out item may be easy to fix, while a less frequent address problem may consume a long delivery window and several staff calls.
In the hypothetical week above, stock accounts for four of seven incidents, so checking item availability and the process for removing unavailable items is a sensible first investigation. That count alone does not prove which change will work. Ask when staff learned an item was unavailable, who could update each ordering channel, and how long the update took to reach the menu. Compare the next reporting period using the same definitions.
For capacity incidents, compare acceptance times with kitchen workload and the promised windows. Decide who can pause or limit incoming orders when the operation is stretched, and ask each provider what controls are available. For address incidents, review where the location failed: checkout entry, service-area rules, access instructions, or delivery handoff. Ask whether staff can review and correct those points before acceptance.
Do not treat a lower incident count as proof of improvement if accepted volume also fell. Compare incidents with accepted orders, and read the notes for changes in severity. Keep the raw count too: a busy shift with a modest rate can still create more guest calls than the team can handle.
If you are reviewing the ordering setup behind the log, the online ordering buying guide covers broader selection questions. Also check how a restaurant website presents the menu and delivery information, and use the direct and marketplace order comparison when reviewing channels beyond fulfillment incidents.
Next step: Review the last week of accepted orders using the definitions above. Assign a lead to close open incidents, then ask Fleksa about restaurant online ordering, the reporting and controls you need, and verified US availability for your setup.
Frequently asked questions
Should every canceled order go in the fulfillment incident log?
No. Include cancellations caused by the restaurant’s inability to fulfill an accepted order. Track unrelated guest-requested cancellations separately so they do not obscure operational causes.
What if an order has more than one cause?
Choose one primary cause for counting and record the others as contributing causes. Review uncertain cases with the shift lead rather than counting the same order in multiple categories.
When should an incident be closed?
Close it when the final order outcome is known and the assigned guest-contact and payment actions have been confirmed or handed off under your restaurant’s process. Keep pending refunds visible until their status is verified.
