21 августа 2026 г. · Maksim Shchegolev

Заявки из Telegram в CRM: приём, дубли, ответственный

Канал Telegram становится управляемым источником заявок при 4 условиях: событие заявки записано с источником, контакт склеен с уже существующим, у обращения появился названный ответственный и таймер, и вся переписка попала в CRM. Без этих четырёх Telegram остаётся чатом, в котором заявки теряются тише всего.

Хотите проверить это на своём сайте? Запустите бесплатную проверку видимости в ИИ, она занимает десять секунд и не требует почты.

Заявки из Telegram ведут себя не так, как заявки с формы на сайте. У формы есть момент отправки, обязательные поля и адрес страницы. В мессенджере есть только слово «здравствуйте», написанное в 23:40 сотруднику, который в отпуске. Инструкций по сборке бота в сети достаточно, и почти все они заканчиваются там, где начинается работа: бот научился отвечать. Что происходит с обращением дальше, кто за него отвечает и как оно становится записью без дублей, не пишет почти никто.

Этот гайд отвечает за операционный контракт канала: что считать событием заявки, какие данные обязаны дойти до CRM, кто владеет диалогом и что происходит с историей переписки, когда сотрудник уходит. Логика квалификации разбирается в гайде про квалификацию заявок с помощью ИИ, приоритет правил выбора ответственного живёт в плейбуке по распределению заявок.

Одним предложением

Канал Telegram становится управляемым источником заявок при четырёх условиях: событие заявки определено заранее, у обращения есть стабильный числовой ключ личности и метка источника, у диалога есть названный ответственный и норматив времени ответа, а переписка живёт в общем боте с передачей в CRM, а не в личном аккаунте сотрудника, который уносит историю при увольнении.

Почему заявки из Telegram теряются чаще, чем заявки с сайта

Форма на сайте плоха тем, что её надо заполнять, и хороша тем, что момент отправки существует. Есть событие, есть набор полей, есть страница, с которой оно пришло. В мессенджере ничего этого нет по умолчанию. Есть поток сообщений в чате, у которого может не быть ни одного структурированного поля, зато есть ожидание, что вы ответите прямо сейчас.

Дальше срабатывает бытовая механика. Сообщение приходит в личный чат конкретному сотруднику, и видит его только он. Уведомления в рабочем телефоне отключены, потому что там же семейный чат и три отраслевых канала. Человек написал в пятницу вечером, а понедельник начался с планёрки. Через неделю руководитель спрашивает, сколько заявок дал Telegram, и получает ответ «ну, штук пять было».

Порядок величины тут известен. В 2011 году Harvard Business Review посмотрел, как отвечают на входящие 2 241 американская компания: у ответивших середина пришлась примерно на 42 часа, а часть не ответила никогда. Работа старая, американская и про одну выборку, так что берите из неё картину неуправляемого потока, а не ориентир для российского рынка сегодня. В мессенджере эта задержка ощущается больнее: покупатель видит время последнего посещения собеседника и делает выводы сам.

Обратите внимание, чего в этой таблице нет: конструктора ботов. Ни одна строка не чинится выбором платформы. Все они чинятся договорённостями, которые надо записать до того, как бот скажет первое слово.

Четыре входа через Telegram и почему их нельзя обрабатывать одинаково

Фраза «мы принимаем заявки в Telegram» обычно скрывает четыре разных канала с разной механикой, разными данными и разными рисками. Их регулярно пытаются свести к одному правилу, и именно оттуда растёт большая часть потерь.

Бот компании это единственный вход, который изначально приспособлен для приёма заявок. Согласно документации Telegram Bot API, бот получает обновления по каждому сообщению в диалоге с ним, и в этих обновлениях есть числовой идентификатор пользователя и время. С этого можно строить контракт. Важное ограничение того же порядка: бот не начинает диалог первым, пока человек сам не запустил его. Значит, дожим через бота работает только внутри уже начатого диалога, и планировать цепочку касаний по холодной базе через этот канал не получится. Как устроен сам дожим, разбирается в гайде про систему дожима заявок.

Личное сообщение сотруднику это самый частый и самый опасный вход. Он выглядит как забота о клиенте и работает как чёрный ящик: нет журнала, нет ответственного в системе, нет способа передать диалог, нет доказательства договорённостей. Полностью запретить его нельзя, потому что покупатель пишет тому, чью визитку получил на выставке. Можно и нужно сделать другое: определить, что личный диалог это точка перехвата, а не место обработки, и записать процедуру перевода в рабочий контур в первые же минуты.

