WordPress AI chatbot

Test the chatbot before buyers do.

A plugin demo can answer one prepared question. Your decision starts with real visitor questions, data recipients, permitted actions, human handoff, operating cost, and a way to remove it.

By Vineet Talwar·2026-07-29·12 min read

Review AI automation delivery ↗Open AI project prices

On this page

Direct answer
Buyer decision
Choose the intervention
Supplier comparison
Data flow
Answer and action policy
Evaluation set
Pilot and acceptance
Pilot scorecard
Cost and exit
Primary sources
Buyer questions
Next decision

WordPress AI chatbot proposal reviewed against questions data actions and human handoff

Direct answer

Approve eight boundaries before launch: purpose, data path, knowledge, permitted actions, human handoff, evaluation, operating cost, and exit.
A WordPress plugin may store transcripts locally and still send each message, conversation history, and retrieved site content to an external model. Ask for the full path.
Grounding limits the sources available to the assistant. It does not prove that the source is current, the right passage was retrieved, or the answer preserved every condition.
Test the assistant on supported, unsupported, current-data, personal-data, adversarial, multilingual, action, and handoff cases. Set your release thresholds before seeing the result.
Report counts with denominators, cost per accepted outcome, complaints, and open failures. Keep the disable switch and export path ready throughout the pilot.

Buyer decision

The WordPress plugin is one part of a wider service.

A public chatbot can read approved pages, call a model, store a transcript, collect a lead, write to a CRM, look up an order, or book an appointment. Those are different systems with different risks. “Installed in WordPress” does not tell you where processing happens or what the assistant may change.

Start with the job. Name the visitor question, the source that can answer it, the result your team needs, and the case that must reach a person. Then compare products against the same test set.

German hosting answers one location question. Your review still needs purpose, recipients and subprocessors, fields sent, retention, access, transfers, security, rights handling, and deletion. Send legal conclusions to the company role accountable for privacy and AI governance.

Choose the intervention

Use the smallest system that solves the visitor problem.

A chatbot should earn the extra data, model, testing, and support boundary. Improving the underlying page or contact route may solve the problem sooner.
Observed problem	First intervention	Evidence before adding AI	When a chatbot adds scope
Visitors cannot find a known answer	Fix navigation, page copy, search, and FAQ	Search terms, exits, support questions, and task test	Only when natural-language discovery remains useful after the page fix
Visitors need a quick route to a person	Short form, callback, booking, or staffed live chat	Response coverage, routing, service hours, and handoff result	When the assistant can collect useful context within an approved boundary
The same bounded questions recur	Rule-based answers or a grounded answer assistant	Question sample, approved sources, refusal cases, and source owner	When language variation makes fixed navigation or rules inadequate
The answer depends on current account, stock, booking, or order data	Authenticated live-system lookup	Identity, authorization, fields returned, stale-data rule, and audit log	When the assistant can call the source safely and explain the result
The visitor wants something changed	Human service process or one tightly bounded action	Permission, confirmation, failure, reversal, fraud, and complaint route	Only after the action passes separate acceptance and monitoring

Supplier comparison

Compare every proposal through eight recorded boundaries.

Keep unknowns visible. A blank data recipient or deletion field is a procurement issue, even when the demo answer looks good.
Boundary	What the supplier must state	Acceptance evidence
1. Purpose	Users, questions, intended outcome, excluded uses, and responsible business role	Approved use statement and sample conversations
2. Data path	Every recipient, processor, subprocessor, location, field, log, retention rule, and deletion route	Current data-flow record and supplier documents
3. Knowledge	Pages, files, systems, update cadence, source priority, and unavailable subjects	Source inventory, owner, last refresh, and citation trace
4. Actions	Read and write permissions, authentication, confirmation, limits, failure path, and reversal	Permission matrix plus successful and denied action tests
5. Human handoff	Trigger, channel, context transferred, service hours, response target, and queue owner	Routed test with a person receiving usable context
6. Evaluation	Test cases, expected answer or refusal, thresholds, evaluator, and retest trigger	Dated evaluation results with failures retained
7. Operating cost	Setup, platform, model, storage, integration, monitoring, support, and change units	Usage assumptions, budget alert, invoice example, and owner
8. Exit	Data and prompt export, knowledge export, deletion evidence, contract end, plugin removal, and fallback	Tested export, removal steps, and restored contact route

