Companion & communication
FAQ & first-contact assistant
Are you open today? Do you have gluten-free dishes? Where do we park? Can we bring a dog? – Every one of these questions is fair. And every one is interrupting someone mid-service right now.
Website companion & knowledge chat
01Intro
The FAQ & first-contact assistant answers the recurring questions right on the website – instantly, warmly, in the tone of the house. It knows your opening hours including holiday exceptions, the menu with allergens, the rooms, the cancellation rules and the parking situation. And it leads on: whoever asks about the hall gets the way to the event inquiry; whoever wants to reserve lands in the booking tool. What it doesn't know for sure – the very personal question about accessibility in detail, say – it deliberately hands to your team, with context rather than a dead end. The phone still rings after that. But for bookings, not for parking.
Straight up: the assistant needs a maintained knowledge base – opening hours that change quietly make every chat lose credibility. Solid groundwork and a clear plan for ongoing knowledge upkeep are therefore an essential part of the project. And with personal or delicate questions it hands over to a person rather than guessing.
02Demo
The companion of the fictional “Alte Mühle” event venue. Ask one of the three questions – and watch two things: where the answer comes from, and what next step the companion offers you.
The living example: Neo, the companion of this website, works exactly to this pattern – only with a real language model. Ask him in the bottom right.
The companion invents nothing: it answers from a curated knowledge base built from your content. And for anything that needs judgement or expertise, there's the built-in switch to a human.
The most important part is the least conspicuous: the maintained knowledge base on the left. It decides whether the companion is useful or merely polite.
03How it works
- 01
Gather the real guest questions
What does your service get asked daily, what's in the emails, what rings through on the phone? Out of this comes the list of questions the assistant must handle – usually 30 to 50 that cover 90 per cent.
- 02
Build the knowledge base
Opening hours with exceptions, menu and allergens, rooms and capacities, directions, rules: the house knowledge gets structured – often the first time it lives in one place at all.
- 03
Define tone and limits
Warm or restrained, formal or casual, when does it offer the reservation, what does it hand straight to the team? That's set before it says a word.
- 04
Embed it where guests are
The assistant becomes part of your website – mobile first, because that's where guests look up opening hours. In the design of the house, not as a foreign widget.
- 05
Watch and sharpen
The conversations show what guests really ask – out of that come better answers and sometimes a hint about what's missing on the website. After the first season the assistant knows your business.
04Stages
The entry point is deliberately limited – above all an assistant in hospitality has to be dependable, especially on hours and prices.
Entry: the FAQ assistant
Curated knowledge on hours, menu, rooms and rules, tight guardrails, a clean handover to phone and email. Reliable rather than all-knowing.
Extended: first contact with handover
The assistant sorts concerns and hands them over in a structured way: reservation to the tool, event to the inquiry, special case to the team – as a usable message, not a chat transcript.
Full build: the thinking companion
The assistant quietly adapts the website to the concern and works with tools – the model you're experiencing on this page right now.
05Technical implementation
- At its core is a language model with the curated house knowledge base as context – at typical volumes cached rather than run through a vector database.
- The assistant runs as a component in your website with its own small back end; no foreign branding, no external widget window.
- Tool connections as needed: a link to the reservation tool, a handover to the event inquiry, a contact switch to the team.
- Guardrails on two levels: behaviour rules in the prompt plus technical limits in the back end (rate limiting, input limits, moderation).
- Data minimisation as the default: what's stored is what's agreed – contact data kept separate and only with consent.
- Running costs stay manageable: a warm answer typically costs a few cents – that's measured, not guessed.
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.