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

Проблемы начинаются со второго письма.

Представьте, что один клиент присылает четыре файла. Пятая выписка из банка так и не приходит. Архив чеков присылают, но он охватывает не тот месяц, поэтому команда его отклоняет. Отчет по зарплате на самом деле пришел три дня назад через Slack, и кто-то его уже обработал. Документ по инвентаризации этому клиенту вообще не требуется — эту деталь вы узнали только после того, как ушло первое сообщение. Если вы повторно отправите исходный шаблон, вы снова запросите пять файлов. Четыре из этих запросов теперь бессмысленны. Один — вводит в заблуждение. Формулировки в порядке. Просто у письма нет памяти.

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

Проблемы начинаются тогда, когда следующее сообщение зависит от событий, произошедших после первого письма. Шаблон по-прежнему показывает исходный список. Он не знает, что вчера пришла выписка из банка. Он не знает, что отчет по зарплате был отклонен. Эти данные находятся в почтовом ящике, возможно, в нескольких, а у приложения, генерирующего напоминание, нет возможности их прочитать.

Когда статуса «открыто» недостаточно

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

  • Выписка из банка: Отсутствует. Клиент её не прислал.
  • Архив чеков: Загружен, но не проверен. Он лежит в папке и ждет внутренней проверки.
  • Отчет по зарплате: Отклонен. Клиент что-то прислал, но это был не тот формат или не тот расчетный период.
  • Отчет о продажах: Получен по другому каналу. Он пришел через Slack, по телефону или в бумажном виде, и ваша команда его уже зарегистрировала.
  • Документ по инвентаризации: Не требуется. Этому клиенту не нужно его предоставлять, и система должна перестать его запрашивать.

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

Создавайте только то, что необходимо

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

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

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

Если загрузка была отклонена, в напоминании об этом следует сообщить и объяснить причину. Нельзя молча возвращать документ в общий список, как будто клиент просто забыл его отправить. Клиент знает, что он что-то загрузил; попытки сделать вид, что это не так, выставляют вас неорганизованными.

Тест на передачу дел

Есть простой способ понять, нужна ли вам эта дополнительная модель данных. Спросите себя:

Сможет ли другой член команды подхватить этот запрос, не перечитывая всю цепочку писем?

Для одного файла это не имеет значения. Для ежемесячных повторяющихся запросов с множеством переменных это имеет огромное значение. Если основной контакт в отпуске, сможет ли коллега за считанные секунды понять, чего не хватает? Сможет ли менеджер определить, выполнил ли клиент все обязательства, не открывая десять писем и три общие папки? Если единственный способ зафиксировать отказ — это четвертое сообщение в ветке, погребенное под подписями и пересылками, значит, ваша система заставляет людей выполнять работу, которую должна выполнять база данных.

Шаблоны улучшают сообщение. Отслеживаемый запрос сохраняет историю. Один отвечает за то, как вы говорите. Другой — за то, что вы знаете.

Запросы, а не скрипты

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

Это