Restaurant POS Guide: Orders, Kitchen Handoff and Payment

Demonstrate one complete busy-period order

Choose a representative order with sizes, modifiers, an allergy note handled under your restaurant’s procedure, a discount and a changed item. Check the price before sending it to preparation. Verify which station receives each item, how changes appear and how staff know whether an order has already been sent.

For table service, demonstrate seat or table assignment, a moved item, split checks, partial payment and the supported tip process. For counter service, check queue handling, customer names or order numbers and pickup status. These are distinct operating needs.

Keep kitchen and payment responsibilities clear

A payment device does not automatically include kitchen displays, preparation printers, online ordering or restaurant software. List the required software plan, apps, devices and routing rules in the proposal. Confirm who maintains menu changes and who resolves an order that was paid but never reached the kitchen.

1. Send an order to each required preparation destination.
2. Amend or cancel an item using the permitted staff role.
3. Mark the order ready and confirm the customer handoff.
4. Complete payment, receipt and tip handling.
5. Inspect sales, refunds, voids and tender totals during closeout.

Reconcile direct orders and delivery channels

Track which platform owns each order, takes the payment, issues refunds and provides settlement reports. Marketplace deposits may include adjustments and commissions that do not match the gross order total. Keep those records separate from direct card batches until the reconciliation explains the differences.

For your own website, test mobile checkout, item availability, pickup times, order acceptance and cancellation. Use the restaurant online-payment guide to prepare those tests.

Compare the whole setup and plan go-live

Request equipment ownership, software, paid apps, accessories, installation, menu work, training and processing terms separately. Compare transaction types and volumes against the same period. A quote for a terminal alone is not a quote for a complete restaurant system.

Before launch, verify network coverage, printer locations, counter power, staff permissions and the fallback procedure. Agree how existing tabs, deposits, gift cards and refunds will be handled. Keep the previous reports available and inspect the first settlement before closing the old account. Provider approval and product availability determine the final scope.

Choose the service model before the hardware

A counter-service restaurant, a table-service dining room and a pickup-focused kitchen do not use the same sequence. Identify where the order begins, who enters it, when payment occurs and how preparation is confirmed. Use the busiest normal service period as the design reference.

A counter may need rapid item lookup, clear modifiers and an order number. A dining room may need table assignment, courses, split checks and a supported tip workflow. A kitchen serving several channels needs a clear source and status for every ticket. Demonstrate those requirements instead of assuming a larger screen solves them.

List each station and its purpose before choosing devices. The menu-entry workstation, customer payment device and preparation display perform different jobs. Confirm the software, applications, accessories and connections that make the proposed arrangement complete.

Give menu data a responsible owner

Prepare categories, items, sizes, modifier groups, prices and approved tax configuration. Decide who may change the menu and who signs off the result. A menu imported from a spreadsheet still needs testing at the point where an employee enters an actual order.

Test a required choice, an optional add-on, an unavailable item and a product whose modifier changes the price. Verify the customer total and the preparation ticket. Staff should not need to type the same instruction repeatedly because the catalogue structure does not match the kitchen’s work.

Keep allergy-handling procedures under the restaurant’s approved operating process. If the system displays notes or prompts, demonstrate where they appear and who sees them. A POS note is not a guarantee that an order has met every food-safety or customer-service requirement.

Prove kitchen routing from the actual order screen

Send a sample order containing items for more than one preparation destination. Confirm each station receives the intended items, modifiers and reference. Check how staff recognise the service channel, table or pickup identity without unnecessary customer information.

Amend the order after it has been sent and demonstrate the resulting ticket or display change. The kitchen needs to distinguish a new item from a correction or cancellation. A second printout without a clear meaning can lead to duplicate preparation.

Test an unavailable printer, disconnected display or missed acknowledgement through the supported procedure. Decide who notices the problem, how the order is recovered and who contacts the customer if service is affected. A payment approval does not prove that a preparation station received the order.

Test split checks and payment changes

For table service, demonstrate splitting by item and the supported method for dividing a balance. Include an item moved between checks, a partial payment and the remaining amount. Inspect taxes, discounts, receipts and final totals so the division is understandable to staff and guests.

Show how the customer selects a tip and how the transaction appears in the report used by management. Confirm the supported adjustment process and have the person responsible for staff payments approve the required outputs. Tip reporting and payroll calculation are separate requirements.

Also test a void before payment and a refund after payment. These actions may affect preparation, sales reporting and payment records differently. Assign the appropriate manager permissions and check the audit trail rather than giving every server unrestricted authority.

Make pickup and direct online ordering accountable

Identify which system publishes availability, accepts payment and sends the order to preparation. Test a phone checkout with required modifiers and a pickup time the kitchen can honour. Inspect the confirmation, order reference and staff view.

