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

У меня у самого был опыт с такими ботовыми пилотами. Мы в Ticky AI часто прототипируем микросервисы поверх Telegram: рассылки, опросы, напоминания для команд. Когда нужно быстро проверить гипотезу, Make выручает. Не нужно собирать сервер, думать про фреймворки и обновления библиотек. Подключил токен, смаппил поля, расставил фильтры и готово. Да, не все задачи удобно решать визуально, но старт получается быстрым и живым. И да, позже лучше перейти на вебхуки и аккуратно распределить нагрузку, но до этого мы еще дойдём.

Для вдохновения можно заглянуть в нашего помощника — TickyAI_bot.

Регистрация бота и быстрый старт в Make

Начинается все с BotFather. В Telegram находите @BotFather, жмете Start, даете команду /newbot, придумываете имя и уникальный username, который кончается на bot. Он выдаст токен — длинную строку, по которой весь мир поймет, что вы это вы. Токен опасный: его нельзя пересылать в общие чаты, класть в скриншоты и хранить в заметках без замка. Сохраните его в менеджер паролей, а в Make подключите через защищенное подключение, там токен шифруется и не торчит наружу. Если уже на этом этапе закралась мысль «а вдруг сольётся», просто помните, что токен можно в любой момент перевыпустить в BotFather командой /revoke.

Дальше открываем Make (бывший Integromat), создаем новый сценарий и выбираем модуль Telegram Bot. На этапе подключения вставляем токен и проверяем, что соединение установилось. Для первого теста удобен Watch Updates — это polling-модуль, который периодически спрашивает у Telegram, не пришло ли что-то новенькое. Он прост как молоток: запускаете сценарий, пишете боту «/start» и видите в логах входящее сообщение. В пару кликов добавляете Send a Message, маппите chat_id и текст — и бот уже отвечает. Это быстрый путь, чтобы ощутить, что всё живое и слушается рук.

Watch Updates против Webhook: что выбрать и когда

Watch Updates — отличный крюк для начала, но polling не тянет большие нагрузки и слегка тормозит. Он периодически дергает Telegram за рукав, а это лишние запросы, задержки и иногда пропуски при пиковых всплесках. Для продакшена лучше перейти на Webhook. В модуле Telegram Bot есть настройка «Set up a webhook», Make поднимет у себя URL и начнет получать события сразу, как только пользователь напишет вашему боту. Вебхуки экономят операции, снижают задержки, а обработка становится предсказуемой. Если у вас домен и вы хотите совсем по-взрослому, можно настроить свой HTTPS-коннектор с сертификатом, но Make прекрасно справляется и без внешних серверов.

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

Логика без кода: строим цепочки, фильтры и роутеры

В Make любая логика — это маршрут из модулей: триггер Telegram, дальше фильтры и роутеры, после — действия вроде ответов, загрузок файлов, записи в таблицы или вызовов внешнего API. Вместо переменных и if-else вы используете визуальные фильтры и маппинг полей. Приходит апдейт — вы берете text, chat.id, from.username и принимаете решение: если text начинается с «/start», катим в одну ветку, если «/survey» — в другую. Это делается фильтрами на связях, где можно поставить условия по содержимому сообщений, типу апдейта, данным callback-кнопок.

Работать с данными удобно через встроенные переменные от Telegram-модуля. Там есть и message_id, и дата, и тип контента. Для сложных разборов пригодится регулярка: быстро достать параметр из «/start abc123», выделить email или команду с аргументами. Идея простая: фильтры сужают поток, роутеры разветвляют, а каждый модуль делает понятную маленькую задачу. Когда я собираю такие цепочки, стараюсь держать один сценарий про одно дело. Диалоги — отдельно, админские команды — отдельно, системные задачи — в фоновой ветке, чтобы не мешать ответам пользователям.

Состояние и память: Data Store, Google Sheets, Airtable

Чтобы бот вел себя как воспитанный собеседник, ему нужно помнить контекст. В Make есть Data Store — встроенное хранилище ключ‑значение, идеально для пользовательских состояний. Ключом часто становится user_id, а значением — JSON со стадией диалога, временем последнего шага, промежуточными ответами. Когда приходит новое сообщение, вы делаете lookup по user_id, проверяете текущую стадию и ведете пользователя в нужную ветку. Хранить долгие истории можно в Google Sheets или Airtable: добавили строку с ответом, временем и тегами — потом легко выгружать статистику или строить дашборд.

И тут кроется важный нюанс: не пытайтесь держать в одном сценарии и память, и сложную разметку, и агрегирование. Лучше разбить на небольшие сценарии, которые общаются через Data Store или таблицы. Это ускоряет обработку и снижает «микрозависания», когда одно тяжелое действие тормозит очередь. Если сценарии нужно синхронизировать, используйте Webhooks внутри Make или краткие задержки с ретраями. И старайтесь делать операции идемпотентными: проверяйте, не обработан ли уже этот message_id, чтобы случайно не отправить дубликат.

Работа с внешними API: HTTP как универсальный адаптер