Data flow

Trace a visitor message until it reaches a person or system.

Representative WordPress.org listings disclose very different arrangements. Read the actual external-service section and current supplier documents for the shortlisted product.
Stage	Data to record	Question for the supplier	Control or evidence
Browser and widget	Message, page URL, IP or device data, cookies, identifiers, consent state	What loads before interaction and which data leaves the browser?	Network record, cookie behavior, accessibility and performance test
WordPress plugin or proxy	Configuration, API key path, local transcript, user account, selected content	What remains in WordPress and who can read it?	Role test, storage table, retention job, export and deletion
Retrieval or knowledge service	Queries, content chunks, files, embeddings, metadata, source URLs	Where is site content indexed and when is it refreshed or removed?	Source inventory, refresh log, access and deletion result
Model provider	Prompt, history, retrieved context, tool result, identifiers, output	Which provider receives which fields under which account and terms?	Processor/subprocessor record, region, retention and security evidence
Business systems	Lead, CRM record, booking, order lookup, email, webhook, ticket	Which read or write can the assistant perform?	Least-privilege credentials, confirmation, audit log and error route
Human team	Transcript, summary, contact details, requested action, urgency	Who receives the handoff and when?	Queue receipt, access, response result and retention

Answer and action policy

Tell the assistant when to answer, look up, clarify, stop, or act.

Grounding supports the first row. The other rows need current systems, policy, permissions, and operational ownership.
Situation	Allowed behavior	Required source or control	Proof
Stable published fact	Answer from an approved source and show or retain the source reference	Current page or document with an owner	Expected answer, source used, date checked
Price, stock, availability, order, or booking status	Read the approved live system or direct the visitor to it	Authenticated current-data source and stale-data rule	Current and stale test cases with timestamps
Question lacks a required fact	Ask one useful clarification	Defined required fields and data-minimisation rule	Conversation reaches the right branch without collecting surplus data
Unsupported, sensitive, disputed, or high-consequence question	State the limit and offer the approved human route	Refusal topics, escalation criteria, and service coverage	Refusal contains no invented answer and the handoff arrives
Approved customer or business action	Explain the action, verify authorization, request confirmation, execute within limits, and report the result	Permission, input validation, idempotency, audit log, failure and reversal	Successful, denied, duplicate, failed, and reversed tests

Evaluation set

Test the cases the public assistant will meet.

Build the set from approved site content, support questions, sales objections, and the actual actions in scope. Keep failed cases for the retest.
Case	Test input	Expected behavior	Failure to record
Supported answer	Representative wording and paraphrases from real questions	Correct answer tied to the approved source	Wrong source, missing condition, unsupported claim, or dead link
Unsupported answer	Question outside the approved knowledge boundary	Clear limit plus the correct next route	Confident invention, irrelevant answer, or blocked exit
Current data	Price, stock, availability, order, or policy that can change	Live lookup or explicit direction to the authoritative system	Stale cached answer or invented current value
Personal data	Message with unnecessary identifiers or a rights request	Minimise collection and route the request under the agreed process	Sensitive data exposed, retained, or sent to the wrong recipient
Adversarial input	Prompt injection, source override, abusive text, and request for hidden instructions	Keep system and data boundary, respond safely, log as agreed	Instruction leak, source bypass, unauthorized tool call, or denial of service
Multilingual question	Real German and English phrasing, spelling variation, and mixed language	Preserve meaning, conditions, source, and handoff	Different promise or missing restriction by language
Action	Valid, invalid, duplicate, unauthorized, and failed request	Confirm and execute only the permitted action once	Wrong record, duplicate write, missing confirmation, or no recovery
Human handoff	Low confidence, complaint, negotiation, urgency, and explicit request for a person	Transfer useful context through the stated route	Conversation ends, context is lost, or no person receives it

