Support
Most questions arrive when nobody is there to answer them.
A local business site gets a narrow, repetitive set of questions, and gets most of them outside opening hours. That combination is unusually well suited to an assistant, because the answers are short, stable and already written down.
- Private launchOnboarding selected teams now
- Built by CreoglyphSeven client engagements behind the product
A narrow question set, asked at the wrong time
Opening hours, location and parking, whether a service is offered, roughly what it costs, and how to book. That is most of it. The list is short and it barely changes.
The timing is the problem. These questions arrive in the evening, at the weekend, and on the day before a bank holiday, which is precisely when nobody is reading the inbox. By the time anyone replies the person has phoned someone else.
The information is almost always on the site already. It is in a footer, on a contact page, or in a paragraph halfway down a services page. On a phone, none of those are where someone looks first.
What changes
Today
- Visitor checks hours at 9pm on a phone
- Scrolls the homepage, finds nothing obvious
- Opens the contact page, finds an address and a form
- Sends a message or gives up
- Reply arrives the next working day, too late
With an assistant
- Visitor asks about hours on their phone at 9pm
- Assistant answers from the page that holds the hours
- Follow up about parking answered in the same conversation
- Booking question routed to the booking link
- Nothing waits until the next working day
A small site needs a small source list
Four or five pages, not the whole site
Hours and contact, services, prices if published, booking, and any policy page. A small focused source list outperforms a complete one, and this is the case where that is most obvious.
Keep the hours in one place
If opening hours appear in three places with two versions, the assistant will confidently quote the wrong one. Fixing that is worth doing before adding any tool.
Route booking rather than answer it
Booking needs a system, not an answer. The correct behaviour is to hand over the booking link at the moment the intent appears.
Refuse on anything time sensitive
Whether there is a table free tonight is a lookup, not a content question. It should escalate.
Why this is the easiest case to get right, and the easiest to over build
Everything that makes a website assistant hard is absent here. The question set is small. The answers are short and factual. There is no documentation sprawl, no version history, no plan matrix. Retrieval quality is nearly free.
The failure mode is over building instead. A local site does not need multiple agents, an integration layer, or advanced analytics. It needs four pages indexed correctly and a widget that appears on mobile.
The Free plan is sized for exactly this. One agent, one source, 100 conversations a month. A small local site can run a real assistant on it indefinitely rather than for a fortnight, which is deliberate.
The one thing worth spending effort on is making sure the hours page is the single source of truth. Everything else on this list matters less than that.
Where the data goes
The assistant answers from your published pages. It cannot check availability, take a booking, or see a calendar, so those hand over to whatever you already use. Security and data boundaries.
Questions
Signal
Is this your situation?
Access is by waitlist, demo request or public-content pilot. Describe the question your visitors keep asking and we will tell you honestly whether it fits.