What Is Chatterbox?

Chatterbox is one product spread across an API, a business platform, and an embedded client. A visitor experiences those three codebases as one conversation.

A small-business website keeps receiving questions after the owner stops watching it. Visitors want to know whether a service covers their area, how much something costs, when the shop opens, or whether a product fits their needs. A brochure site can contain the answer and still make the visitor hunt for it. Many visitors leave instead of calling.

Chatterbox is the website chat product I am building for that gap. A business adds its website, FAQs, and documents, then pastes one script tag into its site. Visitors get a small chat bubble that answers from the business’s own content and collects contact details when the conversation needs a person.

The product is designed for Indian and international small businesses, including old PHP sites, WordPress installs, static pages, and hosted builders that cannot run a modern frontend build.

Installation is one script tag

The business receives a public key and a small embed snippet. The script loads the current Chatterbox widget without asking the website owner to change frameworks or install dependencies.

The widget runs inside a Shadow DOM. Its styles stay out of the host page, and the host page cannot casually break the chat window. It uses system fonts and a small bundle so it remains practical on older phones and congested connections.

Each key has an origin allowlist. A copied key should not work on an unrelated website.

The business supplies the truth

The dashboard lets a business add knowledge through website crawling, FAQs, and uploaded content. Chatterbox extracts a small set of important question-and-answer facts, embeds them, and keeps their source relationship.

When a visitor asks a question, the system searches the tenant’s knowledge base, selects relevant material, and drafts an answer from it. The business’s content remains the source of truth.

Questions outside that material receive an honest refusal. Chatterbox does not use general model knowledge to invent an answer about the business.

The multilingual flow is designed for English, Hindi, and Hinglish, with answers returned in the visitor’s language where the knowledge supports them. Wider Indian-language quality still needs measured per-language evaluation before broad claims.

Lead capture handles the next step

The visitor can leave a phone number or email when they want a person, when confidence is low, or when the business config asks for lead capture.

The lead stays connected to the conversation and source page. The business can see what the visitor asked before following up. Once the lead form succeeds, the widget closes that conversation and offers a fresh one. This prevents a captured lead from drifting into an endless bot thread.

Chatterbox does not yet provide a staffed live-agent console. Lead capture gives the owner a practical handoff without pretending someone is waiting behind the chat window.

The dashboard is the control room

A solo business can manage:

• website content and FAQs;
• crawl and ingestion status;
• chatbot greeting, color, position, and lead rules;
• install keys and allowed domains;
• conversations and captured leads;
• answer, refusal, and lead metrics;
• plan limits and usage.

Agencies can manage several client chatbots from one account. Each client remains a separate tenant with its own key, knowledge, configuration, conversations, and leads. White-label settings can replace Chatterbox branding with the agency’s name.

This matches how many small businesses buy website software: through the freelancer or web shop already maintaining the site.

Chatterbox keeps conversations separate

Anonymous visitors receive a local visitor token and conversation ID. Their history can survive page navigation without requiring an account. Separate tabs and completed lead flows need careful state handling so an old conversation does not leak into a new one.

The public widget API stays separate from dashboard authentication. Website visitors use the tenant’s public key and allowed origin. Business users sign into the private platform through backend-owned authentication.

Tenant scoping keeps one business from seeing another business’s knowledge, visitors, or leads.

The product promise

Small businesses need more than support deflection. Their website may receive only a modest number of questions, so saving an agent’s time is a weak reason to pay for software.

The useful outcome is catching a visitor who would otherwise leave. Chatterbox gives that visitor a quick, grounded answer and a short path to the business owner.

Accuracy matters because a wrong answer can lose the same lead the widget was meant to capture. Installation, knowledge management, refusal, and lead follow-up have to work as one path. The website should answer when the business has supplied the facts and help the visitor reach a person when it has not.

Building with AI: I designed the tenant, grounding, and lead-handoff boundaries; AI wrote much of the API, dashboard, widget, crawler, and RAG code. That speed also made extra model calls and parallel ingestion paths cheap to add. A repository-wide audit reduced production to three named model surfaces, moved translation to ingestion, and protected recrawl cleanup with tests that preserve manual and user-edited facts.

What is running underneath

After removing duplicate paths, production has three chat-model surfaces: grounded visitor answers (feature=chat), fact extraction during ingestion (feature=kb_extraction), and knowledge translation (feature=translation). Query and fact embeddings use the embedding provider separately. The old per-question translation call was removed; translated knowledge is prepared during ingestion, and the answer prompt asks the model to reply in the visitor's language.

A crawled page follows this path:

same-domain crawler
  → trafilatura main-content markdown
  → importance-ordered fact extraction
  → answer-aware tenant-scoped dedup
  → embedding
  → DocumentChunk + source provenance

Manual Q&A skips extraction and goes straight to persistence and embedding. Edited detected facts are marked user_edited and protected from recrawl replacement. A cancellation flag is checked between pages, so an operator can stop a crawl without throwing away facts already ingested.

I exercised the entire ingestion and answer path, with extra attention on stale-fact cleanup. A successful recrawl can prune vanished auto-detected facts; an empty or cancelled crawl cannot wipe the knowledge base.

The live-chat path is shorter, duplicate facts are rarer, crawls can be cancelled, and answers remain tied to business-supplied evidence. Tenant-scoped deduplication, source provenance, cancellation checks, and the rule that automation never deletes manual or user-edited facts keep those guarantees in place.