Snoowl Answers
A support assistant that only says what your docs say.
Snoowl Answers is a support assistant built only from a company’s own docs. It can be added to a website with one line, or called from a chatbot the company already has. Every answer cites the passages it came from, and when the docs don’t cover a question it says so instead of guessing.
It grew out of Snoowl Audit. Audit checks chatbots against their docs; Answers is a chatbot built to pass that check, and Audit can test it directly.
What I built
Serving API: an answer endpoint, plus one that follows the common chat-completions format. A team with its own chatbot UI can point it at Answers by changing a URL. Each key is tied to one project, with limits on where it can be called from and how much it can be used.
Website widget: a small script that adds a chat window to any site.
Shared backend: Answers runs on the same backend as Audit. Projects and documents are shared, so docs uploaded once can be answered from and audited.
Console: a React app for managing docs, keys and usage, with a list of the questions the assistant couldn’t answer.
Decisions worth writing down
No passages, no answer
If search finds nothing relevant, the assistant says it doesn’t know without asking a model to write an answer. Asking a model to answer with nothing to go on is how assistants end up inventing things. It also makes “I don’t know” cheap and fast.
Two kinds of search, and a fallback
Questions are matched against the docs two ways: by meaning, and by keywords. Meaning-based search handles paraphrases; keyword search handles product names, error codes and exact terms that embeddings tend to blur. The two lists are merged and reranked.
If the vector search service can’t be reached, search falls back to keywords only. Answers get a little worse, but the assistant keeps working.
A standard API instead of a new one
Most teams that want this already have a chatbot UI. Making the endpoint follow a format their code already speaks means they can switch without a rewrite.
Trade-off
The format expects a streamed reply, but the full answer exists before the first word is sent. So the stream is compatible, not faster.
Price each answer by what it cost
The people asking questions are a company’s customers, so nobody sees a price before each click, and the cost of an answer varies with how much context it needs. Each answer is charged from its actual model cost plus a margin, and an answer that fails isn’t charged.
Where it is now
In early access for design partners, with no uptime guarantee yet. Teams can ask to join at snoowl.com/answers.
What’s in it:
- A one-line chat window for any website, or an API for an existing chatbot.
- Cited answers, and a plain “I don’t know” when the docs don’t cover a question.
- A list of the questions it couldn’t answer, to show where the docs have gaps.
- Usage-based pricing, agreed with each early-access team.
Next: shaped by what the design partners ask for.