Кто-то хочет проверить купон, кто-то подтянуть курс валют, кто-то интегрировать CRM — все это решается модулем HTTP. Задаете метод, URL, заголовки, передаете тело и получаете JSON. Внутри Make его можно распарсить, достать нужные поля и использовать дальше: написать пользователю «Купон принят», приложить файл счета или вызвать другой сервис. Я иногда подключаю быстрые классификаторы текста или простые модели семантики, чтобы бот реагировал на смысл, а не только на команды. Главное правило — ставить таймауты, обрабатывать ошибки и не зависеть от одного запроса. Если внешний API спит, лучше ответить пользователю честно «немного подождите, мы проверяем», чем зависнуть.

Кстати, для подтверждений и оплат у Telegram есть Payments API. В Make это можно обернуть через HTTP и соответствующие методы Bot API: отправить инвойс, обработать подтверждение и записать результат в таблицу. Схема рабочая, но требует аккуратности: валюта, суммы, проверка статусов — без спешки и с тестами в песочнице.

Интерфейс и UX: кнопки, шаги, форматирование

Сухой бот, который отвечает только текстом, годится для черновиков. Чтобы пользователь не заблудился, добавляйте кнопки. Inline Keyboard — это прям находка: вы отправляете сообщение с набором кнопок, каждая из них несет callback_data. Пользователь нажал — Telegram прислал апдейт с callback_query, вы его ловите отдельным модулем, отвечаете через Answer Callback Query, а по необходимости редактируете исходное сообщение или отправляете новое. Так строятся мини-меню для выбора категории, переключателей статуса, фильтров. И не забывайте, что нажатия — это тоже событие, у которого есть свой пользователь и контекст.

Для пошаговых диалогов состояние пользователя обязательно. В Data Store или таблице хранится текущая стадия: «ожидаю email», «проверяю купон», «сохраняю файл». При новом сообщении вы смотрите стадию и решаете, какое действие предпринять. Если пользователь ушел на сутки, на вторые сутки надо его вернуть в общий поток, а то вечно будет «ожидаю email», хотя человек уже передумал. В Ticky AI мы делаем таймауты на 24–48 часов для таких стадий, а потом сбрасываем состояние и кладем дружелюбную подсказку. Мелочь, а UX становится заметно живее.

Форматирование текста в Telegram поддерживает Markdown и HTML. Лично мне нравится MarkdownV2, но его символы требуют экранирования. Подчеркивания, скобки, минусы — всё нужно аккуратно защищать, иначе Telegram ругнется. В Make есть функции для экранирования, или можно написать простой заменитель символов, если заметили конкретные ошибки. Для длинных подсказок удобно собирать текст в шаблоне, чтобы не плодить мусор прямо в модуле. И не перебарщивайте с жирным и курсивом — мессенджер про краткость, а не про верстку.

Надежность, масштаб и безопасность: вещи, о которых хочется думать заранее

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

Ошибка — не катастрофа, если для нее есть маршрут. В Make на каждый модуль можно повесить обработчик ошибок, настроить retries с экспоненциальной задержкой и отправку оповещений. Простой паттерн: если упал внешний API, повторяем три раза, дальше — пишем в лог и отправляем алерт в свой тех-чат в Telegram. Для критичных операций — дублируем запись в таблицу или роняем в отдельный Data Store, чтобы потом «подобрать» это руками. Хорошо работает мониторинг: раз в час проверять, что приходят апдейты и отправляются ответы, иначе мы узнаем о проблеме только от злого пользователя.

Разделяйте нагрузку. Один сценарий принимает вебхук, быстро решает — это команда, сообщение, нажатие — и кидает в разные сценарии-«воркеры» через роутеры или внутренние вебхуки. Каждый воркер делает свое маленькое дело и не держит очередь. Так проще соблюдать тайм‑ауты и не ловить межсценарные блокировки. Если у вас крупная база, подумайте про шардирование по user_id модулем Router с диапазонами. Всё то же, что в коде, только мышкой.

Защита токена — святое. Держим его в защищенных подключениях Make, доступ — только у тех, кто реально работает с ботом. В логах не должны светиться персональные данные, а таблицы с пользователями нужны с ограниченными правами. Если вы собираете телефон и email, вспоминаем про GDPR или локальные аналоги: согласие пользователя, цель обработки, срок хранения, право на удаление. В Ticky AI мы прописываем команду /delete_my_data и удаляем карточку пользователя по запросу. Это и красиво, и сильно снижает вопросы от юристов.

Где граница no-code и зачем иногда все же писать код

No-code отличен для быстрых MVP, типовых интеграций и внятных сценариев без тяжёлой бизнес-логики. Что идет тяжело: сложные ветвления с десятками условий, анализ естественного языка без внешних сервисов, массовые параллельные расчеты. В Make можно, конечно, собрать монстра из сотни модулей, но поддерживать его будет больно, а любой новый шаг — как хирургия. Если видите, что сценарий растет и превращается в «двигатель самолета», разбивайте его, а часть выносите в микросервис. Мы так и делаем в Ticky AI: прототип на Make за вечер, проверка на пользователях, потом выносим вычислительную часть в маленький сервис, а Make оставляем как оркестратора.

