Просроченная дебиторская задолженность: как настроить маршрут ответственности и эскалации в CRM

С какого факта начинается маршрут

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

Это сценарная ситуация, а не описание проекта НТА. На ней удобно разделить два результата: подтвердить состояние расчётов и организовать действия сотрудников. Здесь мы рассматриваем второй результат. К началу маршрута финансовая функция уже проверила обязательство и признала его просроченным для внутренней работы. CRM получает этот факт вместе с основанием, а не устанавливает долг по переписке менеджера.

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

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

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

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

Почему нужны три разных срока

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

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

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

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

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

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

От списка долгов к исполняемому маршруту

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

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

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

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

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

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

Какие состояния действительно меняют работу

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

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

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

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

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

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

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

×

Сценарная схема НТА: сообщение клиента меняет план работы, но не подтверждает погашение. Основание — различие плановых и фактических данных в 1С и описанная здесь модель контроля.

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

Когда напоминание становится эскалацией

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

Техническое различие видно в документации ELMA об эскалации операции: переход процесса по таймеру или условию описывается отдельно от настройки уведомлений. Это документация определённой линейки продукта. Мы переносим принцип «событие — переход — новая работа», а не кнопки, ограничения редакции или сроки из примеров.

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

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

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

×

Сценарное правило НТА: передача считается завершённой после принятия, а не после отправки уведомления. Конкретные полномочия и сроки определяет компания.

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

Как связать CRM с учётным контуром

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

В сценарном контракте у записи есть устойчивый ключ, ссылка на основание, подтверждённое состояние и время актуальности данных. Финансовая функция отвечает за смысл учётных полей. Коммерческая — за контакт, владельца и следующую работу. Обновление из учёта не должно случайно стирать обещание клиента или историю передачи; изменение комментария в CRM не должно незаметно переписывать подтверждённое основание.

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

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

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

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

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

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

Как принять маршрут и наблюдать его работу

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

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

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

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

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

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

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

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

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

Где заканчивается применимость модели

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

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

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

Матрица ответственности для подтверждённой просрочки

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

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

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

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

Тест понедельником

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

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

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

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

Важное уведомление

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