Decide who pauses ordering or marks an item unavailable during a rush. Confirm how updates reach the website and whether a connector or paid application is involved. A change at the counter should not leave customers ordering an item the kitchen cannot supply.

Test a paid order that fails to reach the kitchen using the approved integration tests. Staff need a way to find the payment, recover the order and avoid collecting again. The restaurant online-payment guide and ecommerce planning guide provide the wider checkout and reconciliation checklist.

Keep delivery-marketplace payouts separate

For each marketplace, identify who takes the customer’s payment, handles a refund and issues the restaurant’s payout. An order shown in the POS may still settle through a different commercial relationship. Document the source of the authoritative payment and payout reports.

Reconcile gross orders, cancellations, refunds, commissions and other adjustments to the relevant payout period. A marketplace deposit is not necessarily a card-processing batch from the restaurant’s direct account. Combining the totals too early can hide the reason for a difference.

Check which connector moves orders and what it does not move. An imported ticket does not establish that inventory, refunds or financial reporting synchronise as well. Give each failed handoff a responsible support owner and a clear record for investigation.

Plan employee access around service roles

Define the tasks for a cashier, server, kitchen employee, supervisor and owner. Normal order entry does not necessarily require access to pricing, refunds or account settings. Use individual accounts where supported and test the permissions in the demonstration.

Decide how cash drawers, shifts and handoffs are managed. The restaurant should know who closes a drawer, approves a variance and reviews exceptional discounts or voids. Keep the explanation with the record so a later manager can understand the action.

Include staff changes and lost devices in the access procedure. Confirm how access is removed and where the records remain available. A shared administrator login can make a busy restaurant appear easy to operate while leaving responsibility unclear when something goes wrong.

Compare the complete restaurant cost

Separate equipment, POS software, kitchen tools, online ordering, paid apps, connectivity, installation, menu work and training. Request processing terms for the expected in-person, keyed and online activity where relevant. Use the same volume and transaction assumptions across proposals.

Confirm which charges are per device, location or account and whether a component has a separate agreement. Include ownership, replacement, cancellation and support terms. A quote for one payment terminal does not describe the cost of a complete restaurant operation.

Use the complete-cost framework to organise the offers and the statement review to understand an existing account. Hardware is separately quoted. A lower advertised percentage alone does not establish lower total operating cost or justify the disruption of a switch.

Design a workable service interruption plan

List the dependencies that can interrupt an order or payment: power, network, device, printer, application and provider connection. Confirm the supported response to each. Do not assume offline acceptance, automatic rerouting or a personal phone substitute is included.

For an uncertain payment result, check status before retrying. For an uncertain preparation result, verify the order reference and station before sending another ticket. Staff should understand that order recovery and payment recovery are different investigations.

Prepare the short information set support needs: location, device, time, order or transaction reference and expected result, without card details. Identify the contact for each layer and the applicable escalation route. A restaurant should not discover during service that nobody knows who maintains the connector.

Approve go-live with a complete service simulation

Use the actual menu, staff roles, network and preparation destinations to simulate a normal rush. Include a changed order, unavailable item, split check, direct online order, refund and closeout. Record the expected result and any manual workaround.

Reconcile the completed sales and payment records, then review the first settlement after live launch. Decide how existing tabs, gift cards, deposits and unresolved refunds will be honoured. Keep the previous reports and review cancellation obligations before ending the old service.

The Clover^® plan documentation is a reference for product and plan distinctions, not a substitute for the exact provider proposal. Confirm device generation, software, kitchen accessories, apps and support scope. Discuss the restaurant workflow with Process Rite before ordering equipment so the demonstration and implementation can be built around the service you actually run.

Compare configurations with a single service simulation

Give each proposed provider the same illustrative scenario: a counter order with modifiers, a table requiring a split check, a direct pickup order and an item that becomes unavailable during service. Use the actual menu structure and intended staff roles rather than a simplified demonstration catalogue.

Track the order reference, preparation destination, payment status and receipt for each channel. Change one item after sending it to preparation and ask the kitchen employee to explain the new ticket. If the employee cannot distinguish the amendment from a new order, the routing demonstration is not complete.

Introduce a disconnected preparation device through the supported test method. Confirm who notices, how staff recover the order and how duplicate preparation is avoided. Then test an interrupted payment separately. Order recovery should not cause a second charge simply because a ticket needs to be sent again.

Close the sample service and reconcile sales, tips, refunds and tenders. For a marketplace example, use its own payout record rather than assuming it belongs in the restaurant’s direct card batch. Give the accounting owner enough information to explain the result.

Score every requirement as demonstrated, documented but untested, manual or unresolved. Attach the exact devices, software, applications and support responsibilities to the scorecard. This creates a fairer comparison than judging proposals by a single monthly price or an impressive-looking front-counter screen.