Как автоматизировать напоминания об оплате

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

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

Сначала определите, что и когда оплачивают

Для напоминания нужен действующий счёт с понятным сроком и подтверждённым остатком. Срок берите из договорённостей с клиентом. Настройка «напомнить за два дня» управляет сообщением и сама по себе не меняет дату оплаты.

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

Различайте счёт и отдельную попытку заплатить. Клиент мог открыть платёжную ссылку, закрыть страницу и перечислить деньги по реквизитам. Отмена первой попытки не сообщает, что счёт отменён или денег нет. У ЮKassa статусы pending, waiting_for_capture, succeeded и canceled относятся к платежу; в двухстадийном сценарии авторизованные деньги ещё ожидают списания. Эти состояния описаны в документации процесса платежа.

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

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

Соберите данные для одного счёта

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

В синтетическом примере счёт составляет 10 000 рублей, подтверждённая частичная оплата - 3 000 рублей. Остаток равен 7 000 рублей. Все эти суммы вымышлены. Формулу выполняет программа: сумма счёта минус подтверждённые оплаты, с нижней границей ноль. Возврат, переплата или перенос оплаты между счетами должны иметь собственные правила учёта; их нельзя молча свести к ещё одному письму с долгом.

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

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

Как устроить цепочку событий

Цепочка начинается с изменения счёта, подтверждения оплаты или наступления выбранного этапа. Каждое событие приводит к проверке текущего состояния. Результат проверки - подготовить проект, пропустить контакт либо передать случай человеку.

Событие «этап наступил» не является разрешением отправить письмо по вчерашним данным. Между этими действиями клиент может оплатить, сотрудник - согласовать перенос срока, а источник - перестать отвечать. Поэтому подготовленный текст остаётся проектом до повторной проверки перед действием.

Последовательность для одного напоминания:

1. Прочитать счёт и подтверждённые оплаты из выбранного источника.
2. Проверить остаток, срок, состояние счёта, паузу и связь с адресатом.
3. Найти в постоянном журнале запись этого счёта, периода и этапа.
4. При разрешённом новом этапе сохранить проект сообщения и основание подготовки.
5. Непосредственно перед действием ещё раз прочитать актуальное состояние.
6. Отменить устаревший проект либо выполнить предусмотренную попытку через канал.
7. Сохранить фактический результат попытки и отдельно учитывать доступные события доставки.

В локальном примере есть четыре части: источник счёта, проект с журналом, повторное чтение и заглушка канала - часть программы, которая возвращает условный ответ без реальной отправки. Изменение оплаты, пауза или ошибка могут остановить проект. При unknown, то есть неизвестном исходе попытки, случай разбирают вручную. Состояние accepted означает, что заглушка сообщила о принятии запроса; реальное сообщение в этом примере не отправляется. В проверке использованы 16 сценариев и 41 событие; повтор создал ноль новых проектов и выполнил ноль вызовов заглушки.

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

Выберите этапы и время контакта

Этапы должны соответствовать действующим договорённостям и принятому способу общения с клиентом. Можно отдельно описать сообщение до срока, после срока и после подтверждённой частичной оплаты. Добавление каждого этапа требует понятного условия и правила остановки.

В приложенной демонстрации этап до срока становится подходящим за два календарных дня. Синтетическое время - 4 октября 2026 года, 12:00, часовой пояс Europe/Moscow; срок вымышленного счёта - 6 октября, 18:00 в том же поясе. Вход также содержит настройку этапа после срока со смещением два дня. Эти значения показывают устройство правила. Они не устанавливают периодичность для вашего бизнеса; этап после срока в приложенном прогоне не испытывался.

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

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

Время попытки и день этапа различаются. Если процесс запущен в 12:00 и повторён в 12:05, это тот же этап. Ключ, построенный из текущей минуты, создаст две разные записи и позволит повтор. Граница суток тоже должна вычисляться в выбранном часовом поясе, независимо от настроек компьютера исполнителя.

Три вежливых шаблона напоминаний

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

До срока уместно нейтральное напоминание, если такой контакт предусмотрен вашим процессом. Не называйте клиента должником и не обозначайте срок как просроченный. Ссылка должна вести к нужному счёту; реквизиты берутся из утверждённого источника.

Тема: Напоминание о сроке оплаты счёта [номер]

Здравствуйте, [имя].

Напоминаем: срок оплаты счёта [номер] за [предмет / период] - [дата].
По нашим подтверждённым данным к оплате осталось [остаток] рублей.
Оплатить можно здесь: [проверенная ссылка на счёт].

Если вы уже перевели деньги или видите расхождение, ответьте на это сообщение.
Проверим поступление и данные счёта.

[имя ответственного / организация]
[контакт для ответа]

После срока опирайтесь на последнюю сверку и просите уточнить ситуацию. Сам факт запаздывания учёта не даёт основания усиливать тон. Формулировка о подтверждённых данных оставляет место для платежа, который ещё не сопоставлен со счётом.

Тема: Уточнение оплаты по счёту [номер]

