AI chatbot for your website: build or buy?

What to look at first

The decision depends on data, risk and required actions. A brochure chatbot differs from a support assistant connected to CRM.

• Define questions and actions.
• Check data sources.
• Decide approval rules.
• Measure containment and escalation.

What the result should be

The right chatbot answers common questions and escalates cleanly instead of hallucinating.

Start with the work that should genuinely disappear

A website assistant should complete a customer job: find reliable information, prepare an enquiry, explain status or route support. A simple FAQ search may be enough for static content. Custom development becomes relevant when answers depend on private sources, CRM or booking actions, brand controls and user permissions.

• State which questions the assistant owns and which it must refuse.
• Assign owners and review dates to source content.
• Separate public knowledge from authenticated customer information.
• Design escalation before enabling actions.

A realistic delivery example

A B2B provider answers questions about services, terms and implementation using approved pages with citations. The assistant asks only relevant intake questions and, after consent, creates a CRM lead. Pricing commitments, complaints and unsupported answers go to a person. The experience becomes useful without turning into an aggressive sales bot.

Move from trial to dependable operation

Begin with one bounded workflow, representative examples and human review. Increase automation only after failures are visible and recoverable.

• Build an evaluation set from real customer questions.
• Index only current, approved sources with provenance.
• Test answer, citation, refusal and hand-off.
• Launch without autonomous changes to operating systems.
• Add one logged and confirmed action at a time.

Measure quality and business outcome

Record a baseline before launch. Model activity is not an outcome; the application should improve time, quality, revenue or risk.

• Correct answers supported by a valid source.
• Successful resolution or clean hand-off.
• Unsupported answers, refusals and corrections.
• Qualified enquiries or support time genuinely saved.

Where human control must remain

Do not hide uncertainty behind confident writing. Customer-specific data requires authentication and must not leak into public chat. Explain AI and data use clearly. Without an ownership process for knowledge, answer quality will decay quickly.

Choose build, buy or hybrid around the customer task

An off-the-shelf chatbot can suit simple FAQs and a quick trial. Bespoke work becomes relevant when the assistant needs multiple knowledge sources, languages, customer permissions or actions in CRM and booking systems. A hybrid uses established models and infrastructure while keeping sources, rules and integrations under company control. Compare data governance, adaptability, analytics, export and cost at realistic usage rather than judging the scripted demo alone.

• Buy for low-risk standard questions and few connections.
• Use hybrid for owned knowledge on proven infrastructure.
• Build for distinctive journeys, permissions or complex actions.
• Use no chatbot when navigation or a form solves the problem better.

Create a governed knowledge base first

The assistant can only be as dependable as its sources. Assign approved pages, documents and owners to each subject. Remove old versions and schedule content review. Answers should point to their evidence and decline when it is missing. Customer-specific data needs authorisation before retrieval; a sentence in the system prompt is not an access-control mechanism.

• Owner, publication date and review date for each source.
• Separation of public, internal and customer-specific content.
• Citations or links that let visitors verify the answer.
• Feedback route for missing or incorrect information.

Design conversations around tasks and boundaries

Decide what the visitor should complete: find an answer, prepare an appointment, route a support issue or qualify an enquiry. Ask only for information needed for that task and state that AI is being used. Offer human help before frustration escalates. Complaints, legal questions, emergencies and commercial commitments need specific routes rather than one generic fallback message.

• Open with relevant choices instead of an empty prompt.
• Confirm details before booking, sending or changing records.
• Carry context into a human handover.
• End with a clear next step and realistic expectation.

Connect business systems with narrow permissions

Actions create value and risk. Implement server-side tools with one purpose, validated input and idempotency to prevent duplicates. A public assistant must not retrieve customer data without authentication. For appointments, payment or account changes, show a summary and request explicit confirmation. Record which tool ran, its result and the user who initiated it. Never give a language model broad database or administrator access.

• Create a CRM lead with consent and page source.
• Read availability before proposing a booking.
• Prepare a ticket with summary and transcript preference.
• Keep privileged business rules outside the model.

Evaluate each intent and language separately

Testing should go beyond friendly examples written by the project team. Maintain a fixed set of real phrasing, errors, incomplete questions, hostile instructions and situations requiring refusal. Score answer, evidence, tone, privacy and handover separately. Treat English, Dutch and Spanish as distinct experiences. A literal translation can be accurate and still sound unnatural or mislead visitors about the next step.

• Correct answer and valid evidence by intent.
• Safe refusal and appropriate escalation rate.
• Completed tasks, qualified enquiries and repeat contact.
• Cost, latency and abandonment by channel and language.