The problem
The client sells technical B2B infrastructure software, and its website's lead generation relied almost entirely on a "book a demo" form. Prospects in early research with specific technical questions (does this support our database? what's the pricing model? how does it handle a particular integration?) had no way to get an answer without booking a 30-minute call. A meaningful share simply left rather than fill out a form for a question they wanted answered in two minutes.
The sales team's own data showed that many demo calls spent the first ten minutes on the same handful of technical qualifying questions before reaching real discovery. That wasted sales time and lost prospects who didn't want to book a call just to ask "do you support X?"
Why we scoped this as a technical pre-sales tool, not a generic support bot
The client's first instinct was a general-purpose chat widget built on their whole website. We pushed back. The real opportunity was answering the recurring technical qualifying questions that were consuming sales time and losing early-stage prospects, grounded strictly in accurate product and pricing information, not a chatbot trying to be helpful about everything on the site, blog and careers pages included.
Architecture
Retrieval scoped to a curated knowledge base, not the whole website
Rather than indexing the entire website, we built a curated knowledge base covering product capabilities, technical integration details, and pricing, reviewed and approved by the client's product and sales leadership before launch. The constraint was deliberate: indexing marketing pages and blog content tends to produce a chatbot that's confidently vague, while a narrow, expert-reviewed knowledge base produces one that's precisely accurate on the questions that matter in a sales conversation.
Strict grounding on pricing and capability claims
Any response involving pricing, SLAs, or specific capability claims is generated only from the curated, approved knowledge base with no open-ended elaboration. When a question falls outside what it has grounded information for, the system declines and offers a human handoff rather than guessing. In a technical B2B sale, an inaccurate capability claim can cost real trust with a technical buyer, so this mattered more than making the bot feel maximally conversational.
Qualification and warm handoff to sales
The widget picks up qualification signals naturally in conversation (company size, use case, timeline) instead of through a separate form. When a conversation shows real buying intent, it offers a warm handoff to book time with a specific sales rep and passes along the full conversation, so the prospect doesn't repeat themselves on the call. That turned it from a support tool into a genuine top-of-funnel qualification asset.
Native widget, not a third-party embed
We built it as a lightweight widget integrated directly into the client's site rather than a heavy third-party chat embed, to keep the impact on page load minimal and to give full control over styling and behavior, consistent with the rest of the site's design.
Challenges and tradeoffs
- Getting the knowledge base curated and approved took longer than the engineering. Product and sales leadership's review of every piece of content the bot could cite took nearly three of the five weeks. It was time well spent: it's the mechanism that keeps the bot from making claims the sales team would have to walk back on a call.
- Distinguishing "I don't know" from "let me find a human" needed careful tuning. Early versions either declined too eagerly on questions they could answer, frustrating users, or answered too confidently on genuinely out-of-scope questions. We tuned this against a labeled set of real prospect questions gathered during a soft launch before wider rollout.
- Keeping the knowledge base current required a defined ownership process, not just a one-time build. Product changes and pricing updates needed a clear internal owner for the curated source content, which we helped the client establish within their existing product marketing workflow.
Results
The widget handles over 2,100 conversations a month, and 44% of qualified demo requests in the two months after launch followed a chatbot conversation. The sales team noted these correlated with shorter, more productive first calls, because basic technical questions had been answered beforehand. A post-launch audit of a sample of pricing and capability responses found zero fabricated claims, the specific risk the curated, grounded architecture was designed to prevent.
The client's sales leadership rated the qualification handoff, more than the question answering, as the most valuable outcome, because it surfaced serious prospects earlier in their research than the old demo-request-only funnel.
What we'd do differently
We'd establish the content-ownership process for keeping the knowledge base current before launch rather than defining it during the post-launch period. It worked out, but a clear owner from day one would have avoided a short window when a pricing page update wasn't reflected in the bot's knowledge base until it was caught in review.