Answer generation, model routing, and safe hand-offs
Learn which instructions shape a chatbot answer, when more reasoning is used, how corrections apply, and what authorises a lead form.
On this page
What the answer request containsAnswer the actual technical distinctionRouting and fallbackGrounded links and commerce claimsCorrections improve a defined knowledge problemContact collection requires a real hand-offA practical regression setDiagnose the failed stageWhat the answer request contains
The server combines the merchant's configured behaviour, platform constraints, approved corrections, language and formatting requirements, source mode, relevant conversation context, and retrieved evidence. These layers have different roles. A tone instruction can make the answer concise; it cannot establish a missing product fact. Website text is evidence to evaluate, not an instruction that may override ownership or platform rules.
Answer the actual technical distinction
A useful compatibility answer identifies the exact product and version, states a supported restriction, and provides a supported alternative. If a saved source says a case closes only with a low-profile knob, the answer should explain that condition rather than stopping at 'designed for this keyboard'. If the source does not establish the tall-knob fit, the assistant must not infer it from the generic compatible-model name. Tests should include the exception, not only the easy product question.
Routing and fallback
Automatic routing can use a faster tier for routine questions and a reasoning tier for compatibility, troubleshooting, comparisons, multi-step needs, or an unsatisfactory prior answer. An explicit fixed-model configuration is a separate choice. Fallback is constrained by configured models and error handling; it is not an endless retry loop. Permanent provider or credit failures cannot be fixed by repeatedly making the same paid request. Model names and availability may change, so inspect the active configuration rather than relying on a permanent model promise.
Grounded links and commerce claims
The assistant should use validated product and policy links from the relevant evidence. A similar-looking URL is not proof that a product page exists. Do not convert an imported price into a guaranteed live quote or a catalogue match into an inventory promise. When an attribute cannot be established, the answer should identify the specific uncertainty and give a useful next step instead of filling the gap with a confident guess.
Corrections improve a defined knowledge problem
Review an incorrect conversation, identify the source or identity issue, and add an approved correction using the supported dashboard workflow. Make the correction specific: product identity, applicable revision, factual rule, and supporting source. A blanket 'always say yes' instruction will damage unrelated questions. Re-test the original case and adjacent cases, including variants that must remain unsupported.
Contact collection requires a real hand-off
An ordinary answer should not force a contact pitch. The lead flow is appropriate when a visitor explicitly requests contact or accepts an offered hand-off. The server also checks the supported capability, access, consent, and fields. A statement that someone will follow up is not equivalent to a saved lead. Do not put private contact details into knowledge pages to simulate a lead workflow.
A practical regression set
Test both facts and behaviour using questions with known expected outcomes. Keep the source version used for the test so a later change is explainable.
| Test | Expected behaviour |
|---|---|
| Exact product and supported variant | Direct answer using the correct source and link |
| Known incompatibility or exception | Restriction and supported alternative, without a false fit claim |
| Ambiguous follow-up | Resolve from context or ask one necessary clarification |
| Unavailable price or stock | State the missing evidence rather than inventing current conditions |
| Visitor accepts a support hand-off | Offer the supported contact form once; distinguish submission from an offer |
| Malicious instruction in a page or message | Keep source and user content inside the intended boundaries |
Diagnose the failed stage
A wrong answer can originate in collection, indexing, retrieval, entity resolution, generation, or output rendering. Save the conversation identifier and source URL when reporting a problem. Public documentation describes the behaviour; it does not expose private prompts, operational secrets, or customer transcripts.
Still need help?
Tell us what you expected and what happened.