Give guest contact details only to staff who need them to complete a specific part of a direct order. A shift lead handling a missing item may need a phone number. A cook preparing the same order usually needs the items and allergy instructions, not the guest’s email or full order history.
Start with the task, then decide which details, orders and time period that task requires. Your ordering system may not offer every restriction you want, so check the actual controls before assigning accounts. If a role combines several duties, give that person the access needed for those duties rather than copying a generic job title.
Map the work before assigning access
List the points where someone might need to contact a guest: confirming an unclear address, resolving a sold-out item, arranging a pickup correction or responding to a complaint. Then separate those tasks from work that only needs order information, such as preparing food or checking whether an order is ready.
Ask the people doing the work what they use during a normal shift and what changes when something goes wrong. The owner or general manager can identify who approves refunds and handles complaints. Shift leads can describe how they resolve order problems. Kitchen and delivery staff can explain what appears on their screens or tickets and what they actually need.
For each task, record four things: the person responsible, the minimum information needed, when they need it and who covers when they are absent. Include delivery partners and anyone who manages marketing, not just employees at the counter. Also note where details travel after an order arrives: the ordering dashboard, POS, kitchen display, printed ticket, delivery tool or exported file.
Access to a phone number is different from permission to change the ordering menu, prices or hours. Keep those decisions separate. A person who can update a menu does not automatically need a list of guest contacts, and a shift lead who can call a guest does not necessarily need to change ordering settings.
Build a guest-data role matrix
The following matrix is a hypothetical starting point for a restaurant with pickup and delivery orders. It assumes a shift lead handles order problems, a delivery worker takes orders to guests, and the owner handles escalated complaints. Your staffing and service model may call for different assignments.
| Role | Task | Suggested access | Limit to check |
|---|---|---|---|
| Kitchen staff | Prepare the order | Items, preparation notes and an order identifier | Hide contact details if the workflow permits |
| Counter staff | Hand off pickup orders | Pickup name or identifier and order status | Contact details only if assigned to resolve pickup issues |
| Shift lead | Resolve active-order problems | Relevant order and a way to contact that guest | Restrict broad history or exports where possible |
| Delivery worker | Complete an assigned delivery | Delivery address, instructions and contact method | Limit visibility to assigned deliveries and the delivery window where possible |
| Owner or manager | Handle escalations and review operations | Details needed to investigate a specific issue | Restrict exports and routine browsing to authorized staff |
| Marketing staff | Run an approved guest campaign | Only the audience and fields needed for that campaign | Check consent, export controls and who can send messages |
The table separates an operational need from a suggested limit; it does not assume your software can enforce that limit. For example, a driver needs a way to find and reach a guest, but that does not establish a need to browse every previous order. Likewise, an order note may be necessary for preparation even when the guest’s contact information is not.
Before applying the matrix, identify exceptions. Who calls a guest when the shift lead is off? Can a counter employee help with a pickup issue without receiving permanent access to all customer records? Name a backup and define when that person can use the access. Avoid creating a broad account simply because an unusual problem might occur.
Check the controls against a real shift
Use the matrix as a list of questions for your current provider and for any restaurant online ordering provider you are considering. Ask for a demonstration using separate roles. Pay attention to what each person can see, search, download, print and send—not just the names of the permission settings.
- Fields: Can you show an order identifier and preparation notes without displaying the phone number, email or delivery address?
- Scope: Can access be limited to active orders, a location or assigned deliveries? What historical orders remain visible?
- Exports and messages: Who can download a customer list or send a message? Can those permissions be separated from viewing an individual order?
- Downstream copies: Which details appear on printed tickets or pass to connected systems and delivery partners? How are those copies controlled?
- Accounts: Can each worker have an individual login? How are access changes made, and what activity can a manager review?
There is a practical trade-off. Restricting contact details can make a routine kitchen screen easier to manage, but someone on the shift still needs a way to resolve a wrong address or missing item quickly. If the system cannot give a backup temporary or narrow access, decide who will handle those situations and how staff will reach that person.
For a hypothetical practice check, create a fictitious pickup order in a safe demo or test environment. Have a kitchen-role user find the items and preparation note, then have a shift-lead-role user find the contact method needed to resolve an issue. Check whether each can see or export unrelated guest records. Do not place a real card payment, send a guest message or dispatch a courier during the simulation.
A simulated check shows what those accounts can do in that environment; it does not prove every integration, printed ticket or live exception behaves the same way. If you later run a live service pilot, plan it separately with authorized staff, normal safeguards and a way to stop or correct problems. Never treat a real guest order as a practice transaction.
Change access as roles change
Choose an owner for the access list, typically the manager responsible for staffing. Keep a simple record of each user, their role, the access approved, the approver and the date it was reviewed. Record connected services and external partners too. A login removed from one system may leave access elsewhere.
Use the same process for a new hire, a promotion, a temporary cover shift and a departure. A manager should approve the required role before access is granted, check that the account matches the job, and remove or revise access when the duties end. When someone leaves, review individual logins, connected tools and any shared credentials. If a shared credential cannot be avoided, agree who controls it and how it will be changed when staff leave.
Review the list on a regular schedule and after a change to the ordering workflow. Look for former staff, duplicate accounts, users with export rights they no longer need and roles that have accumulated permissions over time. Ask managers to confirm the backup for each contact-dependent task so tighter access does not leave a shift unable to help a guest.
Set retention and training rules with counsel
Access is only one part of the decision. Ask the provider what information it retains, how long it remains available to restaurant users, whether retention can be configured and what happens to exports or records in connected services. Find out how a guest request is received and who at the restaurant is responsible for responding.
Review your proposed retention and handling rules with qualified counsel familiar with your circumstances. Ask about the treatment of guest contact data, marketing permissions, vendor agreements and requests involving personal information. Do not assume that deleting a local spreadsheet also removes records held in the ordering system or by another service.
Train staff on the tasks in the matrix. Show a shift lead how to find the relevant order without browsing unrelated records. Show counter staff where to find pickup identifiers. Explain where printed tickets go after service, who may use contact details for an order problem and who must approve a marketing export. Give employees a clear person to notify if a ticket, account or file may have been exposed.
For the next step, walk through one normal order and one exception with your team, mark each data handoff, and compare the result with the matrix. Use the online ordering buying guide to review the broader purchase, and check how your restaurant website connects to the ordering process. Then ask Fleksa to demonstrate the relevant access controls and confirm US availability for your setup.
Frequently asked questions
Does kitchen staff need a guest’s phone number?
Usually not for preparation alone. Kitchen staff need the order, relevant preparation notes and an identifier. Assign a person who can access the contact method when a problem requires a guest conversation.
Should a delivery worker see the guest’s full order history?
Start with the information needed for the assigned delivery: address, instructions and a contact method. Ask whether the system can limit visibility to assigned deliveries and avoid exposing unrelated history.
Who should be able to export customer lists?
Limit exports to people with an approved business task, such as a manager or authorized marketing worker. Check what fields are included, where the file will be stored and how access will be removed when the task ends.
