Автоматизация электронной почты: как я искал повторяемую работу и не нашёл продукт

У меня была сильная почтовая экспертиза, работающая инфраструктура и большой ежедневный поток. Я проверил, превращается ли это в повторяемую бизнес-функцию, которую стоит продуктировать.

У меня есть область, где накопилось много практического опыта, поэтому сначала мне казалось, что найти там хорошую работу для цифрового сотрудника будет относительно просто.

Это инфраструктура корпоративной электронной почты.

С 2018 года моя команда поддерживает собственный почтовый контур. Через него для компаний в среднем отправляется ~120 тысяч персональных деловых сообщений в день.

За этими объёмами стоит довольно большая система:

• почтовые серверы;
• домены и ящики;
• постепенное наращивание объёмов отправки;
• контроль доставляемости;
• работа с попаданием писем в спам;
• персонализация;
• возвраты и ошибки;
• связь с CRM - системой управления отношениями с клиентами;
• удаленные рабочие столы для генерации и отправки писем;
• статистика.

На первый взгляд это почти идеальная территория для автоматизации.

Есть большой поток событий.
Есть данные.
Есть повторяющиеся технические операции.
Есть накопленная экспертиза.
Есть ИИ, который умеет анализировать и классифицировать информацию.

Но в рамках моего нового подхода этого недостаточно.

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

Поэтому я поставил другой вопрос:

Какую конкретную работу внутри всей почтовой инфраструктуры компании можно выделить, стандартизировать и передать цифровому исполнителю?

Я прошёл несколько уровней сужения.
И в итоге не нашёл задачи, которую сейчас считаю достаточно сильным основанием для нового продукта.

Почему нельзя было просто сделать продукт из нашей экспертизы

В начале мне мешало простое предположение:

если у меня есть редкая и глубокая компетенция, где-то рядом должен находиться продукт.

На практике между этими вещами нет прямой связи.
Корпоративная почтовая инфраструктура может включать десятки разных работ:

• выбрать схему отправки;
• настроить серверы;
• подключить домены;
• создать и подготовить ящики;
• распределить объёмы;
• контролировать репутацию;
• отслеживать доставляемость;
• обрабатывать ответы;
• разбирать технические ошибки;
• синхронизировать данные с CRM;
• формировать статистику;
• поддерживать весь контур после запуска.

Это большая инженерная и консультационная услуга.
У разных компаний отличаются CRM, объёмы, источники данных, почтовые системы, требования к отправке и внутренние процессы.

То есть передо мной была не одна функция, а целая инфраструктурная область.
Раньше я, возможно, начал бы думать, как всё это упаковать.
Сейчас я поступил наоборот.
В карте из 240 повторяемых работ бизнеса я уже увидел, что отрасль, отдел или большой процесс слишком крупны для поиска нового продукта.

Поэтому начал уменьшать масштаб.

Первая проверка: может быть, компании покупают саму почтовую инфраструктуру

Я начал с поискового спроса вокруг серверов и доставляемости.

В исследовании Wordstat на 7 сентября 2026 года получил такие точные значения за 30 дней:

Сам спрос на проблемы с электронной почтой существует.
Люди ищут, почему письма попадают в спам. Ищут настройку и проверку серверов.

Но здесь меня интересовало другое: существует ли достаточно понятный стандартизированный продукт, который компании самостоятельно формулируют как отдельную потребность?
Чем ближе запрос становился именно к инфраструктуре рассылок, тем слабее был сигнал.
Например, запрос купить SMTP сервер для рассылки дал всего 6 точных показов за 30 дней.

Это не доказывает, что компаниям не нужна такая инфраструктура.
Из моего собственного опыта я знаю, что такие проекты существуют.

Но поисковые данные не дали основания считать собственную почтовую инфраструктуру хорошим массовым входным продуктом.
Такой проект слишком быстро превращается в индивидуальную работу:

• какой объём отправки;
• какие домены;
• какая CRM;
• откуда появляются получатели;
• какие письма отправляются;
• как обрабатываются ответы;
• кто отвечает за данные;
• что делать с ошибками;
• какая статистика нужна.

Я решил подняться на один уровень выше.
Возможно, компании покупают не инфраструктуру, а бизнес-результат, ради которого она строится.

Вторая попытка: холодные письма для продаж компаниям

Следующей гипотезой стали холодные рассылки между компаниями - исходящие письма организациям, с которыми до этого не было контакта.

