n8n для контроля дебиторской задолженности: напоминания с подтверждением менеджера

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

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

Один счёт и пять его состояний

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

Обратите внимание: между «подтверждено» и «отправлено» стоит ещё одна проверка. Именно её чаще всего пропускают, потому что подтверждение менеджера выглядит как финальная печать. На деле оно подтверждает только то, что текст приемлем, а не то, что долг всё ещё существует.

Откуда брать задолженность и что считать просрочкой

Первый шаг workflow начинается с запуска по расписанию. Здесь есть техническая тонкость: по документации n8n, Schedule Trigger работает только в опубликованном workflow и опирается на часовой пояс либо самого workflow, либо экземпляра (документация Schedule Trigger). Для дебиторки это важнее, чем кажется. «Каждое утро в девять» — это девять по чьему времени? Если сервер живёт в одной зоне, а бухгалтерия и клиенты в другой, срез задолженности может оказаться вчерашним или завтрашним относительно того, как его видит менеджер. Часовой пояс стоит задать явно в настройках workflow и проверить, что именно он применился, а не полагаться на значение по умолчанию.

Теперь о самом запросе. Просрочка — это не просто «дата оплаты меньше сегодняшней». Нужно отделить три группы счетов:

• счета, по которым платежа нет совсем и срок действительно прошёл;
• счета, по которым платёж есть, но он ещё не сопоставлен со счётом (пришёл на расчётный счёт, не разнесён в учёте);
• счета, по которым в учёте стоит пометка о споре, рассрочке или переносе срока.

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

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

Разберём срез на том же счёте. В среду в 09:00 запрос возвращает строку: счёт, срок оплаты во вторник, остаток 84 000, пометок о споре нет, метка среза «среда, 09:00». Если в этот момент выписка уже лежит на расчётном счёте, но не разнесена, учёт её не видит, и счёт выглядит чистым кандидатом. Поэтому метку среза полезно хранить не как текст в письме, а как отдельное поле карточки: позже по ней можно вычислить возраст данных и решить, нужна ли дополнительная осторожность, например при ожидании дольше одного рабочего дня.

Ещё одна причина хранить идентификаторы, а не готовые письма: идентификатор позволяет через сутки или через два заново спросить учёт о том же счёте. Готовый текст такой возможности не даёт, он описывает прошлое. Тем же принципом удобно пользоваться при расчёте границ суток: запуск Schedule Trigger привязан к часовому поясу, поэтому «просрочено на сегодня» нужно считать в той же зоне, которая задана для workflow, иначе счёт со сроком «вторник» может оказаться в списке на несколько часов раньше, чем его видит бухгалтерия (документация Schedule Trigger).

Черновик: адресат, сумма и текст без сюрпризов

Следующий этап — превратить кандидата в черновик. В нём три части, и у каждой свои ловушки.

Адресат. Контакт для напоминаний о счетах — не то же самое, что основной контакт клиента. Если в справочнике есть поле «получатель закрывающих документов» или «бухгалтерия», берите его. Если контакта нет, это не повод подставлять первый попавшийся адрес: карточка должна получить статус «нет адресата» и уйти менеджеру как задача, а не как письмо на согласование. Отдельно проверьте, не помечен ли контакт как отписавшийся или не требующий деловой переписки. Эти правила ваши внутренние; юридические требования к взысканию и коммуникации с должниками в статье не разбираются, их стоит уточнять у юриста компании.

Сумма. Здесь легко ошибиться на частичной оплате. Счёт на 84 000, из которых оплачено 50 000, — это долг 34 000, а не 84 000. Если учётная система отдаёт остаток, используйте остаток. Если отдаёт только сумму счёта и список платежей, остаток считается в workflow, и расчёт лучше показать в черновике прямо: «выставлено — оплачено — остаток». Менеджер видит арифметику и сразу замечает расхождение.

Текст. Шаблон с подстановкой полей достаточен. Тон выбирайте по числу уже отправленных напоминаний по этому счёту: первое письмо и третье должны звучать по-разному. Для этого в карточке хранится счётчик попыток, а не только факт «напоминали».

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

Передача решения: что на самом деле делает Wait

Теперь самое интересное. Менеджер должен ответить, а workflow — подождать. В n8n для этого есть узел Wait. По документации, он приостанавливает выполнение и сохраняет данные в базе, а продолжить можно по времени, по HTTP-вызову или после отправки формы (документация Wait). Для согласования подходят два последних способа: менеджер получает ссылку и либо открывает форму с кнопками решения, либо переходит по адресу, который вызывает возобновление.

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

