Require a phone number when your restaurant or delivery partner has a real need to reach the guest about that order and another contact method will not reliably do the job. For a straightforward pickup, an optional number may be enough. For a delivery where a driver may need directions, a number may be necessary if there is no workable alternative.
The right answer depends on how the order is fulfilled, who handles problems, and which contact methods actually reach the guest. Make that decision for each order type, then explain the purpose beside the field. Don't make guests guess why you want their number.
Start with the situations that need contact
Ask the people handling orders what happens when something goes wrong. A manager may know the refund procedure, while the person packing orders knows which substitutions need a quick answer. A delivery partner can explain how drivers resolve an unclear address or inaccessible entrance.
Useful reasons to contact a guest can include:
- An item is unavailable and the kitchen needs approval for a substitution.
- A pickup order is ready but the guest has not arrived and the food cannot be held indefinitely.
- A driver cannot find the entrance or needs a gate instruction.
- A scheduled order needs a time change or clarification before preparation begins.
- Staff need to resolve an order detail that cannot wait for the guest to contact the restaurant.
For each case, write down who initiates contact, how quickly they need an answer, and what happens if they cannot reach the guest. Also ask whether email, an in-order message, a call, or another method fits the situation. A channel that exists on paper is not useful if staff cannot access it or the guest is unlikely to see it in time.
Separate the contact needed to fulfill an order from contact wanted for marketing. A guest who provides a number for a delivery question should not have to infer that it will be used for promotions. Check how your ordering setup handles those choices and ask a qualified adviser about applicable requirements.
Your restaurant website and checkout should give a consistent explanation. If the website promises a particular contact method, make sure the people fulfilling the order can actually use it.
Choose the field by fulfillment mode
The matrix below is a starting point, not a rule for every restaurant. The decision changes if a courier requires a number, staff have a reliable alternative, or the order needs an answer before a deadline. Confirm what your restaurant and any delivery partner can do before setting a field as required.
| Order type | Contact problem | Starting decision | What to check |
|---|---|---|---|
| Immediate pickup | Substitution or delayed collection | Optional if staff can proceed or reach the guest another way | Can staff resolve common issues without a call? |
| Scheduled pickup | Timing change before preparation | Optional or required based on the time-sensitive handoff | Will the alternative reach the guest before work starts? |
| Delivery | Driver cannot locate or access the address | Require if the delivery workflow needs it and has no workable alternative | Who receives the number, and can the driver use another channel? |
| Scheduled delivery | Address or timing issue before dispatch | Require if a timely response is essential and no alternative works | Can staff and the delivery partner reach the guest at the right stage? |
Read the decisions as questions to settle with your team, not default settings. For example, a pickup restaurant that always substitutes only with guest approval may need a quick contact method. Another may have a clear policy to leave an unavailable item out and resolve the charge through its established process. Those workflows create different needs.
Delivery deserves particular attention because the restaurant and the person carrying the food may not be the same party. Ask whether the courier needs the guest's number, receives a masked contact option, or can use another route. Don't promise a particular privacy feature until you have confirmed it in your setup.
Make the requirement match the workflow
Use three practical categories: required, optional, and not collected. Required means the order cannot proceed without the information. Optional gives the guest a choice but still needs a clear purpose. Not collected makes sense when nobody has an order-related use for the number.
Consider this hypothetical restaurant: it handles its own pickup orders and uses a separate delivery partner. For pickup, staff can prepare most orders without a conversation, and an email address is available for nonurgent issues. The owner makes the phone number optional. For delivery, the partner says its drivers need a number to resolve access problems and offers no alternative contact channel. The owner makes it required for delivery only.
That choice follows the stated workflow; it is not a claim that every courier needs a number. Before using it, the owner should confirm who can see the number, when it reaches the driver, and how staff handle an invalid or missing number. If the partner later offers a workable contact alternative, the owner can revisit the requirement.
Don't use one broad setting just because it is easier to explain internally. Ask your ordering provider whether the field can change by fulfillment mode. If it cannot, compare the trade-off: a single required field may collect unnecessary information from pickup guests, while a single optional field may leave delivery staff without a needed contact. You may need to adjust the operational workflow or choose a different setup.
For a wider look at checkout and fulfillment decisions, use the online ordering buying guide. Judge the phone field on its own purpose rather than treating it as a substitute for an account decision.
Explain the number beside the field
Put the reason where the guest makes the choice. A short label or helper sentence can answer three questions: is the number required, who may use it, and what order-related problem does it solve?
For the hypothetical restaurant above, pickup copy could say: Phone number (optional). We may call if we have a question about your pickup order. Delivery copy could say: Phone number (required). The delivery partner may call if the driver needs help finding you.
Use those lines only if they match what actually happens. If restaurant staff may also call about delivery substitutions, say so. If the contact goes to a delivery partner, don't imply that only your restaurant can access it. Avoid vague copy such as “for a better experience”; it does not tell a guest what the number is for.
Check the whole path, not just the label. Does the required marker appear only on the order types you intend? Can a guest understand and correct an invalid entry? Does the explanation remain visible on a small screen? If the number is optional, can the guest continue without it?
Also ask the provider where the number appears after checkout, who can access it, how long it is retained, and what controls exist for removing or limiting access. Have a qualified adviser review your privacy and contract questions when needed. A sentence beside a field should describe the real process, not replace those decisions.
Practice the handoff before changing live checkout
First, run simulated checks in a safe practice environment with test data. Confirm with the provider that the exercise cannot charge a real card, send a guest message, or dispatch a courier. If a safe environment is unavailable, review the screens and handoff with the provider without placing an order.
- Walk through pickup without a number. Confirm that checkout can continue if the field is meant to be optional, and ask staff how they would handle an unavailable item.
- Walk through delivery with a test number. Check that the requirement and explanation appear before submission, then trace what information would reach restaurant staff and the delivery partner.
- Try a clearly invalid entry. Check whether the error tells the guest what to correct without implying the number has been verified.
- Simulate a driver access problem. Identify who would make contact, which screen they would use, and what happens if the guest does not answer.
A simulated check can expose confusing copy or a broken handoff, but it cannot tell you how real guests will behave. If you later run a live service pilot, use your normal order process and tell staff what to watch: abandoned checkouts where measurement is available, repeated questions, unreachable guests, and orders staff could not resolve. Compare pickup and delivery separately, since their contact needs differ. Record observations without assuming a phone field alone caused a change.
Give staff a short instruction for each mode: when to call, what to do if there is no answer, and where to record the outcome under your existing process. Review it with the delivery partner too. A required field has little value if the person facing the problem cannot reach it in time.
For your next step, use the matrix with one recent order workflow and identify the first point where staff might need a guest response. Then ask Fleksa about restaurant online ordering, including whether the contact-field settings you need are available for your location in the US.
Frequently asked questions
Should a phone number be required for every pickup order?
Not necessarily. If staff can handle common problems without a call or have a timely alternative, an optional field may be enough. Require it when your actual pickup process depends on reaching the guest by phone.
Can a delivery order use email instead of a phone number?
Possibly, but check whether the driver and guest can use it quickly when an address or access problem arises. If the delivery partner requires a number and has no workable alternative, explain that requirement at checkout.
Can an order phone number also be used for marketing?
Keep the order-contact purpose distinct from promotional use. Check your system's choices and ask a qualified adviser about applicable requirements before using contact details for marketing.
