Telegram бот и Make - это та связка, которая в российских реалиях тихо вытаскивает менеджера из рутины, вместо того чтобы "магией ИИ" всё переписать. В классическом московском онлайн-бизнесе клиенты давно ушли в чат бот Telegram, но отвечать на повторяющиеся вопросы, гонять лиды через таблицы и CRM все равно приходится руками. Я на своей шкуре почувствовала, как автоматизация работы менеджера через Telegram бот и Make отъедает около 40% ручного труда: те же 50 диалогов обрабатываются уже не за два часа, а за сорок минут. В этом тексте разбираю, как это сделать под российский 152-ФЗ, с учетом white-data и трендов 2025–2026 годов, без нелегальных серых схем. Статья для тех, кто в России строит процессы вокруг мессенджеров, хочет прозрачности и не хочет бояться Роскомнадзора.
Однажды ко мне пришел Антон-предприниматель - владелец небольшого интернет-магазина курток и рюкзаков. Антон показывал Telegram на телефоне с красными глазами: "Марин, мы тонули в заявках, а теперь тонем в переписке. Клиенты пишут, бот Telegram bot отвечает что-то базовое, а дальше менеджер копирует имя, телефон и вопрос в CRM. Ошибки, потери, и ещё эти согласия по 152-ФЗ... Я хочу, чтобы всё делалось через Telegram бот автоматически, но без танцев с кодом бота Telegram". Я пообещала ему, что из этого можно сделать аккуратную цепочку Make плюс Telegram бот, где менеджер вмешивается только там, где нужен человек, и сейчас я покажу, как мы к этому пришли и что из этого может забрать себе любой российский бизнес.
Когда я впервые системно посмотрела на переписку менеджеров в Telegram, стало ясно, что у нас не чат, а бесконечный конвейер мелких решений: "ответить - скопировать - проверить", и так по кругу. Российский контекст добавляет сюда ещё одну ось боли - персональные данные, 152-ФЗ, журналы учёта, реестры процессов и регулярные проверки, когда к вам могут заглянуть до 11 раз в год, если обработка автоматизирована. Получается, что без автоматизации в такой среде менеджер превращается в живую прослойку между клиентом, CRM и Роскомнадзором, и у него просто нет шансов не выгорать. В этом разделе разберу, из чего реально состоит нагрузка в Telegram, и где именно Telegram бот и Make могут безопасно забрать эти 40% работы.
Почему менеджер в Telegram тратит часы и как это разложить по полочкам
Как выглядит день менеджера в Telegram без автоматизации
Типичный день российского менеджера в продажах в Telegram похож на игру "найди лишнее", только лишним оказывается сам менеджер. С утра он открывает чат бот Telegram, в котором клиенты уже написали десятки сообщений: "Хочу куртку", "Где мой заказ?", "Сколько стоит доставка по России". Дальше начинается мозаика: часть ответов он берет из шпаргалки, часть из головы, часть ищет в прайсах, а при этом каждые новые ФИО и телефон фактически запускают цепочку по 152-ФЗ - согласие, основание обработки, запись в журнал, актуализация реестра. На бумаге это выглядит академично, в реальности менеджер судорожно копирует данные в CRM, а где-то в отдельной Google-таблице пытается вести учет согласий. Я заметила, что здесь Telegram бот бесплатно часто воспринимается как "поставил ответы и забыл", хотя он решает только одну десятую проблемы.
Вот как это выглядит на практике, если честно описать шаги: клиент пишет в Telegram бота, тот отвечает заготовленной фразой, менеджер видит уведомление и открывает диалог, вручную формулирует ответ на уточняющие вопросы, копирует контактные данные, проверяет, было ли согласие (или решает, что "и так сойдет", что уже плохо), вносит информацию в CRM, параллельно отмечает где-то статус заказа. При этом каждый шаг имеет как минимум два риска - человеческая ошибка и несоответствие требованиям по персональным данным. Чтобы не утонуть, некоторые компании вводят жесткие регламенты, но регламент сам по себе не экономит время, он только формализует хаос. Настоящая точка экономии появляется там, где мы превращаем повторяющееся поведение в сценарий Telegram бота и Make, а менеджера оставляем в зонах, где нужна гибкость.
На практике экономия в 40% времени возникает не из одного волшебного бота, а из последовательного выноса рутинных шагов в автоматизацию, где каждый клик менеджера превращается в условие сценария.
Если посмотреть на переписку за день, вы легко найдете несколько повторяющихся кластеров: первичные запросы "хочу заказать", уточнения по статусу, вопросы по оплате и доставке, редкие нестандартные кейсы и совсем уж уникальные истории. Telegram бот команды справляется с первыми двумя кластерами, если правильно его скормить, а Make собирает и раскидывает данные по системам, не трогая менеджера. Это означает, что расчленив день менеджера на такие кластеры, мы заранее понимаем, где уместен Telegram бот ответ боту (то есть автоответ на автоответ) и где нужно оставить человека. У Антона 60-70% сообщений в Telegram вообще не требовали креатива, но продолжали отнимать одинаковые по структуре 1-2 минуты, и именно на этом мы потом "сделали" те самые 40%.
Что добавляет стресса в России: 152-ФЗ, проверки и серые паттерны
В российском контексте сама переписка - это только половина нагрузки, вторая половина сидит в голове менеджера с подписью "а если Роскомнадзор". Когда клиент через telegram бот отправляешь ФИО и телефон, компания автоматически становится оператором персональных данных, и дальше включается вся конструкция 152-ФЗ: уведомление в реестр, указание цели, основания обработки, описание категорий субъектов данных и получателей, а ещё организация защиты. Отдельное удовольствие создают журналы учета носителей, акты уничтожения, реестры процессов, и вот то самое до 11 проверок в год для автоматизированной обработки - не шутка, а реальная практика с 2025 года. Менеджеру об этом, конечно, никто подробно не рассказывает, но они чувствуют, что "что-то мы делаем неправильно", и это съедает фоновое внимание.
Серые паттерны выглядят буднично: Telegram бота пользователь пишет "телефон такой-то", менеджер сохраняет его в CRM без зафиксированного согласия, потому что "без этого работать невозможно", и продолжает общаться. В какой-то момент кто-то из юристов приносит презентацию с штрафами: для ИП от 30 000 рублей за отсутствие уведомления в реестре операторов, до 500 000 за нарушения при утечке, и команды впадают в ступор. Я поняла, что главная ошибка здесь - пытаться решить проблему разрозненными действиями: написать политику конфиденциальности, повесить баннер на сайте, попросить менеджеров "быть внимательнее". Это всё не закрывает главный риск: отсутствие единой трассировки, что, когда и на каком основании вы собрали. Если к вам придут с вопросом "покажите, как вы уничтожаете данные через три года", менеджер, уставший после Telegram, вряд ли достанет аккуратный журнал, если его не формирует сцепка Telegram бот и Make.
В такой ситуации автоматизация работы менеджера через Telegram бот часто воспринимается как дополнительный риск, хотя по факту она позволяет выстроить прозрачную цепочку: запрос - согласие - запись - обработка - уничтожение. Здесь критично не уходить в "магические" обещания ИИ, а честно развести то, что можно отдать боту, и то, что всегда останется за человеком. Например, текст согласия и логика его запроса должны опираться на понятные шаблоны из КонсультантПлюс или аналогов, а не на "мы так в соседней компании сделали" (нет, подожди, есть нюанс: у соседней компании могут быть другие категории данных и другие цели обработки).
Получается, что без привязки Telegram бота к реальной системе управления персональными данными любая автоматизация только ускоряет путь к штрафам, а не к свободному времени менеджера.
Как понять, что вы дозрели до Telegram бота и Make
Иногда ко мне приходят с запросом "хотим умного бота", а на вопрос "зачем" начинают перечислять всё подряд: от прогрева лидов до автоматической юридической проверки договора. В такие моменты я мысленно ставлю галочку "пока рано", потому что хорошая автоматизация работы менеджера начинается с приземленных критериев: есть поток однотипных запросов, он идет через Telegram, менеджер не успевает, ручных ошибок много, а данные о клиентах уже где-то сумбурно хранятся. Второй маркер готовности - наличие или хотя бы желание навести порядок в истории с 152-ФЗ: зарегистрироваться в реестре, описать процессы, зафиксировать основания обработки и разобраться, какие данные действительно нужны. Если вы пока не готовы отвечать на вопрос "зачем нам этот телефон" - автоматизация только законсервирует хаос.
Вот как это выглядит на практике, когда компания реально дозрела: есть базовый Telegram бот, пусть даже сделанный через конструктор или простую интеграцию, есть CRM (Bitrix24, AmoCRM или отечественный аналог), есть кто-то, кто отвечает за персональные данные, хотя бы номинально. В идеале уже зарегистрированы в реестре Роскомнадзора и понимаете разницу между согласием и законным интересом. Дальше достаточно зафиксировать три группы: повторяющиеся вопросы, простые маршруты данных (куда чего складываем) и зоны ответственности менеджера. На этом этапе Telegram бот бесплатно через @BotFather и базовый сценарий в Make уже дают ощущимый эффект. Если всего этого нет, я сначала прошусь "в шкаф с документами", а затем в чаты менеджеров, и только после этого мы садимся рисовать реальный сценарий.
Чтобы не увязнуть в теории, я для себя отметила три признака, что пора переходить к реальной связке Telegram бот и Make: минимум 30% запросов в мессенджере повторяются почти дословно, менеджер тратит больше часа в день на перенос данных в CRM и сопутствующие таблицы, и в компании уже звучали тревожные фразы про 152-ФЗ и проверки Роскомнадзора. Если вы в этих критериях себя узнаете, то дальнейшие блоки текста можно считать рабочей инструкцией, а не "на будущее". Это критично, потому что половина провальных внедрений случается, когда автоматизацию включают либо слишком рано, либо слишком поздно, когда команда уже выгорела.
На этом этапе полезно признать, что цель Telegram бота в российских реалиях - не заменить менеджера, а высвободить ему время и снизить юридические риски, встроив переписку в понятную систему обработки персональных данных.
Как настроить Telegram бота под 152-ФЗ, чтобы потом не было больно
С чего начать: реестр Роскомнадзора и основания обработки данных
Если смотреть строго, любой бизнес в России, который через telegram бота пользователь просит оставить имя и телефон, должен быть оператором персональных данных и стоять в реестре Роскомнадзора. Это делается через pd.rkn.gov.ru: заполняется форма, где вы описываете, какие категории данных собираете, на каком основании, для каких целей, в каких системах храните. Я помню, как впервые села заполнять эту форму и подумала: "Звучит как наказание за любопытство", но потом поняла, что это отличная шпаргалка для настройки Telegram бот и Make - вы заранее структурируете, что у вас вообще происходит с данными. Важно определиться с основаниями обработки: договор, законный интерес или согласие, потому что дальше от этого будет зависеть текст, который вы показываете пользователю в диалоге с ботом.
На практике для продаж и поддержки чаще всего достаточно договора и законного интереса, а согласие пригодится для маркетинговых рассылок и всего, что выходит за рамки прямого выполнения обязательств. Например, если клиент пишет "Хочу купить куртку", вы обрабатываете его ФИО и телефон для заключения и исполнения договора, и это можно честно так и обозначить. В Telegram бот команды это превращается в текст вроде: "Укажите ФИО и телефон для оформления заказа, обработка по 152-ФЗ для заключения договора". Когда нужен дополнительный маркетинг, вы аккуратно добавляете отдельный блок про согласие на рассылку. Я заметила, что самый частый перекос - пытаться брать "универсальное согласие на всё", хотя с 2026 года тренд идет на отказ от подобных универсальных форм, и Роскомнадзор будет на них смотреть все строже.
Коротко: чем четче вы пропишите цели и основания обработки на этапе реестра, тем легче потом выстроить сценарии Telegram бота и Make и тем меньше шансов, что согласие будет "натягиваться" на все подряд.
Как собрать Telegram бота через BotFather и не забыть про юридический текст
Дальше начинается более приятная часть: сам Telegram бот. Для базовой схемы достаточно @BotFather, который позволяет создать бот telegram bot бесплатно, задать ему имя, описание и сгенерировать токен. После регистрации бота вы можете сразу протестировать его в обычном чате, но на этом этапе закладывается одна скрытая ловушка: многие останавливаются на короткой приветственной фразе и паре команд, хотя именно здесь удобно встроить юридическую часть. Я обычно делаю так: приветствие бота содержит общее описание, что он умеет, и аккуратную ссылку на политику обработки персональных данных, а дальше при первом запросе ФИО и телефона появляется короткий текст с основанием обработки. Звучит сухо, но если написать по-человечески, клиенты это воспринимают нормально, им важнее получить внятный сервис, чем "волшебные" анимации в чате.
Вот как это выглядит на практике: бот отвечает пользователю, что поможет оформить заказ и уточнить статус, и предлагает кнопки "Оформить заказ" и "Уточнить статус". При выборе первой кнопки бот объясняет, что для оформления нужен минимум данных, и просит согласиться с обработкой, показывая текст вроде: "Нажимая 'Да', вы подтверждаете обработку ФИО и телефона по 152-ФЗ для заключения и исполнения договора". Текст я беру из шаблонов правовых систем и адаптирую под конкретный кейс (звучит скучно, но работает). Если пользователь жмет "Нет", бот вежливо предлагает альтернативу - позвонить по номеру, где уже нет автоматизированной фиксации через систему, и это тоже часть честного подхода. Важно, что сам telegram бот отправляешь только минимум нужных данных дальше в Make, а не любую фразу пользователя подряд.
В этой точке часто всплывает вопрос: "А можно ли вообще без согласия?". Ответ - иногда да, когда вы строго остаетесь в рамках договора или закона, но я все равно рекомендую явно проговаривать, что и зачем вы собираете. Это убирает лишние споры и снижает риск, что кто-то воспримет ваш бот как "серого". Антону мы как раз помогали оптимизировать текст: сначала у него был длинный юридический абзац, который отпугивал людей, потом мы оставили ключевую суть и вынесли подробности в политику на сайте. Я немного улыбалась, когда он проверял юристов по словам "достаточно ли строго", хотя сама я так делала ровно один раз - обычно строгости там более чем хватает.
Юридический текст в боте не должен быть романом, но он обязан честно отражать, какие данные вы берете, на каком основании и куда их понесет Make.
Как связать Telegram бот и Make через webhook и не нарушить 152-ФЗ
Ключевой мостик между Telegram ботом и Make - это webhook, адрес, по которому Telegram отправляет входящие сообщения и события. В Make вы создаете сценарий, который начинается с модуля "Webhook" и использует токен вашего бота для приема данных. На этом этапе главное - не жадничать: я всегда минимизирую состав полей, которые уходят в Make, передавая только то, что действительно нужно для CRM и журналов, а не всю историю переписки. Это критично, потому что в 152-ФЗ есть принцип минимизации, и он в новых разъяснениях 2025–2026 годов звучит всё громче. В сценарии Make первым шагом после приема webhook я ставлю проверку на наличие согласия или отметки "обработка по договору", и только при положительном результате данные уходят дальше.
Вот как это выглядит на практике: Telegram бот отправляет Make идентификатор пользователя, его ответ на вопрос о согласии, ФИО и телефон. В Make сценарий проверяет флаг согласия, и если он отсутствует, делает одно из двух: либо возвращает пользователю уточняющий вопрос через Telegram бот ответ боту, либо записывает факт отказа в отдельную таблицу и не создает карточку в CRM. При положительном флаге Make создает или обновляет контакт в CRM, создает задачу для менеджера, записывает событие в Google Sheets как журнал обработки, а также, при необходимости, отмечает дату начала срока хранения для последующего уничтожения. В сценарий легко добавить блок, который формирует логи для вашей системы защиты персональных данных, чтобы можно было показать трассировку при проверке Роскомнадзора.
Важная деталь: webhook в Make сам по себе становится каналом обработки персональных данных, поэтому его адрес и настройки доступа нужно рассматривать как элемент СЗПДн, а не просто техническую мелочь.
Я видела, как некоторые команды раздавали ссылку на webhook направо и налево, "чтобы быстрее подключиться", а потом удивлялись странной активности в логах. Это ровно та зона, где лучше потратить лишние 20 минут на настройку прав и тестовых данных, чем потом объяснять, почему половина запросов клиентов ушла в никуда. Для Антона мы договорились, что первый прогон сценария делаем на полностью обезличенных данных и смотрим, как Make ведет себя на пиках нагрузки, только потом подключаем реальных клиентов. Он сначала ворчал "давай сразу в прод", но после первой ночи с нулем ошибок честно признал, что перестраховка того стоила. Получается, что технический мостик webhook - это не просто интеграция, а часть общей модели угроз для персональных данных, и относиться к нему стоит соответствующе.
Как собрать цепочку Telegram бот + Make + CRM, чтобы она реально экономила 40% времени
Как спроектировать маршрут данных: от чата до задач менеджера
Когда юридический фундамент выстроен, начинается самая интересная часть - проектирование маршрута данных. Я обычно начинаю не с Make, а с блокнота и ручки (или Miro, когда хочется красиво), рисуя путь сообщения: клиент пишет в telegram бот, бот задает пару уточняющих вопросов, потом при наличии согласия данные уходят в Make, и уже там принимается решение, что делать дальше. Первый принцип - разделение потоков: первичные заявки, уточнения по статусу и остальные вопросы лучше сразу разводить по разным веткам, чтобы не городить десяток условий "если" в одном модуле. Второй принцип - явные точки входа менеджера: в сценарии должно быть видно, где автоматизация заканчивается и где создается задача для живого человека.
Вот как это выглядит на практике: в Make я делю маршруты так, чтобы для типичных запросов по статусу заказа менеджер вообще не вмешивался, а бот получал статус из CRM и отправлял его назад клиенту. Для новых заказов Make создает сделку и ставит задачу "Согласовать детали" с дедлайном и приоритетом. Для сложных кейсов (например, нестандартная доставка или юридические вопросы) сценарий сразу помечает задачу как "ручная обработка" и не пытается давать автоматический ответ. Антон сначала хотел, чтобы бот отвечал "на всё", но когда мы вместе посмотрели на несколько диалогов, стало понятно, что лучше честно признать, где нужен человек, чем учить бота симулировать компетентность. Я заметила, что именно такое честное разделение автоматически убирает часть стресса у менеджеров - они видят, что сложные задачи к ним приходят уже в структурированном виде.
Ключевая цель маршрута данных - превратить разрозненные сообщения в Telegram в понятные сущности: лиды, задачи, события журналов и записи СЗПДн, а не оставить "магический" хаос на стороне бота.
Чтобы не утонуть в ветвлениях, полезно заранее договориться о минимальном составе данных для каждой сущности: какие поля обязательны для лида, какие - для задачи, что нужно записывать в журнал обработки. Это можно зафиксировать в одной таблице, и потом уже под нее настраивать Make. В связке с 152-ФЗ это особенно полезно, потому что вы сразу видите, где собираете лишнее, а где, наоборот, записываете меньше, чем нужно для отчетности. Здесь же удобно наметить, какие элементы вы будете выгружать для регулярных проверок - в большинстве российских компаний это можно автоматизировать до состояния "отчет за две кнопки".
Как автоматизировать журналы и акты, чтобы не делать это потом вручную
Второй большой кусок экономии времени спрятан в бумажной, казалось бы, части - журналах учета, реестрах и актах уничтожения. На практике менеджеры очень редко ведут эти документы ежедневно, чаще это "отложенный ужас перед проверкой". Я поняла, что лучше всего работает подход, при котором каждый значимый шаг сценария в Make автоматически порождает запись в журнал. Например, при создании лида мы фиксируем дату, категорию данных, основание обработки и систему, в которой храним запись. При закрытии сделки или истечении срока хранения мы создаем запись об уничтожении данных, и по расписанию выгружаем эти записи в отдельный файл для дальнейшей подписи ответственным.
Здесь хорошо помогают уже готовые российские продукты вроде PrivacyLine, 152DOC или QForm, которые умеют собирать реестры и генерировать документы, но даже без них можно настроить базовый журнал в Google Sheets или отечественной таблице и подключить к нему Make. Для Антона мы сделали простую схему: Make при каждом новом согласии записывает строку в журнал, где указывает идентификатор пользователя Telegram, дату, основание обработки и срок хранения. Отдельный сценарий раз в месяц формирует из этих строк PDF-отчет, который уходит ответственному за персональные данные. Антон сначала удивился, что "такая бюрократия" может делаться сама, а через пару месяцев признался, что уже не представляет, как бы они проходили проверки без этого файла.
Получается, что автоматизация журналов через Make - это не дополнительная нагрузка, а встроенный побочный эффект правильно собранного сценария Telegram бота, который защищает вас от накопления "долгов" перед Роскомнадзором.
Как встроить менеджера в цепочку так, чтобы он не мешал автоматизации (и наоборот)
Самый тонкий момент - роль живого менеджера в автоматизированной связке Telegram бот и Make. Если оставить всё на автомат, вы получите формально красивый сценарий, который в реальной жизни начнет сбоить при первых нестандартных ситуациях. Если же не доверять автоматизации и заставлять менеджера перепроверять каждый шаг, экономия времени исчезнет. Я для себя вывела принцип "умный фильтр": автоматизация берет на себя подготовку и маршрутизацию информации, а менеджер принимает решения там, где нужна оценка, эмпатия или гибкость. Это означает, что в Make стоит заранее прорисовать точки передачи ответственности: создание задач определенного типа, запрос подтверждения у менеджера по сложным вопросам, возможность вручную остановить сценарий для конкретного диалога.
Вот как это выглядит на практике: для стандартных запросов по статусу заказа весь цикл идет без участия менеджера, но если клиент пишет что-то вроде "меня не устроило качество", сценарий помечает диалог как "чувствительный" и создает задачу с высоким приоритетом. Менеджер видит в CRM не сырую переписку, а уже структурированное описание: кто клиент, когда делал заказ, что именно его не устроило, какие действия уже предприняты автоматически. Это сильно снижает когнитивную нагрузку и позволяет сфокусироваться на сути, а не на поиске "того самого сообщения". Помнишь про кофе из начала? В те моменты, когда система сама собирает контекст, у менеджера действительно появляется шанс допить его горячим.
Смысл хорошей автоматизации не в замене людей, а в том, чтобы к тем случаям, где нужен человек, они подходили уже не выжатые, а с ресурсом.
Антон после запуска связки Telegram бот и Make честно признался, что сначала его команда пыталась "обмануть систему" и всё равно ручками лезла в некоторые диалоги. Через пару недель, когда они увидели, что типовые кейсы действительно закрываются без сбоев, сопротивление сошло на нет. Мы договорились, что они раз в месяц пересматривают сценарии и добавляют туда новые паттерны, если видят, что какая-то проблема повторяется часто. Это живая работа, а не "один раз настроили и забыли", но при таком подходе автоматизация становится естественной частью процесса, а не внешней надстройкой, которую все тихо обходят.
Что изменится в 2025–2026 годах и как не попасть под новые риски
Как Роскомнадзор усиливает контроль за ботами и зарубежными сервисами
Если смотреть на тренды 2025–2026 годов, становится очевидно, что автоматизация вокруг Telegram ботов будет жить под всё более пристальным вниманием регуляторов. Роскомнадзор уже сейчас использует автоматизированное сканирование сайтов и ботов на предмет наличия форм сбора персональных данных без уведомления в реестре, а с 2026 года добавится более плотный контроль за локализацией данных и использованием зарубежных сервисов. Это означает, что связка Telegram бот и Make, если последний размещен на серверах за пределами России без должной локализации, может попасть в зону повышенного внимания. Для российских компаний это не повод паниковать, но хороший стимул проверить, где физически хранятся данные и как устроен доступ.
Я заметила, что многие воспринимают Make как "европейский, значит автоматически рискованный", хотя реальная картина тоньше: часть компаний использует его только как транзитный инструмент, не хранят там длительно персональные данные, а основное хранилище размещают в российских CRM и таблицах. В таких схемах важно минимизировать содержание и время жизни данных в Make, настроить очистку логов и ограничить доступ к сценарию. Альтернативой остается n8n - open-source, который можно развернуть на сервере в РФ и использовать похожим образом. На практике я часто делаю гибрид: прототипирование и пилоты на Make, а для зрелых процессов - перенос на самохостимое решение.
Критично, чтобы на вопрос проверяющего "где физически обрабатываются и хранятся данные клиентов из Telegram" у вас был внятный ответ, а не "ну как-то через Make, там все умно".
Что меняется с согласиями и Госуслугами к 2026 году
Вторая крупная линия изменений касается самих согласий и взаимодействия с государственными системами. Тренд идет к тому, что "универсальные" согласия, которые раньше спокойно жили на сайтах и в ботах, будут постепенно вытесняться более точечными, привязанными к конкретным целям и действиям. Параллельно развивается идея интеграции согласий через Госуслуги, когда гражданин сможет централизованно управлять, кому и на что он дал разрешение. Для бизнеса это звучит сначала как дополнительная головная боль, но если смотреть системно, становится понятно, что это шанс избавиться от лишнего документооборота. Правда, при одном условии: процессы внутри компании должны быть достаточно прозрачными, чтобы вообще можно было подключиться к такой системе.
Для Telegram бот и Make это означает, что уже сейчас стоит разносить согласия по смысловым блокам: отдельно для договора, отдельно для маркетинга, отдельно для каких-то специфических обработок. На практике это можно реализовать через разные ветки сценария: одна - когда клиент просто оформляет заказ и вы опираетесь на договор, другая - когда он добровольно подписывается на новости, и это уже отдельная отметка. Антону мы как раз помогали переразметить старые согласия, убрав из них фразы вроде "и любые иные действия, не запрещенные законодательством", которые в новых реалиях выглядят как приглашение к придирке. Он сначала грустил, что "так красивый текст был", но потом признал, что честный минимализм работает лучше.
Чем раньше вы разведете разные цели обработки и научите Telegram бота и Make фиксировать их по отдельности, тем мягче пройдет адаптация к новым форматам согласий и возможной интеграции с Госуслугами.
Как вписать автоматизацию ботов в систему защиты персональных данных
И третья линия изменений - развитие требований к системам защиты персональных данных, особенно там, где данные проходят через несколько сервисов и стран. Уже сейчас при проектировании СЗПДн для компаний с Telegram ботами я отдельно описываю каналы передачи данных: сам мессенджер, webhook в Make или n8n, CRM, журналы, архивы. Для каждой точки нужно оценить угрозы: несанкционированный доступ, утечка, изменение данных, блокировка сервиса. На бумаге это выглядит как очередная таблица, но при честном подходе она превращается в карту, по которой вы двигайтесь, когда выбираете, где и что автоматизировать. В этом смысле Telegram бот и Make не отдельная "фича", а часть общей системы, и к ней применимы те же правила, что и к любой другой автоматизированной обработке.
На практике это выливается в несколько простых решений: ограничиваем круг людей, имеющих доступ к токену бота и сценариям Make, включаем двухфакторную аутентификацию, настраиваем логирование действий администраторов, описываем порядок реагирования на инциденты. Звучит немного скучно по сравнению с "умными" нейросетями, но именно это потом спасает, когда кто-то случайно удаляет сценарий или выкладывает токен бота в общий чат. Я помню историю одной компании, где код бота telegram оказался в открытом репозитории, и им очень повезло, что никто не воспользовался этим до того, как мы провели аудит. Они до сих пор вспоминают тот день как "почти учебную тревогу".
Если Telegram бот и Make описаны в вашей модели угроз и СЗПДн как полноправные элементы, а не "добавка сверху", вы заметно снижаете риск неприятных сюрпризов при проверках и инцидентах.
Как это работает на реальном кейсе Антона и чего удалось добиться в цифрах
Как мы разложили хаос Антона по шагам и сценариям
Возвращаясь к истории с Антоном-предпринимателем, начну с того, что изначально у него был вполне живой, но абсолютно неуправляемый процесс. Клиенты писали в Telegram "Хочу куртку", дальше чат бот Telegram выдавал приветствие и общий каталог, после чего всё зависело от настроения конкретного менеджера. Кто-то сразу брал телефон, кто-то сначала уточнял размер и цвет, кто-то забывал спросить согласие, а кто-то записывал заявку в отдельный блокнот. В CRM попадала примерно половина реальных обращений, остальное растворялось в чате. Я попросила выгрузить обезличенную историю переписки за неделю и просто прошлась глазами по диалогам, делая пометки.
Вот как это выглядело на практике: первый проход показал, что 65% начальных сообщений можно свести к трем типам ("хочу купить", "нужен размер/цвет", "где мой заказ"), а 70% ответов менеджеров повторяются дословно или с минимальными вариациями. Я заметила, что половина "где мой заказ" заканчивается одинаковой фразой "сейчас уточню по номеру телефона", после чего начинался ручной поиск по CRM и таблицам. Мы с Антоном сели и нарисовали три базовых сценария: новый заказ, уточнение статуса и сложный вопрос. Для каждого сценария определили, какие данные нужны, что мы можем автоматизировать через Telegraph бот и Make, а где менеджер по-прежнему незаменим. Уже на этом этапе Антон впервые за долгое время увидел свой процесс не как "сплошной кошмар", а как набор блоков.
Разложение хаоса на повторяющиеся шаблоны - это момент, когда Telegram бот перестает быть "игрушкой" и превращается в инструмент управления потоком запросов.
Как мы подключили Make и какие результаты увидели в первые недели
После того как сценарии легли на бумагу, мы перешли к Make. Я сделала три основных маршрута: новый заказ, запрос статуса и эскалация сложного вопроса. Для новых заказов Telegram бот собирал ФИО, телефон и выбранный товар, Make создавал контакт и сделку в CRM, фиксировал согласие и записывал событие в журнал. Для запросов статуса сценарий шел из Telegram в CRM, вытаскивал актуальные данные и возвращал их в чат бота без участия менеджера. Для сложных вопросов Make формировал задачу "разобраться" с указанием контекста и отправлял уведомление ответственному. Антон настоял, чтобы первое время все задачи дублировались в общий чат, чтобы команда привыкла к новой схеме (забудь, что я только что сказала про "не дублировать" - в фазе привыкания это иногда оправданно).
На практике уже в первую неделю запуск показал интересные цифры: среднее время реакции на запросы "где мой заказ" сократилось с 15-20 минут до 2-3 минут, причем без участия менеджера, а количество забытых заявок упало до нуля, потому что каждое обращение либо превращалось в задачу, либо отмечалось как "автоматически обработанное". Мы засекали время, которое менеджеры тратят на Telegram: до внедрения это было около двух часов в день на 50-60 сообщений, после - примерно 40-50 минут. Остальное время ушло на работу с нестандартными ситуациями и донастройку сценариев, но уже без ощущения, что ты бежишь по беговой дорожке без кнопки "стоп".
Антон честно признался, что впервые за полгода его менеджеры смогли уйти с работы вовремя в сезонный пик, а не в девять вечера, и это был для него лучший нематериальный KPI.
Какие ошибки мы чуть не допустили и как их обошли
Не буду делать вид, что всё прошло идеально: пару раз мы были в миллиметре от классических ловушек. Один из сценариев в Make поначалу создавал карточку в CRM даже при отсутствии явного согласия, потому что разработчик по привычке ориентировался только на факт сообщения "Хочу заказать". Я уже собиралась запускать тест, но в последний момент, проверяя логи на тестовых данных, заметила, что флаг согласия нигде не учитывается. Это как раз тот случай, когда "быстрее" означает "опаснее". Мы переписали логику так, чтобы без явного подтверждения бот предлагал клиенту позвонить или написать на почту, не сохраняя телефон в CRM.
Вторая потенциальная проблема была связана с переспамом уведомлений: в первые дни команда Антона получала по три разных сообщения о новой задаче - из CRM, из Make и из Telegram. Они честно выдержали два дня, потом пришли ко мне с квадратными глазами. Мы сократили количество каналов до одного и оставили Telegram только для критических ошибок и эскалаций. Помнишь про кофе из начала? В те дни он у всех стабильно остывал, и это как раз тот опыт, который потом помогает не повторять подобное на других проектах. Я поняла, что автоматизация должна не только экономить время, но и беречь внимание, а уведомления - самый простой способ это внимание уронить.
В итоге мы получили работающую систему, где Telegram бот, Make и CRM перестали бороться друг с другом за право "быть главным" и заняли свои места: бот общается, Make маршрутизирует и логирует, CRM хранит и помогает менеджеру действовать. А Антон теперь периодически пишет мне скриншоты с новыми диалогами и короткой фразой: "Кажется, это уже живет своей жизнью" 🙂.
Что я вынесла из этих внедрений и как подступиться, если вы хотите повторить путь
С чего начать, если вы пока в точке "просто отвечаем в Telegram"
Если сейчас вы узнаете себя в картине "менеджер весь день в Telegram, а бот только здоровается", то начинать стоит не с нырка в Make, а с инвентаризации. Я бы предложила выделить один-двa рабочих дня, выгрузить (или хотя бы просмотреть) историю переписки за неделю и пометить повторяющиеся типы запросов. Это можно сделать вручную или с помощью простых инструментов анализа текста, но даже "человеческий глаз" хорошо видит повторяющиеся паттерны. Отдельно стоит обратить внимание на то, сколько раз вы просите одни и те же данные и как именно формулируете вопросы, связанные с персональными данными. Иногда достаточно поменять порядок и формулировки, чтобы уже упростить жизнь менеджеру.
Дальше логично выписать, какие системы у вас участвуют в обработке: CRM, таблицы, почта, внутренние базы, и где хранится финальная версия правды про каждого клиента. Я заметила, что во многих компаниях "финальная версия" размазана, и это основная причина, по которой автоматизация потом буксует - непонятно, куда что класть. Если этот список у вас получился, уже можно набросать простую схему: клиент - Telegram бот - Make (или другой интегратор) - системы. И уже под эту схему делать первые шаги: привести в порядок политику обработки персональных данных, зарегистрироваться в реестре, определить основания обработки. Звучит как "бумажная работа", но без нее любые технические решения будут стоять на песке.
Стартовый этап - это не про сложные ИИ-агенты, а про честный взгляд на свои процессы и готовность их описать без украшений.
Как двигаться дальше и где искать опору по пути
Когда базовая картина сложилась, можно постепенно двигаться к технической реализации. На этом этапе имеет смысл почитать пару разборов по Make или n8n, посмотреть, как другие выстраивают связки с Telegram ботами, и выбрать, на чем вы будете собирать первую версию. Если вы любите визуальные сценарии и не хотите сразу заморачиваться с инфраструктурой, Make подойдет как стартовая площадка, при условии, что вы ограничите состав и длительность хранения данных. Если корпоративная политика требует полного контроля и локализации, стоит посмотреть в сторону n8n и его размещения на сервере в РФ. На сайте MAREN я иногда делюсь разбором таких архитектур, как их комбинировать и не свалиться в избыточную сложность.
Параллельно стоит помнить, что автоматизация - это не только про инструменты, но и про людей. Менеджерам нужно объяснить, зачем всё это, показать, как изменится их рабочий день, какие рутинные куски уйдут, а какие останутся. Я в таких случаях всегда прошу выделить одного "владельца процесса" из числа сотрудников, который будет смотреть на систему глазами пользователя и собирать фидбек по улучшениям. Иначе есть риск, что через месяц после запуска часть команды тихо вернется к старым привычкам, и вы начнете ловить дубли и расхождения между ботом и реальностью.
Лучший индикатор того, что вы двигаетесь в правильном направлении - когда менеджеры сами начинают присылать идеи, какие еще кусочки рутины можно отдать Telegram боту и Make, чтобы освободить себе время.
Что получилось у Антона в итоге и как это можно масштабировать
Настало время закрыть наш сюжет с Антоном. Через три месяца после запуска автоматизации мы с ним снова сели за цифры. Время обработки типового объема сообщений (около 50 в день) сократилось с двух часов до примерно сорока минут. Если перевести это в месячный цикл при 22 рабочих днях, получается экономия около 17 часов, которые раньше улетали в переписку и ручной перенос данных. Процент заявок, которые попадали в CRM, вырос с 55–60% до 98–99% - редкие отклонения были связаны только с теми, кто сознательно отказывался оставлять контакты. Количество "потерянных" запросов по статусу свелось к нулю, потому что бот теперь сам тянул актуальные данные из системы.
С точки зрения 152-ФЗ Антон стал чувствовать себя заметно спокойнее: регистрация в реестре оператора прошла без вопросов, журналы и акты формировались автоматически, а на внутреннем аудите по персональным данным было впервые не стыдно показывать процессы. Мы отдельно проговорили план на 2026 год с учетом возможной интеграции согласий через Госуслуги и ужесточения требований к локализации, и теперь он смотрит на это не как на катастрофу, а как на эволюционное развитие уже выстроенной системы. Его любимая фраза из последней встречи: "Раньше 152-ФЗ был страшной сказкой, теперь это просто набор правил игры, под которые мы настроили своего Telegram бота и Make".
Антон уже думает о том, чтобы масштабировать эту модель на новые проекты, добавляя, например, интеграции с маркетинговыми рассылками и антифрод-проверками, но теперь он делает это не "на коленке", а с опорой на отлаженную архитектуру. Для меня это самый приятный момент в работе: видеть, как автоматизация перестает быть разовой акцией и превращается в органическую часть бизнеса. Это означает, что цель достигнута - контент и процессы начинают делать часть работы сами, а люди возвращают себе время и внимание.
Куда можно пойти дальше с этими идеями
Если тебе хочется не просто почитать и разойтись, а аккуратно разложить свои процессы с ботами, можно начать с малого: описать свои диалоги в Telegram, выписать типы запросов, отметить, где уже сейчас напрашивается автоматизация. Для тех, кто готов перейти от теории к практике и потестировать связки Telegram бот, Make, n8n и ИИ-агентов на живых кейсах, я часто разбираю такие истории и их архитектуру в телеграм-канале MAREN. Там же периодически показываю, как мы в реальных проектах экономим те самые часы и дни за счет осмысленной автоматизации, а не гонки за модными словами.
Если же интереснее посмотреть, чем я как Марина Погодина занимаюсь профессионально и какие решения по AI governance и автоматизации мы строим, можно заглянуть на сайт MAREN. Я за то, чтобы любой шаг в сторону Telegram ботов, Make и других интеграторов был не "попробуем что-нибудь", а продуманным вложением в прозрачные и честные процессы, где 152-ФЗ не пугает, а просто задает рамки игры. И да, кофe я по-прежнему иногда забываю допить вовремя, но теперь, по крайней мере, не потому, что копирую телефоны из чата в CRM...
Что ещё важно знать
Вопрос: Как понять, что Telegram бот действительно экономит время менеджера, а не добавляет работы?
Ответ: Я бы замерила базовое время обработки типичного объема сообщений за день до внедрения бота и Make, а потом сравнила через 2–3 недели после запуска. Если автоматизация настроена правильно, вы увидите сокращение ручных действий по переносу данных и уменьшение количества повторных вопросов от клиентов. Если же время и количество ошибок растут, это сигнал, что бот берет на себя не те задачи или сценарии слишком сложны.
Вопрос: Можно ли обойтись без регистрации в реестре Роскомнадзора, если бот собирает только имя и телефон?
Ответ: Для российских компаний имя и телефон клиента уже считаются персональными данными, и их автоматизированная обработка в Telegram и CRM требует уведомления Роскомнадзора. Исключения есть, но они касаются очень специфических случаев, которые редко применимы к онлайн-продажам и поддержке. Поэтому лучше один раз корректно зарегистрироваться, чем потом спорить с проверяющими и платить штрафы.
Вопрос: Что делать, если Make размещен за рубежом, а корпоративная политика требует локализации?
Ответ: В такой ситуации есть два варианта: либо использовать Make только как транзитный инструмент с минимальным набором данных и быстрым удалением, либо перейти на самохостимое решение вроде n8n на сервере в РФ. Решение зависит от масштаба и чувствительности ваших процессов, но в любом случае архитектуру стоит согласовать с ответственным за персональные данные и ИБ.
Вопрос: Можно ли передавать обработку жалоб и конфликтных ситуаций Telegram боту без участия менеджера?
Ответ: Я бы не стала полностью отдавать такие диалоги автоматизации, даже если бот кажется очень "умным". Бот может помочь собрать факты и оформить их в структурированном виде, но оценка, извинения, предложения по решению и юридические нюансы остаются за человеком. Хороший компромисс - бот подготавливает контекст и заводит задачу, а дальше подключается менеджер.
Вопрос: Как проверить, что сценарии в Make не нарушают требования 152-ФЗ?
Ответ: Я бы прошлась по сценариям шаг за шагом, фиксируя, какие данные собираются, куда передаются, на каком основании и как долго хранятся. Затем это можно сверить с вашей политикой обработки персональных данных, реестром процессов и моделью угроз СЗПДн. Если на каком-то шаге вы не можете четко ответить на вопрос "зачем нам эти данные здесь", вероятно, сценарий стоит упростить или изменить.
Вопрос: Что делать, если менеджеры сопротивляются внедрению Telegram бота и Make, боясь потерять работу?
Ответ: В таких случаях помогает честный разговор и демонстрация того, какие именно задачи уйдут в автоматизацию, а какие останутся и даже вырастут по значимости. Стоит показать на примерах, что бот забирает рутину и монотонный перенос данных, а людям остается больше пространства для сложных кейсов, личного общения и развития. Хорошо работает пилотный период, когда один-два менеджера пробуют новую схему и делятся реальными ощущениями с командой.
