Design grounded answers instead of confident guesses

A helpful support answer has two jobs: it must solve the visitor’s problem, and it must make the visitor comfortable trusting the answer. Those jobs are related but not identical. A concise answer with a clear source can be more useful than a beautifully written answer that cannot explain where it came from.

Chatty’s knowledge workflow is designed around grounding: retrieve relevant content, generate an answer from that content, and make the limits of the evidence visible when the answer is uncertain.

Separate retrieval from response style

Teams often try to solve accuracy with a longer personality prompt. That can improve tone, but it cannot repair missing or contradictory source material. Treat the system as two layers:

1. Evidence layer: Which passages are relevant and authoritative?
2. Conversation layer: How should those passages be explained to this visitor?

The evidence layer should win when the two are in tension. A friendly answer that invents a feature is still a bad answer.

What a good grounded response contains

For a factual product question, the response usually needs four parts:

1. Direct answer: Resolve the question in the first sentence.
2. Useful qualification: Mention plan, platform, version, or prerequisite when relevant.
3. Next step: Tell the visitor what to do next.
4. Source signal: Link or name the supporting documentation when possible.

Example:

Yes. Chatty can be embedded on a React site with the standard script snippet. If you need a native mobile experience, use the iOS, Android, or React Native SDK instead. See the integration guide for the required workspace ID and domain settings.

That answer is short, but it distinguishes web embedding from native SDKs and gives the visitor a path forward.

Handle uncertainty explicitly

There are three useful states, not two:

Avoid language that disguises uncertainty: “probably,” “I think,” and “it should” sound conversational but do not tell the visitor what is actually known. Prefer: “The documentation confirms X, but it does not specify Y. I can connect you with the team to confirm the account-specific detail.”

Source quality beats source volume

When answers are off, inspect the retrieved sources before changing the prompt. Common causes include:

• A broad overview page outranking a specific implementation guide
• A duplicate page containing an old limit
• A PDF with no headings or page context
• A source that uses internal names customers never use
• A page that answers the question only through an image or diagram

Improve the source before adding instructions. Give the canonical page a clear title, put the answer near the relevant heading, and remove duplicates that cannot be maintained.

Use conversation context carefully

Context helps Chatty understand follow-up questions such as “Does that work on mobile too?” But context should clarify the reference, not override current product facts. If the conversation is ambiguous, ask a focused question:

Do you mean the website widget or the native mobile SDK?

That one sentence is better than choosing the most likely interpretation and sending the visitor down the wrong implementation path.

Write fallback language in advance

Fallbacks should be useful, not dead ends. A good fallback says what is missing and what the visitor can do:

I can explain the standard setup, but I do not have access to your workspace’s billing details. Share your workspace email with our team, or open the billing page and I’ll walk you through the relevant settings.

Define fallbacks for at least these cases:

• Account-specific billing or permissions
• Security incidents and data requests
• Unsupported integrations
• Legal or compliance questions
• A request that requires a human decision

Measure answer quality by outcome

Track more than whether the model produced text. Useful signals include:

• Was the answer grounded in an approved source?
• Did the visitor ask the same question again?
• Did the visitor click the cited documentation?
• Did the conversation require a human handoff?
• Did the visitor complete the intended next step?

The goal is not maximal automation. The goal is a trustworthy first response that either resolves the issue or moves it cleanly to the right person.