Полезно сопоставить, что происходит с одним счётом, пока выполнение стоит на узле Wait. Данные карточки, записанные в момент остановки, остаются прежними: остаток 84 000, адрес получателя, текст письма. Тем временем реальный мир движется: в четверг разносится выписка, в учёте остаток становится нулевым, а у ожидающего выполнения по-прежнему лежит 84 000. Расхождение растёт ровно столько, сколько менеджер не отвечает, и узел ничего об этом не сообщит, потому что его задача состоит в сохранении данных и возобновлении после сигнала: по времени, по HTTP-вызову или после отправки формы (документация Wait).

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

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

Что именно показывать менеджеру в запросе:

• название клиента, номер счёта и остаток;
• полный текст письма в том виде, в каком он уйдёт;
• время, на которое снят срез задолженности;
• номер попытки по этому счёту;
• варианты решения: отправить, отложить, отменить, и поле для причины.

Отметка времени среза здесь не декор. Менеджер, увидев «данные на среду, 09:00», а сам открыв письмо в пятницу, получит сигнал, что картина могла измениться. Это лёгкая подсказка человеку, но не замена автоматической проверки, о которой пойдёт речь ниже.

Решение подтверждено, но долг мог исчезнуть

Вернёмся к нашему счёту. Менеджер в пятницу нажал «отправить». Workflow возобновился и держит в руках данные от среды. Что делать дальше? Не отправлять сразу.

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

1. Остаток. Запросите по идентификатору счёта текущий остаток. Если он нулевой, карточка уходит в «отменено: оплачено». Если он изменился, текст нельзя отправлять как есть: сумма в письме уже неверна.
2. Статус спора и переноса. Если за время ожидания в учёте появилась пометка о рассрочке или споре, напоминание теряет смысл.
3. Допустимость контакта. Адрес мог быть заменён, клиент мог отписаться, менеджер мог поставить паузу на все письма по этому клиенту.

Результат проверки удобно свести к трём исходам:

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

Для нашего счёта на 84 000 проверка в пятницу показывает остаток ноль, потому что в четверг выписка наконец разнеслась. Карточка закрывается со статусом «отменено: оплата поступила после подготовки». Письмо не уходит. Менеджер видит в журнале запись, что его «да» не превратилось в отправку, и причину.

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

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

Когда менеджер молчит, отказывает или отвечает слишком поздно

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

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

Молчание. Wait позволяет возобновлять выполнение по времени, поэтому у ожидания можно задать предел. Если ответа нет, скажем, два рабочих дня, workflow продолжается по ветке «не получено решение». Важно, что именно произойдёт на этой ветке. Отправить письмо «по умолчанию» было бы подменой согласования: молчание не есть согласие. Безопаснее два действия: напомнить менеджеру и, если ответа по-прежнему нет, закрыть карточку статусом «не согласовано» с пометкой для руководителя или передать её другому ответственному. Тогда просроченное согласование превращается в видимую задачу, а не в тихо накапливающуюся очередь.

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

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

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

Один счёт, три варианта развития

Соберём всё вместе на нашем счёте на 84 000 с тремя возможными историями.

История первая: всё спокойно. Среда, 09:00: счёт попадает в кандидаты, к утру создан черновик. Менеджер открывает запрос в среду же и одобряет. Workflow возобновляется, перепроверяет остаток: 84 000, споров нет, контакт допустим. Письмо уходит, карточка получает статус «отправлено» и счётчик попыток увеличивается.

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

История третья: частичная оплата. Пока запрос ждал менеджера, клиент перевёл 50 000. Остаток 34 000. Workflow не отправляет прежний текст, а создаёт обновлённый черновик с новой суммой и возвращает менеджеру. Старое «да» помечается как относящееся к устаревшему тексту, новое согласование — отдельное.

Во всех трёх историях Wait делал одно и то же: хранил данные и ждал сигнала. Различие создавала проверка после сигнала. Это и есть центральная мысль схемы: ожидание хранит решение, а свежесть данных каждый раз заново подтверждается источником.

Что записывать, чтобы потом разбираться

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

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

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

Хранилище карточек и сам n8n должны работать там, где вы контролируете среду и можете хранить данные. Если вы разворачиваете n8n самостоятельно, подойдёт обычный VPS с root-доступом; в каталоге MAATRIX есть предложение с установкой n8n, а точное состояние наличия и операционной системы проверяется в форме заказа. Для такой задачи нагрузка невелика: это периодические запросы к учётной системе и ожидающие выполнения, а не потоковая обработка. Какой тариф выбрать, зависит от числа параллельных ожиданий и других workflow на той же машине, и это стоит оценить замером на своих данных.

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

Лучшее письмо — то, которое не ушло

Легко измерять такую автоматизацию числом отправленных напоминаний. Но это ложная метрика: рост числа писем может означать и рост дисциплины, и рост ошибок. Куда честнее смотреть на карточки, закрытые статусом «отменено: оплата поступила» или «отменено: изменилась сумма». Каждая такая карточка — случай, когда схема заметила расхождение между тем, что знали вчера, и тем, что известно сегодня, и избавила клиента от требования, а менеджера от неловких извинений.

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