Customer Support Widget
Embed an AI-powered support assistant on your website that answers customer questions instantly from your existing documentation, with source citations.
What does it cost you every time a customer submits a ticket that could be answered by your existing documentation?
I will tell you what it cost one of my early users. They ran a B2B SaaS product with a 12-person support team. Average cost per ticket: around 15 euros when you factor in agent salary, tooling overhead, and response time. Sixty percent of their tickets were questions that had documented answers in their help center.
That is 15 euros per deflectable ticket, times hundreds of deflectable tickets per week, for answers that already existed. The documentation was there. Customers just could not get to it.
This is the specific problem the embed widget solves. Not "AI for your website." Ticket deflection through better retrieval.
Deflection, Not Replacement
I want to be precise about what this does and does not do.
The widget handles tier-0 and tier-1 questions. Password resets. Billing explanations. "How do I export my data?" Feature walkthroughs. Configuration guides. Questions with clear, documented answers.
Your human agents then spend their time on the things that actually need a human. Complex troubleshooting. Edge cases. Frustrated customers who need empathy, not a knowledge base article.
This is about respecting your support team's time. Every repetitive question the widget deflects is time they get back for work that matters.
What the Customer Experiences
A customer lands on your help center. They have a question. They want an answer now - not in 24 hours, not after navigating 400 articles sorted by categories that made sense to whoever wrote them.
They click the chat button. Type their question in plain language. The answer streams back in real time with clickable citations linking to the original documents.
No login. No account creation. No ticket form. A question and an answer.
The citations matter. Customers can click through to verify the response in the original document. This is not a black box generating plausible-sounding text. Every claim traces back to your documentation. When customers see that, trust goes up. Ticket escalations from "I do not believe this answer" go down.
Why This Works Better Than a Help Center
A help center is a library. It requires the customer to know what they are looking for, browse the right category, click the right article, and find the right paragraph.
The widget is the opposite. The customer describes their problem in their own words. Knowably finds the answer regardless of how the documentation is organized or what terminology it uses. "I cannot log in" matches documents about "authentication troubleshooting" and "password reset procedures" and "account recovery workflow" - even though none of those contain the phrase "cannot log in."
That is the difference between keyword search and what happens inside Knowably's retrieval pipeline. The customer does not need to think like your documentation team.
The Deployment Story
I deliberately built the widget deployment to be trivial. One script tag:
<script
src="https://embed.knowably.ai/embed/loader.js"
data-workspace="your-workspace"
data-agent-token="your-agent-token">
</script>
Paste that into any page. Static HTML, WordPress, a React app, your docs platform. No npm package. No build step. No framework dependency.
The widget loads inside a Shadow DOM boundary, which means complete CSS isolation. Your styles do not bleed in. The widget does not break your layout. I made this decision specifically because I saw too many embeddable tools that required a frontend engineer to babysit the integration. A marketing manager can deploy this by editing a single HTML file.
For the full technical details on Shadow DOM, iframe architecture, and customization, see the embed widget setup guide.
Security for Public-Facing Deployment
This is where I get opinionated. Most "AI chat widgets" treat security as an afterthought. A floating button, an API key in the source code, and hope nobody abuses it. That does not survive contact with the real internet.
I built the widget's security model for public-facing deployment from day one. The details are on the security page and the embed widget feature page, but here is what matters for the business decision:
Origin validation. Every agent has an explicit allowlist of domains. No allowlisted origins, no widget. Deny by default. Revoke a domain and existing sessions from that domain stop working immediately.
Session tokens. SHA-256 hashed before storage. The plain token never touches the database. If the database is compromised, the tokens are useless.
Rate limiting. 10 session creations per minute per IP. 20 messages per minute per session. Automated abuse gets blocked before it costs you money.
CSP and CORS. Browser-enforced restrictions on which domains can load the widget. Even if someone copies the iframe URL, it will not render on an unauthorized domain.
Your security team can review the full architecture. I built it to withstand that conversation.
What You Actually Learn
Here is something that surprised me about production deployments. The widget is not just a support tool. It is a research tool for your product and documentation teams.
Every conversation reveals what customers actually ask about. Not what you think they ask about. What they actually type, in their actual words.
When the agent cannot answer a question, that is a documentation gap. When the same question comes up repeatedly, that is either a confusing feature or a missing help article. When answers are slow, Langfuse tracing shows you exactly which pipeline step is the bottleneck.
The dashboard tracks all of this per agent - query volume, token costs, user feedback. The organizations that get the most from the widget treat this data as a product feedback channel, not just a support metric.
Scale and Cost
The widget serves one visitor or ten thousand concurrent visitors the same way. It answers questions at 3 AM on a Sunday. It does not take holidays. The cost per interaction is a fraction of a human support interaction.
For that B2B SaaS company I mentioned, the widget handled roughly 400 conversations per week within the first month. Their support ticket volume dropped by about 35%. The math was not subtle.
Support teams are expensive. Hiring does not scale linearly with ticket volume. And your customers do not want to wait for an answer to a question that is already documented. They want the answer now.
Get Started
Your documentation already has the answers. Your customers just cannot find them.
Put a widget on your help center. Let them ask.
Start Free Trial | Book a Demo | Embed Widget Feature Details