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.

Before and after on a support siteThe same visitor question, handled by the current site and then by an assistant grounded in that site's own content.BEFOREVisitor checks hours at 9pmon a phoneScrolls the homepage, findsnothing obviousOpens the contact page, findsan address and a formSends a message or gives upAFTERVisitor asks about hours ontheir phone at 9pmAssistant answers from thepage that holds the hoursFollow up about parkinganswered in the sameconversationBooking question routed tothe booking link
  • 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

  1. Visitor checks hours at 9pm on a phone
  2. Scrolls the homepage, finds nothing obvious
  3. Opens the contact page, finds an address and a form
  4. Sends a message or gives up
  5. Reply arrives the next working day, too late

With an assistant

  1. Visitor asks about hours on their phone at 9pm
  2. Assistant answers from the page that holds the hours
  3. Follow up about parking answered in the same conversation
  4. Booking question routed to the booking link
  5. 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.

The three ways a conversation leaves the flowMost conversations end in a grounded answer. The exits are a logged refusal, an escalation to a person, or a capture before continuing.IN THE FLOWQuestionRetrieveGrounded answermost conversationsEXITSRefuse, log gapEscalateCapture, then continue

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

For a site with one location and a short service list, yes. 100 conversations a month and one source covers a genuinely small business, and the plan is not time limited.

No. It can recognise booking intent and hand over the booking link, but taking a booking needs a system with a calendar behind it, which Creobot is not.

Update the page and reindex. If the index is stale the assistant will state the old hours with total confidence, which is worse than saying nothing. This is the single biggest risk for this use case.

Adding the embed is a copy and paste. Deciding which four pages to index is the part that needs a person who knows the business, and that is not a technical skill.

It answers from your pages, so it inherits your writing. If your site reads formally, so will it.

It refuses and does not engage. Off topic questions are outside the sources, so the grounding behaviour handles them without a separate moderation layer.

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.