> For the complete documentation index, see [llms.txt](https://www.oddle.me/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.oddle.me/docs/new-guests/shop/processing-orders.md).

# Processing Orders

Every order on Oddle Shop moves through a series of stages — from the moment a guest places it to when it's delivered or collected. Understanding the order lifecycle helps your team process orders efficiently and keep guests informed.

Your team manages orders on the **Register App** — a Sunmi device that Oddle provides, pre-installed and ready to go. Connect it to Wi-Fi and your team can start processing orders.

***

## The Order Lifecycle

Here's the typical flow an order goes through:

### Pending

A new order has just been placed. The Register alerts your team with a sound notification. The order shows the items, quantities, variations, option groups, delivery or takeaway details, and any special instructions.

Your team needs to **confirm** the order. You can also choose to send an email notification to the guest when confirming. If the order can't be fulfilled (e.g., a key ingredient is unavailable), your team can void it instead.

{% hint style="warning" %}
Don't leave orders sitting in "Pending" status. Guests expect a quick response, and a long wait before confirmation creates a poor experience. Aim to confirm orders within a few minutes.
{% endhint %}

### Confirmed

The order has been confirmed and the kitchen starts preparing. For delivery orders with managed logistics, this is when Oddle's system begins coordinating a rider. You can also send an order summary email to the guest from this screen.

### Delivered

Your team marks the order as "Delivered" once the guest has received their food — whether that's a rider handing off a delivery or a guest collecting a takeaway order. For delivery, the guest can track rider progress in real time via the tracking link.

***

## Batch Operations

During a busy service, you can confirm or update multiple orders at once. Select multiple orders using the checkboxes, then choose the status to apply to all of them. This saves time when several orders come in at the same time.

***

## Payment Status

For online orders, payment status is updated automatically once payment is received. If you need to send a guest an online payment link (e.g., the guest hasn't completed payment), you can do this from the order detail screen.

For offline payments (e.g., cash on collection), you'll need to manually update the payment status and payment method on the order. Every action is logged in the **order log** at the bottom of the order summary, along with the user who made the change and the timestamp.

***

## Creating Orders Manually

If a guest calls or emails to place an order, your team can create an order manually — either from Merchant Admin or directly on the Register. This is useful for phone orders, catering requests, or any order that doesn't come through the webstore.

Manual orders follow the same lifecycle as webstore orders once created.

***

## Adjusting During Service

Things change during a busy service. The Register gives your team tools to adapt:

**Extending preparation time** — If the kitchen is backed up, extend the estimated prep time. This pushes back rider dispatch for delivery orders and updates the guest's expected time.

**Pausing orders** — If you're overwhelmed, temporarily pause new orders on your webstore. Guests will see that you're currently not accepting orders. Resume when you're ready.

**Marking items as unavailable** — If you run out of something mid-service, mark the item as unavailable directly from the Register. It's immediately hidden from your webstore.

***

## Viewing Order Records

While the Register is where your team processes orders in real time, **Merchant Admin** is where you review order history. You can view all online order records — including order details, status, guest information, and payment — from the orders section in Merchant Admin.

This is useful for resolving guest enquiries, checking order history for a specific date, or reviewing order volumes and trends. Managers and owners who aren't on the floor can keep visibility into operations without needing access to the Register.

***

## Refunds & Cancellations

Sometimes orders need to be cancelled or refunded. Common scenarios:

**Guest requests cancellation** — If a guest contacts you before the order is prepared, you can void the order. Note that voiding an order does not automatically refund payment — you'll need to process the refund separately.

**Item unavailable after confirmation** — If you confirmed an order but discover an item is unavailable, contact the guest to offer an alternative or partial refund. If the guest prefers to cancel, void the order and process a refund.

**Delivery issue** — If a delivery fails (wrong address, guest unreachable), your team manages the resolution — re-delivery, partial refund, or full refund depending on the situation.

**Quality issue** — If a guest reports a problem with their order (missing items, wrong items), you can issue a partial or full refund.

Refunds are processed through Merchant Admin. Refunded amounts are deducted from your next payout cycle.

{% hint style="info" %}
Responding quickly and generously to order issues builds guest trust. A guest who has a problem resolved well is often more loyal than one who never had an issue at all.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.oddle.me/docs/new-guests/shop/processing-orders.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
