Короткий ответ: лимит должен проверяться до обещания клиенту
Кредитный лимит клиента — это максимальная сумма неоплаченных обязательств, которую компания готова принять при продаже с отсрочкой. Рабочий процесс связывает коммерческое решение в CRM с фактическими счетами, оплатами и просрочкой в учётной системе. До подтверждения нового заказа менеджер видит доступный остаток лимита, срок ближайшего платежа и статус исключений. Если заказ выходит за рамки правила, система не скрывает проблему и не отказывает молча: она запускает согласование с указанным владельцем и сроком.
Главная цель — не запретить отсрочку, а сделать риск видимым до отгрузки. Для этого достаточно понятной кредитной политики, единого источника данных по каждому показателю, устойчивого обмена между CRM и 1С и журнала решений. Кредитный отчёт может быть только отдельным законным источником в предусмотренном процессе; он не заменяет внутреннюю платёжную историю клиента.
Кредитная история, платёжная история и кредитный лимит — не одно и то же
Кредитная история содержит сведения об обязательствах субъекта, которые формируются кредитными бюро по установленным правилам. Получение кредитного отчёта не является обычной функцией любой CRM: для него нужны допустимый получатель, предусмотренное основание, согласие субъекта и соблюдение требований к обработке данных. Нельзя загружать в карточку клиента чужой отчёт, полученный сотрудником «для удобства», или просить прислать его в рабочий чат.
Внутренняя платёжная история — это собственные данные компании: выставленные счета, сроки, оплаты, просрочки, возвраты и согласованные претензии. Кредитный лимит — управленческое решение компании о допустимой сумме открытых обязательств. Эти три понятия могут участвовать в оценке риска, но у них разные источники, основания доступа и сроки хранения. Для большинства проектов безопаснее начать именно с качества внутренней истории и дисциплины решений.
| Понятие | Что показывает | Как использовать |
|---|---|---|
| Кредитная история | Обязательства из кредитного отчёта | Только в законном сценарии и с требуемым согласием |
| Платёжная история | Как клиент рассчитывался с вашей компанией | Для анализа сроков, просрочки и спорных сумм |
| Кредитный лимит | Какой открытый долг компания готова принять | Для проверки заказа и маршрута согласования |
Сначала утвердите правило, затем автоматизируйте
Если финансовый директор определяет лимит в таблице, руководитель продаж обещает отсрочку в переписке, а бухгалтерия узнаёт о ней после отгрузки, интеграция лишь ускорит конфликт. Зафиксируйте базовое правило: для каких клиентов допустима отсрочка, кто назначает лимит, на какой срок он действует, какие суммы входят в расчёт, что считать просрочкой и кто может сделать исключение.
Разделите лимит и условия оплаты. Один клиент может иметь лимит пять миллионов тенге и разные сроки по типам поставки; другой — оплачивать авансом, несмотря на высокую выручку. Не вычисляйте лимит только из ожидаемого объёма сделки. Учитывайте подтверждённую историю отношений, концентрацию риска, текущие обязательства, спорные документы и способность команды вовремя остановить следующую отгрузку. Формула должна быть понятна тем, кто принимает и исполняет решение.
Назначьте систему-источник для каждого показателя
CRM удобна для клиента, сделки, ответственного, коммерческих условий и задачи на согласование. Учётная система обычно отвечает за реализацию, счёт, оплату, задолженность и закрывающие документы. Не копируйте всё во все стороны. Для каждого поля выберите источник правды и получателя. Например, лимит утверждается в CRM после согласования, а использованная сумма рассчитывается по открытым обязательствам в 1С.
Также определите момент актуальности. Менеджеру важен не просто остаток «на сегодня», а время последнего успешного обмена. Если платёж ещё не загружен из банка или интеграция остановилась, интерфейс должен показать задержку данных. Значение без отметки времени создаёт ложную уверенность. Для критичной отгрузки полезнее честный статус «данные требуют проверки», чем зелёный индикатор, рассчитанный вчера.
Минимальная карточка кредитного решения
Не превращайте карточку клиента в финансовое досье. Сотруднику нужны только данные, которые меняют действие: утверждённый лимит, использованная сумма, доступный остаток, максимальная просрочка, ближайший срок оплаты, дата пересмотра и статус исключения. Финансовому специалисту может потребоваться расшифровка по документам; менеджеру достаточно итогового статуса и понятного следующего шага.
Укажите автора решения, основание, дату начала и срок действия. Если лимит рассчитан вручную, сохраните ссылку на утверждённый документ или запись согласования, а не случайный файл в переписке. Для временного повышения обязательно задайте дату окончания. Истёкшее исключение не должно незаметно превращаться в постоянное правило.
- Утверждённый лимит и валюта расчёта.
- Открытые обязательства и доступный остаток.
- Просроченная сумма и возраст просрочки.
- Дата последнего обновления из учётной системы.
- Владелец решения, срок действия и основание исключения.
Проверяйте заказ по последовательному сценарию
Проверка должна запускаться в конкретной точке — например, перед подтверждением заказа, передачей на склад или формированием реализации. Сначала система определяет клиента и собирает актуальные обязательства. Затем считает будущую позицию: текущий долг плюс сумма нового заказа минус подтверждённые оплаты или авансы по согласованному правилу. После этого сравнивает результат с лимитом и проверяет наличие просрочки.
Если условия выполнены, сделка продолжает обычный путь. Если не выполнены, создаётся запрос на решение: уменьшить заказ, запросить частичную предоплату, дождаться оплаты, временно повысить лимит или отказать в отсрочке. Каждое действие должно быть названо одинаково в CRM, учётной системе и инструкции сотрудников. Не используйте неопределённый статус «на согласовании» без ответственного и срока.
Свяжите CRM и 1С так, чтобы сбой был заметен
Для обмена важны устойчивый идентификатор клиента, заказа и учётного документа, а также защита от повторной обработки события. Повторный вебхук не должен дважды уменьшать доступный остаток или создавать два запроса на согласование. Храните технический журнал отдельно от пользовательской карточки: время события, идентификатор, результат, число попыток и понятную причину ошибки.
Определите резервный режим. При недоступности 1С можно временно запрещать автоматическое подтверждение отсрочки, направлять ограниченный объём заказов на ручную проверку или разрешать только полностью оплаченные операции. Выбор зависит от цены ошибки и скорости процесса. Главное — не оставлять менеджера с молча устаревшим зелёным статусом. Для обмена между системами полезны очереди, повторные попытки и идемпотентность, то есть безопасная повторная обработка одного события без двойного результата.
Исключение должно быть решением, а не обходом
Продажи иногда требуют отгрузить больше лимита: крупный заказ, задержка банковского платежа или стратегический клиент. Полный запрет заставляет команду искать обход, а бесконтрольное разрешение делает лимит декоративным. Создайте короткий маршрут исключения с причиной, суммой превышения, сроком, компенсирующим действием и ответственным руководителем.
Согласующий должен видеть открытые обязательства, просрочку, ожидаемую маржу, историю предыдущих исключений и ближайший платёж. Не разрешайте повышать лимит тому же сотруднику, который получает бонус только за объём продажи. После даты окончания система возвращает обычный лимит автоматически, а незакрытое превышение остаётся в отчёте. Регулярные исключения по одному клиенту означают, что основное правило нужно пересмотреть.
Смотрите на качество портфеля, а не только на выручку
Руководителю полезен список клиентов с доступным остатком лимита, просрочкой, ближайшими платежами и истекающими решениями. Отдельно покажите заказы, задержанные из-за неактуальных данных или незавершённого согласования. Сопоставляйте продажи с оплатой: высокая отгрузка без поступления денег увеличивает нагрузку на оборотный капитал, даже если план продаж формально выполнен.
Не превращайте один показатель в универсальный рейтинг клиента. Средний срок оплаты может скрыть один крупный просроченный документ. Доля просрочки не объясняет спор по качеству товара. Аналитика должна помогать открыть конкретные обязательства и решение, а не навешивать непрозрачную метку. Отслеживайте также время согласования, число временных повышений и заказы, которые прошли при устаревших данных.
Условный пример: дистрибьютор и повторный заказ
Представим условного дистрибьютора. Клиент имеет лимит 8 миллионов тенге. В учётной системе открыты обязательства на 5,5 миллиона, из них 600 тысяч просрочены. Менеджер создаёт повторный заказ на 3 миллиона. CRM получает актуальную позицию из 1С и показывает, что будущая сумма превысит лимит на 500 тысяч, а правило запрещает автоматическую отгрузку при любой просрочке.
Система предлагает три действия: дождаться оплаты, запросить предоплату на часть заказа или отправить исключение финансовому директору. Менеджер выбирает частичную предоплату, клиент оплачивает миллион, а обмен подтверждает поступление. Доступный остаток становится достаточным, просроченный документ закрывается по согласованному порядку, и заказ продолжает путь. В карточке остаются факты и решение, но не копии банковских сообщений из личного чата. Это пример проектирования, а не клиентский кейс ZXC.
План внедрения на две недели
В первые три дня выберите один тип продажи с отсрочкой и опишите текущий путь от предложения до оплаты. Зафиксируйте формулу открытых обязательств, источник каждого поля и список исключений. Затем очистите соответствия клиентов между CRM и 1С: дубли и неверные идентификаторы опаснее сложной формулы.
На второй неделе настройте расчёт в режиме наблюдения. Система показывает решение, но сотрудники действуют по старому процессу. Сравните результаты, разберите различия и проверьте задержки данных. После этого включите автоматический проход для простых случаев, а превышения направьте в ограниченный маршрут согласования. Проведите тесты повторного события, недоступности 1С, частичной оплаты, возврата, спорного документа и истечения временного лимита. Назначьте владельца правил и дату первого пересмотра.
Частый вопрос: можно ли автоматически получать кредитную историю клиента в CRM?
Не следует считать это стандартной функцией CRM. Кредитный отчёт предоставляется в предусмотренном законом порядке: важны статус получателя, основание, согласие субъекта и правила защиты данных. Сначала проверьте правовой и договорный сценарий с ответственными специалистами. Для управленческого лимита часто достаточно собственной платёжной истории и утверждённых критериев.
Частый вопрос: где хранить кредитный лимит — в CRM или в 1С?
Выберите одну систему-источник для утверждённого значения и передавайте его в другую систему для исполнения. CRM удобна для согласования и связи с продажей, а 1С — для контроля учётных документов. Конкретный выбор зависит от того, где компания фиксирует решение, кто его меняет и в какой точке блокируется отгрузка.
Частый вопрос: что делать, если оплата есть, но обмен ещё не обновился?
Не подтверждайте платёж по скриншоту в личном чате как единственному основанию. Покажите время последней синхронизации и запустите установленную ручную проверку у ответственной роли. После подтверждения исправьте причину задержки и сохраните связь решения с конкретным платежом, заказом и сотрудником.
Следующий шаг: соберите один прозрачный контур отсрочки
Возьмите десять последних заказов с отсрочкой и восстановите для каждого лимит, открытые обязательства, источник данных, принятое исключение и фактическую оплату. Если решение нельзя объяснить по записям систем без поиска в чатах, начните с карты данных и ролей. Затем автоматизируйте проверку перед одной точкой — подтверждением заказа или отгрузкой.
ZXC CRM помогает связать решение с клиентом, сделкой и ответственным, а ZXC CONNECT — организовать обмен с 1С и другими источниками по наблюдаемым правилам. Первый проект должен сделать видимыми лимит, актуальность данных и исключения, а не пытаться сразу построить сложный скоринг.