Клиент спрашивает у бота про комплектацию и условия рассрочки. Бот думает. Одиннадцать секунд в чате не происходит ничего — ни точек, ни статуса, ни признака жизни. На двенадцатой приходит отличный, подробный, выверенный ответ, но клиент его уже не читает: он свернул переписку и открыл конкурента.
Это не проблема модели. Это проблема канала, который до недавнего времени умел показывать только готовое сообщение целиком. За 2026 год Telegram-бот получил набор возможностей, которые эту дыру закрывают: ответ можно показывать по мере генерации, оформлять как документ с таблицами и списками, а в групповом чате отвечать одному человеку так, чтобы остальные не видели переписку.
Разберём, что именно появилось, и — что важнее — какие сценарии продаж от этого выигрывают, а какие не изменятся вообще.
Главное за минуту
Черновик вместо тишины
Метод sendMessageDraft показывает ответ частями, пока он генерируется. Пустой черновик выводит плашку «Thinking…».
Сообщение как документ
Rich-сообщения умеют заголовки, таблицы, чек-листы, цитаты и сворачиваемые блоки — с июня 2026 года.
Ответ только одному
Ephemeral-сообщения видны в группе конкретному пользователю и боту — остальным участникам нет.
Кнопки внутри текста
С августа 2026 года кнопку можно поставить прямо в rich-сообщение, а не только под ним.
Стриминг: ожидание перестаёт быть тишиной
Метод sendMessageDraft отправляет черновик — частично готовое сообщение, которое бот дописывает по мере генерации. Появился он в Bot API 9.3 в конце декабря 2025 года, а первого марта 2026-го Telegram открыл его всем ботам без ограничений.
Деталей две, и обе полезные. Пустой черновик показывает в чате плашку «Thinking…» — то есть даже до первого токена клиент видит, что бот работает. А пользователь может остановить генерацию: бот получит соответствующий апдейт и погасит фоновую задачу, вместо того чтобы дописывать ответ, который уже никому не нужен.
Второе — про деньги. Прерванная генерация означает неоплаченные токены: клиент понял ответ с третьей строки и остановил бота, а вы не заплатили за оставшиеся полторы тысячи знаков. На длинных консультационных сценариях, где ответ собирается из базы знаний, это заметная экономия.
И сразу ожидание, которое стоит приземлить. Стриминг не ускоряет модель ни на миллисекунду. Он меняет ощущение: вместо одной паузы в одиннадцать секунд клиент видит текст, который растёт. Разница в поведении при этом вполне реальная — уходят не потому, что долго, а потому, что непонятно, происходит ли что-нибудь.
Rich-сообщения: когда ответ больше похож на документ
В июне 2026 года Bot API 10.1 принёс rich-сообщения — методы sendRichMessage и sendRichMessageDraft. Бот перестал быть ограничен жирным, курсивом и списком через дефис.
Что поддерживается: заголовки и абзацы, разделители, обычные списки и списки задач, таблицы с выравниванием, подписями и объединением строк и столбцов, блочные цитаты, сворачиваемые блоки с деталями, якоря и ссылки внутри сообщения, формулы LaTeX, карты с произвольными координатами, коллажи и слайд-шоу. В июле версия 10.2 добавила стриминг для rich-черновиков, а 24 августа 2026 года в версии 10.3 появились кнопки прямо внутри rich-сообщения.
Теперь честно о применимости. Большинству ботов это не нужно. Ответ «да, есть в наличии, доставим завтра» не становится лучше от таблицы. Но есть сценарии, где разница принципиальная:
- подбор из нескольких вариантов — три комплектации с ценой, сроком и отличиями в таблице читаются с одного экрана, а списком не читаются вовсе;
- расчёт — строки сметы с итогом вместо абзаца, в котором клиент ищет цифру глазами;
- чек-лист документов для заявки — список задач, по которому видно, что уже прислали, а что нет;
- длинный регламент или условия — сворачиваемый блок вместо простыни на два экрана;
- карта с точкой самовывоза вместо адреса текстом.
Общий принцип, который мы для себя вывели: rich-разметка оправдана там, где клиент сравнивает. Там, где он просто получает факт, она лишняя.
Ephemeral-сообщения: приватный ответ в общем чате
Версия 10.2 от 14 июля 2026 года добавила ephemeral-сообщения — реплики внутри группового чата, видимые только конкретному пользователю и боту. Поддерживаются не только текст, но и фото, видео, документы, контакты и локации. Есть и ephemeral-команды: исходное сообщение пользователя остальные участники не видят.
Для B2B это интереснее, чем кажется. Допустим, у вас проектный чат с клиентом: с вашей стороны три человека, со стороны заказчика пятеро. Менеджеру нужно уточнить у бота остаток по складу и текущую скидку по договору. Раньше выбор был между «спросить при всех» и «уйти в личку и потерять контекст». Ephemeral снимает развилку: бот отвечает в том же чате, но видит ответ только спросивший.
Тот же приём работает в клиентских сообществах: подсказка новичку, персональная сводка по его заявке, ответ на вопрос, который не нужно показывать сотне людей.
Что из этого стоит внедрять, а что подождёт
Если коротко — включать по возрастанию сложности и по убыванию эффекта.
| Возможность | Кому даёт эффект | Стоимость внедрения |
|---|---|---|
| Черновик со стримингом | Всем, у кого ответ собирается дольше трёх секунд | Низкая — один метод и обработка остановки |
| Таблицы и чек-листы | Подбор, расчёты, сложные условия | Средняя — нужен шаблон вывода, а не свободный текст |
| Ephemeral в группах | Проектные чаты, сообщества, дилерские группы | Средняя — меняется логика адресации ответа |
| Кнопки внутри rich-сообщения | Сценарии, где выбор идёт по строкам таблицы | Выше — переверстка сценария целиком |
Стриминг мы обычно советуем включать первым: он дешевле остального и заметнее всего влияет на то, дочитывает ли клиент ответ.
Канал стал выразительнее. Это не значит, что боту стало что сказать, — содержание по-прежнему приходит из вашей CRM и вашей базы знаний.
Границы, про которые лучше знать заранее
- Это возможности одного канала. В WhatsApp ничего подобного нет, и сценарий, построенный на таблицах с кнопками, в другом мессенджере придётся выводить иначе.
- Стриминг усложняет контроль реплик: текст уже виден клиенту, пока проверка ещё идёт. Модерацию придётся строить до начала показа, а не после генерации.
- Красивое оформление повышает доверие к содержанию. Ошибка в таблице выглядит убедительнее, чем ошибка в абзаце, — это аргумент в пользу жёсткой проверки фактов, а не против таблиц.
- Старые версии клиентов отображают богатую разметку не полностью. Критичные данные — цену, срок, номер заявки — дублируйте обычным текстом.
- Закон обязывает уведомлять пользователя, что он общается с ИИ. Стриминг делает бота похожим на печатающего человека, и раскрытие становится важнее, а не наоборот.
- Ephemeral-ответ не попадает в общую историю чата. Если реплика важна для разбора, её нужно отдельно писать в карточку клиента.
Про последние два пункта — подробнее в соседних материалах: обязанность раскрывать бота разбиралась в статье Закон об ИИ в Казахстане: маркировка контента и раскрытие бота, а проверка реплик до отправки — в материале Бот пообещал скидку: как проверять реплики до отправки клиенту.
Чек-лист перед доработкой бота
- Замерьте, сколько секунд проходит от вопроса клиента до первой реплики бота в реальных диалогах.
- Найдите сценарии, где ответ дольше трёх секунд, — именно им нужен черновик.
- Определите, какие ответы клиент сравнивает: они кандидаты на таблицу.
- Проверьте, что цена и срок дублируются простым текстом, а не живут только в разметке.
- Решите, что происходит при остановке генерации: бот молчит или предлагает уточнить вопрос.
- Уточните, где в диалоге стоит фраза о том, что отвечает ИИ.
- Опишите, какие ответы в групповых чатах должны быть приватными.
- Заложите деградацию: как тот же сценарий выглядит в WhatsApp и в веб-чате.
Связанные материалы
- Telegram-бот для бизнеса: интеграция с CRM и автоматизация коммуникаций
- Telegram WebApp + бот: как запустить магазин внутри мессенджера
- AI-боты для входящих обращений
Покажем стриминг и таблицы на вашем сценарии
Возьмём один ваш реальный диалог — подбор, расчёт или проверку наличия — и соберём его в тестовом боте: с черновиком вместо паузы, таблицей вариантов и кнопками выбора. Посмотрите на своём вопросе, а не на демо-примере.