Website chatbot: template or custom

Choose a ready-made or custom website chatbot by its demonstrated grounding, integration, data handling and recovery capabilities.

Choose between a ready-made chatbot and a custom build by testing the job you need it to do. A static FAQ, catalogue search and a confirmed booking have different acceptance boundaries. The label template or custom does not establish answer quality, live integration or privacy.

Start with representative questions and required actions. Ask each candidate to demonstrate them with an approved fixture. Compare the result and recovery behaviour before committing to a deployment approach.

When a ready-made product may fit

A supported product can be appropriate when its existing capabilities cover the task: a maintained FAQ, guided choices, contact capture or a supported integration. Check the actual plan, configuration and limits rather than assuming every widget is a button tree or an ungrounded model.

An early trial can reveal whether users need the channel, but a chat transcript alone does not establish business value. Use existing authorised evidence and a clear acceptance rule; do not add tracking or collect unnecessary personal information merely to justify a bot.

When custom work may be justified

Custom engineering may be useful when the supported product cannot meet a demonstrated requirement: a specialised matching rule, a particular data boundary, a legacy integration or an auditable recovery path. First check whether the candidate product already supports it through a reviewed extension or API.

A live catalogue needs an agreed source of truth and update mechanism. A scheduling assistant needs authoritative conflict handling. Those are integration requirements, not properties that appear automatically when the model is placed on a private server.

Compare capabilities with the same fixture

Scroll horizontally to compare all columns on a narrow screen.

Required capability	Test to request	Evidence to keep
Supported business answer	Ask an in-scope question and a missing-policy question	Source version, supported claim or explicit unresolved state
Fresh catalogue information	Change a test record and repeat the query	Update delay and source used
Consequential action	Exercise a safe reservation or write fixture	Authoritative outcome and duplicate handling
Human handoff	Request a person and simulate unavailable support	Destination receipt and honest status
Recovery	Interrupt a dependency after possible acceptance	Reconciliation and retry decision

Keep failed and untested cases alongside passes. There is no universal 100 percent catalogue accuracy or refusal rate asserted here. A demonstration establishes the tested configuration and fixtures, not every future question.

Grounding needs verification

A useful design separates the source of business facts from generated wording. Retrieve the relevant record, preserve its version and require an unresolved or refusal path when it is insufficient. Then test whether the answer actually follows those conditions.

A custom build can still invent an unsupported answer. A hosted product can provide grounding and source controls. Inspect their behaviour rather than treating either deployment model as proof. See the RAG acceptance checklist for a source-linked test record.

Ownership and privacy are explicit requirements

Review source-code rights, exportability, supported data formats, maintenance responsibilities and an exit plan. A custom system can still depend on external APIs and libraries; a hosted product’s portability depends on its agreement and export capabilities.

Map prompts, documents, embeddings, logs, backups and support access. Hosting the application on an operator-controlled VPS does not prove those other transfers stay local. An EU location alone also does not settle every privacy requirement. Review the actual data path and applicable terms with the responsible owner.

Compare operating assumptions over the same workload and period, including maintenance, integration changes and recovery effort. No fixed two-year ownership saving or public tariff is claimed. See the local/API comparison worksheet when inference deployment is part of the decision.

Request a bounded first scope

A trial on a representative subset can test source freshness, unsupported questions and integration failures before a larger rollout. Agree what counts as accepted, what stays unverified and who owns recovery. Preserve the human route when the application cannot complete the promised action.

Request a scope with the catalogue or policy source, required live operations, data constraints and answers the assistant must not invent. The useful choice is the one that demonstrates the agreed capability and operating boundary.