How to Build an AI Chatbot for a Client Website (Without Overselling It)
- The chatbot is not the product. Answered questions and captured leads are the product. Scope the build around the ten to fifteen questions the client's customers actually ask, not around the technology.
- Ground the bot in the client's real content so it cannot make things up. An ungrounded chatbot that invents a return policy or a price is worse than no chatbot, because now the client is liable for what it said.
- Price it as a lead-capture and support-deflection outcome, not as a chatbot. A widget that books three extra calls a month or deflects thirty support emails is easy to justify. A chatbot as a feature is easy to cut.
Start With the Questions, Not the Chatbot
Before you write a line of code, get the list of questions the client's customers actually ask. Not the questions the client thinks they ask - the real ones. Pull them from the contact form submissions, the support inbox, and the FAQ page. Most small businesses answer the same ten to fifteen questions over and over: hours, pricing, location, availability, whether you do X, how to book.
That list is the scope of the build. A chatbot that reliably answers those fifteen questions and knows when to hand off is worth money. A chatbot that tries to answer anything a visitor types is a liability. Narrowing the job is the single decision that separates a build that ships from a build that embarrasses the client.
Ground the Bot in the Client's Real Content
The most important technical decision is grounding: the chatbot answers only from the client's own content, and it says it does not know rather than inventing an answer. An ungrounded model will confidently state a return window, a price, or a warranty that does not exist. The moment it does, the client owns that statement. Grounding is not a nice-to-have. It is the difference between an asset and a lawsuit risk.
The practical build: collect the client's pages, FAQ, policy documents, and service descriptions into a small knowledge base. Feed only that content to the model as context and instruct it to answer from that content alone. When a question falls outside the content, the bot says so and offers the escalation path instead of guessing.
| Question | Ungrounded bot | Grounded bot |
|---|---|---|
| What is your return policy? | Invents a plausible 30-day policy that does not match reality | Quotes the client's actual policy, or says it will connect the visitor to someone who can confirm |
| Do you service my area? | Guesses yes to be helpful | Answers from the client's real service-area list, or asks for a zip code and escalates |
| How much is a project like mine? | Makes up a number | Explains that pricing is scoped per project and captures the lead for a quote |
Grounded versus ungrounded chatbot behavior
This is the same discipline that makes a CLAUDE.md file work on a client build: constrain the model to the client's real facts. The full approach is in [the CLAUDE.md file for client projects](/blog/claude-md-file-for-client-projects).
Build It With a Human Handoff Baked In
The chatbot's job is not to answer everything. It is to answer the routine questions instantly and route everything else to a human without dropping the visitor. Every unanswered question is a lead. The bot should capture a name and an email or phone number the moment it hits a question it cannot ground, then tell the visitor someone will follow up.
This is where the value actually lives. A support bot that only deflects is a cost saving. A support bot that captures every off-script question as a qualified lead is a revenue engine. Build the escalation as a first-class feature: a form the bot fills as it talks, a notification to the client, and a confirmation to the visitor.
- Bot answers routine questions from grounded content.
- On any off-script or high-intent question, bot captures contact details in the flow of conversation.
- Client gets an instant notification with the visitor's question and details.
- Visitor gets a clear next step so the conversation never dead-ends.
Embed It Without Breaking the Client's Site
Ship the chatbot as a lightweight widget the client drops into their site with a single script tag, not as a rebuild of their website. Most small business sites run on a platform the client already pays for. Do not touch it beyond adding one embed snippet. The widget lives in an iframe or a script that loads asynchronously so it never slows the page or conflicts with the client's existing setup.
Test it on the client's actual site before handoff, not just on localhost. Check it on mobile, check it does not cover the client's own call-to-action button, and check it loads even when the visitor is on a slow connection. The widget breaking a client's site is the fastest way to turn a paid build into a refund conversation.
Price It as an Outcome, Not a Feature
Nobody buys a chatbot. They buy fewer missed enquiries and fewer hours answering the same questions. Price against that. If the widget captures three extra leads a month that would otherwise have bounced, and the client closes even one, the build has paid for itself many times over. Frame the quote around captured leads and deflected support, and the price stops being a comparison to a five-dollar plugin.
The strongest structure is a build fee plus a small monthly retainer to maintain the grounding as the client's content changes. Policies update, prices change, new services launch. A chatbot grounded in last quarter's content slowly goes stale. The retainer keeps it accurate and gives you recurring revenue. The pricing logic is the same one in [value-based pricing - stop charging hourly](/blog/value-based-pricing-stop-charging-hourly).
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
How long does it take to build an AI chatbot for a client website?
A grounded website chatbot for a small business is a two to four day build once you have the client's content and question list. The model integration is fast. Most of the time goes into collecting and structuring the client's real content so the bot cannot invent answers, wiring the human handoff, and testing the widget on the client's actual site across mobile and desktop.
How do I stop an AI chatbot from making things up on a client site?
Ground it. Feed the model only the client's own pages, FAQ, and policy documents as context, and instruct it to answer from that content alone. When a question falls outside the grounded content, the bot should say it does not know and capture the visitor's details for a human follow-up rather than guessing. An ungrounded chatbot that invents a policy or price makes the client liable for what it said.
What should I charge to build a chatbot for a client website?
Price it as a lead-capture and support-deflection outcome, not as a chatbot feature. A build fee plus a small monthly retainer to keep the grounding current is the strongest structure. Anchor the quote to what the widget is worth - extra leads captured and support hours saved - so it is not compared to a cheap off-the-shelf plugin. Value-based pricing applies directly here.
Should the chatbot try to answer every question a visitor asks?
No. The most valuable chatbot answers the routine questions instantly and routes everything else to a human without dropping the visitor. Every off-script or high-intent question is a lead. Build the escalation as a first-class feature: capture the visitor's contact details in the flow of the conversation, notify the client immediately, and give the visitor a clear next step.
Where should I host the chatbot so it does not break the client's website?
Ship it as a lightweight widget the client adds with a single script tag, loaded asynchronously so it never slows the page. Keep the API key server-side, lock the widget to the client's domain, rate-limit requests, and cap model and token spend so a funded key cannot be drained through an open endpoint. Test on the client's real site, on mobile, before handoff.
Last reviewed September 8, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