Еще одна граница — задержки. Слишком последовательные модули тянут время, особенно если каждый ходит во внешний API. Иногда проще распараллелить в несколько сценариев или предусмотреть «ленивую» обработку: сначала ответить пользователю «приняли запрос», потом досчитать и прислать результат. Пользователи ценят честность и скорость реакции, а вовсе не то, чтобы все было «за один тик».

Примеры, которые можно повторить за 20–40 минут

Автоответчик на /start и запись в таблицу звучит скучно, но полезен как воздух. Схема простая: триггер Watch Updates (или Webhook), фильтр по тексту «/start», модуль Send a Message с приветствием и подсказкой первого шага. Дальше — Google Sheets: добавить строку с user_id, username и временем. В маппинге Send a Message используйте chat_id из входящего апдейта, а в таблицу кладите дату через функцию now, чтобы потом видеть динамику. Хороший тон — отправить человеку короткое сообщение «Добавил вас в список, спасибо», если запись в таблицу прошла успешно. Если нет, честно предупредите, что «таблица занята, попробуем ещё раз чуть позже».

Опрос-бот — чуть интереснее. Пользователь пишет «/survey», вы ставите его состояние в Data Store: stage=s1, ожидаю ответ на вопрос №1. Отправляете вопрос с Inline-кнопками или просто текстом. Следующий входящий апдейт проверяет состояние пользователя: если stage=s1, считываем ответ, валидируем и переводим в stage=s2. Когда все вопросы пройдены, записываем ответы в Airtable, отправляем спасибо и возвращаем stage=idle. Ветка с админкой может отдавать CSV или давать статистику за день. Тут из нюансов — аккуратная обработка отмены, чтобы «/cancel» всегда возвращал пользователя на старт и чистил состояние. Пара тестов с друзьями — и вы увидите, где сценарий ломается или что нужно подсказать кнопкой.

Тихие фишки, которые сэкономят час в самый неудачный момент

Если отправляете сообщения с Markdown, заранее протестируйте экранирование. Один неэкранированный символ и Telegram вернет ошибку, а сценарий уйдет в ретрай. В Make это можно поймать и красиво обработать, но лучше не допускать. Для массовых рассылок заведите отдельный сценарий-планировщик, который берет пачку пользователей, отправляет сообщения с небольшой задержкой по каждому чату и следит за ошибками «too many requests». А еще полезно логировать исходные апдейты целиком в Data Store на пару часов, чтобы разбирать инциденты. Когда что-то падает, эти полчаса логов — золото.

Мы однажды в Ticky AI сохранили пару багов в виде маленьких паттернов: если внешний API подвис, отправляй промежуточное сообщение «Минуточку, считаем» и прогревай ретрай; если пользователь нажал старую Inline-кнопку, проверяй, существует ли связанное состояние, иначе показывай «Кнопка устарела — попробуйте ещё раз». Эти вещи кажутся очевидными, но почему-то вспоминаешь о них в три ночи, когда уже все горит.

Зачем это всё и как не застрять

Телеграм-бот — это не только канал уведомлений, но и маленький интерфейс для задач, где приложения избыточны. Поддержка клиентов, быстрые формы, сверки, уведомления о событиях, выдача ссылок и отчетов. Порог входа низкий: вы и правда можете создать Telegram-бота без кода через Make за один вечер и получить результат, который не стыдно показать команде или первым пользователям. А дальше уже по ситуации: если гипотеза заходит, обвешивайте сценарии качественными обработчиками, выносите тяжелое в сервисы и держите порядок.

Два мягких совета на дорогу. Во-первых, документируйте сценарии. Короткие заметки в описании модулей спасают от хаоса. Во-вторых, заранее решите, какие данные вы храните и сколько. Чем меньше храните — тем спокойнее спите и легче соответствуете требованиям регуляторов. А если хочется более продвинутого диалога — не бойтесь подключать внешние NLU‑сервисы через HTTP, просто держите контроль над тайм‑аутами и ошибками.

FAQ

Нужно ли сразу настраивать Webhook или можно остаться на Watch Updates?

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

Как хранить состояния пользователей и не запутаться?

Для кратких диалогов используйте Data Store: ключ — user_id, значение — JSON со стадией и данными. Для аналитики и отчетов — Google Sheets или Airtable. Разделите сценарии на прием апдейтов и «воркеров», чтобы состояние не блокировалось в длинной цепочке.

Что делать, если перестали приходить апдейты?

Проверьте, не активен ли старый вебхук, и нет ли параллельных сценариев с Watch Updates на того же бота. Перепривяжите Webhook в Make, перезапустите сценарий и убедитесь, что BotFather не выдал новый токен. Если токен сменился, заново подключите его в Make и удалите старые подключения.

Попробуйте тоже наш телеграм-бот — TickyAI_bot, чтобы посмотреть примеры и идеи.