Web design · Restaurants
A restaurant sitewith the menu in text.
Hours, address, prices, and a way to reserve or order. A photograph of last spring's menu is not a menu.
The short answer
What the site has to answer before the guest gives up.
A guest is deciding tonight or this Friday. They need the hours, the location, the dishes and prices as text, and a reservation or order path that matches how you actually seat people. Seasonal menus have to be editable by the person who already changes the specials. We build the menu and the ordering path so they can be used without a mouse. We do not certify the site, and we do not claim a badge for it.
Buying cycle
Tonight is a different visit from a celebration.
A weeknight decision is fast: are you open, how far, what is on the menu, is there a table. A birthday or a buyout needs a date, a headcount, and a person. Those should not be the same button. A homepage that autoplays a dish and hides the hours is aimed at nobody.
Hours, menus, and the book are often different across rooms. One address in the footer sends a guest to the room that is dark on Mondays.
Constraints
HTML menus, real hours, a book you already use.
The menu is HTML. Dish, price, and a short description are text a manager can edit. A JPG or a PDF is frozen the day it was exported, and it is miserable on a phone. Photos can support a dish. They do not replace the list. Wine and brunch follow the same rule.
Reservations hand off to the system you already pay for. We do not invent a reservation product, and we do not badge a company we have no agreement with. If you seat by phone only, the phone is the action. Parties above the size your book allows get a short inquiry, not a two-top widget that will reject them.
Holiday hours and seasonal menus need an end date. A July prix fixe that is still the hero in October is a trust problem. Allergen notes, if you publish them, have an owner in the kitchen. We will not invent them.
- Each location has its own hours, address, and menu when those differ.
- Specials and holiday hours are dated modules, not a hardcoded banner.
- Large-party and private-dining inquiries are separate from a standard reservation.
- Menu and ordering controls have visible names and work from a keyboard.
- No overlay that claims the site is certified. Accessibility of the menu is a build requirement, not a badge.
Channels and KPIs
Tables, directions, and the dish.
The numbers that matter are reservation handoffs, completed reserves if your book can report them, direction requests, and pickup or order starts if you do that. Calls for parties the widget cannot take belong on the scorecard too. A spike in homepage video plays is not a Friday service.
- Reservation clicks and, when the book provides it, seated covers from the site.
- Menu page use on a phone, which collapses when the menu is an image.
- Hours accuracy checked against the door, especially around holidays.
- Private-dining inquiries kept separate from two-top reserves.
Mistakes
Last month's brunch, photographed.
The failure mode is familiar. A beautiful film of the dining room, a menu that is a picture, hours that match the grand opening, and an email popup before the guest can read a price. Multi-location groups add a single 'locations' page that lists four rooms with one set of hours.
- No menu trapped in a JPG, a PDF, or a slideshow.
- No hours that live only on a social profile and contradict the site.
- No reservation button that opens a book for a room you closed.
- No popup that covers the hours on a phone.
Example engagement
Three dining rooms, one brand.
A small group, three dining rooms, different hours. The site was one homepage and a menu JPG that had survived two seasons. The reservation number rang the original room, including for the room that does not take reservations.
We built location pages, put the menus in HTML, and handed standard tables to the reservation product they were already paying for. Large parties got a short form. Holiday hours got an end date. We did not add a certification badge.
HTML
Menus a manager can edit as text
3
Dining rooms with their own hours
The example uses anonymized results from a Quorum engagement. It is one account, not a benchmark you should budget against.
Questions
Restaurants questions.
Can we keep the menu as a designed PDF?
You can hand guests a PDF in the restaurant. The site still needs the dishes and prices as text. A download can sit beside the HTML menu. It cannot be the only menu.
Will you build a reservation system?
No. We connect the site to the book you already use, or we put the phone on the page if that is how you seat people. A custom booking product is a different project.
How do seasonal menus work?
A manager edits the dish list, or swaps a dated section, without calling a developer and without exporting a new image. If the only person who can change a price is the agency, the menu will be wrong.
What about online ordering?
If you already use an ordering product for pickup, we hand off to it from the location that actually cooks that order. We do not stand up a second menu that drifts from the first.
Is the site ADA certified when you launch?
No. We do not certify, and we do not install an overlay that claims we did. Menus as text, named buttons, and a keyboard path through reservation or ordering are build requirements. A formal program is a separate service.
How long does this take?
With menus in text, hours confirmed, and the reservation handoff known, a marketing site most often ships in 8 to 12 weeks. Waiting on a photographer is the usual slip, and it should not block the menu from going live as text.
More in this lane
Other Web Design industries.
Talk through restaurants.
One conversation. A diagnostic. A plan you can kill if it is not the work.