Комментарии и обсуждения под постами канала живут в связанной группе обсуждения. Это публичная площадка, и цена молчания здесь выше: неотвеченный вопрос под постом видят все следующие читатели. Отдельная техническая деталь: по умолчанию бот в группе видит не все сообщения, а поведение зависит от настроек приватности бота и от того, как он добавлен в группу. Проверьте это на своём боте до того, как построите на комментариях процесс, иначе половина обращений просто не дойдёт до приёма.

Переход по ссылке на сайт формально не является заявкой в мессенджере вообще. Человек кликнул и ушёл заполнять форму. Проблема в том, что для отчёта он теперь «прямой заход» или «переход из мессенджера» без деталей, а для CRM это отдельная личность, никак не связанная с диалогом в боте. Приёмом заявки на стороне сайта владеет гайд про приём заявок на сайте, здесь нас интересует только сшивка.

Правило, которое стоит за таблицей, простое: обрабатывать одинаково можно только то, что одинаково наблюдаемо. Три из четырёх входов дают разный набор данных, поэтому у них разные требования к минимальному набору полей и разные нормативы времени ответа.

Что считать заявкой там, где нет формы и обязательных полей

В форме событие определено кнопкой. В мессенджере вам придётся определить его самостоятельно, письменно и до запуска. Иначе будет два одинаково бесполезных исхода: либо заявкой считается каждое «здравствуйте» и отчёт по каналу превращается в счётчик приветствий, либо заявкой считается только диалог, дошедший до цены, и половина работы исчезает из статистики.

Рабочее определение состоит из двух состояний, а не из одного. Первое: диалог открыт. Второе: заявка зафиксирована. Первое наступает при первом входящем сообщении и означает, что запущен таймер ответа и назначен ответственный. Второе наступает, когда в диалоге появился предмет обращения или явный запрос действия от вашей компании, и означает, что создана или обновлена запись в CRM.

Два состояния решают ещё одну проблему. Диалог, который открыт больше суток и так и не стал заявкой, это не мусор, а материал: либо вопрос был непонятен, либо человек не дождался ответа. Такие диалоги стоит смотреть отдельным списком раз в неделю. Обычно там же обнаруживается, что бот задаёт первый вопрос слишком широко.

Отдельно проговорите, что делать с сообщениями, которые пришли, но человек их удалил. Собеседник может удалить своё сообщение, в том числе у обеих сторон, и в чате не останется ничего. Это ещё одна причина, по которой факт обращения должен фиксироваться в вашей системе в момент получения, а не восстанавливаться потом по скроллу переписки.

Минимальный набор данных до передачи в CRM

Соблазн понятный: раз в мессенджере можно задать любой вопрос, давайте зададим все. Так рождается бот, который спрашивает восемь полей до того, как человек узнал хоть что-нибудь полезное. Обратная крайность тоже плоха: в CRM падает карточка с текстом «интересует сотрудничество» и без единого способа связаться.

Работающий компромисс собирается из трёх слоёв. Первый слой получен автоматически и не стоит собеседнику ничего. Второй слой обязателен для передачи в продажи и добывается по одному полю за раз, вперемешку с полезными ответами. Третий слой желателен и спрашивается только тогда, когда разговор уже идёт.

Про способ связи вне мессенджера стоит сказать отдельно. Bot API не отдаёт боту номер телефона пользователя сам по себе. Человек может поделиться контактом через специальную кнопку, и это добровольное действие. Значит, номер это не поле, которое вы «получаете», а поле, которое вам соглашаются дать, и просить его надо в момент, когда взамен уже что-то дано: расчёт, время встречи, подготовленный документ.

Правило вопросов, которое спасает диалоги от превращения в допрос: один вопрос за одно сообщение, и каждый следующий вопрос идёт после полезного ответа с вашей стороны. Три вопроса подряд без единого ответа читаются как анкета, и на третьем человек закрывает чат. Что именно спрашивать для оценки готовности покупать, разбирается в гайде про квалификацию заявок с помощью ИИ, а какие поля обязаны существовать в самой карточке, описывает гайд про автоматизацию обработки заявок в CRM.