Здравствуйте, [имя].

Срок оплаты счёта [номер] за [предмет / период] был [дата].
После сверки на [дата и время проверки] остаток к оплате составляет [остаток] рублей.
Ссылка на счёт: [проверенная ссылка].

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

[имя ответственного / организация]

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

Тема: Остаток по счёту [номер]

Здравствуйте, [имя].

По счёту [номер] за [предмет / период] подтверждено поступление [оплачено] рублей.
Спасибо. Остаток составляет [остаток] рублей, согласованный срок оплаты - [дата].
Ссылка на счёт: [проверенная ссылка].

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

[имя ответственного / организация]
[контакт для ответа]

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

Как ограничить повторы одного этапа

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

DEMO-INVOICE | 2026-10 | before_due

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

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

Для следующего периода появляется другой ключ. Октябрьское напоминание не должно навсегда блокировать ноябрьский счёт. В приложенном наборе есть отдельная проверка нового периода и отмены старого подготовленного проекта при повторном чтении.

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

Ключ внешнего API имеет свой контракт. Например, справка Unisender Go описывает отклонение повторного запроса с тем же idempotence_key в течение одной минуты. Это короткое окно не заменяет историю этапа, которая нужна и при повторе завтра. Ограничение проверено по справочнику Web API на 4 октября 2026 года. Перед подключением сверяйте контракт вашего фактического канала.

Повторно проверьте счёт перед действием

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

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

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

Повторное чтение уменьшает риск устаревшего текста, но оставляет короткое окно между проверкой и внешней отправкой. Клиент может заплатить именно в этот момент. Обещание «напоминание никогда не совпадёт с оплатой» потребовало бы подтверждения, которого локальный пример не даёт.

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

Что означает результат канала

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

Эта таблица описывает предлагаемый журнал. Набор событий у разных каналов отличается. При успешном sendMessage Telegram возвращает объект Message; контракт Bot API не подтверждает прочтение клиентом. У почтовых каналов также нужно отдельно выяснить, что означает конкретное событие, и не подписывать accepted словом «доставлено».

Для unknown назначьте ответственного и порядок разбора. Он ищет попытку по сохранённым идентификаторам, проверяет данные канала и актуальную оплату. Пока исход не установлен, программа не создаёт новую попытку с другим ключом «на всякий случай». Именно это поведение проверяется в синтетическом наборе.

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

Запустите локальную демонстрацию

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

Для запуска нужен Python 3.9 или новее и системная база часовых поясов с Europe/Moscow. Скрипт использует стандартную библиотеку. Он читает локальный JSON, последовательно обрабатывает события и пишет локальные файлы. Заглушка возвращает заранее заданное состояние; сетевых вызовов в коде нет.

Распакуйте архив в отдельный каталог, откройте в нём терминал и выберите новое имя файла состояния. Для первого запуска fresh-state.json не должен существовать. Сохранённый demo-state.json нужен для просмотра выполненного прогона и проверки повторного запуска.

python3 demo-run.py --input demo-input.json --state fresh-state.json --result first-output.json --expected demo-expected.json

При совпадении с ожиданиями команда завершится с кодом 0 и покажет passed: true. В выполненном прогоне обработано 16 сценариев и 41 событие, создано 13 проектов, выполнено два обращения к локальной заглушке. Заглушка один раз вернула смоделированное состояние accepted и один раз unknown. Это результаты программы, реальной отправки за ними нет.

Затем повторите тот же вход с тем же файлом состояния:

python3 demo-run.py --input demo-input.json --state fresh-state.json --result replay-output.json --replay-check

Фактический повтор прошёл контроль: ноль новых проектов и ноль вызовов заглушки. При несовпадении с ожиданиями скрипт вернёт код 1 и запишет причины в failures. Сопоставьте свои результаты с demo-result.json и demo-replay-result.json; состав и целостность архива проверяются по demo-files.sha256.

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

Как принять первый рабочий сценарий

Приёмка начинается с согласованной таблицы случаев и ограниченного испытания в вашей системе. Сначала проверьте решения и проекты на синтетических данных. Затем отдельно испытайте подключённый источник и канал с заранее выбранным тестовым адресатом.

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

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

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

Первый реальный запуск ограничьте согласованным объёмом и наблюдением сотрудника. У него должна быть возможность остановить будущие этапы. Успешное принятие запроса каналом фиксируется отдельно от события доставки. Оплату после напоминания тоже нельзя автоматически считать его заслугой: клиент мог планировать перевод независимо от письма.

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

Где здесь нужна нейросеть

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

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

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

Источники

Технические контракты проверены по первичным документам 4 октября 2026 года. Они подтверждают описанные состояния своих систем; рекомендации по цепочке и выполненный синтетический пример являются отдельной частью гайда.

• ЮKassa: процесс платежа.
• ЮKassa: входящие уведомления и проверка актуального статуса.
• Unisender Go: справочник Web API и окно ключа идемпотентности.
• PostgreSQL 18: ограничения уникальности.
• Telegram Bot API: контракт sendMessage.

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