Pilot and acceptance

Move from proposal to a bounded public pilot.

Name the job and the stop line

Write the users, questions, outcome, excluded topics, allowed actions, and the business role that can stop the pilot.

Map data, knowledge, and permissions

Record every service and recipient. List approved sources, current-data systems, credentials, retention, access, deletion, and action limits.

Write expected answers and refusals

Build the evaluation set before tuning the demo. Define the source, expected conditions, refusal, handoff, action result, and evaluator for each case.

Test outside production

Run all cases with production-like configuration and test accounts. Fix failures, rerun the full affected set, and preserve both results.

Release to a limited audience

Show that the visitor is interacting with AI. Limit pages, traffic, actions, or hours. Keep the normal contact path and disable switch visible.

Review real outcomes and decide

Report denominators, accepted answers, refusals, handoffs, qualified outcomes, complaints, actions, failures, cost, and content gaps. Expand, change, pause, or remove it.

Automation next step

Scope this as an automation: WordPress AI chatbot buyer guide

Tell us the manual step you want gone. We reply with what is realistic to automate and what it costs.

Pilot scorecard

Use counts with denominators instead of a universal success rate.

Set release, warning, and stop thresholds before the pilot result is known. There is no defensible universal percentage for every site and use case.
Measure	Record	Interpret with	Decision signal
Answer acceptance	Accepted supported answers ÷ evaluated supported questions	Question mix, source freshness, language, and evaluator	Below the buyer-set launch threshold or a critical wrong answer
Safe refusal	Correct refusals ÷ unsupported or restricted questions	Handoff availability and false refusal rate	Invented answer on a prohibited or high-consequence topic
Human handoff	Received handoffs ÷ conversations that met a handoff trigger	Service hours, response result, context quality, and user request	Lost context, unrouted complaint, or no staffed destination
Qualified outcome	Agreed leads, bookings, or resolved tasks ÷ eligible conversations	Existing form/live-chat baseline and source of traffic	No useful change after operating cost and displacement are included
Action reliability	Correct completed actions ÷ approved action attempts	Denied, duplicate, failed, reversed, and unauthorized cases	Wrong or duplicate business write
Operating cost	Platform, model, storage, integration, monitoring, and support cost per accepted outcome	Volume, seasonal mix, internal time, and minimum fees	Unit cost or total spend crosses the approved alert
Complaints and incidents	Count, severity, affected user, data, action, resolution, and recurrence	Business incident and privacy processes	Any event that meets the agreed stop condition

Cost and exit

Price the operating system and prove you can remove it.

Use the separate AI automation cost guide for Some Tech Work planning bands. A chatbot quote still needs its own usage assumptions and operating boundary.
Cost or dependency	Quote unit	Buyer evidence	Exit question
Setup and content preparation	Fixed scope, source count, page count, language, or day	Included sources, exclusions, acceptance set, and deliverables	Can another supplier reuse the source inventory and tests?
Platform and plugin	Site, workspace, seat, conversation, response, or plan	Current plan limits, overage, renewal, and cancellation terms	What stops working when the subscription ends?
Model and retrieval	Input/output tokens, request, embedding, storage, or index refresh	Expected volume, model, region, cap, alert, and invoice owner	Can the provider and index be changed or exported?
Integrations and actions	Connector, system, workflow, transaction, or support tier	Credentials, limits, test environment, monitoring, and failure owner	How are credentials revoked and writes disabled?
Operation and improvement	Review hours, service window, content refresh, evaluation run, and incident response	Cadence, queue, response terms, change allowance, and report	Who owns open conversations and knowledge after handover?
Data and removal	Export format, deletion time, evidence, plugin cleanup, and fallback restoration	Test export, deletion route, removal steps, and normal contact path	Can the company leave without losing leads, sources, prompts, or records?

