Forno Template: A Restaurant Site With Table Booking
Forno Template: A Restaurant Site With Table Booking
Forno is one of the 25 ready-made Zugo templates: a restaurant site with a full menu, an origin story, opening hours, a location block and a guest area for booking and managing tables. Cloning it into your project costs no credits, and everything after that is done by writing sentences in chat.
Below: what actually ships in the file, which parts of a restaurant site people always underestimate, how to swap in your own menu without a mess, and where the honest limits of a template like this are.
What does the Forno template include?
Forno sits in the website group, so most of it is content rather than state, with one exception: the booking area behaves like an app. The three screens follow the same pattern every non game template uses, but the dashboard here belongs to a guest rather than an admin.
| Screen | What it holds | Where the work usually goes |
|---|---|---|
| Main page | Hero with the founding year, story section, four signature dishes, full menu by course, hours, address, phone | Menu items and prices, story, photos |
| Guest access | Name and email entry, Google button, a guest quote, no password | Wording, then a real notification path |
| Guest area | Booking form with date, time slots, party size and a note, plus a list of upcoming tables | Time slots, maximum party size, the confirmation text |
The menu is the largest part of the file and it is structured properly: courses (starters, pizza, pasta, dessert and wine), a price on every line, a one sentence description, and dietary tags such as vegetarian, vegan option and spicy. The demo prices are in euro because the restaurant is Italian, and currency is a one line edit.
Two small pieces deserve protection when you rewrite it. The opening hours table lists every day including the closed one, and it notes that the kitchen shuts before the door does. Guests ask both questions constantly, and a site that answers them stops a phone call.
Who should start from Forno rather than a prompt?
The best fit is an independent restaurant, trattoria, pizzeria or bistro with a real menu and a story worth telling. The template assumes you have something specific to say about how the food is made, and it gives that a whole section rather than a line.
It adapts cleanly to neighbours: a wine bar, a bakery, a coffee roaster, a small hotel restaurant. What carries over is the shape, a long menu with prices plus a booking path, and only the vocabulary changes. If you want the wider version of this job, see building a restaurant site with AI.
It fits less well where the menu is not the point. A dark kitchen selling only through delivery apps needs ordering, not booking. A canteen with a menu that changes daily needs an editable menu source rather than text baked into a page.
And it is the wrong starting point for a chain. Multiple locations, each with its own hours, menu and booking pool, is a platform rather than a page, and that is a different build with a different price.
How do you put your own menu in without breaking the layout?
Menus are where template edits go wrong, because people paste forty items into one message and get back a wall. Feed it by course instead, one edit per course, and check the page after each one.
- Do the identity first: "rename it to Osteria Bruna, founded 2011, replace the wood fired story with a story about handmade pasta, and use a green and cream palette".
- Then one course at a time: "replace the pizza section with eight pasta dishes, keeping the same layout, price and one line description for each" followed by the same for starters and desserts.
- Fix the currency and any tags: "prices in dollars, and add a gluten free tag alongside the vegetarian one".
- Correct the practical block: "these are the real opening hours, this is the address, and the phone number goes in the header too".
- Only then adjust the booking rules, because they depend on how the restaurant actually runs.
The order is not decorative. Identity edits rewrite copy across every section, so doing them after your menu is in means paying to have your own menu paraphrased. Every rebuild is opened in a sandbox before delivery, so a bad edit costs one credit charge and a minute, not an evening of debugging.
What does adapting Forno cost in credits?
Cloning the template costs nothing, because the finished page is copied into your project without calling the model. A menu heavy site simply needs more edits than a landing page does, and that is the whole of the maths.
| Action | Credits | Notes |
|---|---|---|
| Clone the template | none | A copy of a finished page, no AI |
| One chat edit | 3 | One course, one section, one rule |
| Full rebuild | 6 | When redoing beats correcting |
| Multi page platform, first three pages | 12 | Separate pages for menu, events and contact |
| Each page beyond the first three | 3 | For example a private dining page |
| Hi-Fi edit | 6 | Double the standard mode |
| Hi-Fi build | 12 | Same doubling |
Free includes 5 credits, which covers the clone and one edit, enough to see your own name on the hero. Pro is $25 a month with 200 credits, roughly 66 edits, and Business is $99 a month with 800. A restaurant with four courses and a rewritten story usually needs somewhere between eight and fifteen edits, so a full menu swap fits inside a single Pro month with plenty left.
What has to be connected before the booking is real?
The booking form in the template collects a date, a time, a party size and a note, and then confirms on screen. Nobody in the kitchen learns about it. That is the gap between a demo and a working restaurant site, and it takes two connectors to close.
Resend sends the email: one to the guest confirming the table, one to the restaurant inbox so the booking exists somewhere other than a browser. Ask for both in the same edit, because a confirmation the guest never receives is worse than no confirmation at all.
Supabase stores the bookings and gives them an owner, which is what makes the guest area list real reservations instead of an empty state. It also lets you block a slot once it is taken rather than accepting six parties at eight o'clock.
After that: your own domain, because a restaurant on a subdomain looks temporary, and Google Analytics to see whether people reach the booking form or leave at the menu. The domain step is covered in using your own domain, and the booking mechanics more generally in building a booking site with AI.
What will Forno not do for you?
Three limits, stated plainly, because a restaurant owner deserves to know them before spending an evening.
It is not a reservation system. There is no table map, no capacity model, no double booking protection and no integration with the systems your front of house may already use. You can build a simple version of the rules with edits, but if you already run a proper booking platform, embedding it is the sane move.
It does not take orders or payments. Delivery, pickup, a checkout with a basket: that is a storefront, and a different template starts closer to it. Stripe can be connected for deposits on large parties, which is a much smaller job than online ordering.
And the photography is on you. The template ships with generated imagery and it looks good, but a restaurant site lives or dies on real photographs of real plates. No builder fixes that, and it is the highest return hour you can spend on the project.
Where to start with your own version
Open the gallery, find Forno under websites, and preview it on a phone rather than a laptop. Most restaurant traffic arrives on a phone, usually while someone is deciding where to eat in the next hour, and that is the view that has to work.
Then go in order: identity, menu by course, practical details, booking rules, domain, notifications. Because the clone is free, the only thing you spend on a wrong turn is the edit itself.
The template is waiting at zugo.dev. Free credits are enough to get your own name, your own story and your first course onto the page, which is usually the point where you can tell whether the rest is worth doing.