Привет, Хабр! На связи команда Just AI. Два раза в год мы проводим конференцию Conversations — это от 500 до 700 участников, и каждый из них должен получить персональную памятку: уникальный ID для входа в приложение, персональную ссылку на трансляцию, информацию о программе. Звучит несложно до тех пор, пока не выясняется, что 30% писем вообще не доходят — участники из крупных банков и госструктур просто не видят их: корпоративные фильтры блокируют письма на уровне инфраструктуры.
В этой статье расскажем, как мы собрали автоматизированный workflow* на агентной платформе, который отправляет персонализированные письма — и проверили, что они действительно доходят даже на домены крупных банков. Это был самый оперативный способ облегчить жизнь команды, которая в день конференции получала десятки писем с одними и теми же вопросами.
* В этом решении нет языковой модели и принятия решений, только детерминированная цепочка шагов.
Откуда взялась задача
Итак, каждую конференцию мы отправляем участникам памятку. Внутри размещаем два персонализированных элемента: уникальная ссылка на трансляцию от партнерской платформы и ID для входа в приложение конференции, дополнительно идет наша стандартная информация о программе мероприятия.
Раньше это был ручной процесс из нескольких шагов. Команда конференции вносила данные участников в облачную таблицу с несколькими вкладками. За неделю до конференции команда организаторов импортировала в приложение конференции список контактов, чтобы каждому участнику присвоился ID.
Потом выгружали базу с ID обратно в таблицу, сопоставляли с итоговым списком, добавляли ссылки на трансляцию из другого списка, который отдавала служба трансляции. Загружали все это в сервис массовых рассылок, создавали шаблон с переменными и делали рассылку.
И повторяли это каждый день или даже несколько раз в день по мере того, как люди докупали билеты — иногда в ночь перед конференцией.
Первая рассылка занимала пару часов. Потом все больше и больше. За 2 дня до конференции это могло занять больше рабочего дня, при этом часть писем не доходили.
В чем была техническая проблема с доставкой
Среди участников Conversations много сотрудников крупных банков, государственных организаций и других структур с жесткими политиками безопасности. Их корпоративные фильтры работают по двум принципам: блокируют массовые рассылки как класс — неважно, какой именно сервис, — и с особым подозрением относятся к письмам со ссылками на сторонние сайты. У нас внутри как раз ссылка на трансляцию.
В результате в канун и утро конференции нам приходило более 30 входящих писем с просьбой прислать ссылку. Также поступали потоки вопросов через аккаунт-менеджеров и продажи, которые напрямую общаются с клиентами-участниками конференции.
Что мы хотели получить
Прежде чем браться за разработку, мы зафиксировали конкретные требования в формате измеримых критериев, чтобы наше решение не превратилось в сложный инструмент, который закрывает одну боль и порождает три новые. Поверьте, мы такое проходили. Главное, чего хотелось избежать, — это ситуации, когда автоматизация требует не меньше внимания, чем ручной процесс.
Первое требование звучало так: наш Рассыльщик (назовем так автоматизированный workflow) должен сам отслеживать новых участников в таблице, без ручного контроля со стороны команды. Данные об участниках поступали от разных коллег и в разное время: кто-то приходил через специалистов по продажам, кто-то — из рекламы, кто-то — из других каналов. Поэтому записи появлялись в таблице хаотично, и команде нужно было вручную отслеживать, какие участники добавились недавно. Мы хотели, чтобы Рассыльщик сам находил новые записи и добавлял их в общий список.
Автоматизированная система должна была взять эту логику на себя: при каждом запуске просматривать все вспомогательные вкладки, забирать свежедобавленных участников и переносить их в сводную таблицу — без участия команды организаторов и без риска кого-то пропустить или посчитать дважды.
Второе требование касалось ID из приложения конференции. Приложение не поддерживало интеграцию, поэтому загрузить участников и выгрузить присвоенные ID можно было только вручную. При этом выгружался всегда полный список — со всеми участниками подряд. А значит, при каждом новом прогоне нужно было вручную искать, у кого в рабочей таблице ID еще не стоит, и догружать именно их. Чем ближе к конференции и чем больше появлялось новых участников, тем дольше и запутаннее становилась эта сверка. Требование к Рассыльщику было в том, чтобы после добавления новых участников в таблицу, он сам сопоставлял данные по ФИО и email, и явно показывал, кто еще остался без ID и ссылки на трансляцию — чтобы можно было разобраться до рассылки.
Третье требование — отправлять письма напрямую, без платформ-посредников вроде Mailganer. Каждое письмо должно уходить с нашего собственного адреса через SMTP, а не через инфраструктуру сторонних сервисов рассылок. Именно они считываются корпоративными фильтрами как источник спама.
Четвертое требование — персонализация письма. Как и в сервисе массовых рассылок, в каждое письмо должны подставляться уникальные данные конкретного участника: персональный ID и ссылка на трансляцию. Только теперь Рассыльщик берет эти значения напрямую из таблицы и вставляет в HTML-шаблон — без ручной настройки переменных в стороннем сервисе перед каждой рассылкой.
Пятое требование — режимы запуска. В спокойный период достаточно расписания: Рассыльщик сам проверяет список раз в день и рассылает памятки новым участникам. Но за два дня до конференции поток заявок резко вырастает, люди покупают билеты поздно вечером и ждут памятку почти сразу. Здесь нужен ручной запуск — мы решили это через отдельный веб-интерфейс управления, из которого можно обновить таблицу участников, запустить основную или повторную рассылку, а также отдельную пост-рассылку.
В метриках мы зафиксировали три ориентира: доставляемость от 95%, попадание в спам менее 3%, и ручная работа не более 30 минут в день — против восьми и более часов в пиковые дни до автоматизации.
Архитектура: три блока, один workflow
Мы сделали решение на Just AI Agent Platform. Важная оговорка по архитектуре: LLM здесь не используется вовсе. Мы собрали автоматизированный workflow, который работает по четким правилам, без генерации текста. Такой подход делает решение предсказуемым и бесплатным в части токенов. Так мы сделали намеренно — памятка содержит конкретные данные: ID, ссылку на трансляцию, программу конференции.
Нам важно было не дать Рассыльщику возможность придумывать что-то от себя, а сделать его максимально точным: текст письма заранее прописан, а из таблицы он только подставляет нужные значения.
Если у вас другая задача и вы хотите, чтобы агент еще и писал текст письма — это тоже можно. Просто заранее решите, какие переменные модель не должна трогать ни при каких обстоятельствах.
В нашем же случае архитектурно это классическая цепочка шагов без сложной маршрутизации, потому что задача предсказуемая, последовательная, без ветвлений по типу запроса.
Основа всей системы — таблица с несколькими вкладками, с которой работает Рассыльщик. Среди них:
Несколько вкладок с участниками (Партнеры, СМИ и т.д.) — данные конференции (имя, email, компания, тип билета и т.д.), которые мы заполняем вручную по мере покупки билетов. Рассыльщик читает их и синхронизирует изменения: добавляет новых, убирает удаленных.
Вкладка «Итого» — сводная таблица со всеми данными участников, ID и ссылкой. Именно из нее Рассыльщик берет данные для рассылки.
Вкладка «ID» — сюда Рассыльщик добавляет фамилии участников, которым еще не присвоен ID в приложении и хранит все данные об уже присвоенных ID. После запуска он собирает со всех вкладок новые строки, которых еще нет в итоговом списке, и добавляет их в сводную таблицу.
Затем проверяет, есть ли у новых участников ID. Если ID еще нет, Рассыльщик добавляет их фамилии во вкладку «ID» — здесь команда может вручную вписать полученный в приложении ID напротив нужного участника или загрузить в таблицу выгруженный из приложения список. После этого Рассыльщик сопоставляет данные по email и переносит коды доступа в сводную таблицу «Итого».
Вкладка «Ссылки» — список уникальных ссылок на трансляцию от партнерской платформы, которые добавляются в таблицу вручную. Рассыльщик присваивает ссылки по одной на каждого участника и отмечает в чек-боксе, что он забрал ссылку.
При массовом добавлении участников мы просто импортируем в приложение новых участников, потом выгружаем список с ID из приложения и вставляем во вкладку «ID» — а Рассыльщик уже сам сканирует фамилии и находит недостающие данные.
Для отправки писем мы использовали функцию email-send на платформе, которая отправляет письмо с указанного адреса как обычное личное.
Весь воркфлоу состоит из трех основных блоков, собранных на Just AI Agent Platform.
Блок 1 — Excel_Workflow1: сбор и синхронизация участников. Рассыльщик проходит по всем вспомогательным вкладкам исходной таблицы, забирает свежедобавленных участников и переносит их в итоговую сводную таблицу, где собраны все данные по участникам.
Блок 2 — Excel_Workflow2: присвоение ID и ссылок. Рассыльщик проходит по итоговой сводной таблице и проверяет, у каких участников не заполнены колонки ID и Cсылка на трансляцию. Если после первого прогона ID у участника нет, Рассыльщик добавляет такого участника в отдельную вкладку с таблицей «ID», из которого команда организаторов берет список для ручного присвоения идентификаторов в приложении. Затем команда вручную добавляет полученные ID из приложения во вкладку «ID». При повторном запуске Рассыльщик сопоставляет данные по email и заполняет пустые колонки в итоговой таблице. Ссылки на трансляцию Рассыльщик берет из списка уникальных ссылок и присваивает каждому участнику следующую свободную.
Блок 3 — Email Workflow: рассылка писем. Когда у всех участников заполнены ID и ссылки, финальный блок отправляет каждому персонализированное письмо с выделенного почтового адреса. Письмо сверстано в HTML по шаблону конференции, внутри подставляются переменные: ссылка на трансляцию, ID. После отправки Рассыльщик фиксирует статус в таблице.
Рассыльщик отправляет письма через SMTP с конкретного адреса — каждое письмо технически отдельное, поэтому спам-фильтры не распознают это как массовую рассылку.
Пример запуска
Покажем на конкретном примере, как это выглядит в работе. Допустим, появился новый участник — Петр Романов, добавляем его в соответствующую вкладку в списке участников.
Заходим в веб-интерфейс управления и нажимаем запуск. Рассыльщик сканирует вкладки, видит нового участника, добавляет его в итоговую таблицу и во вкладку с ID, показывая, что ID у участника пока нет.
Затем заходим в приложение, присваиваем Петру ID — допустим, 3458, добавляем это значение в список в таблицу «ID». Затем возвращаемся в интерфейс и запускаем обновление таблицы — Рассыльщик сканирует ее и проставляет недостающие значения в итоговом списке. Ссылка у него уже есть из списка, который передала платформа трансляции — Рассыльщик берет следующую свободную из тысячи.
В том же интерфейсе нажимаем «Запустить рассылку» — workflow отправляет письмо. В таблице появляется статус «отправлено» и дата отправления.
После этого можно открыть письмо: оно сверстано в HTML по шаблону конференции, внутри подставлены уникальная ссылка на трансляцию и ID для приложения. Письмо пришло не в спам, а прямо во входящие — это мы проверили на адресах с доменами банков, которые раньше не получали наши рассылки.
Проблемы, с которыми мы столкнулись
Письма при большой рассылке попадали в спам
На тестах обнаружили, что при отправке большого количества писем — больше 30 за один запуск — часть писем все-таки попадала в спам. Поэтому мы разделили рассылку на пачки по 30 писем и запускали их последовательно, а не отправляли все письма одновременно. Так удалось избежать массового срабатывания спам-фильтров.
Ручное присвоение ID пока остается
Приложение с присваиванием ID не поддерживает интеграции по API. Это единственный шаг, который автоматизировать пока не удалось. Нужно вручную добавить участников в приложение, выгрузить список и загрузить в таблицу для агента. Но мы уже нашли альтернативу с API, на которую перейдем к следующей конференции.
Результаты
✔️ Мы проверили доставляемость на проблемных доменах — банки, государственные структуры и все письма дошли.
✔️ Ручная работа с рассылками памяток сократилась до 30 минут в день: загрузить список из приложения, проверить статусы, при необходимости запустить вручную. До этого: от двух часов в спокойный период до 8+ часов в пиковые дни перед конференцией.
✔️ Входящих с просьбой «пришлите ссылку на трансляцию» — единицы вместо 30+, как раньше. Аккаунт-менеджеры и продажи перестали получать запросы от клиентов с этой проблемой.
✔️ Важный для нас плюс — экономия. Платформы для организаций ивентов предлагают похожий функционал в рамках полноценных тарифов, но стоит это минимум 50 000 рублей. Наше решение работает в рамках стоимости лицензии на платформу — затрат на LLM нет вообще, т.к. это чистая автоматизация workflow.
Когда этот подход имеет смысл
Мы намеренно собирали решение универсальным. По сути это шаблон для любой задачи, где нужно отправить персонализированное письмо большому списку контактов, в каждом письме подставить уникальные данные конкретного человека и автоматически обновлять список без ручного отслеживания изменений.
Это работает для:
Продаж — после вебинара или встречи на конференции разослать follow-up с персональными деталями обсуждения.
Маркетинга — после демо-сессии, мероприятия или онбординга отправить материалы с именными данными.
Ивент-менеджмента — любое мероприятие с большим количеством участников, где у каждого должна быть уникальная ссылка, код или документ.
Не стоит применять такой способ автоматизации, если рассылка разовая — проще сделать вручную, — если нет формализованного шаблона письма или нет человека, который будет следить за статусами.
Что дальше
Со стороны workflow еще есть что улучшить. Например, заменить приложение для генерации ID на сервис с API. Тогда исчезнет последний ручной шаг, а процесс станет полностью автоматическим.
Еще хотим добавить аналитику: смотреть, сколько писем открыли, у каких доменов низкая открываемость и кому стоит отправить повторное напоминание за день до конференции.
Третье, и самое амбициозное, — отдельный IMAP-агент для ответов на входящие. Это уже не доработка рассылочника, а совсем другой инструмент, который мы хотим построить.
Workflow закрыл проактивную рассылку, но не закрыл реактивный сценарий: часть участников все равно пишет напрямую на почту — «где моя ссылка», «как попасть на конференцию», «не могу найти ID». До сих пор на такие письма отвечал человек, а теперь этим займется агент.
Мы хотим сделать агента, который будет подключаться к корпоративной почте по IMAP и обрабатывать такие запросы сам. В отличие от Рассыльщика, здесь будет LLM, которая принимает решения: анализирует текст письма и выбирает, что делать. Если участник потерял ссылку или ID — будет искать его по email в той же таблице «Итого» и отправлять персональный ответ. Если участника не нашлось, но есть совпадение по корпоративному домену — не будет угадывать, а уточнит данные. Историю переписки тоже будет учитывать, если письмо придет в существующей цепочке.
Workflow и IMAP-агент будут работать с одной таблицей, но решать разные задачи: первый будет проактивно напоминать участникам о конференции, второй — отвечать тем, кто напишет сам.
Если у вас похожий процесс — список контактов, шаблонное письмо с уникальными данными, и все это повторяется регулярно — этот кейс легко переиспользовать.
Если хочется разобраться детальнее или обсудить, как адаптировать под свою задачу — приходите в наше Telegram-комьюнити для разработчиков. Там мы разбираем реальные кейсы, обсуждаем архитектуру и иногда спорим, когда нужен агент, а когда достаточно workflow, собранного из простых блоков.