Личность пользователя в Telegram: что стабильно, а что нет

Здесь ломается больше всего интеграций, собранных на скорую руку. Кажется естественным записать в карточку «@ivanov» и считать это идентификатором клиента. Через три месяца человек меняет имя пользователя, и связь между записью и диалогом исчезает молча.

Три следствия, которые надо принять до настройки полей.

Первое: ключом делается числовой идентификатор, а имя пользователя хранится рядом как справочное значение. Имя пользователя удобно менеджеру, чтобы найти человека, и бесполезно системе, чтобы его опознать. Освобождённое имя пользователя вдобавок может занять кто-то другой, и тогда поиск по нему приведёт не к тому человеку.

Второе: числовой идентификатор стабилен внутри вашего бота, но он ничего не говорит о том, что это тот же человек, который вчера оставил заявку на сайте. Мостом между каналом и сайтом служит только общий признак: нормализованный номер телефона, почта или явно переданный код, о котором ниже.

Третье: у одного покупателя может быть личный диалог с ботом и одновременно сообщение в группе обсуждения. Это два контекста, два потока сообщений и один человек. Если ваша интеграция считает их разными личностями, вы получите двух ответственных на одну сделку.

Как узнать, откуда пришёл человек: параметры перехода и метки источника

Мессенджер не передаёт метки UTM. Это стоит написать на стене. Человек нажал рекламное объявление, попал на сайт, кликнул кнопку «написать в Telegram» и оказался в боте: если ссылка была статичной, вся история перехода осталась на сайте, а в боте вы видите чистый лист.

Документация Telegram Bot API описывает механизм ссылки со стартовым параметром: параметр приходит боту вместе с командой запуска диалога. Это единственный штатный способ дотащить контекст перехода внутрь мессенджера. Работает он так: сайт или рекламная система формирует ссылку с коротким кодом, бот получает код в первом сообщении, а расшифровку кода в понятный источник вы держите в справочнике на своей стороне.

Четыре практических замечания.

Параметр короткий, полный набор меток UTM в него не поместится. Поэтому передаётся код, а не строка перехода, и расшифровка живёт в справочнике, которым владеет операционная роль. Словарь значений источника принадлежит гайду про атрибуцию источников заявок, здесь важно только одно: значение, которое приходит из канала, должно быть из того же справочника, что и значения с сайта.

Поведение приложения при повторном открытии ссылки человеком, у которого диалог с ботом уже начат, отличается от первого запуска. Проверьте оба сценария на своём боте до запуска кампании, а не после первого отчёта.

Пустое значение источника это тоже данные, но только если оно записано явно. Заведите значение «источник не определён» и никогда не оставляйте поле пустым: пустое поле в отчёте неотличимо от сбоя интеграции.

Обратный переход тоже стоит размечать. Когда бот отправляет человека на страницу с расчётом или на оплату, вставляйте в ссылку код диалога, иначе заявка с сайта придёт как новая и не свяжется с перепиской.

Дубли: один покупатель, три входа

Классический сценарий выглядит так. Человек звонит по номеру с сайта, ему не отвечают, он заполняет форму, а через два часа пишет боту, потому что так быстрее. Три записи, три ответственных, три версии правды. Через неделю двое менеджеров звонят ему в один день с разными предложениями.

Правила поиска дублей и приоритет полей принадлежат гайду про автоматизацию обработки заявок в CRM. Здесь разбирается только то, что специфично для мессенджера: какие ключи у вас вообще есть и насколько им можно верить.

Российская деталь, которую стоит учесть заранее: значительная часть малого бизнеса пишет с личных аккаунтов и даёт мобильный номер, тот же самый, что уже лежит в карточке от звонка. Нормализация телефона на входе, включая приведение восьмёрки к международному формату, закрывает больше дублей, чем любое последующее слияние вручную.

Последняя строка регулярно всплывает как претензия от клиентов. Человек, который уже платит вам деньги, пишет в бота «а можно продлить», получает автоматическое «расскажите о вашей задаче» и звонок от продавца, который его не знает. Отдельный маршрут для известных плательщиков стоит завести до запуска, а не после первой жалобы.

Личный аккаунт сотрудника против бота компании

