Restaurant Thomas

Restaurant Thomas is a dedicated public website for the restaurant side of the Thomas ecosystem. It is separate from the catering operations platform: this surface is about the restaurant, Biergarten, event location, Refektorium, inquiry paths, and local search visibility.

The project matters because the restaurant and catering surfaces have different jobs. A catering configurator needs operational detail and offer flows. A restaurant site needs trust, atmosphere, local clarity, event information, and simple ways for guests to inquire. Splitting the two makes both surfaces easier to understand.

What it supports

• Public restaurant, Biergarten, and event-location pages.
• Local Geldern positioning and structured SEO foundations.
• Inquiry flows for groups, events, and restaurant-related requests.
• Schema, metadata, llms.txt, and public images for machine-readable and search-friendly context.
• Safer fallback behavior for customer inquiries.
• Clear links between the restaurant site and the catering surface where appropriate.

Why this project exists

The Thomas ecosystem includes more than one customer journey. Someone looking for a local restaurant experience is not necessarily ready for a catering configurator. Someone planning an event may need venue context before discussing menus. Someone searching locally needs a page that matches their intent, not a generic business homepage.

Restaurant Thomas gives those journeys their own public home. It can talk about the place, the Biergarten, the Refektorium, group inquiries, and local event context without overloading the catering operations platform.

Recent work from local commits

The recent commits show a fast build from initial site to practical fixes: page structure, schema, llms.txt, inquiry handling, group-size copy, and header links.

The first foundation pass started the Next.js restaurant website with public pages, images, metadata, structured schema, and local Geldern positioning. Later fixes tightened group-size copy so the offer matches how guests understand restaurant bookings, improved the inquiry email fallback, and fixed the Catering Online header link so the restaurant surface connects correctly to the catering product.

Product story

This project is not just “make a restaurant website.” It is a separation-of-concerns project. The public restaurant brand needs a warm, local, trustworthy surface. The catering platform needs a more operational, conversion-focused flow. Keeping them distinct prevents the restaurant story from being swallowed by software mechanics.

That separation also helps SEO. Restaurant, Biergarten, event location, and catering queries can each have clearer surfaces instead of fighting over one generic page.

Current direction

The next useful steps are deeper page content, stronger local event positioning, more polished inquiry UX, and better cross-linking between restaurant/event pages and the catering configurator where the intent actually matches.

Public boundary

This page describes the public website and customer-facing flows. It does not expose private inquiries, customer data, internal email configuration, credentials, or operational restaurant details that should stay private.