AI Telegram bot for order intake from your website in Uzbekistan
In Uzbekistan Telegram has replaced both email and phone calls: a customer will not wait for an email reply, they message the bot. Here is how to build one that actually gets the order into CRM.
Why the entry point is Telegram, not a web form
The classic name-phone-comment form performs poorly on this market: the user submits it and then waits in silence with no idea when someone will call back. A bot replies instantly, and it is the only channel where a reply within a minute is the expectation.
The second factor is mobile connectivity. In the regions a large share of traffic runs over 3G and unstable 4G, where a heavy form page may never finish loading. Telegram performs noticeably better on poor connections and is often already open in the background.
A practical pattern: put a deep link button on the site, t.me/yourbot?start=product_123. The user lands in the bot with product context already known, and the bot composes the first message itself.
The stack and how the parts connect
Minimum viable set: Telegram Bot API over webhooks (not long polling — webhooks are cheaper to host and faster), a Node.js or Python server function, a call to the OpenAI API or Claude API to parse free-form text, and a write into amoCRM or Bitrix24 via their REST API.
The LLM is not there to chat, it is there to extract structure. The user writes 'need 3 units, delivery to Chilanzar, tomorrow before noon' and the model returns JSON with quantity, district and delivery_window. This is a structured output task and it is reliable when the response schema is strict.
Never let the model write into CRM directly. A validation layer belongs between LLM and CRM: phone format check against +998, product existence check against the catalogue, total amount check. Models make mistakes, validators do not.
The language question
Customers write in Russian, Uzbek Latin, Uzbek Cyrillic and mixtures of all three. Separate language detection is usually unnecessary: modern models handle mixed input if the system prompt states plainly to answer in the language of the last user message.
The trouble starts with buttons and templates. Those have to be maintained in two languages by hand, with an explicit switcher on first launch — auto-detection from Telegram's language_code works badly because many users have their interface set to English.
Transliteration is a separate headache. District and street names are written a dozen ways: Chilonzor, Chilanzar, Чиланзар. Keep a synonym dictionary on your side and match against it rather than trusting the model.
Payments inside the bot
Payme and Click offer payment integrations, and in a bot this is normally done by generating a payment link rather than through native Telegram Payments — the local providers are not wired in as official Payment Providers there.
The working pattern: the bot assembles the order, creates it on your backend, generates a Payme or Click link with the amount and order_id, and sends it as a button. The provider calls your webhook on success and the bot confirms.
In the regions a substantial share of customers will still pick cash on delivery. Do not make online payment the only option — the conversion loss will exceed whatever you save on refunds.
Cost and timeline
Market reference as of late 2026: a simple bot that captures leads and forwards them to the sales team's Telegram channel runs 6M – 12M UZS. With LLM parsing of free text, a catalogue and CRM integration, 18M – 40M UZS.
Running costs are routinely underestimated. At roughly a thousand conversations a month and sensible context length, model API spend lands around 300,000 – 900,000 UZS monthly. Savings come from caching the system prompt and routing simple branches through plain code with no model call at all.
Timeline: 2–3 weeks for a base version, another 3–4 weeks tuning scenarios against real logs. Do not skip the second phase — real users do not write the way you assumed at design time.
What breaks in production
Timeouts. Telegram expects a fast webhook response while the LLM may think for several seconds. Answer the webhook immediately, queue the job, and send the reply as a separate sendMessage call, or Telegram will retry and users will get duplicates.
Lost leads when an external API is down. Write the lead into your own database before attempting the CRM push, and sync in a background process with retries. A lead the bot accepted and then lost costs more than any refactor.
No human fallback. Always keep a command that hands the conversation to a person. In projects of this type that branch is what rescues complex orders where the model starts to stall.