Это самый неудобный разговор при внедрении, и обходить его бесполезно. Продавцу удобно писать с личного аккаунта: там уже есть контакты, там быстро, там не надо ничего согласовывать. Компании это стоит истории, доказательств и управляемости.

Про восстановление доступа надо сказать прямо, потому что этот вопрос задают каждый раз. Личный аккаунт привязан к номеру телефона и защищён средствами самого сервиса. Технической процедуры «передать переписку уволенному сотруднику обратно компании» не существует. Если диалоги велись там, вы располагаете ровно тем, что сотрудник согласится переслать, и ровно до тех пор, пока он не удалит остальное. Даже если номер был корпоративным, вопрос о том, что и на каком основании вы вправе делать с привязанным к нему аккаунтом и с личной перепиской в нём, лежит в юридической плоскости и обсуждается с вашим юристом, а не решается администратором.

Заметка оператора. Полный запрет личных аккаунтов не работает: покупатель всё равно пишет тому, чей контакт у него есть. Работает другое. Запишите правило перехвата в одну строку: получил обращение в личку, в течение рабочего часа создал запись и перевёл человека в рабочий контур одной фразой вроде «отвечу здесь, а расчёт и документы пришлю через наш бот, там всё сохраняется». Дальше сделайте это правило измеримым: раз в неделю сверяйте число сделок, у которых первый контакт помечен как личное сообщение, с числом карточек, где есть подтверждение перевода. Расхождение и есть ваш реальный объём теневой переписки. Тревожный признак заметен раньше отчёта: если менеджер отказывается переводить диалог в общий контур «потому что клиенту так удобнее», обсуждать надо не удобство, а то, что произойдёт с этой сделкой в его отпуске.

Промежуточные варианты тоже существуют, и притворяться, что их нет, не стоит. Часть команд использует рабочие аккаунты на корпоративных номерах, часть подключает мессенджер через контур CRM. Возможности конкретных систем проверяйте по действующей документации amoCRM и Битрикс24: набор функций и способ подключения меняются, а требования из таблицы выше нет. Настройка конкретных систем разбирается в гайде про операционную работу с amoCRM и Битрикс24.

Ответственный и передача диалога без потери истории

Диалог принадлежит записи, а не человеку. Формулировка звучит скучно, а на практике означает, что при смене ответственного вы не теряете ничего, кроме имени в поле.

Правил всего четыре. В каждый момент времени у диалога ровно один ответственный, и он виден в карточке. Смена ответственного это событие с причиной, а не тихая правка поля. Передача сопровождается резюме, а не ссылкой «посмотри выше». История сообщений хранится там, где её видит следующий сотрудник, а не в чате, к которому у него нет доступа.

Резюме передачи это не пересказ переписки. Это четыре строки: что человеку нужно, что ему уже пообещали, что мешает закрыть сделку, какое следующее действие и когда. Менеджер, принимающий диалог, должен войти в разговор, не заставляя покупателя повторяться. Отдельная договорённость нужна на случай отпусков и больничных: у каждого ответственного есть заранее названный заместитель, иначе первый же длинный отпуск превращается в неделю тишины в чатах.

Как именно выбирается ответственный, по компетенции, по очереди или по территории, определяет плейбук по распределению заявок. Здесь важно только то, что выбор происходит в момент открытия диалога, а не в момент, когда кто-то заметил сообщение.

Норматив времени ответа в канале, где ждут мгновенности

Норматив времени ответа, он же SLA, это записанное обещание команды самой себе: за какое время после приёма обращения покупатель получает осмысленный ответ и что происходит, если срок нарушен. Определения таймеров, порядок эскалации и отчётность принадлежат гайду про скорость ответа на заявку. Специфика мессенджера в трёх вещах.

Первая: точка старта. Таймер запускается в момент получения сообщения точкой приёма, а не в момент создания карточки в CRM. Иначе задержка интеграции исчезает из отчёта, и вы измеряете скорость роботов вместо скорости команды.

Вторая: что считается ответом. Автоматическое «ваше сообщение принято» ответом не является. Ответом считается сообщение, которое продвигает дело: отвечает на заданный вопрос, задаёт уточняющий, предлагает время или называет условие. Иначе команда научится закрывать норматив штампом.

