Online order fulfillment
Keep online orders moving from intake to pickup or shipping.
Give the team one queue for customer, items, channel, fulfillment branch, reserved stock, recorded payment state, and allowed status changes—then keep the handoff accountable.
One queue from order to handoff
Keep online orders moving without losing payment or stock context.
LiftedPOS gives the team a visible queue for accepted online orders, their pickup or ship-to path, reserved stock, and allowed status changes. During scoped setup, we help configure the enabled order sources, locations, roles, payment evidence, handoff rules, and exception procedure your operation needs.
See the next order
Open the customer, items, total, notes, channel, fulfillment branch, and recorded payment state in one queue.
Protect available stock
Reserve the complete accepted order at intake and keep cancellation or completion tied to the inventory record.
Own the handoff
Move the order through the allowed states and verify pickup, shipping, payment, sale, and cancellation evidence separately.
Use the seeded product to explore the operating path, then bring us the locations, roles, devices, records, and exceptions that matter to your business.
The operating rule
Payment and fulfillment are separate controls.
An order can enter the queue with products, customer context, a server total, and a reported payment state. The operator still reads the Payment badge and the order details before accepting work. Confirmed does not prove paid.
Online order intake controls
Six control points from queue to close.
The tenant's OMNICHANNEL module must be enabled, and a user with manage_sales permission works the order. Inventory has already attempted a full-order reserve-or-fail operation at intake; the queue is where staff verify and fulfill it.
- 01OpenAuthority · order record
Open one Pending order.
Match the external order identity, customer, items, total, placed time, notes, and current state before changing anything. Use the channel filter to isolate a source before opening the order.
- 02PaymentControl · separate verification
Read the Payment badge.
Check the recorded payment status before Confirmed and again before completion. The badge communicates the order record; it is not a substitute for the capturing channel's payment evidence.
- 03StockAuthority · reserved stock
Recognize the reservation already made.
At intake, LiftedPOS attempts to reserve the complete order atomically. Insufficient inventory rejects the order instead of partially reserving a basket.
- 04RouteControl · fulfillment branch
Read the handoff from the address.
A shipping address means Ship to customer. No shipping address means In-store pickup. Validate the customer, contact, items, address or pickup identity, and notes.
- 05AdvanceAuthority · state transition
Move one allowed state at a time.
Use Pending → Confirmed → Preparing → Ready → Completed. If another operator changed the order first, refresh and try again from the current state.
- 06CloseAuthority · final records
Complete or cancel with evidence.
Completion commits the final state, then idempotently attempts the linked sales ledger booking without deducting inventory again. Cancellation attempts an atomic release of actually reserved quantities that can apply at most once. Verify both results.
Swipe to inspect the full product screen, or open the full-resolution proof.
Swipe to inspect the full product screen, or open the full-resolution proof.
Fulfillment branch board
Route the physical work without inventing a payment result.
No shipping address
Verify customer and contact, item quantities, notes, Payment badge, and pickup identity. Prepare the order, move it to Ready, then use the merchant's approved handoff policy.
Shipping address present
Validate the address, items, notes, and Payment badge, then follow the configured shipping workflow. A Ready state does not buy postage and does not create a carrier label.
Stop before completion
Handle any needed payment reversal through the capturing channel, cancel the uncompleted order, then verify that its reserved stock was released.
Cancellation does not issue a payment refund. It changes the order and reservation record. If money was captured, the operator must use the qualified void or return path for that payment channel and reconcile both outcomes.
Order status workflow
Each state is an operating handoff—not a payment claim.
Confirmed does not prove paid. Confirmed acknowledges the order workflow. Preparing begins physical work. Ready indicates the order is staged for its pickup or shipping process. Completed closes fulfillment, then the product attempts the linked sale booking; scheduled reconciliation can retry a missing booking. Cancelled is available from a nonterminal state and is terminal once accepted.
Queue, stock, and sales records
Read the record created at each boundary.
The queue polls for current work on a 20-second interval. New work can produce a visual pulse; the browser chime is best-effort because browser audio policy and the user's environment can suppress it. Search, status counts, channel filter, and refresh support the active queue.
Export CSV covers the currently loaded page, not an unlimited historical export. Treat it as a page-scoped operating extract and retain the active filters and time of export with any shift review.
Inventory is reserved at intake. Completion commits Completed, then idempotently attempts sales ledger booking without deducting the same stock again. Scheduled reconciliation retries missing bookings, so the manager verifies the linked sale. Cancellation attempts an atomic release of actually reserved quantities that can apply at most once; verify location stock because the terminal state and release are separate outcomes.
Exception handling
When something disagrees, reopen the live order before acting.
Payment is pending or unclear
Do not infer approval from Confirmed. Check the Payment badge and the capturing channel before completion.
Another operator moved the order
A stale concurrent transition can return a conflict. Refresh and try again from the state the server now returns.
Stock cannot reserve
The intake operation rejects the complete order instead of leaving a partially reserved basket. Investigate availability before asking the source to retry.
Payment was captured but order must stop
Use the qualified payment reversal path separately, cancel the uncompleted order, and reconcile both the money and the actual inventory result.
Before you go live
Make sure every online order reaches a clean handoff.
Run each scenario with the merchant's configured order source, payment evidence, locations, inventory, shipping process, permissions, and operating policy.
| Scenario | Operator control | Expected POS record | Reconciliation gate |
|---|---|---|---|
| Paid pickup order | Verify Payment badge, customer, items, and no address | Pending through Ready, then Completed at handoff | Payment evidence, linked sale, and one stock effect agree |
| Ship-to order | Validate payment and shipping address | Allowed state path retained with external identity | Configured shipping workflow has separate label and tracking evidence |
| Insufficient inventory | Do not fulfill a rejected intake | Whole order fails reserve-or-fail | No partial reservation remains |
| Concurrent state change | Refresh and try again | Server's current state wins | No skipped or duplicate transition |
| Cancel reserved order | Cancel before completion | Cancelled is terminal | Verify the reserved-stock release applied at most once |
| Cancel captured payment | Reverse through capturing channel separately | Order cancellation does not assert a refund | Payment and inventory evidence both reconcile |
| Complete order | Verify payment, handoff, then complete | Completed plus linked sale after booking or reconciliation | Verify the sale exists and inventory was not deducted twice |
| Export active queue | Record filters and export time | CSV contains the currently loaded page | Page scope is understood |
Manager shift runbook
Operate the queue as a control surface.
- 01 · OpenReview status counts, channel, new-order pulse, and the oldest Pending work.
- 02 · VerifyRead identity, items, total, notes, fulfillment branch, and Payment badge.
- 03 · RouteUse no address for in-store pickup or a present address for ship-to handling.
- 04 · AdvanceMove one allowed state at a time; recover a conflict from the refreshed record.
- 05 · CloseComplete only after payment and handoff checks, or cancel and separately resolve captured funds.
- 06 · ReconcileCompare queue state, reserved stock, sales ledger, payment evidence, and any shipping record.
Complete commercial picture
Know what is included before you launch.
LiftedPOS software is $100/month for the first station and $50/month for each additional station. A standard station is $499.99 to buy or $39.99/month to lease. Cancel anytime—there is no long-term software contract. Leased equipment must be returned after cancellation or billed at full purchase price.
Tenant access uses {company-prefix}.liftedpos.com/login. External order sources, credentials, shipping services, payment rails, and separately scoped rollout work require deployment verification. Creating or revoking integration keys requires manage_settings; reading and working the queue requires manage_sales.
LiftedConnect is the supported card-present PAX boundary for configured POS payments. It does not prove that an external order is paid; use the order's Payment badge and the capturing channel's evidence.