ИИ-бот в Telegram для приёма заказов с сайта: как внедрить в Узбекистане
В Узбекистане Telegram давно заменил и email, и звонки: клиент не будет ждать ответа на почту, он напишет в бот. Разбираем, как собрать бота, который реально доводит заказ до CRM.
Почему точка входа — Telegram, а не форма на сайте
Классическая форма «имя — телефон — комментарий» на локальном рынке даёт низкий отклик: пользователь заполняет её и уходит в неизвестность, не понимая, когда с ним свяжутся. Бот отвечает мгновенно, и это единственный канал, где ответ ожидается в течение минуты.
Второй фактор — мобильный интернет. В регионах значительная часть трафика идёт через 3G и нестабильный 4G, где тяжёлая страница с формой может не догрузиться. Telegram работает при плохом соединении заметно лучше и часто уже открыт у пользователя в фоне.
Практичная схема: на сайте кнопка с deep link вида t.me/yourbot?start=product_123. Пользователь попадает в бот с уже известным контекстом товара, и первое сообщение бот формирует сам, не заставляя человека объяснять, что ему нужно.
Стек и как связываются части
Минимальный рабочий набор: Telegram Bot API (вебхук, не long polling — вебхук дешевле в хостинге и быстрее), серверная функция на Node.js или Python, вызов OpenAI API или Claude API для разбора свободного текста, и запись результата в amoCRM или Bitrix24 через их REST API.
LLM здесь нужна не для «болтовни», а для извлечения структуры. Пользователь пишет «нужно 3 штуки, доставка Чиланзар, завтра до обеда» — модель возвращает JSON с полями quantity, district, delivery_window. Это задача structured output, и она решается надёжно, если задать строгую схему ответа.
Никогда не давайте модели напрямую писать в CRM. Между LLM и CRM должен стоять слой валидации: проверка телефона на формат +998, проверка, что товар существует в каталоге, проверка суммы. Модель ошибается, валидатор — нет.
Языковой вопрос
Клиенты пишут на русском, узбекской латинице, узбекской кириллице и вперемешку. Отдельно распознавать язык обычно не нужно: современные модели справляются с mixed-input, если в системном промпте прямо сказано отвечать на языке последнего сообщения пользователя.
Проблема начинается на кнопках и шаблонах. Их придётся вести на двух языках вручную и давать пользователю явный переключатель при первом запуске — автоопределение по language_code в Telegram работает плохо, потому что у многих в интерфейсе стоит английский.
Транслитерация — отдельная головная боль. Названия районов и улиц пишут десятком способов: Chilonzor, Chilanzar, Чиланзар, Чилонзор. Держите словарь синонимов на своей стороне и матчите по нему, а не полагайтесь на модель.
Оплата внутри бота
Payme и Click предоставляют интеграции для приёма платежей, и в боте это обычно реализуется через генерацию платёжной ссылки, а не через нативные Telegram Payments — локальные провайдеры туда не подключены как официальные Payment Providers.
Практическая схема: бот собирает заказ, создаёт заказ на вашем бэкенде, генерирует ссылку на оплату Payme или Click с суммой и order_id, отправляет её кнопкой. Провайдер дёргает ваш webhook при успешной оплате, бот отправляет подтверждение.
В регионах значительная доля клиентов всё равно выберет оплату при получении. Не заставляйте платить онлайн как единственный вариант — конверсия просядет заметно сильнее, чем вы сэкономите на возвратах.
Сколько это стоит и сколько занимает
Ориентир рынка на конец 2026 года: простой бот с приёмом заявок и передачей в Telegram-канал отдела продаж — 6 000 000 – 12 000 000 сум. С LLM-разбором свободного текста, каталогом и интеграцией с CRM — 18 000 000 – 40 000 000 сум.
Операционные расходы часто недооценивают. При потоке в районе тысячи диалогов в месяц и разумной длине контекста расход на API модели укладывается в 300 000 – 900 000 сум ежемесячно. Экономия достигается кэшированием системного промпта и переводом простых веток на обычный код без вызова модели.
Сроки: 2–3 недели на базовую версию, ещё 3–4 недели на доведение сценариев по реальным логам. Второй этап пропускать нельзя — реальные пользователи пишут не так, как вы предполагали на этапе проектирования.
Что ломается в проде
Тайм-ауты. Telegram ждёт ответ на webhook быстро, а LLM может думать несколько секунд. Отвечайте на webhook сразу, ставьте задачу в очередь и отправляйте сообщение отдельным вызовом sendMessage, иначе Telegram начнёт ретраить и пользователь получит дубли.
Потеря заявки при падении внешнего API. Пишите заявку в свою базу до попытки отправки в CRM, а синхронизацию делайте отдельным фоновым процессом с ретраями. Заявка, которую бот принял и потерял, обходится дороже любого рефакторинга.
Отсутствие живого оператора. Всегда оставляйте команду для переключения на человека. В проектах такого типа именно эта ветка спасает сложные заказы, где модель начинает буксовать.