Просроченная задолженность становится проблемой не только тогда, когда клиент долго не платит. Для компании не менее важно вовремя заметить сам факт просрочки и начать регулярную коммуникацию с клиентом.
На практике информация о задолженности обычно уже есть в 1С: известен контрагент, документ расчетов, сумма, срок оплаты, поступившие платежи и остаток долга. Но уведомление о просроченной задолженности часто остается отдельной ручной операцией. Сотрудник должен обнаружить просрочку, проверить данные, найти контакт клиента, подготовить письмо и отправить его.
Если таких клиентов много, процесс становится зависимым от внимания конкретных сотрудников. Одному клиенту напомнят на следующий день после наступления срока, другому — через неделю, а по части задолженности сообщение вообще не будет отправлено.
Поэтому задача автоматизации состоит не просто в отправке писем. Необходимо связать состояние расчетов в 1С с понятным правилом коммуникации:
наступила просрочка → проверены данные задолженности → определен получатель → сформировано персонализированное сообщение → письмо отправлено автоматически или после проверки → результат зафиксирован в журнале.
Так уведомление о задолженности становится частью регулярного процесса работы с расчетами, а не разовой задачей менеджера.
Когда задолженность становится основанием для уведомления
Сам факт наличия дебиторской задолженности еще не означает просрочку. У клиента может быть согласованный срок оплаты через несколько дней или недель после поставки.
Для автоматической коммуникации необходимо определить момент, когда обязательство действительно вышло за установленный срок.
Например, если по документу срок оплаты установлен на 15 сентября, то до этой даты сообщение может носить характер обычного напоминания о предстоящем платеже. После наступления установленного срока возникает другой сценарий — уведомление о просрочке оплаты.
Именно поэтому для автоматизации важна не просто сумма задолженности, а сочетание нескольких данных:
- клиент и его контактные данные;
- документ или основание задолженности;
- первоначальная сумма обязательства;
- поступившая оплата;
- текущий остаток;
- установленный срок оплаты;
- количество дней после наступления срока;
- ответственный сотрудник;
- дополнительные признаки, влияющие на способ коммуникации.
Набор доступных данных зависит от используемой конфигурации 1С и организации учета.
Например, официальный материал фирмы «1С» по «1С:Бухгалтерии 8» подтверждает, что программа позволяет анализировать задолженность покупателей по срокам долга, выделять просроченную задолженность, учитывать установленные сроки оплаты и формировать напоминания покупателям.
Это важно разделять с задачей событийной автоматизации. Штатные возможности конкретной конфигурации 1С обеспечивают учет и доступные в ней операции с задолженностью. А отдельный механизм коммуникаций нужен тогда, когда компания хочет по своим правилам автоматически отслеживать нужные состояния и системно формировать сообщения клиентам.
Уведомление о просрочке — это не массовая рассылка
Уведомление о просроченной задолженности относится к транзакционной коммуникации.
Причина отправки такого сообщения — не маркетинговая кампания и не необходимость обратиться ко всей клиентской базе. Сообщение появляется потому, что произошло конкретное бизнес-событие: у конкретного клиента по конкретному обязательству наступил срок оплаты, а необходимая сумма не поступила.
Поэтому содержание каждого уведомления должно определяться фактическими данными учета.
Вместо общего текста «У вас имеется задолженность» клиенту можно сообщить, например, номер документа, дату оплаты по условиям расчетов, первоначальную сумму и текущий неоплаченный остаток.
Такое сообщение полезнее и для клиента, и для сотрудника компании: сторонам проще понять, о каком обязательстве идет речь.
Информационные и чувствительные сообщения о задолженности
Не все автоматические уведомления о задолженности следует обрабатывать одинаково.
Есть стандартные информационные коммуникации, содержание которых практически полностью определяется учетными данными. Например: срок оплаты наступил вчера, по документу числится неоплаченный остаток, клиенту направляется нейтральное напоминание.
Для такого сценария может быть допустима полностью автоматическая отправка, если компания заранее утвердила условия запуска и текст сообщения.
Но по мере увеличения срока или суммы задолженности коммуникация может становиться более чувствительной.
Например, отдельного контроля могут требовать сообщения крупному клиенту, уведомления по значительной для компании сумме, ситуации с частичной оплатой, измененными условиями расчетов или наличием договоренности между клиентом и менеджером, которая еще не отражена в учетной системе.
В таких случаях автоматизация не обязательно означает автоматическую отправку. Система может подготовить сообщение с заполненными данными, а ответственному сотруднику остается проверить его, при необходимости изменить текст и подтвердить отправку.
Получается два режима работы.
Полностью автоматический: правило однозначно, данные достаточны, сообщение стандартное и не требует оценки сотрудника.
С предварительной проверкой: данные можно сформировать автоматически, но решение о содержании или самой отправке должен принять человек.
Такой подход особенно важен для работы с задолженностью, поскольку автоматизация не должна исключать коммерческий контекст отношений с клиентом.
Как может выглядеть последовательность уведомлений
Работу с просроченной задолженностью лучше рассматривать не как единственное письмо, а как последовательность событий.
Конкретные сроки компания устанавливает самостоятельно в соответствии со своими процессами и договоренностями с клиентами. Универсального интервала, подходящего для всех организаций, нет.
Условный сценарий может выглядеть следующим образом.
До наступления срока оплаты
В 1С приближается установленная дата платежа. Клиенту отправляется информационное напоминание о сроке оплаты.
Это еще не уведомление о просроченной задолженности. Его задача — заранее сообщить о предстоящем платеже.
Срок наступил, оплаты нет
После наступления срока система проверяет состояние расчетов. Если необходимая сумма не поступила, возникает основание для первого уведомления о просрочке.
Сообщение остается нейтральным: указывается обязательство, срок и текущий остаток.
Задолженность сохраняется
Если после первого сообщения оплата не поступила, правило может повторно проверить задолженность через установленный компанией период.
В зависимости от суммы, клиента и продолжительности просрочки новое сообщение может либо отправиться автоматически, либо быть передано ответственному сотруднику для проверки.
Получена частичная оплата
Здесь важно не отправлять первоначальную сумму долга повторно.
Система должна использовать актуальное состояние расчетов и подставлять именно оставшуюся задолженность.
Например, если клиент должен был оплатить 150 000 рублей и после наступления срока перечислил 100 000 рублей, следующее сообщение должно учитывать остаток 50 000 рублей, если именно такие данные отражены в 1С.
Получена полная оплата
После отражения полной оплаты условие просрочки перестает выполняться.
Следующее уведомление о задолженности формироваться не должно.
Это одна из причин, почему события и правила коммуникации целесообразно связывать непосредственно с актуальными данными учетной системы, а не вести отдельный список должников вручную.
Какие данные нужно подставлять в сообщение из 1С
Хорошее напоминание о задолженности клиенту должно давать достаточно информации, чтобы получатель мог идентифицировать обязательство и проверить его у себя.
При этом не следует переносить в письмо все данные из учетной системы.
Практически полезный набор обычно состоит из названия или имени клиента, номера и даты документа, срока оплаты, суммы обязательства, уже поступившей оплаты при необходимости, актуального остатка задолженности и контактов ответственного сотрудника.
Если расчеты ведутся по нескольким документам, нужно заранее определить бизнес-правило: отправлять отдельное сообщение по каждому обязательству или формировать сводную информацию по клиенту.
Это уже не вопрос текста шаблона. От такого решения зависит само правило формирования коммуникации.
Пример уведомления о просроченной задолженности
Для первого стандартного уведомления обычно достаточно нейтрального информационного текста.
Пример сообщения
Здравствуйте, Александр.
По данным нашей учетной системы на 18 сентября не поступила полная оплата по счету № 1845 от 1 сентября.
Срок оплаты: 15 сентября.
Сумма счета: 120 000 руб.
Поступившая оплата: 80 000 руб.
Остаток к оплате: 40 000 руб.
Пожалуйста, проверьте состояние оплаты со своей стороны. Если платеж уже отправлен, это сообщение можно считать информационным.
По вопросам расчетов вы можете связаться с вашим менеджером Анной Петровой.
Такой шаблон не требует вручную переписывать сумму и реквизиты для каждого клиента. Они должны подставляться из актуальных данных 1С.
Сам текст при этом остается утвержденным компанией.
Важно, что это пример деловой коммуникации, а не юридический шаблон требования о взыскании задолженности. Формальные претензии, требования, начисление санкций и другие юридически значимые действия требуют отдельного процесса и выходят за рамки задачи обычного автоматического уведомления.
Как превратить данные 1С в автоматические уведомления о задолженности
Для регулярной работы недостаточно один раз подготовить шаблон письма. Необходимо определить правило, которое будет решать, когда и кому этот шаблон использовать.
В простом сценарии логика выглядит так:
Событие или состояние: срок оплаты прошел, остаток задолженности больше нуля.
Получатель: контактное лицо клиента, для которого в учетной системе определен соответствующий адрес.
Содержание: номер документа, срок оплаты, сумма, оплаченная часть, остаток, контакт ответственного сотрудника.
Режим: автоматическая отправка первого информационного сообщения либо предварительная проверка менеджером.
Результат: факт формирования и отправки фиксируется в журнале.
Алертариум используется именно на этом уровне — между учетным событием и клиентской коммуникацией.
Он не заменяет учет задолженности в 1С. Источником информации остается учетная система клиента. Алертариум применяет настроенное правило, подставляет необходимые данные в шаблон и формирует персонализированное сообщение.
В зависимости от сценария оно может быть отправлено автоматически или сначала передано сотруднику для проверки.
Почему правило должно проверять задолженность непосредственно перед отправкой
Между наступлением срока оплаты и моментом формирования сообщения ситуация может измениться.
Клиент мог перечислить деньги. Могла поступить частичная оплата. Сотрудник мог изменить срок оплаты в соответствии с новой договоренностью. Задолженность могла быть скорректирована в учете.
Поэтому автоматическое письмо о задолженности нельзя строить только по старому списку, сформированному несколько дней назад.
Перед созданием сообщения нужно использовать актуальное состояние данных, на которых основано правило.
Принцип особенно важен при повторных уведомлениях. Каждое новое сообщение должно отражать текущее состояние расчетов, а не копировать сумму из первого уведомления.
Что проверять перед полной автоматизацией отправки
Чем однозначнее правило, тем проще автоматизировать его полностью.
Например, компания может определить, что первое информационное уведомление при небольшой стандартной просрочке всегда отправляется автоматически, если в 1С заполнены все необходимые данные и нет специальных признаков, требующих участия менеджера.
Если же ситуация выходит за установленный сценарий, письмо можно не отправлять сразу.
Алертариум может сформировать готовое сообщение с данными клиента и задолженности, после чего сотрудник проверит его.
Такой механизм позволяет автоматизировать рутинную подготовку сообщений, не превращая любые действия с проблемной задолженностью в полностью автоматический процесс.
Зачем нужен журнал уведомлений
Автоматические уведомления о задолженности должны быть контролируемыми.
Недостаточно знать, что в системе существует правило «при просрочке отправить письмо». Руководителю и ответственному сотруднику важно понимать, было ли правило выполнено применительно к конкретному клиенту.
Поэтому результат коммуникации должен фиксироваться в журнале.
В нем имеет смысл сохранять сведения о том, по какому событию было создано сообщение, когда оно было сформировано, кому предназначалось, какой шаблон использовался, требовалась ли проверка сотрудником и было ли сообщение отправлено.
Так можно отделить состояние расчетов от истории коммуникаций.
1С продолжает отвечать за учетные данные и состояние задолженности, а журнал коммуникаций показывает, что компания сообщала клиенту по поводу этого состояния.
Отправка email остается в локальной 1С
При использовании Алертариума для email-коммуникаций важно разделять управление правилами и фактическую отправку почты.
Учетные данные почтового сервера клиента и сама отправка email остаются в локальной 1С организации.
Облачная часть может использоваться для централизованного управления правилами, шаблонами и настройками коммуникаций, однако она не должна становиться почтовым сервером, который отправляет письма от имени клиента.
Таким образом, схема остается понятной: данные и почтовая учетная запись находятся в инфраструктуре клиента, а правила определяют, при каком событии какое сообщение должно быть подготовлено.
Чем событийная автоматизация отличается от задачи менеджеру
Другой распространенный вариант работы с задолженностью — поручить менеджеру самостоятельно контролировать список клиентов.
В этом случае учетная система дает информацию, а коммуникация начинается только после действия сотрудника.
Он должен открыть отчет, заметить новую просрочку, определить клиента, подготовить письмо и отправить его.
При событийной автоматизации начальной точкой становится изменение данных.
Если правило определяет, что возникла просроченная задолженность, система сама инициирует необходимую коммуникацию.
Менеджер подключается только там, где это предусмотрено процессом.
Это не замена CRM. CRM может использоваться для ведения отношений с клиентом, задач, сделок и работы сотрудников. Алертариум решает другую задачу: позволяет стандартной коммуникации запускаться самим бизнес-событием в 1С.
С чего начинать автоматизацию уведомлений о задолженности
Необязательно сразу автоматизировать весь процесс работы с дебиторской задолженностью.
Практичнее сначала определить один понятный сценарий — например, первое информационное уведомление после наступления срока оплаты.
Для него нужно установить источник данных, условие просрочки, получателя, необходимые реквизиты сообщения, шаблон, режим отправки и правило остановки уведомлений после получения оплаты.
После проверки такого сценария можно переходить к повторным сообщениям, частичной оплате и ситуациям, где требуется согласование сотрудником.
Так автоматические уведомления о задолженности постепенно превращаются из набора отдельных писем в управляемую последовательность коммуникаций.
Уведомление о просроченной задолженности как часть регулярного процесса
Основная задача автоматизации — не отправить клиенту больше напоминаний. Задача состоит в том, чтобы каждое необходимое сообщение появлялось в нужный момент и основывалось на актуальном состоянии расчетов.
Для этого достаточно понятной последовательности:
состояние задолженности в 1С → правило → персонализированное сообщение → автоматическая отправка или проверка сотрудником → журнал.
Так компания перестает зависеть от того, открыл ли менеджер сегодня отчет по дебиторской задолженности и вспомнил ли написать конкретному клиенту.
При этом чувствительные ситуации остаются под контролем сотрудника, а стандартные уведомления о просрочке оплаты можно выполнять по единым правилам.
Автоматизируйте сообщения по событиям 1С
Автоматизируйте клиентские коммуникации в 1С с Алертариумом. Система сама создаст и отправит нужное сообщение по событию, сократит ручную работу менеджеров и ускорит информирование клиентов. Начните с нескольких ключевых сценариев сейчас.