Put two clearly labeled choices near the top of your homepage: Order pickup and Order delivery. Give them similar visual weight and make each one lead to the appropriate ordering path. Before guests commit, show the service details they need to make a sensible choice, such as pickup hours and how to check delivery availability.
The goal is not to force every detail onto the first screen. It is to let a hungry guest understand both options, choose one, and recover easily if the first choice does not work. That takes more than placing a single “Order now” button on the page.
Map the two guest journeys
Start with what each guest is trying to do. A pickup customer needs to know where to collect the food, when pickup is offered, and how to start an order. A delivery customer needs to know whether the restaurant serves their address, when delivery is offered, and where any delivery charges will appear.
Both journeys also need a clear route to the menu. But they should not require the same information at the same time. Asking for an address before someone can choose pickup creates unnecessary work. Promising delivery before an address check can create a frustrating surprise.
List the information your homepage needs and agree on who will keep it current:
- Restaurant operator: service hours, pickup location, temporary closures, and the wording guests should see.
- Ordering provider: the destinations for each action, how service hours are managed, and where address checks and charges appear.
- Delivery provider, if used: the service area and any operational limits the restaurant must account for.
- Website manager: page layout, working links, mobile display, and the process for updating the page.
One person should be responsible for checking that the homepage and ordering flow agree. A holiday-hours change, for example, is not complete if the homepage says pickup is open while the ordering page says it is closed.
If you already have a site, you may be able to keep it and connect guests to an ordering page rather than rebuild everything. Fleksa describes an option to retain an existing site with an ordering button or link. Ask how separate pickup and delivery destinations would work in your setup. For a wider site decision, see the restaurant website builder comparison.
Name each action in plain language
Use the words guests use. “Order pickup” and “Order delivery” tell people both the task and the service mode. Labels such as “Get started,” “Explore,” or “Order here” leave the next step unclear. Avoid making one option a large button and hiding the other in a menu or a line of small text.
On a narrow screen, the actions can sit one above the other. Equal weight does not mean they must be side by side. Use the same button style and enough space around each action to make tapping comfortable. Put a short explanation beneath each if it helps: “Collect from our restaurant” and “Check your address.”
Suppose a hypothetical neighborhood restaurant offers pickup throughout its opening hours but delivery only during dinner. Its homepage could show both choices all day. Next to delivery, it could say “Delivery starts at 5 p.m.” when that is the current schedule. A guest can still see that delivery exists without assuming it is available right now.
Do not use a delivery label to send everyone into an unexplained pickup flow, or vice versa. If the ordering system requires an intermediate mode-selection screen, ask whether the homepage choice can carry through. If it cannot, make the handoff clear and check that guests can select the intended mode without starting over.
Give guests a way back, too. Someone may choose delivery, discover their address is outside the service area, and decide to collect instead. A visible option to switch to pickup is more useful than a dead end. Ask the ordering provider whether a switch preserves the guest’s selections; do not assume it does.
Show availability before the handoff
Put stable, decision-making details close to the two choices. For pickup, that may be the restaurant address and pickup hours. For delivery, show the delivery hours and explain that the address must be checked. If service times differ from dining-room hours, name them separately.
A homepage does not need to calculate every fee or promise an arrival time. It should tell guests where they will see those details before placing an order. If delivery charges depend on the address or provider, use wording such as “Check your address and delivery charges before placing your order.” Only use it if the ordering flow actually provides that information at that point.
Unavailable service needs an honest state. During a temporary delivery pause, keep the delivery path visible and explain the pause rather than silently removing it. Depending on the ordering setup, the action might lead to an availability explanation or a later-order option. Confirm what happens before choosing the wording; do not promise scheduling unless it is available.
Agree on an update routine for exceptions. Who changes the message when a kitchen closes early? Can that person update it from a phone? Does the ordering system stop taking orders for the affected mode as well? A homepage notice helps, but it cannot replace controls in the ordering flow.
When comparing online ordering options, ask the provider to show the path from each homepage choice through service selection, address checking, fees, and the point before an order is submitted. Also ask who controls the hours and messages. A polished homepage cannot fix an unclear ordering handoff.
Build and test a two-path mobile page
The following is a hypothetical mobile wireframe, not a claim about a particular product. Read each row from top to bottom as the order in which content appears on a phone. The two actions have equal prominence even though they are stacked.
| Position | Content | Purpose |
|---|---|---|
| Top | Restaurant name and short description | Confirm guests are in the right place. |
| First choice | Order pickup — Collect from our restaurant | Start the pickup path without an address request. |
| Second choice | Order delivery — Check your address | Start the delivery path without implying every address is served. |
| Service details | Pickup address and hours; delivery hours and availability note | Help guests judge whether their choice fits. |
| Below choices | Menu, contact details, and other restaurant information | Answer follow-up questions without burying the ordering paths. |
In the actual page, the choices should be actionable links or buttons, not just text in a table. Check that both are visible early on a common phone screen. If the second choice falls below the screen edge, reduce oversized decoration or introductory copy before shrinking the labels.
Run a simulated task check before changing the live service. Use a draft page or a safe preview of the ordering flow. Give each participant one task at a time, without pointing to the answer:
- “You want to collect dinner. Show me where you would start and find the pickup location.”
- “You want dinner delivered. Show me where you would check whether your address is served and where charges would appear.”
- “Delivery is unavailable for your address. Show me how you would switch to pickup.”
Watch where people tap, whether they can explain the difference between the choices, and where they hesitate. Ask them to stop before submitting an order. Use a simulation or provider-approved test environment that cannot create a real payment, guest message, or courier dispatch. Do not enter a real card or place a real order for this practice.
Set pass criteria before watching: for example, a participant should find the intended path without coaching and identify where to check the relevant service details. If a task fails, change one obvious source of confusion and repeat it. A few practice sessions can reveal usability problems; they cannot establish how every guest will behave or prove the live operation is ready.
After the simulated check, review the live setup with the people who manage the site and orders. If you run a live service pilot, arrange it separately with staff and providers, define who monitors orders and exceptions, and communicate any limits to participating customers. A live pilot can create real operational consequences; it is not the same as a practice task.
Use this checklist on your current homepage, then ask Fleksa how its restaurant website can support your two paths and confirm current US availability for your setup.
Frequently asked questions
Should pickup or delivery appear first?
Either can appear first if both are easy to see and have comparable visual weight. Choose an order that fits your guests, then test whether people can find each option without help.
Should guests enter an address on the homepage?
Not necessarily. A clear delivery action can take guests to an address check in the ordering flow. Make sure pickup customers are not required to enter a delivery address.
What if delivery is temporarily unavailable?
Keep the option recognizable, explain the current status, and offer a clear pickup path if pickup is available. Make sure the ordering controls match the homepage message.