Здесь поисковый язык оказался намного заметнее.
В первом проходе я проверил 28 формулировок:

• 5 подтвердились точно;
• 4 получили только близкие сигналы;
• 19 не получили сигнала.

Среди подтверждённых были:

• email outreach;
• холодный аутрич;
• холодная email рассылка;
• холодные письма b2b;
• сервис холодных рассылок.

После очистки списка я отправил в Wordstat 31 запрос.
Точное значение получилось получить для 10 формулировок.

Самые показательные результаты:

Отдельно присутствовал информационный спрос:

• холодный аутрич это - 24;
• email аутрич это - 16;
• email outreach что это - 14;
• что такое холодный аутрич - 7.

То есть категория существует.
Компании и специалисты знают холодные рассылки как отдельный способ поиска клиентов.
Но масштаб прямого коммерческого спроса оказался небольшим.

Ещё интереснее было то, какие запросы не подтвердились.
Например:

• автоматизация B2B-рассылок;
• автоматизация холодных рассылок;
• интеграция электронной рассылки с CRM;
• обработка ответов в CRM;
• статистика рассылки в CRM;
• рассылка писем с вложениями из CRM.

Именно так всю систему склонен описывать инженер.
Но не так её формулирует рынок.

Архитектура решения и работа клиента оказались разными вещами

С моей стороны весь процесс выглядит примерно так:
база получателей
↓
персонализация
↓
вложения
↓
почтовые ящики
↓
отправка
↓
серверы и домены
↓
контроль доставки
↓
ошибки и возвраты
↓
CRM
↓
статистика

Для меня это один связанный технический контур.
Но клиент не обязан воспринимать его таким образом.
Его работа может звучать гораздо проще:

найти новых корпоративных клиентов с помощью холодных писем.

Тогда появляется другая проблема.

Если продавать именно этот результат, продукт сразу выходит далеко за пределы автоматизации электронной почты.
Нужно:

• определить целевую аудиторию;
• получить базу;
• подготовить предложение;
• написать письма;
• настроить последовательность;
• обеспечить доставку;
• отслеживать ответы;
• передавать заинтересованных клиентов в продажи.

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

Я начал искать одно конкретное событие и одно конкретное действие

Мне нужна была задача, которую можно описать без длинной схемы.
Например:

произошло событие X - система выполнила действие Y - бизнес получил результат Z.

Одной из наиболее интересных точек оказались недоставленные письма.

Представим обычную ситуацию.
Менеджер отправляет клиенту письмо.
Адрес уже не существует.
Почтовый сервер возвращает сообщение о недоставке.
Менеджеру приходит техническое уведомление.
Но CRM продолжает хранить адрес как обычный контакт.

В результате сотруднику нужно самому:

1. заметить техническое письмо;
2. понять причину;
3. найти клиента в CRM;
4. исправить данные;
5. не забыть найти новый контакт.

А если он этого не сделал, компания может продолжать использовать заведомо нерабочий адрес.
Так появилась новая гипотеза:

автоматически обрабатывать недоставленные письма и возвращать их статус в CRM.

Схема уже значительно проще:
письмо отправлено
↓
пришла ошибка доставки
↓
определена причина
↓
контакт найден в CRM
↓
адрес помечен как нерабочий
↓
менеджеру поставлена задача

Это уже похоже на атомарную повторяющуюся работу.

Третья проверка: существует ли спрос на обработку недоставленных писем

Для этой гипотезы я провёл отдельный поиск.
Проверил 32 исходные формулировки.
Получил:

• 8 точных подтверждений;
• 6 близких;
• 18 без сигнала.

Поиск собрал 117 связанных формулировок, из которых после первичной очистки релевантными выглядели 106.
Точно находились запросы:

• проверка email на существование;
• массовая проверка email на существование;
• soft bounce;
• hard bounce;
• email bounce;
• bounce management;
• почему письмо не доставлено;
• проверка доставки email.

На поверхности это выглядело многообещающе.
Но после очистки оказалось, что поисковая выдача смешивает совершенно разные ситуации.
Там встречались проблемы Почты России, WhatsApp, iPhone и даже нерелевантные результаты по словосочетанию hard bounce.

Гораздо важнее другое.
Формулировки, связывающие недоставленное письмо именно с CRM, практически не получили подтверждения:

