AI Website Assistant: answers from real knowledge, and a conversation that becomes a lead

Before this system, much of the communication with users happened through Telegram or the website's ticketing system. Users had to wait for an answer, and there was no defined path from asking a question to getting the information — and, where it made sense, to booking a consultation. The goal was an assistant that could talk to users on the website and in Telegram, answer from the website's real information, guide them, and move anyone with a serious intent to get in touch into lead registration and consultation booking.

• The assistant had to work on both the website and Telegram.
• Answers had to be grounded in available, reliable information.
• Where the information to answer did not exist, the system could not make an answer up.
• Contact details could only be collected and recorded with the user's consent.
• A consultation request needed every required detail collected.
• Booking details had to be shown back to the user and confirmed before final registration.
• Lead data had to be validated before it was stored.
• Every lead had to stay linked to its channel and its conversation.

1. One assistant, two entry points

   Rather than two independent systems, one assistant logic serves both the website's chat widget and a Telegram bot. The path from conversation to conversion is built on the same structure in both channels, so they cannot drift apart.

2. RAG as the source of knowledge

   The website's information sits in a RAG system, so the assistant answers from the knowledge that actually exists. When the answer is not in it, the assistant does not guess or generate one — it points the user to the appropriate next step instead.

3. From conversation to lead

   The assistant is more than a question-answering bot: the conversation follows a defined path — Knowledge → Conversation → Qualification → Lead Creation → Consultation Booking. There are two kinds of lead: a contact lead, when the user wants to leave their details for further contact, and a consultation lead, when they want a consultation and give what booking one needs. For a booking, the assistant collects the details first, reads them back, and registers the request only after the user confirms.

4. Validated before it is stored

   The language model does not get the final say on storing a lead. What it collects arrives through defined tools and is validated on the server, with the same schemas the website's own forms use — so a lead that comes through the chat has to pass exactly the rules a form submission does.

5. Conversation details are not a lead

   Mentioning a name, an email or a phone number during a conversation does not create a lead on its own. Conversation details are kept separately from real leads, and a lead is created only once its conditions are met and its data is complete and valid.

6. No duplicate leads

   Each conversation has limits on the leads it can register, so one user cannot create duplicates within the same conversation. Every lead is also tied to where the user came in — chat-widget or chat-telegram.

7. Stored first, then notified

   A lead is written to PostgreSQL before its notification is sent, so a failed notification never loses the lead itself. After a successful registration the user receives a tracking number and an explanation of what happens next.

• AI website assistant
• Website chat widget
• Telegram bot
• RAG knowledge system
• Knowledge-grounded answers
• Handling of questions the knowledge base cannot answer
• Conversation guided by what the user needs
• Contact lead flow
• Consultation booking flow
• Contact details collected and validated
• Collection of the details a consultation needs
• Final confirmation of the booking details by the user
• Every lead linked to its channel and conversation
• Duplicate-lead prevention within a conversation
• Lead storage in PostgreSQL
• Notification system
• A tracking number for the user