Skip to content
Firmspace
Back to blog

From Website Chat to a Deal in the CRM: What Happens After the First Message

A chat widget on a website is usually judged by how fast it answers. The harder problem starts afterwards: the visitor got an answer, closed the tab, and nothing about that conversation reached the CRM. A day later nobody can say who asked, what exactly they needed or what was promised. The measure that matters is not the reply speed but whether the first message turned into a record the team can work with.

In Firmspace the website chat is not a separate tool but one of the channels of the same conversation inbox. The widget is embedded on the firm's website, and each visitor receives an identifier that exists only in his own browser. Nobody has to create an account to start a conversation.

The visitor is met by the public assistant. It answers only from the platform's knowledge base: what the product does, which modules exist, how plans and prices work, whom it suits. It has no access to CRM data and no tools, so it cannot look into anyone's records. It replies in the language the visitor writes in, in one to five short sentences, and does not invent features or prices.

Not every question should be answered by a bot. When the conversation touches a specific account, a payment or invoice problem, a bug, a contract or legal matter, a discount, a partnership or custom development, the assistant hands the conversation over to a colleague and notifies the team. The person answers in the same chat, and the visitor is invited to leave an e-mail in case he leaves the page.

The public bot is deliberately kept on a short leash: short answers, a limit per visitor and a daily ceiling for the whole site. If the model is unavailable or the ceiling is used up, the earlier keyword-based matching takes over, so the widget does not fall silent. The whole public assistant can be switched off entirely when it is not wanted.

A chat on a public website is exposed to anyone, so visitor messages are treated as untrusted text. The assistant is instructed not to follow instructions hidden inside them, not to reveal its own rules, and never to ask for passwords, card numbers or other secrets.

What turns a conversation into a CRM record is the contact. An e-mail address or a phone number is validated by form — free text, a website address or a random string is not accepted as a contact — and then matched against the existing customer base. If the person is already known, the chat lands in his history instead of creating a second card.

The next step is deciding what deserves attention. The lead filter works in two layers. Rules come first, because they are free and instant: robot addresses, newsletter headers, typical auto-reply signatures, empty messages. Only what the rules cannot decide goes to the model, and messages are checked in batches rather than one by one. Every item ends as lead, junk or unsure. Unsure never enters the pipeline, but it stays in the journal. The firm can also describe its own rules in plain words — for example, that only enquiries about one particular service count.

For chats, the first messages of a conversation are assessed, and the assessment stops as soon as the verdict is lead or junk; after three unsure results in a row it stops guessing. A missed call with no content is not treated as a lead at all — it stays in the call journal, and if the person writes afterwards, that message is assessed like any other.

When the verdict is lead, three things happen at once: a contact is created, with the phone number from the chat if the identifier was a phone number; a card appears in the first column of the deals board; and the first message is saved into the history as a note. The source is recorded as the channel the person came through, the team receives a notification, and the CRM emits a lead-created event, so an automation rule can pick it up immediately.

Nothing here is a black box. The journal shows what the filter decided and why, so a wrongly rejected enquiry can be pulled back into the pipeline — the contact and the card are created again, in the first column. The owner can review and correct this from the CRM or from Telegram, where the assistant is available as a separate control bot, not the one that sends work notifications.

The point is not that a bot answers the first message. The point is that the website chat stops being a channel of its own and becomes the beginning of a deal record: the same contact, the same history, the same board — from the first hello to the signed contract.

Let us automate your next process together.

Describe a recurring workflow to us. Together we will check whether and how it can be automated sensibly.