• статус доставки email crm;
• ошибки доставки email crm;
• обработка недоставленных писем в crm;
• обработка bounce в crm;
• недоставленные письма crm;
• обработка bounce email;
• автоматическое исключение email из рассылки;
• автоматическая очистка email базы.

Техническая задача существует.
Но я не увидел признаков того, что рынок воспринимает её как самостоятельную категорию решения.

Вместо этого поиск показал другую работу

Самый ясный кластер оказался связан не с обработкой возвратов после отправки, а с проверкой адресов заранее.
В очищенном наборе остались запросы вроде:

• валидация базы email;
• проверка email на существование;
• проверка базы email на валидность;
• массовая проверка email на существование;
• проверить email на существование;
• проверка существования email.

То есть атомарная работа нашлась:

определить, существует ли электронный адрес до отправки письма.

Но здесь возникла уже другая причина не делать продукт.
Эта работа давно стала стандартной.

На рынке есть отдельные сервисы проверки адресов, почтовые платформы и готовые приложения для CRM.
Я технически могу сделать ещё один сервис проверки адресов.
Но наличие поискового спроса само по себе не объясняет, зачем рынку ещё одно аналогичное решение.

Если существующую работу уже можно закрыть стандартным дешёвым инструментом, мне нужна отдельная сильная причина входить в этот рынок.
Такой причины в исследовании я не нашёл.

Последняя попытка: пусть CRM сама знает, какие адреса работают

После этого я попробовал соединить предварительную проверку и реальные события после отправки.
Гипотеза стала такой:

CRM постоянно знает, какие электронные адреса клиентов работают, а какие уже нет.

Для конкретности я взял Битрикс24.
Сценарий мог выглядеть так:

• новый адрес появился в CRM - система проверила его;
• менеджер отправил письмо;
• пришла ошибка доставки;
• система определила причину;
• адрес получил статус “не работает”;
• повторная отправка на явно несуществующий адрес прекращается;
• менеджер получает задачу найти новый контакт.

Этот вариант мне понравился намного больше предыдущих.
Он соответствует тому, что я вообще ищу в исследованиях автоматизации:

• есть понятное событие, запускающее действие;
• есть конкретные входные данные;
• есть проверяемое действие;
• есть изменение состояния бизнес-системы;
• есть возможность повторять решение между компаниями;
• не нужно перестраивать всю почтовую инфраструктуру.

Я провёл ещё одну широкую проверку уже вокруг Битрикс24: посмотрел вопросы пользователей, штатные возможности системы, готовые приложения, внешние сервисы проверки адресов и возможные варианты интеграции.

В исследованном сценарии я не нашёл штатного механизма, который автоматически превращал бы уведомление о недоставке в статус нерабочего адреса в CRM.
Технический разрыв я вижу.
Достаточно сильного рыночного разрыва пока нет.

Технически полезная функция ещё не означает продукт

Допустим:

1. менеджер отправил коммерческое предложение;
2. адрес клиента больше не существует;
3. сервер прислал уведомление о недоставке;
4. CRM не превратила это событие в изменение качества контакта;
5. адрес остался активным;
6. позже компания снова использовала его.

Это нормальная задача для автоматизации.
Я могу представить, как её решить.

Но это ещё не отвечает на более важные вопросы:

• как часто такое происходит в компании;
• сколько ручной работы создаёт;
• кто отвечает за последствия;
• сколько денег компания на этом теряет;
• замечает ли проблему руководитель;
• ищет ли решение;
• готов ли за него отдельно платить.

Это тот же фильтр, который я использую и в других исследованиях: как выбирать процесс для автоматизации.
Техническая возможность - только один из критериев.

ИИ в найденной задаче оказался почти не нужен

Это был ещё один неожиданный результат.

Я начинал исследование с вопроса, какую работу из почтовой инфраструктуры можно передать новому ИИ-сотруднику.
Но стандартные ошибки доставки писем лучше сначала обрабатывать обычными программными правилами.

Есть коды почтовых серверов, стандартные уведомления о недоставке и понятные классы ошибок.
Для них применение ИИ может только добавить ненужную сложность.
ИИ становится интереснее там, где ответ нужно понять по смыслу.

Например:

• сотрудник больше не работает в компании;
• человек находится в отпуске;
• теперь нужно писать другому сотруднику;
• адрес изменился;
• в автоматическом ответе указан новый контакт;
• из содержания письма нужно определить дальнейшее действие.

Это уже другая потенциальная функция:

