On this page: what we actually build, why most website chatbots fail, how we approach it differently, and what it costs.
What We Build
Content-grounded site assistants. An assistant that answers from your actual content — service pages, product data, documentation, FAQs, policies — rather than from a general model’s guesswork. When it doesn’t know, it says so and offers a route to someone who does.
Lead qualification and routing. For businesses where the sales conversation starts with the same five questions every time: what do you need, what’s the scope, what’s the timeline, what’s the budget, who are you. The assistant collects that conversationally, then routes to the right person with the context attached — which usually matters more to your team than the deflection does.
Support deflection. Order status, shipping policies, hours, returns, “do you work with X.” The volume of repetitive questions that consumes a real person’s day without ever needing one.
Product and catalogue navigation. For e-commerce: helping someone describe what they need in their own words and arriving at the right product. Genuinely useful in catalogues where the taxonomy makes sense to you and not to your customer.
Internal knowledge assistants. Same technology pointed inward — an assistant your staff can ask about your own documentation and procedures.
Why Most Website Chatbots Fail
The technology is rarely the problem. These are:
It answers questions it shouldn’t. A general-purpose model attached to a website will happily answer questions about your refund policy that it invented. Every one of those is a promise a customer believes you made.
It’s grounded in nothing, or in the wrong thing. Pointed at a whole website including outdated blog posts and a five-year-old pricing page, an assistant will quote all of it with equal confidence.
There’s no exit. The single most common complaint about website chatbots isn’t wrong answers — it’s not being able to reach a human. An assistant that traps people is worse than no assistant.
Nobody measures it. It gets installed, it produces conversations nobody reads, and a year later nobody can say whether it helped or hurt. Conversation logs are the most valuable and most ignored output of the entire project.
It was chosen as a product, not designed as a service. A widget installed in an afternoon is a widget’s worth of value.
How We Build Them
1. Decide what it’s for — and what it isn’t.
The scoping conversation is the project. What questions should it answer? What must it never answer — pricing, legal, medical, anything requiring judgment? What happens when it doesn’t know? An assistant with a clear, narrow job outperforms an ambitious one, consistently.
2. Ground it in curated content.
Not “the website.” A deliberate, maintained knowledge source — the pages, documents, and product data that are actually current and actually correct. This is also the step that surfaces how much of your existing content contradicts itself, which is useful information regardless of whether you build the assistant.
3. Build in the handoff.
A visible, always-available route to a human. We treat escalation as a feature to design, not a fallback to hide.
4. Log everything and read it.
Every conversation captured and reviewable. Within weeks you’ll know what your customers actually ask, in their words — which routinely reshapes the site’s content, not just the assistant. This is where it connects to our website analytics consulting work.
5. Measure against a baseline.
Support volume, lead quality, conversion rate on assisted sessions, escalation rate, and unanswered-question rate — captured before launch so the “did it work” conversation has an answer.
6. Tune it, because the first version is never right.
Real questions expose gaps in the knowledge base and in the guardrails. The first four weeks after launch are a tuning period, and we scope them as part of the work rather than as a surprise.
Privacy and Data
Worth stating plainly, because clients ask and most vendor pages are vague:
- Conversations may contain personal information visitors typed voluntarily. We design what’s retained, for how long, and who can see it — before launch, not after a request.
- If your business handles regulated data — health, financial, children’s — that constrains what an assistant can be allowed to touch, and we’d rather scope narrowly than optimistically.
- Which AI provider processes your visitors’ messages is a decision with contractual implications. We’ll walk you through the options rather than defaulting to whatever’s cheapest.
What It Costs
Every engagement starts with a $2,500+ scoping engagement — what the assistant is for, what it must never answer, what content grounds it, and what success would look like measured. It’s credited toward the build, and if scoping concludes you don’t need one, you’ll have paid $2,500+ to avoid spending far more.
- Scoping engagement: $2,500+, credited toward the build
- Build: from $12,000, depending on knowledge base size, integrations, and handoff complexity
- Monthly (usage, monitoring, tuning): from $650
The monthly isn’t optional padding. An assistant nobody tunes degrades as your content changes, and the clients who buy this as a one-time build are reliably the ones who end up disappointed.
Related Services
- Custom Web Application Development — when the assistant needs to reach into real systems
- Website Analytics Consulting — measuring what the assistant actually changes
- Generative Ranking Optimization — visibility in AI search, a different service entirely
- Conversion Rate Optimization — for improving the paths the assistant sends people down