Третья: ожидания в канале выше, чем на сайте. Человек, который пишет в мессенджер, обычно рассчитывает на минуты, а не на часы. Известное сравнение из исследования Lead Response Management, выполненного на данных 2007 года при участии MIT, показывает резкое падение шансов на разговор при задержке ответа. Это сравнение внутри одного старого датасета по телефонным обращениям, а не отраслевая норма и тем более не обещание конверсии для вашего канала. Используйте его как аргумент за короткое окно, а не как цифру для презентации.

Цифры в колонке целей это стартовый шаблон для обсуждения, а не норма рынка. Ставьте свои, исходя из графика смен и объёма потока.

Про нерабочее время стоит сказать отдельно, потому что здесь чаще всего врут. Честное поведение состоит из четырёх частей: подтвердить получение, назвать реальное окно ответа, дать способ действия для срочного случая и задать один вопрос, ответ на который сэкономит время утром. Нечестное поведение это фразы «менеджер уже подключается» в три часа ночи и бот, который изображает живого человека. Второе особенно дорого обходится: покупатель, который двадцать минут разговаривал с роботом, считая его сотрудником, начинает утро с претензии, а не с обсуждения задачи.

И одно правило очереди, которое стоит внедрить сразу: ночное обращение утром попадает в начало очереди, а не в конец. Люди, написавшие ночью, ждут дольше всех и остывают быстрее всех.

Что бот имеет право решать сам и когда обязан позвать человека

Разделение простое по формулировке и трудное на практике: бот отвечает на то, у чего есть один правильный ответ в вашем же справочнике, и передаёт человеку всё остальное. Проблема в том, что соблазн расширить зону бота растёт вместе с числом обращений.

Два правила поверх таблицы. Прямая просьба позвать человека выполняется всегда и без уговоров: попытка удержать собеседника в автоматическом сценарии после такой просьбы обходится дороже сэкономленной минуты менеджера. И при низкой уверенности бот передаёт диалог, а не угадывает: неверный ответ, произнесённый уверенно, стоит дороже паузы.

Передача человеку это тоже событие, а не смена интонации в чате. В карточке должно остаться время передачи, причина и состояние диалога на момент передачи. Требование прослеживаемости автоматических решений сформулировано шире мессенджеров, например в методологии NIST по управлению рисками ИИ: управлять можно тем, что можно проследить и измерить. Если бот умеет назначать ответственного или менять этап, вы обязаны уметь ответить, на каком основании он это сделал.

Где проходит граница между тем, что бот решает, и тем, что он оценивает, разбирается в гайде про квалификацию заявок с помощью ИИ.

Согласие на обработку и хранение переписки

Сразу оговорка: ниже операционная практика, а не юридическое заключение. Состав документов, сроки хранения, основания обработки и формулировки согласия проверяйте со своим юристом, потому что они зависят от того, что именно вы собираете и как используете.

Операционная часть выглядит так. Согласие запрашивается в момент, когда человек передаёт вам контактные данные, а не задним числом при выгрузке базы. Текст согласия версионируется: в карточке хранится не галочка, а номер версии, время и способ получения. Доказательство живёт в вашей системе, а не в чате, потому что сообщения в мессенджере может удалить любая из сторон.

Три вопроса, которые стоит задать юристу до запуска, а не после: на каком основании вы храните переписку и как долго, что именно из диалога вы вправе выгружать в CRM и показывать сотрудникам, и как обрабатывается запрос на удаление данных, если часть переписки лежит в мессенджере, а часть в вашей системе. Ответы влияют на настройки, поэтому получить их лучше заранее.

Отдельная деталь для рабочих аккаунтов и общих чатов: сотрудники должны знать, что рабочая переписка фиксируется и доступна компании. Это записывается во внутренний документ, с которым знакомят при выходе на работу. Тут тоже вопрос к юристу, а не к администратору.

Последовательность подключения канала

Порядок важен. Команды, которые начинают со сценария бота, обычно переделывают его дважды: сначала когда выясняется, что нет ключа личности, потом когда обнаруживается, что нет ответственного.

