The restaurant owner or a delegated manager should make the final launch decision, but that person should not be the only reviewer. Assign the people closest to the work to approve the menu, business details, ordering and reservation paths, and the technical change that makes the site public. Record what each person reviewed and what remains open.
A launch approval is different from a technical test. A button can work perfectly and still take a guest to the wrong location. A menu can look good on a phone and still contain an old price. The goal is to have a named person confirm both the facts and the guest-facing result before launch.
Choose reviewers and give them the right inputs
Start with a short list of decisions, not a long list of job titles. In a small restaurant, one person may hold several roles. That is fine as long as each approval is explicit and the final decision-maker can see what was checked.
- Owner or general manager: Confirms the business name, locations, contact details, hours, key policies and final launch decision. This person also decides whether an unresolved issue is acceptable.
- Menu owner: Usually the chef, kitchen manager or menu administrator. Confirms items, descriptions, prices, modifiers and availability against the current approved menu.
- Front-of-house or service lead: Checks whether reservation instructions, contact routes and guest-facing policies match how the team operates. This person can flag wording that will cause confusion during service.
- Ordering lead: Confirms that ordering links lead to the intended restaurant and that the menu and fulfillment instructions match the operation. This may be the same person who owns the menu.
- Website or technical contact: Identifies the site version being approved, confirms access to the domain and publishing controls, and explains how to publish or reverse the change. This may be an employee, agency or website provider.
- Mobile reviewer: Reviews the guest journey on a phone and reports content or usability problems. A manager can assign this check to someone who did not build the pages.
Give reviewers a single launch candidate: the preview address, the version or date, and a list of pages and links included. Also provide the current menu, approved hours, location details, reservation instructions and the intended ordering destination. Without a common set of inputs, people can approve different versions without realizing it.
Decide who can change the content after review. If a menu price or ordering link changes, the relevant owner should review that change again. A minor spelling correction may only need the content owner; a change to pickup hours needs the operations lead as well.
Connect each approval to evidence
Use a shared document or project board for the matrix below. An approval should point to something another person can inspect: a dated menu, a page preview, a destination address or a short record of a simulated check. A message saying “looks good” is not enough to show which version or detail was approved.
| Area | Approver | Evidence to record | Decision rule |
|---|---|---|---|
| Business facts and policies | Owner or general manager | Preview pages compared with current hours, address, phone and service policies | Correct guest-facing facts before launch |
| Menu and prices | Menu owner | Dated approved menu compared with website items, prices and modifiers | Resolve price or availability differences |
| Ordering and reservations | Ordering lead and service lead | Destination addresses and simulated guest paths for the intended location | Correct wrong destinations or misleading instructions |
| Domain and publishing | Technical contact | Domain access owner, publication steps and reversal contact | Do not publish without an agreed recovery route |
| Mobile content and forms | Mobile reviewer and service lead | Phone review notes, form destination and simulated submission method | Resolve problems that stop guests completing essential tasks |
| Final release | Owner or delegated manager | Recorded approvals, open issues and launch time | Publish only after blockers are closed. Document any accepted non-blocking follow-up. |
For business facts, compare the page with a source the restaurant already uses to run service. Check special hours and location-specific details separately; a correct main address does not prove that every location page is correct. Ask the service lead whether a policy is clear enough for a guest to act on, not just whether the words are technically accurate.
For the menu, review the items a guest can actually select, not only the visual menu page. If the site links to a separate online ordering experience, assign someone to compare both places. Agree which menu is authoritative if the two differ and who will update it after launch.
For links and forms, record where each one should go. A reservation button might open an external booking page, call the restaurant or show instructions. A contact form needs a named recipient and a person responsible for monitoring it. Ask the provider how to verify the destination without sending a real guest message, and who can change the recipient later.
The technical contact should explain who controls the domain account, who can publish changes and who can restore the previous destination or site. The owner does not need to perform the technical work, but should know whom to call and whether that person is available at launch. If you are still choosing a provider, use the restaurant website builder comparison to develop questions about ownership and editing access.
Log issues, owners and evidence before release
Keep one issue log beside the approval matrix. For each item, record the affected page or path, the problem, its impact on a guest, the owner, the target resolution time and its status. Add a link or description of the evidence used to close it. The final decision-maker should see the same log as the people fixing the site.
Separate blockers from follow-up work. A wrong price, an ordering link to another location or an unmonitored contact form can mislead guests or interrupt service. Those are strong candidates to fix before publication. A low-impact wording change may be suitable for a dated follow-up if the owner accepts it. Do not treat an issue as closed merely because someone has been assigned to fix it; the relevant reviewer needs to check the correction.
Hypothetical example: A two-location restaurant is preparing a new site. The menu owner compares the preview with the approved menu and finds that a sandwich is listed at $14 on the site but $15 on the current menu. The ordering lead also finds that the downtown page's order button points to the uptown ordering destination. The mobile reviewer notes that a paragraph wraps awkwardly but remains readable.
The manager logs the price and destination as blockers. The menu owner supplies the correct price, and the website contact updates the page. The ordering lead supplies the intended destination and checks the corrected button in the preview. Both reviewers record the version and time of their recheck. The manager accepts the paragraph wrapping as a follow-up, assigns it to the content owner and sets a due date.
These checks establish that the reviewers saw the corrected content and destination in the preview. They do not establish that a real order was received or fulfilled. For a practice run, use a simulated or provider-supported test path. Do not require a real card payment, guest message or courier dispatch. Ask the provider how test orders and form submissions can be handled safely before conducting them.
A later live service pilot is a separate decision. If the restaurant chooses one, agree on who monitors it, which limited guest-facing functions are in scope, how genuine requests will be handled and when to stop. Do not call a simulated check a live pilot, or treat a pilot as proof that every future order will work.
If a builder produces draft copy or menu content, the restaurant still needs an owner for each claim. Ask who can edit the draft, how changes appear on mobile and how the ordering connection is maintained. The related buying guide offers more questions to use when evaluating a builder.
Make the launch decision and prepare a reversal
Set a decision meeting or message thread shortly before the planned launch. The owner or delegated manager should review the matrix, the issue log and the exact site version. Ask each approver for a clear status: approved, approved with a named follow-up, or not approved. Record the person's name and the time. Silence should not count as approval.
The decision record can be short: “Publish version dated Monday at 10 a.m.; menu, business facts, links and domain approved; mobile wording issue assigned for Wednesday.” It should also name the person who will publish and the person who will verify that the intended public site is showing. If a blocker remains, record a no-go decision and the next review time rather than leaving the launch in limbo.
Choose a launch window when the restaurant and technical contact can respond. Avoid making the change immediately before a busy service if nobody can check a guest-facing problem. Tell staff what is changing, where customers may be directed and whom to notify if they spot an issue.
Before publishing, write down the rollback contact, their backup and their contact method. Agree on the trigger: for example, a public ordering button going to the wrong location or the site showing an outdated menu. Ask the technical contact what reversal means for this setup, who has permission to perform it and what must be saved beforehand. A rollback may involve restoring a previous site or changing a domain destination; the right procedure depends on the setup.
After publication, have the assigned reviewer check the public address and essential links against the approved record. Use safe simulated checks where available. If the public result differs from the approved version, pause promotion and contact the person authorized to correct or reverse the change. Record any changes made after launch so the restaurant knows which approvals need repeating.
Next step: Copy the matrix into your launch document, assign names and review your current setup. If you are considering a Fleksa restaurant website, ask Fleksa about verified availability in your US location and how domain, editing and ordering setup would work for your restaurant.
Frequently asked questions
Who gives final approval for a restaurant website?
The owner or a delegated manager should make the final go or no-go decision after the menu, operations and technical reviewers have recorded their approvals and open issues.
Should the person who built the site approve everything?
No. The builder can confirm publishing steps and report technical checks, but restaurant staff should approve business facts, menu details and service instructions. An independent mobile review can also catch confusing content.
What happens if content changes after approval?
Record the change and ask the owner of that area to review it again. If it affects an essential guest journey, such as ordering or reservations, include the relevant operations reviewer before publishing it.
