Companion & communication
Reservation & inquiry router
Friday evening, service in full swing, and the phone rings: a table booking for next week. The call before was about a wedding, the one before that about opening hours on the bank holiday. Three different requests – one overloaded line.
You'll get …
- 1
A clear path for every request
Table, group, event or quick question: after two questions, every guest sees their next step.
- 2
A quieter phone during service
Fewer calls that should have been bookings – your staff look after guests in the evening instead of manning a switchboard.
- 3
Event inquiries with all the details
Date and party size arrive with the inquiry, and bookings that can be planned go straight into the booking tool.
01Intro
The router sorts these requests before they reach the phone: table, room, group, event or quick question – two questions on the website, and every guest is at the right next step. Bookings that can be planned go straight into the booking tool, event inquiries arrive with the date and party size, and last-minute requests get the phone. For you, that means front-of-house staff who look after guests in the evening instead of manning a switchboard.
The router is the signpost BEFORE the inquiry – it replaces neither a reservation system nor event planning advice. Preparing an event inquiry properly for your team is a separate building block (the event inquiry qualifier). The two work well together, but each also works on its own.
02How it works
- 01
Map your paths
What comes in – tables, rooms, groups, events, small questions? Which paths exist for them today, and where do requests end up in the wrong place? That gives us the map the router works from.
- 02
Find the deciding questions
Two are usually enough: what's it about, and when or for how many? Worded the way guests talk ("there are 25 of us and we're looking for something for Juli's birthday") – not the way a form thinks.
- 03
Build the flow and embed it
The router becomes part of your website – a guided flow in your own design, not a third-party widget. It sits where guests arrive: home page, menu, events page.
- 04
Connect the end points
Every outcome leads somewhere: booking tool, short group form, event callback, phone or WhatsApp. No path is a dead end – and no guest ends up in the catch-all contact form.
- 05
Observe and refine
After a few weeks you can see where guests drop out or take a different turn than expected. We then adjust the questions and paths – the router improves with real guests.
03Stages
The router is one of the most rewarding places to start. Tier 1 needs no AI at all and takes pressure off the phone and your staff straight away.
Starter: the guided path
A rule-based flow with fixed questions and clear branches: table, group, event, question. Reliable, quick to build, measurable from day one.
Next step: it understands free text
Guests can just start typing – an AI works out what they want and drops them into the flow at the right point. The branching behind it stays rule-based.
Full build: deeply connected
The router passes inquiries straight to your reservation system and event process, adapts the website to what the guest is after and shows you in a report what guests are looking for.
04Try it yourself
You're a visitor to the website of the “Zur Linde” inn. Instead of one contact form for everything: two questions. Try different paths through.
No magic: behind it is a switch – questions with clear branches. That's exactly why Tier 1 is so reliable: no AI that could guess. Only when visitors are meant to phrase things freely (Tier 2) does a language model classify the entry point – the switches stay.
Play a path through in the “try it out” tab – it lights up here.
05Technical implementation
- The router lives on your website – no external widget window, no third-party branding.
- Tier 1 is a decision tree: fixed questions, fixed branches. Unexciting, which is why it's reliable – even in the Christmas rush.
- From Tier 2, a language model helps at the start: it interprets requests in the guest's own words – the branching behind it stays rule-based and predictable.
- The underlying data model: rooms, capacities, inquiry paths and criteria in a clean structure – the same foundation an FAQ assistant or knowledge catalog can build on later.
- Handovers as needed: reservation tool (e.g. OpenTable, resmio), email, event form – or the phone, where that's the quickest route.
- Built on your website's existing stack; Tier 2 adds a small back end.
for context · This shows how something like this usually gets built – not how it has to be built for you. What actually fits is worked out in the project: around your existing setup, your team, and what stays easy to maintain.