1. Определения. Запишите, что считается открытым диалогом и что считается зафиксированной заявкой. Согласуйте формулировки с продажами, а не только внутри операционной роли.
2. Ключи и поля. Заведите в CRM индексируемое поле под числовой идентификатор пользователя, поле под имя пользователя, поле под ссылку на диалог и значения источника из общего справочника.
3. Один вход. Запустите бота как единственную официальную точку приёма и опубликуйте ссылку на него везде, где раньше стояли личные контакты.
4. Метки перехода. Соберите справочник кодов и сделайте ссылки со стартовым параметром для сайта, канала и рекламы. Проверьте первый и повторный переход.
5. Приём и запись. Настройте передачу события в узел приёма, нормализацию и запись в CRM по внешнему идентификатору с ключом идемпотентности. Lead Hub забирает каналы на себя, и здесь он нужен ровно для того, чтобы канал не писал в CRM напрямую.
6. Ответственный и таймер. Включите назначение при открытии диалога и запуск таймера в точке приёма. Убедитесь, что список диалогов без ответственного существует и что он пуст.
7. Правила бота. Только теперь пишите сценарий: приветствие, один уточняющий вопрос, утверждённые ответы на однозначные вопросы, честный автоответ вне графика, немедленная передача человеку по правилам.
8. Перевод личных диалогов. Дайте команде формулировку перехвата, объясните причину и начните еженедельную сверку теневой переписки.
9. Дожим и обслуживание. Подключите маршрут для действующих клиентов и правила повторных касаний внутри уже открытых диалогов, опираясь на гайд про систему дожима заявок.

Пятый шаг пропускают чаще остальных, потому что кажется, что бот и так умеет писать в CRM. Умеет. Проблема не в записи, а в том, что без нормализации и ключа идемпотентности повтор доставки создаёт вторую карточку, а без общего справочника источник приезжает в виде сырой строки, которую потом никто не сможет сгруппировать в отчёте.

Что проверить до запуска и на регулярной ревизии

До запуска вы доказываете, что канал ведёт себя правильно. После запуска проверяете, ведёт ли он себя так до сих пор. Оба списка короткие, и оба выполняются вручную на живом боте.

Регулярная ревизия смотрит на другое: на диалоги, открытые дольше нормы и не ставшие ни заявкой, ни отказом; на записи со значением «источник не определён», доля которых растёт; на сделки, у которых первый контакт помечен как личное сообщение; на диалоги, где ответственный менялся больше двух раз; на список без ответственного, который обязан быть пустым.

Полезно проверять сам факт доставки событий раз в месяц: отправьте тестовое сообщение с заведомо ошибочным значением поля и убедитесь, что оно дошло до очереди сбоев, а не растворилось. Очередь, которая неделями пуста, чаще означает поломанный маршрут, чем идеальный канал. Как собрать полный разбор входящего потока, описано в гайде про аудит входящих заявок.

Где канал стыкуется с остальным стеком

Telegram это точка приёма, а не отдельная система продаж. В операционном стеке для входящих заявок он стоит на входе рядом с формой на сайте и телефонией и обязан отдавать дальше ровно то же, что отдают они: одну личность, один источник, одного ответственного, один запущенный таймер.

Дальше начинаются чужие зоны ответственности, и лезть в них из канала не надо. Что делать с полями и дублями в самой карточке, определяет гайд про автоматизацию обработки заявок в CRM. Кому уходит заявка, решает плейбук по распределению заявок. За какое время обязаны ответить и что происходит при нарушении, задаёт гайд про скорость ответа на заявку. Как называются источники, договаривается гайд про атрибуцию источников заявок. Где кончается узел приёма и начинается CRM, разбирает гайд Lead Hub или CRM, а посмотреть, как модули связаны между собой, можно на интерактивной карте системы.

Главный тревожный признак этого канала звучит безобидно: «у нас всё в телеграме, там удобно». Проверяется он одним вопросом на планёрке. Назовите сделку, которая сейчас в работе, и попросите показать историю первого контакта, не открывая личный телефон менеджера. Если показать нечем, канал не подключён, он просто существует. Второй вопрос из того же ряда: что произойдёт с пятью открытыми диалогами, если завтра этот менеджер уйдёт. Ответ «попросим переслать» и есть описание вашей текущей системы хранения.

Объём работ по подключению канала и его связке с CRM можно посмотреть на странице тарифов. Если нужен разбор вашего текущего потока в Telegram, приходите на консультацию: на выходе вы получаете карту четырёх входов, определение события заявки, схему ключей личности и список того, что чинить первым. Бота, который отвечает по вашим документам и отдаёт заявку в CRM, собираем в рамках услуги чат-бот с ИИ.

Цены