AI Chat + Human Takeover System
AI handles the first part of a customer conversation, keeps the context, and surfaces the serious inquiries. When a conversation needs a person, the owner or sales team takes over from Telegram and continues with the visitor in the same chat.
- Visitor
- AI assistant
- Intent check
- Telegram alert
- Human takeover
- Interface
- Chat widget on every page, EN and SR
- Memory
- Persistent conversation history, server-side
- Trigger
- Deterministic intent check, no extra model call
- Operator channel
- Telegram, with inline controls
- Response modes
- AI and human, switched per conversation
- Hosting
- Portable: persistent disk or managed database
The handoff breaks the conversation
A serious inquiry gets pushed to another channel, and the context built up so far is lost.
One conversation, two kinds of answer
The AI opens, a person takes over when it matters, and the AI can resume afterwards.
Serious inquiries reach a person
Business conversations are surfaced instead of sitting in a chat log nobody reads.
Every channel switch loses the context.
An AI assistant can answer questions, but a real inquiry still needs a person. The usual handoff pushes the visitor to email, a form, or WhatsApp - and a conversation that was already going has to start again somewhere else.
The visitor stays in one conversation from first question to real answer. Automation covers the repetitive part, a person steps in where judgement matters, and neither side loses what was already said.
- A persistent AI conversation: history lives on the server, so it survives navigation, refresh, and a server restart
- Deterministic commercial-intent observation - keyword and shape rules, not an extra AI call - that separates a business inquiry from ordinary browsing
- One Telegram alert per interesting conversation, with inline controls instead of a notification you can only read
- Human takeover: the AI stops answering that conversation, and the visitor is told plainly that a person joined
- Operator replies routed through the exact conversation, so two live conversations can never cross
- Return to AI with the full context preserved, including everything the human said
One conversation, from the first question to a person answering.
- 01
AI conversation
The assistant answers from approved content and keeps the history on the server.
- 02
Opportunity detected
Deterministic rules separate a real business inquiry from general questions.
- 03
Operator takeover
One Telegram alert with controls. Taking over pauses the AI for that conversation.
- 04
Live conversation
Visitor messages reach Telegram; the reply appears in the website chat, attributed to the person.
- 05
Return to AI
The assistant resumes with the human part of the conversation preserved as context.
The assistant answers first. A person takes over when it matters.
This is not an AI chatbot with a contact form behind it. It is a conversation that can change hands: AI, then qualification, then a person, then back to AI - with the same context throughout.
The system runs on this portfolio. The assistant in the corner of this page keeps its history across pages and refreshes, decides on its own when a conversation stops being general browsing, and can be taken over from Telegram mid-conversation.
The design principle is the same one that runs through the rest of this portfolio: automation handles the repetitive part, and a person stays in control of the decision that matters.
What runs today, and what is deliberately not built.
Both columns matter. The left one is verified by hand on this site; the right one is a direction, not a feature.
Working in production
- Persistent conversation history across navigation, refresh and server restart
- Deterministic intent check that separates a business inquiry from browsing
- One Telegram alert per conversation, with inline controls
- Human takeover: the AI stops answering that conversation
- Operator replies routed to the exact conversation they answer
- Return to AI with the human turn preserved as context
- Close, and a genuinely new conversation afterwards
- Conversation language follows the visitor, not the page locale
- Images both ways: the visitor sends one, and Jovan can reply with one from Telegram
- Approved knowledge base with semantic retrieval, and a review queue for questions it cannot answer
Not built yet
- Multiple named operators, each with their own attribution
- Documents and PDFs - images work, other file types are refused
- AI lead classification and CRM handoff
- Operator channels other than Telegram
- Rate limiting and retry for a failed operator forward
No conversion, response-time or inquiry-volume figures are claimed. The system has not been deployed for a client yet - the first production installation is this portfolio.
What the screenshots will show.
Screenshots of the real flow are being captured and anonymised. Each frame below marks what it will show; no mock-ups are used in the meantime.
How the system is put together
The conversation is the single source of truth. The AI, the operator, and the system notices all write into the same record, which is why a handover in either direction loses nothing.
- 1Store every visitor and assistant message server-side, keyed by an opaque session token held in the browser.
- 2Score the visitor side of the conversation with deterministic rules and alert the operator once when it becomes a business inquiry.
- 3On takeover, move the conversation to a human state, pause the AI, and write a visible notice into the transcript.
- 4Forward visitor messages to the operator and map each one to its conversation, so a reply can only reach that visitor.
- 5On return, hand the AI the full transcript with the human turn attributed to the person who wrote it.
Implementation notes
How the conversation store, the takeover state machine, reply routing and language handling are actually built.
Persistence
Conversation history lives on the server, not in the browser. It survives client-side navigation, a refresh, and a restart of the Node application. The browser holds only an opaque random token - never message content - and the store sits outside the deployed folder so a rebuild cannot touch it.
Commercial-intent observation
Whether a conversation is worth an alert is decided by deterministic keyword and shape rules over what the visitor already wrote. No extra AI call is made for it, so the decision costs nothing and is reproducible. Pricing questions, described business processes, and stated volumes qualify; "what is CRM" does not.
Human control
Taking over is a real state change, not a label in a chat app: the model is no longer called for that conversation. The visitor is told a person joined, and human presence is shown only for the conversation that was actually taken over - never as a standing claim that someone is online.
Safe routing
An operator reply must be a reply to a message mapped to one exact conversation. There is no fallback to the most recent visitor, so two live conversations cannot cross. If the target cannot be resolved unambiguously, the message is delivered to nobody and the operator is told why.
Language
The conversation follows the visitor, not the page. Somebody who starts in Serbian and walks onto an English page while still writing Serbian keeps getting Serbian answers, and the operator alert reports the conversation language separately from the page.
Portability
The hosting happens to be a Node application on shared hosting with a persistent disk, which is why the store is SQLite in a directory outside the deployment. On a platform with an ephemeral filesystem the same system uses a managed database instead. That is an adapter change; the conversation model, the state machine, and the routing rules do not move.
Reply routing
An operator reply is bound to one conversation by the Telegram message it answers. There is no fallback to whoever wrote last, so two live conversations cannot cross - the failure this design exists to prevent.
A handoff that keeps the conversation intact
The context survives the handover
Visitor, assistant, and human messages share one record, so neither the person nor the AI has to ask what was already said.
Messages cannot cross conversations
Routing is bound to a specific conversation by construction, not by remembering who wrote last.
Nobody is misled about who is answering
The AI never presents itself as a person, and human presence is only ever shown for a conversation a person really joined.
The same pattern works wherever a first conversation is worth automating.
The parts that carry the value are not specific to a portfolio: a conversation store, an intent check, an operator channel and a state machine that decides who answers. What changes per client is the knowledge the assistant is grounded in and who gets the alert.
- A site where most inquiries are routine but a few are worth a person
- A team that already lives in one messaging app and will not open another dashboard
- A business where the first reply matters more than a long support history
- A setup where the AI must never be the last word on price, scope or a commitment
Want this on your own website?
Tell me who talks to your customers today and where those conversations currently get stuck.
