Online ordering systems
Keep repeat orders direct.
Customers choose, pay and receive a clear collection or delivery promise through your website. A focused online ordering system is usually £900 - £1,800 and can work with an existing or new site.
Ernest takes no commission on orders. Card processing, messaging, delivery and connected providers may charge their own fees.
The customer promise and the kitchen ticket agree.
Try it without signing up
A customer sees dinner. The kitchen sees a useful ticket.
Switch between collection and local delivery, then place the pretend order. Nothing is charged, sent or stored. The example shows the information that must stay consistent on both sides.
An allergen note can be passed to the kitchen, but the real menu and kitchen process determine what can be prepared safely.
Waiting for the customer step
The kitchen receives the items, modifiers, payment state, timing and fulfilment detail as one record.
One of six collection slots used at 19:10
Use the rate on your own statement
Compare the same order, not vague promises.
Move the slider to the commission percentage you currently pay. This simple per-order illustration isolates platform commission so the comparison stays understandable.
Illustration only. It excludes card processing, delivery labour, packaging, discounts, promotions, platform subscriptions and any other provider costs.
What the checkout alone cannot solve
Taking payment is easy. Keeping the promise is the work.
Phone orders interrupt service, menus drift apart and generic checkouts can promise more than the kitchen can prepare. A direct ordering route keeps the item, modifier, payment, timing and fulfilment decision together without an Ernest commission on every order.
Phone orders interrupt the team
The customer selects items and options without a rushed conversation over kitchen noise.
Menus disagree
Price, availability and modifiers follow one maintained catalogue instead of several forgotten copies.
Too much arrives at once
Lead times and order capacity prevent the checkout from promising an impossible collection time.
Loyal orders keep paying rent
Delivery apps can stay for discovery while the website gives regular customers a direct route.
Rules before the cart
The menu invites an order. The rules make it fulfilable.
The build starts with what may be sold, where, when and with which options. Customers should only reach payment when the order can be honoured.
Items and modifiers
Sizes, choices, extras, exclusions and useful allergen information stay attached to the item.
Availability and pauses
Staff can mark an item sold out, close a service or pause ordering without editing several menus.
Collection capacity
Lead time and orders per interval reflect what the kitchen can prepare at that moment.
Delivery boundaries
Postcode zones, minimum spend, fees and timing are checked before payment is offered.
One order, start to finish
Simple for the customer. Dependable for service.
The customer chooses currently available items and a valid collection or delivery route. The system checks capacity and location again before payment, creates one authoritative order, gives the kitchen a usable ticket and keeps status and customer messages attached until handover.
A paid order is not complete until the kitchen can see it and the customer has an honest fulfilment promise.
- 01Choose
Items, modifiers and fulfilment
The customer sees only valid combinations and current availability.
- 02Validate
Capacity, time and location
The system confirms the order can still be prepared and fulfilled.
- 03Commit
Payment and kitchen record
Successful payment creates one authoritative order with every modifier intact.
- 04Fulfil
Prepare, notify and complete
Status and customer messages follow the same order until handover.
Choose the right ownership level
Keep, connect or build.
Best for restaurants, takeaways, cafes, bakeries, caterers and local food businesses with a defined menu and fulfilment area. Keep marketplace apps for discovery, add a focused direct website route for repeat customers, or build a fuller application when several locations, stock sources or dispatch roles must work together.
Keep them for discovery
Leave a useful marketplace route in place while giving regular customers a clearer direct option.
Best when the platform still earns its acquisition cost.Own ordering on the website
Take payment, manage availability and receive usable tickets without paying Ernest per order.
Best for collection and a clear local delivery area.Build a custom application
Add multiple locations, roles, advanced stock, dispatch, account pricing or unusual kitchen workflows.
Best when ordinary ecommerce rules no longer fit.Different orders, specific fulfilment
Start with the way customers receive it.
Takeaway collection
Time slots, preparation lead time, order limits and a clear collection notification.
See restaurant website work →Local delivery
Address checks, zones, minimum spend, fees, capacity and a defined handover to the driver.
See the connections →Pre-orders and catering
Order deadlines, future dates, serving quantities and approval for work that cannot be instant.
See event website work →Shipping products instead?
A wider product catalogue, national shipping, customer accounts and stock belong in the ecommerce route.
See ecommerce development →Tables and takeaway orders can share the same website while keeping their inventory and operational rules separate.
See table reservationsConnections checked before the quote
One order record. No pretend integration.
Ernest checks the documented connection, data direction and failure route before promising POS, printer, kitchen-screen, delivery or customer-system integration.
Simultaneous stock and slot requests tested
Payment, printing and notification failures handled
Manual fallback written for service staff
Proof is a completed handover
Test the awkward orders. Then open the route.
The example above is an illustration, not a claim about your kitchen. Acceptance testing uses the actual menu, capacity, provider accounts and the situations most likely to fail during service.
See restaurant website experienceOnline ordering system price
A focused direct route with visible boundaries.
The range covers one contained ordering route. The proposal names the menu, fulfilment rules, payment behaviour and checked connections before the build begins.
See all website and system prices- Editable menu, items and modifiers
- Collection or agreed local delivery rules
- Online payment, confirmation and order record
- Launch testing, training and practical fallback
Price rises with multiple venues, advanced stock, accounts, dispatch, migration, POS integration, custom reporting or closed third-party systems.
Support is optional. Hosting and domain are separate. Payment, messaging, delivery, POS or other providers may charge their own fees directly.
Before the ordering build
Direct ordering questions.
Can I keep delivery apps while adding direct ordering?
Yes. A marketplace can remain useful for discovery while the website gives returning customers a direct option. I map how menus, prices and stock will be maintained so the extra route does not create avoidable work for staff.
Can website orders print in the kitchen or reach my POS?
Often, but it depends on the documented integration exposed by the specific POS, printer or kitchen display. I check the account, hardware, API, data direction and failure route before including the connection in a proposal.
How are delivery zones, minimum spends and fees handled?
They can be based on agreed postcodes, distance or another supported boundary. The system checks the address, current service, minimum spend, fee and available capacity before the customer reaches payment.
Can staff mark items sold out or pause online orders?
Yes. The exact control depends on the build, but a contained system can provide a simple staff view for item availability, service closures, lead time and ordering pauses without editing the public page manually.
What happens when an order is cancelled or refunded?
The proposal defines who may cancel, which payment-provider action is available, what status the kitchen sees and which customer message is sent. Provider timing and transaction fees remain subject to that provider's terms.
Can my current menu and customer records be moved?
Sometimes. It depends on the export or API, data quality and permission to use those records. I map products, modifiers, prices and consent fields, then test a small import before migration is included in the build.
Bring the menu and one real service
Show Ernest how an order is handled today.
The first conversation maps menu changes, busy times, fulfilment and the tools the team already uses. You will know whether to keep, connect or replace them before a build is proposed.