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