AI Support With Citations That Refuses When It Can’t

Why “AI with citations” is not enough

Citation presence can be cosmetic. What buyers need is a citation that maps to a real page the agent actually used—and a refusal when nothing on the site clears the bar.

The hallucination buyers remember

Wrong shipping steps. A fake API sequence. A returns window pulled from model memory. Delivered confidently, in the same tone as a correct reply. Screenshots travel. Neither “honour a policy you never wrote” nor “explain why your own chat lied” is a support outcome you want.

Cosmetic sources vs page-linked answers

Prompting a general model to “add sources” is not the same as answering only from indexed site pages with links back. One is decoration. The other is a constraint: if the page is not in the index, or the passage does not actually answer, generation should not get a free pass.

I think about it like this. A citation you can open and verify is part of the answer. A citation that vaguely “feels related” is theater. Buyers who have been burned once usually notice the difference in the first demo—if they know to click the link.

Refusal is the other half of trust

If the bot never says it cannot answer, citations alone do not prove boundaries. Cite without refuse is half a promise. Refuse without cite is a quiet bot with no audit trail. You want both.

What website-grounded support actually does

Point the agent at your site. Index the useful pages. Embed chat. Answers come from that corpus—or not at all.

Index the pages worth answering from

Docs, help, pricing, policies, sizing, shipping, returns—the pages visitors already read before they open a ticket. Not a general web search. Not someone else’s knowledge base.

You already paid the cost of writing those pages. Website-grounded support is the move that puts them to work in the channel where the question actually arrives—on the site, in chat—without asking you to rebuild the same facts inside a separate knowledge tool first.

Answer in the visitor’s language, cite the page

When the indexed pages support the question, the visitor gets an answer in their language, with a link to the page it came from. The facts still have to live in what you published. Language is presentation; the source is the contract.

Confidence threshold → explicit fallback

Below the threshold, say so instead of guessing. In plain language: if the best retrieved passage is not good enough, generation does not run, and the visitor sees a clear fallback—not an invented shipping rule.

I wrote the longer version of that gate in the refusal essay. The buyer version is simpler: you should be able to force a refusal on purpose in a demo.

Misses land somewhere useful

Unanswered threads should show up somewhere an operator can read them. In Rinhelp that is the shared inbox—flagged when sources could not carry the question—so you know what to write next. A bot that always answers reports perfect coverage and teaches you nothing.

Cite + refuse: the buyer checklist

A five-minute demo beats a feature matrix. Run these on any vendor you are evaluating, including us.

Ask something your site does not cover

Expect a clear fallback, not trivia from model memory. If the bot invents a policy for a topic you never published, walk away.

Ask something your site does cover

Expect an answer plus a real page link you can open. Click it. Confirm the passage actually supports what was said.

Ask a near-miss

Related topic, no exact page. Expect refusal or clarification—not a plausible invented policy stitched from a loosely related paragraph.

This is the test that separates retrieval theater from a real gate. Plenty of systems can look good on the exact FAQ you wrote yesterday. The near-miss is where a loose paragraph gets stretched into a rule you never published.

Check the operator side

Can you see cited answers and unanswered threads? With Rinhelp, every conversation lands in the shared inbox, and misses are marked so you can treat them as a content roadmap.

Who this is for (and the honest no)

Best when published pages already cover repeated questions.

Technical founders and small SaaS

You want a support surface without inheriting a full AI stack, a helpdesk rebuild, or a custom RAG project. Your docs and pricing pages already do a lot of the work. The agent should use them.

eCommerce from published pages

Sizing, shipping policy, returns policy—questions the site already answers in HTML. That is the fit.

Not for questions that need private account data

If the answer lives in an order system, a CRM, or a login-walled account page your public site does not publish, website-grounded chat is the wrong tool for that question. Keep the scope honest and you avoid the wrong trial.

Not a full helpdesk replacement

Rinhelp has live handoff in the widget and a shared inbox. It does not claim ticketing or SLA maturity. Mature support orgs shopping for that stack need different software. See who it is for on About.

How Rinhelp does cite + refuse

Rinhelp is a shared inbox agents can run. It answers from your pages, cites them, and stops when it cannot. That is the whole product shape on the AI agent surface.

Setup in three moves

1. Add your website so useful pages can be indexed.
2. Style the chat and preview a real question against your sources.
3. Paste one script tag.

By the end of an afternoon you know what your content already answers—and, from the flagged conversations, what it is missing. The install itself is deliberately thin on purpose. I do not want the setup to become another project that delays the only proof that matters: ask a covered question, ask an uncovered one, watch cite and refuse in the same session.

Cited answers

Every supported reply links back to the page it came from. If a reply has no citation, it does not ship as a supported answer.

Explicit fallback

Below the confidence threshold, Rinhelp says so instead of guessing. Same philosophy as the refusal post; same buyer-visible behavior in the widget.

Pricing that matches the philosophy

Unresolved conversations are free. You pay for resolutions. The plan is one usage-based line on pricing: $29/mo for 300 resolutions, then $0.10 each, with a 14-day trial (100 resolutions, 500 messages, no credit card). I am not going to invent a deflection percentage or a savings story on top of that. The incentive is already aligned: a quiet miss does not cost you.

Where to go next

• Try it: start the trial
• See the surfaces: features, AI agent, shared inbox, live chat
• Install guide: add AI support with one script tag
• Compare on price if you are shopping: Fin AI alternatives
• Read the deeper refusal essay: why support bots should refuse

FAQ

What is AI support with citations?

Support chat that answers from your own pages and links every supported reply back to the page it used—so you (and the visitor) can verify the claim. It is not a general chatbot that decorates guesses with loosely related links.

What is a website-grounded support agent?

An agent pointed at your site, limited to indexed pages, embedded as a widget. It answers from that corpus or it does not answer. That constraint is the product.

Why refuse when the AI can’t answer?

Because a confident wrong answer becomes a promise. Silence with a clear fallback is a smaller problem than a screenshot of a policy you never wrote. I go deeper on that in the companion essay.

How does a confidence threshold work in support AI?

In plain language: retrieve candidate passages, score whether the best one actually answers, and only generate if it clears a bar. Below the bar, return a fixed fallback. No hedging into “it is typically around thirty days.”

How is this different from Chatbase / SiteGPT-style tools?

Same starting point—chat on a site from your content—different emphasis. Rinhelp’s published differentiation is an explicit confidence threshold, citations on every supported answer, and an inbox that flags which questions your sources could not carry. Confirm current details on pricing and the AI agent page.

Who is this for?

Technical founders, small SaaS teams with docs, and eCommerce brands answering from published pages. Not teams that primarily need mature ticketing and SLA software.

Closing

Link every supported answer. Refuse when content cannot answer. Install from the site you already have.

That is the buyer filter I wish I had the first time I watched a demo invent a policy with a straight face. If your pages already carry the repeated questions, start there—add the site, style the chat, paste one line—and let the flagged misses tell you what to write next.