Answering the inquiry that arrives at 9pm on a Friday

The weekend was the whole problem

The response window was not part of the product. It was the product.

One body of knowledge, more than one door

We did not start by choosing a channel. We started by writing down what the venue knows — the spaces, the policies, what is on the calendar — once, in a form a machine can answer from. Everything after that is a door onto the same knowledge.

1. 01

   Answer on the website, while they are still curious

   A chat assistant grounded in the venue’s own material, so a visitor at nine on a Friday gets a real answer instead of a contact form and a wait. This is the cheapest possible win: the questions were already answered on the site, just not in a form anyone could get at quickly.

2. 02

   Answer in the inbox, under their name

   Chat is forgiving. It is obviously a machine, and a poor answer scrolls away. Email is not: it arrives under the family’s name, from a person the reader thinks they are now talking to, and it cannot be unsent. So email became a second door onto the same knowledge rather than a second system to maintain, and it is deliberately more cautious than the widget. It drafts, a person approves, and sending unattended is something the venue switches on one category at a time, once it has read enough drafts to trust that category. Where they would rather send their own words than ours, the reply is their existing introduction with only the specific question answered around it.

3. 03

   Qualify before spending the scarce thing

   Speed alone would have filled the calendar with tours that were never going to close. So the system establishes fit — the kind of event, roughly when, roughly how big — before a booking link ever appears. The two hours a tour costs get spent on people who might actually book.

4. 04

   Leave the operators in charge

   Every judgment call the venue would want to make itself is configuration, not code: hours, policies, when to escalate to a person, and what the system may send on its own versus what it must hold for review. Changing how it behaves does not require us, which is the difference between a tool they own and a tool they rent.

How the assistant actually answers

Deliberately boring in shape: a door, a pipeline, and a body of knowledge that is refreshed on a schedule. The interesting part is not that it can write — everything can write now — but what it refuses to do.

• Most questions never reach the expensive model. A repeat question comes back from a cache almost immediately, and only a question that genuinely needs reasoning gets the slower, more capable path. Cost and speed both fall out of that, without anyone tuning a budget.
• What is on the calendar is always in front of it. "What is happening next weekend" is not a question you can answer by finding similar text, so the coming fortnight is put in front of the assistant on every question rather than left to be searched for.
• A deterministic check sits after the model and can discard its answer. It compares the draft against a plainly written list of things the venue does not have or does not do. This is the part we would keep if we could only keep one: it is ordinary code, not another prompt, so no amount of clever phrasing from a visitor can talk it out of doing its job.
• When the assistant is not confident, the question is off-topic, or someone sounds upset, it stops and hands over to a person with the conversation attached, rather than guessing. Raising a flag to the team is separate from deciding what to do with the reply, so a message can be answered and still get someone’s attention.
• On the email side the work runs as a short series of stages: decide whether a message deserves a reply at all, work out what kind of inquiry it is, pull the relevant knowledge, compose, and only then decide what to do with the result. Exactly one of those stages is allowed to put mail in a customer’s inbox. Every stage before it can read or draft and nothing else, so the number of places capable of sending something wrong is one, and it is the one under the most scrutiny.
• A wedding is not a private event. They are different packages, in different spaces, at different money, and answering one as though it were the other wastes an afternoon on both sides. So what kind of booking an inquiry is about is decided explicitly and held as settings the venue controls — including which kinds are mutually exclusive — rather than being left for a model to infer from a paragraph of prose.
• Nobody gets answered twice. Handling the same message again is deliberately a no-op, because the failure people actually remember is the system that replied to them four times.
• Anything not answered outright still gets an immediate acknowledgement and joins a queue for a person, so the outcome is never silence while someone catches up.
• The knowledge is rebuilt from the venue’s own material every night. Corrections a person makes by hand are re-applied on top of every rebuild, so the automatic refresh can never quietly undo something a human fixed on purpose.

What changed

Every figure we publish is one the client has confirmed. We do not have confirmed numbers for this engagement yet, so what follows is described rather than counted. When Union Exchange is ready to put figures behind them, they will appear here and not before.

Speed to response

A visitor on the website gets an answer in about the time it takes to read it. An inquiry that arrives by email is answered or acknowledged straight away, rather than waiting for someone to come off the property and open a laptop.

Weekend coverage

Friday evening to Tuesday morning is the venue’s busiest window for new inquiries and the one nobody was free to work. It is now covered without anyone watching an inbox.

Nothing lands in a void

Every legitimate inquiry gets at least an immediate acknowledgement, and anything the assistant should not answer alone reaches a person with the context attached. Silence is no longer one of the possible outcomes.

Breadth

It answers across the venue’s revenue lines rather than weddings alone, so a corporate booking or a cabin question gets the same treatment as a marquee wedding inquiry.

Under the hood

Interfaces

• Embedded web chat
• Email

Reasoning

• Tiered LLM routing
• Retrieval over the venue’s own material

Platform

• Serverless containers
• Managed document store
• Scheduled refresh jobs

Operations

• Configuration-driven behavior
• Human review queue
• Tracing and alerting