Our own product
Support chats answered from each company's own content, with handoff to a person
We built our own AI support assistant: a website chatbot that answers from each company's documents, links and FAQs, with a live agent inbox for handoff. Each chatbot keeps its own knowledge base, and admins can write key answers by hand.
B2B SoftwareAI support assistantBuilt from zero
The challenge
A support bot has to answer from the right company's content, hand a visitor to a person without losing the conversation, and show its owner when it is not helping.
What we did
We scoped and designed every screen first, then built per chatbot knowledge bases, a live agent inbox over WebSockets and our own backend in place of a borrowed helpdesk.
The outcome
A working product with admin console, widget, agent inbox and usage dashboard, tested against grounding failures and shown in demos for admins and end users.
- Product
- Our own, built end to end
- Users
- Chatbot admins, support agents and site visitors
- Knowledge
- Documents, website URLs, FAQs and quick prompts
- Handoff
- Live agent inbox with full conversation history
The starting point
Our AI support assistant is a chatbot a company embeds on its website. Visitors chat with a bot that answers from the company's own content, and support agents take over in a shared inbox when the bot cannot help.
What had to change
A support bot has to answer from the right content, keep each company's content separate and hand a conversation to a person without losing it. Admins also need to see whether the bot is actually helping.
What could not break
- Each chatbot answers only from the documents, URLs, FAQs and prompts assigned to it
- A visitor handed to an agent keeps the whole conversation, and the agent sees every message
- The product carries its own brand, not a third party helpdesk's
- Admins can replace an AI answer with their own words
The calls we made
We framed it as three products in one, a grounded answer engine, a human support inbox and a self serve admin, and designed every screen before any code.
- 01
A knowledge base per chatbot
Documents, URLs, FAQs and quick prompts are assigned to one chatbot, so each company's bot answers only from its own content, and an admin can pick which child links of a website to include.
- 02
Replace the borrowed helpdesk backend
We could not remove its branding or easily change its logic, so we built our own APIs for chatbots, data sources, messages, conversation history, agents and settings while the frontend kept moving.
Ruled outStaying on the open source helpdesk's APIs and living with its brand.
- 03
People can override AI answers
Admins can write quick prompt responses by hand instead of generating them, so the answers that matter most are exactly what the company wants.
- 04
Test the answers, not only the screens
QA test cases ran across sign up, dashboard, knowledge base, widget and inbox, and recorded where the bot went wrong: wrong answers despite a supplied URL, different answers to the same question, only the last of several questions answered, and no answer at all.
- 05
Measure from day one
The dashboard tracks completion rate, escalation rate, feedback and sessions, so an admin can see when the bot is not helping.
How the system fits together
What we built
Chatbot builder and widget
Create and customize chatbots, a pre chat form, agent availability and integration code for an embeddable website widget with quick prompts and feedback after resolution.
Knowledge base
Upload documents, add website URLs and pick which child links to include, plus FAQs and quick prompts written by hand or generated with AI.
Usage dashboard
Bot sessions, conversations, average length, completion and escalation rates, new and returning users and positive or negative feedback, with date filters.
Agent inbox
Conversation list, chat area and details, agents assigned to chatbots and inboxes, read and unread status, real time messages over sockets and an idle timer that resolves inactive chats.
How it works
Set up
An admin creates a chatbot and assigns documents, URLs, FAQs and quick prompts to it.
Embed
The admin adds the widget to the website with the integration code.
Answer
A visitor fills the pre chat form and the bot answers from that chatbot's knowledge base.
Hand off
When the bot cannot help, the visitor moves to a human agent who sees the full conversation.
Review
After resolution the visitor leaves feedback, which shows on the admin dashboard.
A closer look
What changed
We reached a working product under our own brand: admin console, knowledge base, embeddable widget, agent inbox and usage dashboard, run in a test environment. Testing surfaced the ways a grounded bot fails, and we answered them with per chatbot knowledge, hand written answers and visitor feedback after each chat.
Under the hood
- Datics role
- Product built by Datics
- Grounding
- Answers come from the knowledge base assigned to each chatbot: uploaded documents, scraped website URLs, FAQs and quick prompts.
- Real time
- WebSockets carry messages, read status and connection state between visitors and agents, and an idle timer resolves inactive conversations.
- Roles
- Super admin, chatbot admin with collaborators, and agents assigned to chatbots and inboxes.
- Deployment
- Our own Node.js backend and React frontend, run in a test environment for demos and QA.
AI and models
Apps and APIs
Also in the stack
How it shipped
Scope and design
A scope document, user stories for super admin, chatbot admin and agent, workflow reviews and a full design set came before development.
First build and demos
Admin console, knowledge base, widget and inbox were built on a borrowed helpdesk's APIs, with demo videos for admins and end users.
Our own backend
We replaced the helpdesk APIs with our own for chatbots, data sources, messages, history, agents and settings.
Testing and live chat polish
QA test cases across every module, then read status, socket handling on login and logout, and an idle timer for the inbox.
Scope and design first
A scope document, user stories for each role and a full design set came before development, reviewed with our product lead.
Daily scrums, regular demos
The team ran daily scrums and showed working builds in internal demos, recorded as demo videos for admins and end users.
Tested before anyone outside saw it
QA test cases across sign up, dashboard, knowledge base, widget and inbox caught wrong, inconsistent, partial and missing answers before demos.
What this unlocked
The same pattern, answers from a scoped knowledge base with a person one step away, is what a support assistant needs when it lives inside an established product.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.