От КП до оплаты: процесс quote-to-cash
Между выигранной сделкой и деньгами на счёте теряется выручка. Разбираем цепочку quote-to-cash по звеньям и закрываем места типичных разрывов.
Пятница, вторая половина дня. Руководитель продаж открывает воронку: три крупные сделки помечены как «выиграно», команда поздравляет друг друга. В это же время финансовый отдел смотрит на другой экран, где счёт выставлен только по одной из трёх. Детали заказов по двум оставшимся до сих пор лежат вложением в чьей-то почте. Для продаж работа закончена, для расчётного счёта — не начиналась. Расстояние между этими двумя картинами редко измеряется днями: чаще неделями.
Quote-to-cash — это привычка видеть весь этот путь как одну цепочку, а не как три отдела: от момента, когда назначена цена, до момента, когда деньги пришли и корректно легли в учёт. Ниже разбираем звенья цепочки, места типичных разрывов, признаки, по которым разрыв опознаётся, и четыре показателя, которые стоит вести. В конце — поэтапный план исправления, не требующий останавливать работу.
Что именно охватывает quote-to-cash
Quote-to-cash (Q2C) — это весь набор шагов от оценки запроса клиента до получения денег и отражения выручки в учёте. В большинстве компаний эти шаги распределены между тремя командами: продажи готовят предложение, операционный отдел исполняет, финансы выставляют счёт и собирают оплату. Каждая команда может работать отлично, а цепочка всё равно рвётся — потому что разрывы происходят не внутри отделов, а на швах между ними.
Именно поэтому Q2C заслуживает отдельного названия. Скажите «процесс продаж» — никто не подумает о счёте. Скажите «первичный учёт» — никто не вспомнит про строки коммерческого предложения. Как только у цепочки появляется одно имя, ничейные зоны становятся видимыми.
Есть и второй эффект. Рамка Q2C переводит разговор с людей на процесс. Фраза «менеджер поздно выставил счёт» — это обвинение, из которого ничего не следует. Фраза «между записью о поставке и счётом есть двое ничьих суток» — это наблюдение, которое можно исправить. День, когда команда начинает говорить вторым способом, и есть день начала улучшений.
Звенья цепочки и результат каждого из них
Ремонт цепочки начинается с договорённости о том, где заканчивается каждое звено. Звено не считается закрытым, пока не появился результат, на который можно показать пальцем.
- Коммерческое предложение: постатейно рассчитанный документ со сроком действия, который клиент действительно увидел. Для конфигурируемых продуктов правила этого шага мы разбираем в материале о том, что такое CPQ.
- Внутреннее согласование: если скидка, отсрочка или особые условия выходят за рамки политики, наружу ничего не уходит без зафиксированного одобрения.
- Договор и подпись: обязательства, сроки поставки и график платежей закрепляются подписанным документом.
- Заказ: принятое предложение переводится на язык производства и склада — количество, вариант, адрес, срок.
- Поставка или оказание услуги: товар отгружается либо работа выполняется, и остаётся накладная, заказ-наряд или акт.
- Выставление счёта: счёт выставляется ровно на то, что реально поставлено, — не больше и не меньше.
- Оплата: сроки контролируются, деньги приходят, частичные платежи разносятся по нужному счёту.
- Отражение в учёте: выручка, поступление и курсовая разница попадают в правильный период и на правильный счёт.
Точки разрыва: от симптома к причине
Чтобы найти разрыв, редко нужен формальный аудит процессов. Жалобы, которые и так звучат в коридоре, достаточно диагностичны.
- «Клиент ждёт, а мы выясняем цену»: полномочия по цене и скидке не описаны в одном месте; без индивидуальных прейскурантов и матрицы скидок это ожидание не сократится.
- «Позвонил руководителю за согласованием, ответа нет»: согласование устное и завязано на человека, следа в системе не остаётся, измерить задержку невозможно.
- «Склад отгрузил позицию, которой не было в КП»: заказ не унаследован из предложения, а перепечатан заново.
- «Счёт выставили, клиент оспорил»: запись о поставке и запись о заказе не совпадают между собой.
- «Срок прошёл, но никто не позвонил»: у взыскания нет ответственного, напоминания держатся на памяти сотрудников.
Выручка возникает не там, где продажи ставят отметку «выиграно», а там, где деньги дошли до счёта. И каждый ручной перенос данных между этими точками тихо съедает её часть.
Принцип «данные вводятся один раз»
Самая дорогая привычка в Q2C — вбивать одну и ту же информацию по всей цепочке заново. Строки собираются в таблице, переписываются в форму заказа, третий раз попадают в накладную и четвёртый — в счёт. При каждом переносе теряется позиция, неверно применяется скидка или искажается код варианта.
Правило простое: данные входят в цепочку однажды, а каждый следующий шаг их наследует. Согласованное предложение превращается в заказ вместе со строками; запись о поставке превращается в счёт вместе с ними же. Поэтому важно, что в Rocketly строки предложения переходят прямо в счёт и во взаиморасчёты: там, где нет копирования, нет и расхождений. Если учётная программа отдельная, ту же задачу решает настроенный обмен между CRM и бухгалтерией — важно лишь, чтобы направление передачи было одно и источник истины не раздваивался.
Согласование и подпись: самая тихая задержка
Согласование обычно не измеряют, потому что его не считают отдельным шагом. Между фразой «сейчас согласую» и отправкой предложения клиенту при этом легко проходят дни. Решение — не отменить согласование, а дать ему правила и часы: до какой скидки менеджер решает сам, кто утверждает выше порога, кому эскалируется запрос, если он завис. Как перенести это в систему, мы разбираем в материале про автоматизацию согласований.
С подписью та же история. Круги живых подписей, курьеры и потерянные экземпляры способны затормозить выигранную сделку на недели. При этом договор живёт и после подписи: за датами продления и расторжения надо следить, о чём наш материал про управление жизненным циклом договоров.
Частичная поставка и частичное выставление счетов
Здесь модель ломается чаще всего. В жизни заказ редко закрывается разом: две позиции из трёх уходят сразу, третья — когда приедет на склад. В услугах работа идёт этапами. Если система понимает только «заказ открыт» или «заказ закрыт», остаток кто-то записывает себе в блокнот, и эта запись теряется.
Правильная модель считает количества на уровне строки: заказано, поставлено и выставлено — три отдельных числа для каждой позиции. Тогда список «поставлено, но не выставлено» формируется сам. Подробнее эту конструкцию мы описываем в гиде по управлению заказами.
Есть и вторая тонкость: договоритесь с клиентом заранее, сколько счетов он ждёт. Одни закупщики просят отдельный документ на каждую отгрузку, другие — один сводный счёт в конце месяца. Если это условие не зафиксировано при открытии заказа, даже исправно работающая система выставит счёт не вовремя.
Где на самом деле возникает утечка выручки
Утечка никогда не выглядит как драма: это небольшая, но регулярная недостача. Четыре источника встречаются постоянно — поставленное, но не выставленное в счёт; прописанная в договоре ежегодная индексация, которую никто не применяет; дополнительные услуги, отданные бесплатно только потому, что их не было в предложении; скидки сверх политики, которых никто не заметил. По отдельности мелочь, вместе — нет.
Практичнее всего вскрывать их постоянным отчётом об исключениях: поставлено без счёта, выставлено без оплаты. Полную картину мы собрали в статье про утечку выручки.
Передачи и граница ответственности
Самые рискованные моменты цепочки — передачи работы из отдела в отдел. Продажи говорят «я закрыл», операционный отдел говорит «мне не сообщили», и оба правы. Прекратить этот спор можно, зафиксировав для каждой передачи три вещи: какое событие её запускает, какие поля обязаны быть заполнены, и кто отвечает за работу после неё.
На практике это обязательные поля при переходе в стадию «выиграно»: подписанный документ, адрес поставки, условия оплаты, юридическое наименование для счёта. Пустые поля — стадия не двигается. Звучит жёстко, но неделя переписки превращается в минуту заполнения формы.
Разграничивая ответственность, разделите ещё две вещи: кто выполняет работу и кто отвечает за то, что она не выполнена. Счёт выставляет первичный учёт, но заметить, что счёта нет, — задача владельца процесса, а не менеджера по продажам. Если повесить обе роли на одного человека, провиснут обе.
Четыре показателя, которые стоит считать
Управляемым Q2C делает отказ сводить его к одной цифре «длительность сделки». Измеряйте цепочку в четырёх точках: каждый показатель держит зеркало перед своей командой.
| Показатель | Что показывает | Владелец |
|---|---|---|
| Время от КП до заказа | Ожидание внутри согласования и подписи | Продажи |
| Задержка от поставки до счёта | Сколько счёт лежит после выполнения работы | Операции и финансы |
| Время от счёта до оплаты | За сколько дней дебиторка становится деньгами | Финансы |
| Доля расхождений заказ-счёт | Нагрузку ошибок от ручного ввода | Владелец процесса |
Вместе эти четыре цифры не оставляют места для спора о том, в каком звене стоят деньги. Чтобы увидеть эффект всей цепочки на уровне компании, посмотрите наш материал про денежный цикл: он собирает эти показатели в одну рамку.
Обратная связь от оплаты к продажам
В большинстве компаний продажи так и не узнают, заплатил ли клиент. А ведь это одна из самых полезных для менеджера вещей: везти новое предложение с отсрочкой клиенту с двумя просроченными счетами — плохая идея и для финансов, и для самого менеджера. Статус оплаты должен быть виден на карточке клиента по умолчанию, а не в отчёте, который надо специально запрашивать.
Связь работает в обе стороны. Продажи идут на разговор, зная картину платежей, а финансы быстро понимают, задержка — это реальный спор или неверно выставленный счёт. Схемы напоминаний и эскалации мы собрали в гиде по контролю взыскания и просроченным счетам.
Поэтапный план улучшения
Попытка починить всю цепочку одним движением обычно заканчивается тем, что не чинится ничего. Реалистичнее идти тремя волнами.
Волна первая — видимость. Ничего не меняйте, просто начните измерять. Возьмите выигранные сделки за последние три месяца и выпишите для каждой даты: предложения, заказа, поставки, счёта и оплаты. Появившиеся разрывы и есть ваши настоящие узкие места — и они часто расходятся с интуицией.
Волна вторая — убрать перепечатывание. Выберите самый частый ручной ввод и уничтожьте его. Почти всегда это перенос строк предложения в заказ и счёт. Какие типы документов и поля важны, разбирает наш гид по выставлению счетов.
Волна третья — правила и автоматизация. Заведите в систему пороги согласования, обязательные поля и напоминания о просрочке. Здесь автоматизация процессов начинает окупаться: появилась запись о поставке — открылась задача на счёт, прошёл срок — ушло уведомление ответственному.
Если хотите держать цепочку целиком в одном месте, самое устойчивое решение — схема, где предложение, заказ, счёт и оплата живут на одной карточке клиента. Проверить такой поток на своих процессах можно, создав бесплатный аккаунт Rocketly и запустив первую волну уже на этой неделе.