автоматически понимать служебные ответы электронной почты и обновлять дальнейшие действия в CRM.

Но в текущем исследовании я её не проверял достаточно глубоко.
Поэтому для меня это новая гипотеза, а не найденный продукт.

Что получилось по всем проверенным направлениям

После нескольких итераций моя карта выглядит так.

Собственная почтовая инфраструктура

Реальная компетенция и реальная услуга.
Но как стандартизированный входной продукт - пока нет достаточного сигнала.

Полный контур холодных рассылок

Рынок существует.
По запросам холодный аутрич и email аутрич я увидел 119 и 97 точных показов за исследованный 30-дневный период.
Но сама работа слишком широкая и быстро превращается либо в большой программный продукт, либо в услугу привлечения клиентов.

Проверка электронных адресов

Атомарная задача есть.
Спрос есть.
Но рынок уже заполнен стандартными сервисами.
Я не вижу основания делать ещё один сервис проверки адресов.

Недоставленные письма -> CRM

Технически интересная и достаточно компактная автоматизация.
Но прямого поискового подтверждения самостоятельного продукта я не получил.

ИИ для технических ошибок доставки

В стандартных случаях он практически не нужен.
Обычная автоматизация проще и предсказуемее.

ИИ для смысловых служебных ответов

Выглядит интереснее.
Но пока это только следующая гипотеза, требующая отдельного исследования.

Я даже сформулировал пилот, но решил пока его не строить

Если бы я продолжал проверку недоставленных писем в Битрикс24, минимальный пилот выглядел бы так:

• один тип корпоративной почты;
• один Битрикс24;
• сбор уведомлений о недоставке;
• определение адреса;
• поиск контакта в CRM;
• установка статуса “адрес не работает”;
• задача ответственному менеджеру;
• исключение нерабочего адреса из следующих действий;
• простой отчёт.

Для проверки готовности платить я рассматривал тестовую цену 49 000 рублей за внедрение.
Это не рыночная цена и не готовый тариф.
Это цена, с которой можно было бы проверить, воспринимает ли компания проблему как достаточно ценную для оплаты.

Критерий продолжения я сформулировал так:
из 10 подходящих компаний

• минимум 5 признают проблему реальной;
• минимум 3 попросят расчёт;
• минимум 2 согласятся на платный пилот.

Такой тест дал бы мне намного более сильные доказательства, чем ещё сто поисковых запросов.
Но на текущем этапе я решил не тратить ресурс даже на него.
Предыдущие проверки пока не дают достаточно сильной причины ставить эту гипотезу выше других работ, которые я исследую.

Почему отсутствие поискового спроса не равно отсутствию проблемы

Здесь важно не переоценить результаты поиска.
Компания может никогда не вводить:
обработка недоставленных писем в Битрикс24

и всё равно регулярно сталкиваться с такой проблемой.

Поисковый спрос находится довольно низко в моей иерархии доказательств.
Сильнее него:

• реальный процесс внутри компании;
• повторяющиеся жалобы;
• наблюдаемая ручная работа;
• понятная стоимость;
• коммерческий запрос;
• оплаченный пилот.

Поэтому я не утверждаю, что функции недоставленное письмо -> обновить CRM никому не нужны.
Мой вывод уже:

я не получил достаточно доказательств, чтобы сейчас превращать эту техническую возможность в отдельный продукт.

Это разные утверждения.

Почему я остановил эту ветку

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

• многолетняя экспертиза;
• собственная инфраструктура;
• большой ежедневный объём;
• понятные технические проблемы;
• данные;
• интеграции;
• CRM;
• возможность применить ИИ.

Но я искал не место, где можно применить технологию.
Я искал повторяющуюся работу бизнеса.

У неё должен быть понятный владелец, заметная стоимость текущего выполнения, достаточно высокая частота, возможность стандартизации и причина платить за автоматизацию.
В этой ветке я пока такую комбинацию не нашёл.

Поэтому остановил её так же, как ранее остановил гипотезу автоматизации закупок.

Для меня это не провал исследования.
Это и есть его задача.

Лучше потратить время на несколько последовательных проверок и отказаться от идеи, чем построить технически красивого цифрового сотрудника, а потом выяснять, кому он нужен.

Сильная собственная экспертиза помогает увидеть больше вариантов решения.
Но она не создаёт спрос автоматически.

Именно это я в итоге вынес из исследования корпоративной электронной почты.