Before design begins, give your website provider one organized set of approved business details, menus, brand assets, guest links, and instructions for who can answer questions and approve the work. The goal is to give the designer enough reliable material to build useful pages without guessing what guests need or which version is current.
You do not need polished website copy for every page. You do need to identify what is ready to publish, what still needs a decision, and who owns that decision. A shared folder and a short handover document are enough if they are clearly labeled and kept up to date.
Gather approved menus and business details
Start with the information a guest needs to decide whether to visit or order. Ask the person responsible for each item to confirm it, rather than copying details from an old website or a third-party listing.
- Restaurant basics: approved business name, address, phone number, public email, and a short description of the restaurant.
- Hours: regular opening hours, service times that differ from opening hours, and an instruction for how special hours will be updated.
- Menus: current food and drink menus, prices, descriptions, and any separate brunch, catering, or takeout menus the site should show.
- Guest information: accessibility information you can verify, parking or arrival instructions, and policies you want published.
- Locations: the correct details for each location, including any differences in hours, menus, or ordering destinations.
The general manager may confirm hours and contact details, while the chef or menu manager approves dish names and descriptions. For multiple locations, assign a person at each one to check its information. Put an approval date on each file so the provider can tell a current menu from an earlier draft.
Provide editable text where possible, even if you also send a designed PDF. A PDF can show the intended presentation, but editable text makes corrections easier and gives the provider more options for displaying the menu on a phone. If prices or dishes change frequently, explain who will make future updates and how quickly they need to appear.
Separate facts from unfinished copy. For example, send a short list of ingredients and the approved dish name if the description still needs writing. Do not ask the provider to infer allergens, service policies, or availability from a photo. Have the appropriate person at the restaurant check those details before publication.
Record brand assets and usage rights
Put your logo, photographs, and any existing brand guidance in their own folder. For each asset, give the provider a useful file name and a note about where it may be used. A logo file labeled with its format and version is more useful than several files named “final.”
Include the original logo files if you have them, plus any approved colors, fonts, and examples of materials that look like your restaurant. Tell the provider what should remain consistent and where they have room to make design choices. If you have no formal brand guide, a few clear preferences are better than a collection of unrelated inspiration screenshots.
For photographs, identify the subject and whether the image represents the current menu, location, or team. Choose a small set of strong, current pictures rather than handing over every photo from a shoot. If an image shows a dish that is no longer sold, say whether it can still be used as a general atmosphere image or should be excluded.
Also record who supplied each image and whether you have permission for the intended website use. Flag images containing recognizable people, third-party artwork, or other material that may need additional permission. Do not assume that a photo found on social media is available for the site. If rights are unclear, set the image aside and ask the relevant rights holder or a qualified adviser.
There is a practical trade-off between speed and control. Sending only a flattened logo and a few screenshots may get a design started, but it can limit how the provider adapts the brand across page sizes. Original files give the designer more flexibility; your brief should still say which elements require approval before they change.
List guest tasks and their destinations
Tell the provider what guests should be able to do first, then supply the destination for each action. Typical tasks include viewing a menu, placing an order, requesting a table, calling the restaurant, or finding directions. Put these in priority order instead of asking every button to be the most prominent.
For each task, provide the current link or contact detail, say which locations it applies to, and name the person who can confirm it. If you are considering online ordering, explain whether the website should link to an existing ordering destination or whether that destination is still being selected. Ask the provider how guests will return to the site and how the destination will be maintained.
Hypothetical example: A neighborhood restaurant wants guests to view the dinner menu, order pickup, and request a table. Its manager supplies the approved dinner menu, a pickup link for the single location, and a reservation link. The owner makes pickup the first button and asks for the menu and reservation options to remain easy to find on a phone.
Before launch, the provider can walk through those paths in a safe test environment or use non-submitting checks: open the menu, follow the links, and check that the correct location and service appear. Stop before submitting a real order or reservation, charging a card, sending a guest message, or dispatching a courier. This checks navigation, not whether every live transaction will succeed. Agree separately on any live pilot and its controls.
Use the following handover checklist to turn those decisions into a package the provider can act on. The listed owner is the restaurant contact responsible for confirming the item; the provider may still format or implement it.
| Handover item | What to supply | Restaurant owner | Ready when |
|---|---|---|---|
| Business details | Address, contact details, hours, and location differences | General manager | Each location has confirmed its details |
| Menus | Editable text, prices, and current menu files | Chef or menu manager | Items and descriptions are approved for publication |
| Brand assets | Logo files, selected photos, and usage notes | Marketing contact or owner | Versions and permitted uses are identified |
| Guest actions | Priority tasks, links, and location rules | Operations manager | Each destination and its owner are confirmed |
| Approvals | Primary contact, backup, and final approver | Restaurant owner | The provider knows whom to ask and who decides |
Adapt the roles to your team. In a small restaurant, one person may own several rows; what matters is that each item has a named decision-maker and is not left for the designer to guess.
Assign a contact for questions and approval
Choose one person to collect questions from the provider and coordinate answers internally. That person does not have to make every decision, but they should know who can. Name a backup for days off or busy service periods, and identify the final approver for design and content.
Agree on a simple review process before work starts. Decide where the provider should send drafts, how feedback will be collected, and when the restaurant expects to respond. Ask reviewers to combine their comments into one set of instructions. If the chef requests one menu description and the owner requests another, settle the conflict before sending feedback.
Make the status of each item visible: approved, awaiting a named person's decision, or not for publication. Keep one current folder and move superseded files out of it. When a menu or opening hour changes during the project, tell the provider directly rather than silently replacing a file they may already have used.
Include the existing domain and site arrangements in the handover. Identify the account owner and ask the provider what access is actually needed, who will make domain changes, and how access will be removed after the project. Share credentials through an agreed secure method, not in a document sent to a wide group. The domain ownership guide covers questions to settle before access changes.
Finally, confirm the boundaries of the work. Ask who will write missing copy, prepare images, enter menus, connect guest destinations, and handle later updates. Get any additional work and its cost in writing. A complete handover reduces avoidable questions, but it cannot replace agreement about what the provider is responsible for delivering.
Use the checklist to review your current files and links, then ask Fleksa about its restaurant website options and verified availability in your US location.
Frequently asked questions
Do I need finished website copy before design starts?
No. Supply approved facts, menu text, and a short description of the restaurant. Identify missing copy and agree on who will write and approve it before it is published.
Should I give the provider access to every account?
No. First ask what access is needed for the agreed work and who will make each change. Keep a record of access and arrange to remove it when it is no longer needed.
What if my menu changes during the project?
Give the provider one updated, approved version and tell them what changed. Agree on who will make future updates and how those updates will be requested after launch.
