Website chatbot: what to ask before you buy

If you search “chatbot for website” on Google, ads dominate. Many platforms promise “ready in minutes”, “no code”, “24/7”. Pricing shows up “per agent”, “per conversation”, and “per message”. Free trials everywhere. Plugins and templates too. Clear buying guides, almost none.

Search volume trails “free chatbot” and “live chat”. That is the tell: if you are here, you plan to buy. There is little room for error. Ask for the critical points upfront and put them in writing.

What “about to buy” really means

You are one test and one contract away. The question is not “does it work”, but “will it work on your site, with your data, at your scale, and with your processes”. Keep the talk concrete: data access, timelines, limits, total cost, and exit plan. Everything else is noise.

Data and security: first gate

I want full clarity on where data is stored, for how long, and who can access it. Encryption in transit and at rest. Access logs. Deletion on demand. And a data processing agreement. If you operate in the EU, demand a legal basis and compliance annexes.

Ask if the model trains on your data. If the provider uses your data to improve their system, demand an opt‑out and written confirmation. Clarify whether environments are separated (development and production). Check if you can anonymise sensitive fields before the model sees them.

Training and content control

How the bot learns sets the result. Manual upload of questions and answers? A document index with retrieval (RAG)? Both? Ask for version control, review before publish, and a staging environment. Define tone and limits. When in doubt, it should say “I don’t know” rather than invent.

Check how it handles multiple languages. How it resolves ambiguity. How it cites sources. And how often its base updates. If you also plan to use it for lead capture, I frame it as part of AI agents for selling and demand extra controls: prospect scoring, routing paths, and data validation before anything gets stored.

Integrations and handoff

The bot only shines when it connects to your stack. CRM, help desk, e‑commerce, calendars, forms, analytics. Ask about APIs, webhooks, events, and rate limits. If there is a direct connector, validate the exact scope: which fields it reads, which it writes, and with what latency.

Handoff to a human defines the experience. Is there a unified inbox? Assignment by schedules or queues? Do context and history persist when a human joins? Can a human mark a conversation as resolved and have the model learn from that example?

Metrics that matter and how to read them

What you do not measure, you guess. Ask for automatic resolution rate, drop‑offs, escalations to human, satisfaction at close, and time to first response. Review cohorts by channel and by intent. Demand export of logs with tags, so you can audit replies and improve training.

A/B tests help when you test different goals: script vs retrieval, formal tone vs direct, early vs late CTA. Without business goals, metrics mislead. Define success for each intent: sell, support, qualify, or deflect.

Costs and hidden limits

List price rarely equals total cost. You will see models priced per conversation, per message, per seat, per page processed, and per model used. Some charge extra for advanced models, for embeddings, or for premium integrations. Others cap documents, domains, or API calls and add overages after the quota.

Build clear scenarios. For example: a team that spends twenty hours a month on tuning and analysis; 10,000 sessions a month with two messages on average; 5% handoff to a human. Price that. Add internal hours. Add your infrastructure if the bot runs in your cloud. Add taxes and exchange rate if you pay outside your currency.

Production performance

Speed and availability matter. Ask for average latency and peak latency by region. Ask about CDN, queues, and retry mechanisms. Review how it degrades when the model is saturated: short replies, a wait message, or silence? Demand an SLA with metrics and credits. And visibility: a real‑time health dashboard.

Before you sign, run a stress test. Simulated traffic on your site, with your scripts and your analytics. Measure blocks. Measure errors. Measure the impact on load time. Set thresholds: if the P95 crosses a set value, it does not go to production.

Governance and maintenance

Without governance, the bot drifts. Define roles and permissions. Change audit. Approvals. Backups and rollback. A knowledge review calendar. And a clear ticket route with severity levels. The vendor should document how to operate on day one and on day one hundred.

Check your dependency. Can you export all data and outputs in open formats? Is there an exit and migration plan? Who owns the specific training you added? Put it in the contract. Lock‑in by format or by a vague licence hurts most.

How to run the purchase

Write a short RFP. Problem, objectives, available data, integrations, success metrics, and legal constraints. Ask for a closed proof of concept with criteria and deadlines. Two weeks are enough to test fit: 50 to 100 real questions, 10 critical cases, 5 flows with integration.

Define approval upfront. Automatic resolution threshold, handoff rate, satisfaction, latency, and errors per thousand interactions. If it passes, contract. In the contract, annex the DPA, the SLA, the rollout plan, the exit plan, and the responsibility matrix. Without that, “ready in minutes” turns into months of patches.

A website chatbot is not a purchase on promise. It is a purchase on control. Ask for evidence, test on your ground, and sign with verifiable requirements. With low volume and high intent, every bad answer costs. Better prevent now than fix in production.

I post working automations on @WhatsMarketing_es.

If you want me to look at your case, get in touch. I work from Buenos Aires, originally from Málaga, with clients in Mexico City, Argentina, the rest of Latin America and Spain.