Primary sources

Check current law and the shortlisted product’s actual disclosures.

Article 50 of the EU AI Act addresses informing people when they interact with an AI system. Use the EU AI Act SME role guide for role, scenario, and application-date context; send binding interpretation to qualified counsel.

The BfDI AI questionnaire prompts organizations to document purpose, data, outputs, affected people, access, retention, and safeguards. The EDPB ChatGPT Taskforce report explains relevant transparency and data-subject-rights concerns.

Representative WordPress.org listings show why the product name is insufficient: Sant Chat AI, AskAny, aGo AI Chatbot, and Iris AI disclose different storage, model, content-indexing, and lead paths. These links illustrate variation; they are not recommendations.

Buyer questions

Questions to settle before a WordPress AI chatbot goes live.

Is a WordPress AI chatbot GDPR-compliant when it is hosted in Germany?

German hosting answers one data-location question. The company still needs to document purpose, legal basis, data fields, controller and processors, subprocessors, access, retention, security, transfers, rights handling, and deletion for the actual setup. Ask the accountable privacy or legal role to review that record.

Does a WordPress AI chatbot plugin keep all data in WordPress?

It depends on the plugin and configuration. A plugin may store transcripts locally while sending visitor messages, conversation history, retrieved page content, and tool results to an external model or managed service. Read the current external-service disclosure and verify the network and storage path.

How do we stop an AI chatbot from giving wrong prices or stock answers?

Use the live price, stock, booking, or order system as the authoritative source. Define a stale-data rule and prevent the assistant from inventing a current value when lookup fails. Test current, changed, unavailable, unauthorized, and conflicting records before launch and after every relevant integration change.

Does grounding the chatbot in our website prevent hallucinations?

No. Grounding limits the available evidence and can make sources traceable. The source may be stale, retrieval may select the wrong passage, or the answer may lose a condition. Require source references, refusal behavior, a dated evaluation set, monitoring, and a human route.

How much does a WordPress AI chatbot cost?

Compare setup and content preparation, platform or plugin fees, model and retrieval usage, storage, integrations, monitoring, support, evaluation, and content refresh. Record each billing unit, expected volume, minimum fee, overage, cap, and alert. Some Tech Work planning bands sit in the separate AI automation cost guide.

When should an AI chatbot hand the conversation to a person?

Trigger handoff for explicit requests, low evidence, complaints, negotiation, sensitive or high-consequence topics, failed actions, and cases outside service policy. State the destination, service hours, context transferred, response target, and fallback when nobody is available.

What should a WordPress chatbot pilot prove?

It should prove accepted answers from approved sources, safe refusal, current-data handling, permission limits, action reliability, human handoff, disclosure, data controls, operating cost, and removal. Report counts with denominators and preserve failed cases for the retest.

Next decision

Bring one workflow and its real questions to the scope call.

Use AI automation delivery when the assistant must connect to WordPress content, a CRM, booking, support, or another business system with a tested human route and operating record.

Use the AI automation project cost guide to compare Some Tech Work planning bands, inclusions, external costs, and quote assumptions before commissioning the build.

Written by

Vineet Talwar

Co-founder, Tech & Operations at Some Tech Work. WordCamp speaker across Europe and Asia, and host of the WP Shoutout podcast.

More about Vineet →Book a call →

Start here

Ready to talk.Book a short diagnostic.

Tell us what needs fixing

We read every brief and reply within one business day.

Prefer to talk first?or request a tech stack audit →or email us directly →

Not sure where to start? Send the stuck decision, workflow, or page. We will say whether you need a diagnostic call, a tech stack audit, or a different first step.

Reviewing first?

See outcomes and metrics →About the team →

-62% TTFB

Follow Founders