Автоматизация email-подписей в Make звучит как что-то из разряда «сделаем красиво потом», но именно с этого «потом» начинаются и хаос, и риски. В российских компаниях подписи живут своей жизнью: у одного логотип 2018 года, у другого старый номер, у третьего — вообще без подписи, хотя пишет ключевым клиентам. При этом в каждой такой подписи лежат персональные данные по 152-ФЗ: ФИО, должность, email, телефон, иногда даже город и мобильный. В этой статье я разбираю, как настроить автоматизацию email-подписей в Make так, чтобы и бренд был ровным, и комплаенс чувствовал себя спокойно, и команда перестала тратить часы на ручные правки.
Писать буду из позиции человека, который однажды поймал себя на мысли: «Если я ещё раз отправлю сотрудникам инструкцию ‘скопируйте вот этот шаблон’, я просто отключу им интернет». У нас в компании на 20 человек уходило по 2-3 часа каждый месяц на обновление подписей, а потом я узнала, что часть команды вообще продолжала писать со старыми версиями. Параллельно в голове тихо мигал 152-ФЗ с его регистрацией операторов, локализацией и чёткими вопросами проверяющих: кто вносит изменения, где хранятся ПДн, есть ли журнал. В этот момент в мою жизнь тихо вошёл Make и остался.
Чтобы было чуть интереснее, по ходу текста я буду возвращаться к одному реальному кейсу. Назовём его герой Антон, руководитель отдела продаж в московском B2B-сервисе, 35 человек, из которых 22 работают с почтой каждый день. Антон пришёл с задачей «сделать подписи одинаковыми и не мучать людей каждый раз новыми инструкциями». А я про себя подумала: отлично, сейчас заодно подтянем 152-ФЗ и логи, потому что Роскомнадзор с 2026 года шутить перестанет. Как именно Антон прошёл путь от хаоса в Outlook до автоматизированной системы на Make, я разбиваю на три части — начнём с контекста и рисков, дальше перейдём к конкретным шагам настройки, а в финале покажу, во что это вылилось в часах и нервах.
В какой момент хаос в email-подписях перестаёт быть просто эстетической болью маркетолога и становится юридическим риском? Обычно в тот, когда в компанию приходит первая серьёзная проверка или когда кто-то из клиентов выкладывает скрин переписки с подписью «Директор по продажам», а директор уволился полгода назад. В России это ещё усиливается ужесточением 152-ФЗ: регистрация операторов, локализация на российских серверах, автоматизированный мониторинг сайтов и политик, а заодно и косвенный интерес к тому, как вы обращаетесь с ПДн во внутренних и внешних коммуникациях. Email-подпись в этом смысле — тихий носитель данных, который всегда с вами, но о котором вспоминают в последнюю очередь.
Когда я в первый раз собрала все действующие подписи нашей команды в один файлик, получила довольно странный зоопарк: разные шрифты, разный формат телефонов, кто-то вписал туда «любящий папа двоих дочек», кто-то прилепил огромный баннер с акцией. С точки зрения бренда это выглядело как коллаж из разных эпох. С точки зрения 152-ФЗ там спокойно лежали ПДн без явного основания, без описанного способа обновления и без истории изменений. Если перевести на язык проверяющих: «Кто отвечает?», «Как вы обеспечиваете актуальность?», «Где журнал?». На все три вопроса у нас тогда был один честный ответ — никак.
Вот тут в картину и вошёл Антон. Он пришёл не с темой закона, а с очень приземлённой болью: его менеджеры тратили рабочее время на возню с настройками в Outlook, путались в HTML-подписях и в какой-то момент просто перестали что-либо обновлять. Я ему задала один вопрос: «Готов ли ты собрать данные сотрудников в одну таблицу и жить с тем, что подписи будут меняться централизованно?» После короткой паузы он сказал: «Да, я уже устал от креатива внизу писем». Это было то самое согласие, которого не хватает в половине подобных историй.
Прежде чем лезть в Make, я всегда смотрю, как компания обращается с персональными данными сейчас. В российской реальности 2025-2026 годов это уже не история про «где у нас бумажки», а про связку: запись в реестре Роскомнадзора, локализация баз (включая резервные), актуальность политики обработки ПДн и наличие хотя бы минимальной модели угроз. И да, даже внутренние email-рассылки и подписи попадают в зону внимания, потому что содержат ФИО, должности, контакты. Оправдание в стиле «мы же маленькие» в проверке не работает, и сейчас это уже не страшилка юристов, а новая норма.
Чтобы не утонуть в теории, я держу в голове простую рамку. Есть три ключевых вопроса: какие данные вы включаете в подпись, где и в каком виде они хранятся до попадания в почтовый клиент и как вы фиксируете изменения. Ответы на них определяют, как дальше строить автоматизацию. В статье я разложу эту рамку по шагам: от исходной таблицы до логов, но уже на этом этапе предлагаю честно признаться себе, есть ли у вас сейчас единый список сотрудников с ролями, актуальными контактами и минимальным учётом согласий на обработку ПДн. Если нет, автоматизация email-подписей в Make начнётся не с Make, а с таблицы и диалога с HR и юристами.
С Антоном мы начали именно с этого: собрали всех сотрудников, которым нужна корпоративная подпись, сверили ФИО с трудовыми договорами, договорились, что в подпись пойдёт только то, что предусмотрено договором и необходимо по задачам. Никаких «о себе», даты рождения и любимых цитат. Параллельно обновили политику обработки ПДн и добавили туда отдельный пункт про использование данных в служебных email-подписях. На это ушло около 3 часов живого времени, но без этого опираться на автоматизацию было бы странно.
Как подготовить данные для автоматизации email-подписей в Make под российские реалии
Чтобы автоматизация email-подписей вообще имела шанс заработать устойчиво, первым делом нужно привести в порядок данные, а не бросаться сразу к модулям Make. Я заметила, что большинство проблем с подписями потом оказываются не техническими, а организационными: кто-то не знает, где взять актуальный номер телефона, у HR одна версия должности, в CRM другая, а маркетинг вообще рисует третью в презентациях. В России к этому добавляется измеряемый риск по 152-ФЗ: каждая такая рассинхронизация — потенциальная ошибка в ПДн, которая живёт в исходящих письмах и не контролируется. Поэтому база для подписи должна быть единой, понятной и хранящейся там, где вы можете обеспечить защиту и учёт.
На практике я чаще всего начинаю с Google Таблиц или Airtable, хотя иногда компании выбирают Bitrix24 или 1С как источник истины. В таблице достаточно 6-8 колонок: ФИО, должность, рабочий email, рабочий телефон, подразделение, город (если релевантно), ссылка на логотип или фото, а также техническое поле для статуса: активен, в отпуске, уволен. Здесь важно не увлечься и не превратить подпись в мини-резюме сотрудника: по 152-ФЗ мы должны минимизировать набор данных и включать только то, что действительно нужно для коммуникации. Я иногда ловлю себя на желании добавить туда LinkedIn или личный сайт, а потом вспоминаю про локализацию и частные данные и закрываю знакомую вкладку.
Чтобы показать, из чего состоит такая таблица, приведу укрупнённый перечень полей и тех вопросов, которые я задаю себе и команде.
- ФИО — совпадает ли с трудовым договором и внутренними системами, нет ли «креативных» сокращений.
- Должность — синхронизирована ли с кадровым приказом и публичным позиционированием, не раскрывает ли лишнего (например, данные о роли в проекте).
- Email и телефон — рабочие ли это контакты, нет ли там личных адресов или мобильного, который сотрудник не готов светить клиентам.
- Логотип или фото — где хранится файл, на каком домене, соответствует ли корпоративным требованиям к хранению и 152-ФЗ.
- Статус — кто и как меняет состояние записи при увольнении или переводе.
Такой список помогает быстро понять, где у вас уже есть дырки. Это означает, что ещё до Make вы подсвечиваете риски и можете их закрыть.
Антону я сразу предложила хранить картинки логотипов и фото сотрудников на российском хостинге вроде Yandex.Cloud или корпоративном файловом сервере, чтобы не было соблазна заливать всё в первый попавшийся зарубежный CDN. Здесь работает простое правило: если подпись уходит клиентам, значит она может стать предметом интереса проверяющего органа, а вместе с ней — и источники данных. Поэтому ссылки на изображения в HTML-подписи должны вести либо на ваш домен, либо на сервис, по которому ваши юристы уже спят спокойно. Это критично, потому что в 2026 году автоматизированный мониторинг Роскомнадзора вряд ли ограничится только текстами политик на сайте.
Отдельно затрону тему согласий. Многие до сих пор считают, что для использования ФИО и должности в служебной подписи нужно отдельное письменное согласие. В реальности для большинства компаний достаточно ссылки на трудовой договор и локальные акты, где прописано использование ПДн в служебных целях, включая подписи в почте. Но если вы хотите включать в подпись мобильный, мессенджеры или фото, я всё-таки рекомендую сделать короткую форму согласия в HR-системе или в том же Bitrix24 (хотя сама я так оформляла ровно один раз, чаще обходимся положением). Это снимает массу вопросов в будущем, особенно при увольнении или спорных ситуациях.
С точки зрения учёта по 152-ФЗ очень помогает идея отдельного журнала изменений по подписам. Пока мы всё ещё на уровне подготовки данных, можно сразу заложить вторую таблицу: дата изменения, сотрудник, что поменялось, кто инициировал. В будущем именно эта таблица станет финальным модулем в Make и вашим спасательным кругом при любой проверке — «вот журнал, вот история, вот ответственный». С Антоном мы как раз сделали именно так: сначала нарисовали структуру данных, потом спокойно перенесли это в Make, а не наоборот.
Как выбрать источник данных и не нарушить 152-ФЗ при автоматизации подписей
Когда первая таблица с сотрудниками собрана, возникает логичный вопрос: где ей жить и кто за неё отвечает. Я тестировала разные подходы: от хранения всего в Google Workspace до полноценной интеграции с 1С или кадровым модулем в Bitrix24. И каждый раз возвращаюсь к одному и тому же критерию: источник должен быть устойчивым, понятным бизнесу и вписанным в вашу модель угроз по 152-ФЗ. Звучит сухо, но на деле это про простые вещи: где физически лежат данные, кто имеет к ним доступ и как настроены права.
В российских реалиях 2025-2026 годов я чаще всего вижу три сценария. Первый — небольшие компании на 5-30 человек, где проще всего начать с Google Таблиц или отечественного эквивалента, а вопросы локализации решать за счёт настроек и минимального объёма ПДн. Второй — компании, у которых уже есть живая CRM вроде Bitrix24, и тогда логично сделать там отдельный справочник сотрудников и использовать API как источник для Make. Третий — более крупные игроки, где кадровый учёт ведётся в 1С, и таблица для подписей строится поверх выгрузок оттуда. Каждый из вариантов рабочий, если вы не забываете про связку безопасность-комплаенс-удобство.
Чтобы не уходить в абстракцию, приведу небольшой фрагмент из диалога с Антоном. Он изначально хотел хранить всё в CRM, чтобы не плодить сущности, но у их Bitrix24 не было настроенных прав доступа, и любой менеджер мог случайно удалить запись коллеги. Мы посидели с их IT, посмотрели текущие роли и в итоге решили сделать первый уровень в Google Таблицах с ограничениями, а уже затем, когда подтянут роли в CRM, перенести логику туда (нет, подожди, есть нюанс: миграцию всегда лучше планировать, а не делать «по настроению»). В результате source of truth для подписей на первом этапе оказался в облаке, но с жёстким разграничением доступа по отделам и отдельной ролью «администратор подписей».
В этой точке я всегда напоминаю про локализацию. По 152-ФЗ персональные данные граждан РФ должны сначала собираться и храниться на российских серверах, а уже потом, при необходимости, передаваться за рубеж в соответствии с требованиями. Поэтому если вы используете зарубежные облака для Make или хранения картинок, нужно внимательно посмотреть, где физически находятся серверы и какие настройки предусмотрены. Для email-подписей это может звучать избыточно, но, когда в 2026 году заработает автоматизированный мониторинг, такие «мелочи» всплывут неожиданно быстро.
На уровне governance очень выручает простое закрепление ответственности. В политике или регламенте по ИБ и ПДн можно прямо прописать, что за актуальность данных для подписей отвечает, например, HR-менеджер, а за автоматизацию и техподдержку — IT или выделенный владелец процесса. Это не про перекладывание вины, а про то, чтобы в момент инцидента не бегать по офису в поисках «кто последний трогал таблицу». С Антоном мы как раз сделали отдельного ответственного в отделе маркетинга, который раз в квартал сверял подписи с кадровой базой и запускал плановое обновление шаблонов.
В качестве небольшого акцента я бы подчеркнула одну мысль. Источник данных для подписей — это не про «где удобнее таблицу открыть», а про весь цикл жизни ПДн: от сбора до удаления. Если вы сможете на один лист бумаги выписать, где и как эти данные проходят путь от HR до почтового клиента сотрудника, значит вы готовы к автоматизации через Make и к разговору с любым проверяющим. Получается, что хорошая подпись начинается не с красивого HTML, а с скучной, но честной схемы.
Как настроить автоматизацию email-подписей в Make по шагам
Когда данные собраны и источник понятен, можно переходить к тому, ради чего вы, скорее всего, открыли этот текст — к самой автоматизации в Make. Здесь я придерживаюсь очень приземлённого подхода: минимальный набор модулей, понятный триггер, простой HTML-шаблон и обязательный блок логирования. Make хорош тем, что позволяет собрать всё это без кода, но при этом даёт достаточно гибкости для интеграций с Gmail, Yandex.Mail, корпоративными SMTP и даже CRM. При этом в российских реалиях я всегда держу в голове ещё два слоя: где крутится сам Make и как он вписывается в нашу модель обработки ПДн.
Стандартная схема выглядит так. Триггер смотрит за изменениями в таблице с сотрудниками, дальше мы генерируем HTML-подпись на основе шаблона, затем вызываем модуль обновления подписи в почтовом сервисе и в самом конце пишем строку в журнал изменений. Между этими шагами можно ставить проверки, ветвления и дополнительные интеграции, но основа почти всегда одна и та же. Важно, что любой шаг в этой цепочке должен быть прозрачен для вас: что пришло на вход, что ушло на выход, какие данные обрабатываются и где они могут «утечь».
Прежде чем идти дальше, я приведу укрупнённую последовательность действий, по которой мы с Антоном строили его сценарий в Make.
- Связать Make с таблицей сотрудников и настроить триггер на изменение или добавление строки.
- Собрать HTML-шаблон подписи с помощью Text Aggregator или аналогичного модуля.
- Подключить модуль Gmail, Yandex.Mail или HTTP-запрос к API корпоративной почты.
- Добавить запись в журнал изменений в отдельной таблице.
- Проверить сценарий на тестовых аккаунтах и включить регулярный мониторинг.
- Ограничить доступ к сценарию по ролям и настроить уведомления об ошибках.
Это тот самый «скелет», на который потом можно навешивать нюансы. Это означает, что даже если вы поменяете источник данных или почтовый сервис, общая логика останется той же.
С технической точки зрения первый шаг — это выбор правильного триггера. В Make для Google Sheets есть модуль Watch Changes, который срабатывает при изменении строки. Мы настраиваем его на диапазон, где лежат данные сотрудников, и добавляем фильтр: запускать сценарий только при изменении статуса или контактной информации. Это нужно, чтобы Make не дёргался при каждом лишнем пробеле в служебной колонке. Если вы используете Airtable или Bitrix24, логика похожая: триггер на изменение записи с фильтром по нужным полям.
Следующий шаг — генерация самой подписи. Здесь большинство спотыкается об HTML. Я обычно беру минималистичный шаблон: таблица или набор параграфов с логотипом, ФИО, должностью, телефоном и email. В Make удобно использовать Text Aggregator: вы прописываете структуру с плейсхолдерами вроде {{Name}} или {{Phone}}, а затем подставляете значения из таблицы. С Антоном мы добавили ещё одну тонкость: для разных отделов были чуть разные акценты в подписи (у продаж — упор на телефон, у маркетинга — на сайт и соцсети), и мы реализовали это через условные блоки внутри Make (звучит сложнее, чем есть на самом деле).
Как собрать HTML-шаблон подписи и не превратить его в монстра
На этом шаге обычно просыпается внутренний дизайнер и хочет добавить в подпись всё сразу: и баннер, и ссылку на вебинар, и слоган, и маленькую иконку диплома. Я в какой-то момент тоже так делала, а потом посмотрела на это глазами ИТ-риск-менеджера и подумала: нет, лучше так. Чем проще HTML-шаблон, тем меньше шансов, что он развалится в Outlook, мобильном клиенте или при пересылке. И тем проще потом сопровождать автоматизацию в Make, не разбираясь, где там какой div потерялся.
Я придерживаюсь трёх принципов. Первый — использовать базовые теги: таблицы, абзацы, изображения, минимальное количество стилей. Второй — все ссылки на картинки должны вести на стабильный, контролируемый источник. Третий — весь HTML-шаблон хранится не только в Make, но и в отдельном файле или документации, чтобы можно было быстро откатиться или отдать на ревью коллегам. В Make это решается достаточно элегантно: основной текст хранится прямо в модуле Text Aggregator, а резервная копия лежит в вашем репозитории документов.
Вот как это выглядит на практике: в Text Aggregator вы собираете структуру подписи, подставляя переменные из триггера. Например, вставляете img с src из поля «Logo URL», затем параграф с ФИО, затем строку с должностью и телефоном. При желании можно добавить условный блок, который показывает, например, ссылку на Telegram-канал для определённых сотрудников (я один раз видела подпись с прямой ссылкой «Пишите сразу в рабочий чат» и решила, что нам пока рано к такому уровню смелости 🙂). Важно, что на этом этапе вы ещё не трогаете почтовый сервис, а просто формируете HTML, который потом уйдёт дальше.
С Антоном мы договорились, что в подписи будет логотип компании, ФИО, должность, прямой телефон и общий рабочий email отдела, а также лаконичная ссылка на сайт. Внутренний спор был вокруг того, добавлять ли туда юридическую приписку про конфиденциальность. Я честно сказала, что с точки зрения 152-ФЗ она не спасёт от нарушений, если остальные процессы не выстроены, а для зарубежных корреспондентов это иногда выглядит избыточно (хотя в англоязычном мире это уже фон). В итоге оставили короткую фразу, без многострочных простыней.
Сейчас небольшой акцент. Не пытайтесь в первый же день сделать «идеальную» подпись, которая раз и навсегда решит все задачи маркетинга, HR и юристов. Возьмите базовый шаблон, запустите его через Make, посмотрите на реакцию команды и клиентов, а потом постепенно добавляйте нюансы. Это экономит ресурсы и нервы, особенно когда вы впервые лезете в связку HTML и автоматизации.
Как подружить Make с Gmail, Yandex и корпоративной почтой
Когда HTML-шаблон готов, приходит время самого волшебства — интеграции с почтовым сервисом. В Make есть готовые модули для Gmail, в том числе Update Signature, который позволяет обновлять подпись пользователя через API. Для Яндекс.Почты и некоторых корпоративных решений часто приходится использовать модуль HTTP и стучаться в API напрямую. Звучит страшно, но на практике это пара полей: URL, метод, заголовки авторизации и тело запроса с уже готовой подписью.
Я заметила, что основная сложность здесь не техническая, а организационная: кто выдаёт доступы, по какому принципу вы управляете учётными записями и готовы ли вы доверить Make права на изменение подписей от имени сотрудников. В Gmail это решается через сервисный аккаунт и делегирование полномочий, в Яндекс.Почте — через доменную авторизацию. Для локальных решений иногда приходится звать администратора, который знает, где у почтового сервера кнопка «API». В любом случае этот этап прекрасен тем, что вы один раз продираетесь через настройки, а потом просто живёте с готовой связкой.
С Антоном мы ушли от идеи давать Make права на каждую учётную запись в отдельности. Вместо этого их IT настроили сервисный аккаунт с ограниченными правами, который умел только обновлять подписи и не мог, например, читать почту. В Make мы передавали в модуль идентификатор пользователя (email), а дальше API делал своё дело. На тестовых аккаунтах всё заработало с третьей попытки: однажды забыли экранировать кавычки в HTML, во второй раз промахнулись с областью видимости токена. Кофе к этому моменту окончательно остыл, но зато сценарий стал воспроизводимым.
Чтобы не потеряться в логике, я всегда фиксирую структуру запроса в отдельном описании. В нём я прописываю, какие заголовки мы шлём, в каком формате передаём подпись, как обрабатываем ошибки API. Если сервис возвращает коды 4xx или 5xx, в Make можно повесить обработчик ошибок и уведомление, например, в Telegram-бота. Это не обязательно, но очень помогает, когда через полгода кто-то вдруг решает поменять настройки домена и подписи начинают падать тихо и бесславно.
На этом этапе вы фактически завершаете основной поток: изменили данные в таблице — сценарий в Make сработал — подпись в почте обновилась. Осталось только добавить последний штрих: запись в журнал. Вторая таблица, в которую мы пишем дату, сотрудника, тип изменения и результат, становится вашим минимальным центром учёта. И здесь как раз проявляется связка автоматизации и комплаенса: вы не просто сделали красиво, вы сделали отслеживаемо.
Как встроить автоматизацию подписей в процессы и не потерять контроль
Когда базовый сценарий в Make заработал, возникает следующий слой вопросов: как это встроить в ежедневную жизнь компании так, чтобы никто не ломал процесс каждые две недели и чтобы юридический блок продолжал чувствовать почву под ногами. Автоматизация email-подписей сама по себе не решает вопросы с 152-ФЗ, но может сильно упростить поддержку актуальности ПДн и доказательство того, что вы вообще контролируете этот участок. Здесь на первый план выходит не Make как инструмент, а процессы вокруг него.
Для меня точкой опоры всегда становится связка HR — IT — маркетинг — юристы. HR знают, кто у нас есть и кто увольняется, IT управляют инфраструктурой и доступами, маркетинг отвечает за бренд и визуальную часть, юристы — за соответствие закону. Если хоть одно из этих звеньев исчезает из уравнения, автоматизация начинает шататься. В идеале у вас должен быть короткий регламент: кто вносит данные в таблицу, когда, на основании чего, кто запускает обновление шаблона, кто проверяет лог, как обрабатываются инциденты. На бумаге это выглядит скучно, но в момент сбоя именно этот A4-лист экономит часы разбирательств.
Помнишь, я в начале упоминала о той самой чашке кофе, которая успевает остыть, пока ты в третий раз объясняешь людям, как обновлять подпись? Так вот, после внедрения Make количество таких объяснений уменьшается до нуля, если процессы описаны. С Антоном мы сделали так: HR при приёме сотрудника заполняет строку в таблице, IT создаёт почтовый ящик, Make по триггеру подхватывает новые данные и обновляет подпись. При увольнении HR меняет статус на «уволен», а сценарий либо удаляет подпись, либо заменяет её на техническую с текстом «контакт больше не актуален». Все эти действия фиксируются в журнале, который в случае чего можно показать и ревизору, и Роскомнадзору.
Чтобы немного структурировать эту «околотехническую» часть, приведу перечень ролей и их зон ответственности.
В хорошо настроенной автоматизации подписей самое ценное — не код сценария, а договорённость людей, кто и что делает, когда сотрудник появляется, меняет должность или уходит.
Формально это выглядит как простая матрица, но по сути вы строите маленькую экосистему вокруг одной, казалось бы, мелкой функции.
Как связать Make, CRM и учет ПДн так, чтобы не усложнить жизнь
На этом этапе многие компании начинают задумываться: а не завязать ли автоматизацию email-подписей Make на CRM, чтобы, например, менеджеры по продажам автоматически получали ссылки на свои карточки или статусы из воронки. Я тестировала подобные связки с Bitrix24, amoCRM и даже с самописными системами. Опыт показал, что всё, что касается внешних данных (клиенты, лиды, сделки), лучше держать отдельно от подписи, а вот то, что касается внутренних атрибутов сотрудника, прекрасно живёт в одной экосистеме.
Например, в Bitrix24 можно завести отдельный справочник «Сотрудники для подписи» с полями для ФИО, должности, телефона и статуса, а также с отметками о согласиях. Make тогда подключается к API Bitrix24, забирает эти данные и подставляет в подпись. Здесь удобно то, что HR и руководители видят всё прямо в одном интерфейсе, без прыжков между переводами. Минус — Bitrix24 становится критической точкой отказа, и придётся убедиться, что он вписан в вашу модель угроз и перечень ИСПДн (хотя он там, скорее всего, уже есть).
В российском контексте есть ещё одна тонкость: отдельный учёт согласий и оснований обработки ПДн. В 2026 году часть компаний будет вынуждена работать с «Госуслугами» для управления согласиями, но для внутренних данных сотрудников по-прежнему основой будут трудовые договоры и локальные акты. Это означает, что поля в CRM или таблице должны соответствовать этим документам. Если в договоре у вас нет ни слова о размещении фото в подписи, а в таблице это поле есть и активно используется — у проверяющего будут вопросы. Я поэтому всегда сверяю набор полей с юристами ещё на этапе проектирования.
С Антоном мы часть информации о сотрудниках брали из CRM, но сделали отдельный слой абстракции: Make не лез напрямую в таблицы сделок или клиентов, а работал только с сущностью «сотрудник». Это позволило не смешивать ПДн двух разных типов: сотрудников и клиентов. Для управляемости это оказалось критично, потому что в одной проверке ИБ у них как раз спрашивали, какие именно данные проходят через какие интеграции. Если бы подписи тянули поля одновременно и из кадровой базы, и из клиентской, объяснять было бы дольше.
В качестве маленькой самокритики замечу: я один раз попыталась сделать суперумную систему, где подпись сотрудника автоматически менялась в зависимости от его текущего плана продаж и статуса в CRM (звучит забавно, да). На третьем месяце эксплуатации все попросили «открутить» эту функцию, потому что внимание клиентов стало уходить на динамические элементы внизу письма. Так что иногда простое решение гораздо эффективнее.
Как Антон прошел путь от хаоса к устойчивой автоматизации
Возвращаясь к Антону, к этому моменту у него уже был рабочий сценарий в Make, настроенные таблицы и договорённости внутри команды. Первые две недели прошли под знаком тестов: где-то подпись выводилась с лишним пробелом, где-то фотографии не подгружались из-за прав на доступ к папке. Мы вместе с их IT-специалистом планомерно проходились по этим мелочам, правили шаблон, обновляли ссылки на картинки, раздавали минимальные инструкции сотрудникам. Самое интересное случилось через месяц, когда у них уволился один из ведущих менеджеров по продажам.
До автоматизации это выглядело так: HR пишет IT, IT через пару дней вспоминает, что надо отключить почту, сотрудники продолжают ссылаться на старый адрес, а клиенты получают письма в никуда. Теперь при увольнении HR вносит статус «уволен» в таблицу, Make в течение пары минут обновляет подпись и автоматически отправляет уведомление в общий Telegram-чат: «Подпись для адреса такого-то обновлена, сотрудник более не работает в компании». Клиенты при ответе на старые письма видят обновлённую подпись с новым контактным лицом. Антон потом отдельно сказал, что именно этот момент стал для него индикатором, что всё было не зря.
Чтобы подчеркнуть эффект, зафиксирую короткую цитату, которую он написал мне спустя три месяца:
«У нас впервые за два года все подписи выглядят одинаково, и я знаю, что при проверке смогу показать живой журнал, а не переписку в мессенджерах. Для меня как для руководителя это уже не история про ‘красиво’, а про ‘контролируемо'».
Получается, что правильно встроенная автоматизация подписей не только экономит время, но и делает процессы вокруг ПДн чуть более взрослым. И в российском контексте это, честно говоря, уже необходимость, а не приятный бонус.
Какие риски и ошибки чаще всего всплывают при автоматизации подписей
Пока всё звучит довольно гладко, но жизнь, как всегда, богаче документации. Автоматизация email-подписей в Make — это не только экономия часов, но и набор типичных граблей, на которые наступают почти все. Я вижу три уровня ошибок: технические, организационные и юридические. Технические лечатся сравнительно просто, организационные требуют работы с людьми, а вот юридические в российской реальности могут закончиться штрафами и довольно неприятными беседами с проверяющими.
Технически самая распространённая проблема — зависимость от одного человека, который «знает, как тут всё устроено». Если этот человек уходит в отпуск, что-то ломается, и никто не понимает, как поправить сценарий. На втором месте — отсутствие нормального тестового контура: изменения в шаблоне вносятся сразу в боевой сценарий, и клиенты внезапно начинают получать письма с полупустыми подписями или HTML-кодом вместо красивого блока. На третьем месте — некорректная обработка ошибок API: Make падает молча, а команда узнаёт об этом через неделю, когда кто-то случайно замечает расхождение.
Организационные ошибки обычно завязаны на том, что ответственность за подписи размазана. HR думает, что этим занимается маркетинг, маркетинг уверен, что IT, IT вообще не в курсе, зачем всё это нужно. В итоге таблица с сотрудниками живёт своей жизнью, подписей десяток вариантов, а Make изо всех сил пытается что-то обновлять по триггерам, которые никто не отслеживает. В таких условиях автоматизация превращается в ещё один источник хаоса, только теперь он более быстродействующий.
Юридические риски чаще всего связаны с тремя моментами. Во-первых, отсутствие чёткого описания, какие ПДн используются в подписях и на каком основании. Во-вторых, хранение исходной таблицы и связанных с ней файлов на зарубежных сервисах без учёта требований локализации. В-третьих, отсутствие журнала операций по изменениям. Я один раз видела ситуацию, когда компания уверенно рассказывала проверяющим про автоматизацию подписей, а на вопрос «покажите журнал» начинала судорожно искать скриншоты в мессенджерах. Это как показывать красивый фасад дома без фундамента.
Чтобы сфокусировать внимание, приведу короткий список тех зон риска, которые я теперь проверяю почти автоматически, как чек-лист.
Подписи с ПДн без понятного основания и описания — это приглашение к диалогу с регулятором на не самых приятных условиях, особенно после 2026 года, когда автоматизированный мониторинг станет нормой.
Следовательно, если вы уже автоматизировали подписи или только собираетесь, имеет смысл пробежаться по этим точкам и закрыть явные пробелы заранее.
Как не превратить Make в чёрный ящик и что делать при сбоях
Я часто слышу фразу: «Мы настроили Make, он там что-то делает, но лучше его не трогать». В этот момент у меня срабатывает внутренний внутренний аудитор. Автоматизация, которую боятся трогать, — это уже не помощь, а риск. Чтобы не превращать Make в чёрный ящик, нужно с самого начала заложить в сценарии и документации возможность диагностики и поддержки. Это не про многотомные регламенты, а про базовые понятные шаги.
Первое, что я делаю, — прописываю имена модулей в Make не по умолчанию, а осмысленно: «Триггер — изменения в таблице сотрудников», «Генерация HTML», «Обновление подписи в Gmail», «Запись в журнал». Это может казаться мелочью, но через полгода вы сами себе скажете спасибо. Второе — добавляю логирование ключевых ошибок: если API возвращает ошибку, мы пишем это не только в системный лог Make, но и в отдельную таблицу или отправляем уведомление в корпоративный чат. Третье — оставляю короткое текстовое описание сценария в общей документации: что он делает, какие данные трогает, какие есть предохранители.
С Антоном мы на этапе запуска договорились, что любые изменения в сценарии будут проходить через тестовую копию. Мы завели отдельную таблицу, пару тестовых почтовых ящиков и дублирующий сценарий в Make, на котором проверяли все новые фичи и правки. Да, это добавило 15-20 минут к каждому изменению, но зато исключило ситуации, когда клиенты видят «сырые» эксперименты. Один раз мы так поймали баг с кириллицей в имени файла картинки, который в боевом режиме мог бы привести к сломанным логотипам у всей команды.
Отдельная тема — что делать при сбоях. В идеальном мире у вас есть человек, который заходит в Make, смотрит на логи и ошибки, правит сценарий. В реальном мире этот человек иногда занят, болеет или в отпуске. Поэтому полезно иметь хотя бы короткий алгоритм для остальных: где посмотреть статус сценария, как временно отключить автоматическое обновление, как вручную восстановить подписи в почте. Это может быть простой документ из трёх страниц, но он сильно снижает нервозность команды в моменты нестабильности (звучит странно, но психологический комфорт тоже часть управляемости).
Здесь я сама однажды обожглась: в одном проекте мы сделали очень красивый и сложный сценарий, но не документировали его. Через год к нам вернулись с просьбой «немного поменять шаблон подписей», а человек, который делал сценарий, уже занимался другим направлением. Восстановить логику по скриншотам и интуиции заняло почти столько же времени, сколько изначальная настройка. С тех пор я всегда трачу лишний час на человеческое описание сценария и храню его там же, где лежат политики и модель угроз.
Какие юридические нюансы стоит учесть российским компаниям
Про юридическую сторону автоматизации подписей я могла бы писать отдельный текст, но здесь сосредоточусь на том, что реально влияет на жизнь. Первое — статус оператора ПДн. Если вы ещё не уведомили Роскомнадзор и планируете делать это в 2025-2026 годах (что по новому регулированию придётся сделать почти всем), имеет смысл сразу включить в описание процесса и работу с email-подписями. Это не обязанность как таковая, но хороший тон: вы показываете, что понимаете, где у вас проходят персональные данные, и не скрываете «мелкие» процессы.
Второе — локализация. Если вы используете Make, нужно посмотреть, где физически крутятся сценарии и куда уходят логи. В ряде случаев компании выбирают self-hosted решения вроде n8n на своих серверах именно потому, что так проще вписать их в модель угроз и перечень ИСПДн. Make при аккуратной настройке и минимальном составе данных также может жить в white-data-зоне, но тогда в сценарии не должно быть ничего, кроме служебной информации, которая не идентифицирует людей напрямую. Для email-подписей это иногда компромисс: часть компании выносит в Make только шаблонизацию, а сами ПДн остаются внутри локальных систем.
Третье — журнал учёта. Для российской практики последних лет всё чаще спрашивают: «Как вы фиксируете операции с ПДн? Какие есть логи?». Если вы можете открыть таблицу, где видно, когда и какая подпись была изменена, кем инициировано изменение и какой результат, у проверяющего сразу меньше вопросов. Это не отменяет необходимости систем защиты (СЗИ) и других инструментов, но создаёт ощущение управляемости. В кейсе с Антоном журналом как раз и убрали половину потенциальных претензий: даже если где-то что-то пошло не так, это можно восстановить и объяснить.
Я отдельно отмечу тренд, который уже сейчас заметен по обсуждениям с коллегами. Период «все делают как хотят, а потом как-нибудь разберёмся» заканчивается, особенно в крупных городах и секторах, связанных с ИТ и финтехом. Роскомнадзор усиливает мониторинг, бизнес-партнёры начинают задавать больше вопросов о ПДн в тендерах и опросниках, клиенты тоже стали более чувствительны к тому, что написано внизу письма. Автоматизация подписи не спасёт от всех этих тенденций, но она может стать одним из кирпичиков в более серьёзной системе управления данными.
Возвращаясь к практике, я понимаю, что всё это может звучать избыточно для компании на 10 человек, которая просто хочет избавить себя от ручного копипаста. Но чем раньше вы привыкнете думать о таких вещах, как основание обработки, локализация и журналы, тем меньше потом придётся перестраивать, когда вы вырастете до 50-100 человек и у вас появятся крупные клиенты. Это похоже на привычку сразу называть файлы по смыслу, а не «Новый_документ_3» — сначала кажется занудством, потом внезапно экономит часы.
Что в итоге получает бизнес: время, прозрачность и спокойные нервы
После всей этой довольно плотной теории и практики закономерно хочется спросить: а что в итоге? Стоит ли возиться с таблицами, Make, API и журналами ради какой-то подписи внизу письма. Я отвечу из своей профессиональной деформации: да, если смотреть на это как на маленький, но показательный кусочек работы с данными и процессами. Email-подпись — это то место, где встречаются бренд, IT, HR и юристы, и то, как вы с этим участком обращаетесь, довольно точно отражает состояние управляемости в целом.
Если говорить в цифрах, средняя команда из 20-30 человек тратит на обновление подписей вручную примерно 2-3 часа в месяц, если делать это регулярно, и существенно больше, если каждый крутится сам. Автоматизация через Make после первичной настройки забирает на поддержку 10-20 минут в месяц: проверить логи, обновить шаблон раз в квартал, посмотреть уведомления об ошибках. Экономия по времени получается порядка 10+ часов в месяц, если учитывать не только исполнителей, но и тех, кто объясняет, как это всё делать. Если умножить это на год, получается прямо-таки мини-проект по оптимизации.
Но для меня самое ценное даже не это. Настроенная автоматизация подписей даёт ощущение прозрачности: вы знаете, кто и как меняет данные, где это зафиксировано, как восстановить историю. Это снижает уровень бытового стресса: люди перестают дергать маркетинг с вопросом «а как мне поставить новый номер», HR не пишут по вечерам «мы завтра выводим новичка, сделай ему подпись», IT не вспоминает в 23:00, что забыл отключить почту уволенному сотруднику. Да, звучит слегка идеалистично, но ощутимый сдвиг в сторону спокойствия там действительно есть.
Помнишь историю с Антоном? Через три месяца после запуска сценария в Make они подвели свои итоги. Оказалось, что до автоматизации их HR и IT в сумме тратили около 5 часов на каждый массовый апдейт подписей (смена логотипа, юридического адреса, общих контактных данных). После автоматизации это заняло 40 минут: обновить шаблон, прогнать тест, включить сценарий. За полгода они сэкономили примерно 25-30 часов только на этих задачах, не считая времени самих менеджеров, которых больше не дёргали «допилить подпись».
Чтобы не быть голословной, приведу одну фразу из внутренней переписки их команды, которую Антон переслал мне с разрешения автора:
«Я перестала бояться писем от юристов с темой ‘Подписи’ — теперь у нас есть что им показать, кроме скринов из Outlook».
Для меня это прям лакмусовая бумажка: когда автоматизация перестаёт быть игрушкой для IT и становится частью того, как компания показывает свою зрелость, в том числе перед внешними партнёрами и регуляторами.
Что изменится в 2025-2026 годах и почему автоматизация подписей станет ещё актуальнее
Если смотреть чуть вперёд, на 2025-2026 годы, автоматизация email-подписей в Make попадает в более широкий тренд. Ужесточение 152-ФЗ, расширение реестра операторов, локализация, автоматизированный мониторинг сайтов — всё это подталкивает бизнес к тому, чтобы формализовывать даже те процессы, которые раньше жили «по понятиям». Email-подписи как носитель ПДн — вполне в этой зоне: пока вы маленькие, на вас почти не смотрят, но как только вы попадаете в поле зрения крупных клиентов или госструктур, вопросы начинаются быстро.
Сюда же добавляется рост интереса к no-code и low-code инструментам. Всё больше российских компаний начинают использовать Make, n8n, внутренние конструкторы на базе своих ИТ-ландшафтов, чтобы не ждать разработчиков по полгода. Автоматизация подписей в этом смысле хороший учебный полигон: данные не слишком чувствительные, бизнес-логика понятная, эффект виден сразу. Когда команда научится на этом кейсе, дальше легче автоматизировать что-то более сложное: заявки, маршрутизацию документов, интеграции между CRM и бухучётом.
В контексте 152-ФЗ интересен ещё один момент: переход от универсального «согласия на всё» к более точечным основаниям и учёту операций. В подписях это может отразиться, например, в том, что вы будете точнее описывать, какие данные сотрудника и на каком основании используются в служебной коммуникации. Я уже вижу кейсы, когда компании указывают в локальных актах не только общее «использование ПДн в служебных целях», но и конкретные каналы: корпоративная почта, мессенджеры, внутренняя социальная сеть. На первый взгляд это бюрократия, на второй — страховка на будущее.
В этом месте можно сделать ещё один небольшой круг к началу нашей истории. Помнишь тот самый остывший кофе и третий заход на объяснение, как обновить подписи вручную? В реальности это не только про неудобство, но и про скрытые издержки: пока вы тратите время на такие мелочи, у вас его нет на действительно важные задачи. Автоматизация подписей через Make, CRM или другие инструменты — это способ вернуть себе эти часы и одновременно подтянуть комплаенс, не превращая его в болезненную тему для всех.
Если хочется продолжить в ту же сторону и посмотреть, как можно автоматизировать смежные вещи — формирование договоров, журналов ПДн, уведомлений по инцидентам, — я регулярно разбираю такие кейсы и у себя на сайте про автоматизацию и AI governance, и в Telegram-канале. В обеих точках стараюсь держаться того же принципа: без магии, без «завтра всё заменим ИИ», а с честным разбором, где автоматизация действительно экономит время, а где создаёт новые риски.
Куда двигаться дальше после настройки автоматизации подписей
Когда подписи уже обновляются сами, сценарий в Make стабильно работает, а HR с юристами больше не пишут вам по вечерам по этому поводу, наступает приятный момент: можно подумать, как использовать этот опыт дальше. Обычно в этот момент выясняется, что внутри компании есть ещё десяток процессов примерно такого же масштаба, которые все тихо ненавидят, но «так исторически сложилось». И автоматизация подписей вдруг становится не конечной точкой, а первым кирпичиком в выстраивании более широкой системы.
Я часто предлагаю командам посмотреть вокруг: какие ещё процессы похожи по структуре? Есть источник данных, есть шаблон, есть канал доставки, есть требования по ПДн и журналам. Типичные кандидаты — шаблоны коммерческих предложений, уведомления по статусу заявок, документы для онбординга, внутренние рассылки с персонализированными блоками. Логика та же: сначала наводим порядок в данных, потом строим прозрачный сценарий в Make или другом инструменте, потом привязываем журнал и регламент.
На этом этапе очень помогает привычка делиться опытом и решениями. Я, например, заметила, что многим проще начать экспериментировать, когда они видят не только общий принцип, но и живые кейсы, где это уже сработало. Поэтому в своём Telegram-канале про AI-автоматизацию и процессы я часто разбираю именно такие истории: не прекратили ли мы тормозить n8n на третьем шаге, как сочетается Make с российскими CRM, где граница между white-data и зонами с повышенными требованиями. Если тебе хочется не просто прочитать, но и постепенно выстроить свою карту автоматизаций, присоединяйся — там формат более диалоговый.
Возвращаясь к Антону и его «подписям», финал истории выглядит вполне приземлённо. За год после внедрения автоматизации они расширили команду с 35 до 48 человек, при этом не добавив ни одной новой инструкции по обновлению подписей. Сценарий в Make пережил два плановых обновления шаблона, смену логотипа, реорганизацию отделов и одну проверку по ПДн, где журнал изменений стал тем самым аргументом, который снял часть вопросов. В пересчёте на время это около 60 часов, которые раньше тратились на рутину и объяснения, а теперь ушли в продажи и развитие продукта.
Меня в этой истории радует не только цифра, а тот сдвиг, который она показывает. Вместо «да кто вообще читает эти подписи» появляется «давайте сделаем так, чтобы у нас не было серых зон с ПДн». Вместо страха перед сервисами автоматизации — спокойное отношение: да, мы знаем, что там крутится, вот описание, вот журнал, вот ответственный. И это, наверное, самое ценное, что можно забрать из этого текста: автоматизация не как магия и не как игрушка, а как часть взрослого отношения к своим же данным и времени.
Что ещё важно знать
Вопрос: Как начать автоматизацию подписей, если в компании всего 5 человек?
Ответ: Я бы не усложняла: достаточно одной таблицы с сотрудниками, базового шаблона подписи и простого сценария в Make или даже ручного HTML с копированием. Автоматизацию стоит включать, когда вы понимаете, что обновления происходят регулярно и начинают отнимать заметное время. При этом даже для 5 человек полезно сразу продумать, какие ПДн вы туда включаете и где будет лежать исходная таблица.
Вопрос: Можно ли обойтись без журнала изменений по подписям?
Ответ: Формально можно, но я бы не стала, особенно с учётом тренда на усиление контроля по 152-ФЗ. Журнал в виде таблицы почти не требует ресурсов, но даёт сильный аргумент при любых вопросах о том, как вы управляете ПДн в коммуникациях. К тому же он помогает разруливать внутренние ситуации, когда нужно понять, кто и когда менял подпись конкретного сотрудника.
Вопрос: Что делать, если Make недоступен или компания боится зарубежных сервисов?
Ответ: В таком случае имеет смысл посмотреть в сторону self-hosted решений вроде n8n или использовать автоматизацию на уровне CRM и почтового сервера. Логика останется той же: единый источник данных, шаблон подписи, интеграция с почтой и журнал учёта изменений. Критерий простой: сервис должен вписываться в вашу модель угроз и требования локализации ПДн.
Вопрос: Как быть, если сотрудник не хочет указывать в подписи мобильный телефон?
Ответ: Здесь нужно смотреть на трудовой договор и локальные акты: если мобильный не является обязательным атрибутом рабочей коммуникации, навязывать его в подписи не стоит. Можно ограничиться рабочим email, внутренними номерами и общими контактами отдела. В спорных ситуациях я предпочитаю фиксировать позицию сотрудника и компании письменно и по возможности искать компромисс, не выводя в подпись лишние ПДн.
Вопрос: Можно ли использовать фото сотрудника в подписи без отдельного согласия?
Ответ: Я обычно рекомендую всё-таки оформлять отдельное согласие или хотя бы закреплять это в локальных актах с возможностью отказа. Фото относится к биометрическим ПДн в зависимости от контекста, и регуляторы к ним более чувствительны. Даже если юристы считают, что в вашем случае риски минимальны, прозрачное согласие снижает вероятность конфликтов с самими сотрудниками.
Вопрос: Что делать, если в компании несколько доменов и почтовых сервисов?
Ответ: В такой ситуации имеет смысл разделить сценарии по доменам или сервисам, но использовать один и тот же источник данных и шаблон там, где это возможно. Make позволяет ветвить логику в зависимости от домена email, так что часть шагов может быть общей, а интеграция с почтой — разной. Главное — сохранить единый подход к данным и журналу, чтобы потом не разбираться отдельно по каждому домену.
Метки: ai-agents, makecom, n8n, автоматизация, автопостинг, контент-план