Оплата часто воспринимается как финал продажи. Для клиента это наоборот начало ожидания: когда со мной свяжутся, кто возьмет заказ в работу, когда будет отгрузка, запуск проекта или первый созвон. Если в Bitrix24 после оплаты не создается понятный набор задач, компания быстро попадает в ручной режим: менеджер пишет в чат, бухгалтерия подтверждает платеж в переписке, исполнитель узнает о заказе позже всех.
Задачи после оплаты в Bitrix24 нужны не для контроля ради контроля. Они фиксируют момент, когда сделка переходит из зоны продаж в зону исполнения. В хорошей схеме оплата автоматически запускает маршрут: кто проверяет документы, кто готовит заказ, кто назначает дату старта, кто видит просрочку и когда руководитель вмешивается.
Почему оплаченные заказы зависают после сделки
Частая картина выглядит так: сделка перешла в стадию "Оплачено", менеджер выдохнул, а дальше процесс распался на устные договоренности. В карточке нет точной даты запуска, не указано направление работ, не заполнен состав заказа, а исполнитель не получил задачу. Через день клиент пишет менеджеру: "Когда начинаем?", и только в этот момент команда собирает вводные.
В Bitrix24 такая проблема обычно возникает не из-за отсутствия роботов, а из-за отсутствия правила перехода. Нужен конкретный триггер, после которого CRM понимает: продажа завершена, теперь надо передать заказ в работу.
Мини-сценарий для поставки оборудования:
- trigger: сделка перешла в стадию "Оплачено";
- action: создать задачу логисту "Проверить готовность отгрузки";
- responsible role: логист или координатор склада;
- deadline: до 12:00 следующего рабочего дня;
- result: клиент получает дату отгрузки, а РОП видит, что оплаченный заказ не потерялся.
Если этот сценарий не описан, оплаченные сделки начинают жить в чатах. Чат не хранит ответственность, срок и контроль. CRM должна делать это автоматически.
Какие данные нужны до автоматизации
Перед настройкой задач после оплаты важно не начинать с робота. Сначала нужно понять, какие данные должны быть в сделке в момент запуска исполнения. Если робот создает задачу с пустым описанием, он только ускоряет хаос.
Для большинства компаний достаточно проверить такие поля:
- тип заказа: поставка, услуга, проект, внедрение, обучение;
- сумма и статус оплаты;
- состав заказа или ссылка на спецификацию;
- дата, обещанная клиенту;
- ответственный менеджер;
- ответственный за исполнение или направление работ;
- необходимость документов: счет, договор, акт, доступы, ТЗ;
- канал связи с клиентом;
- особые условия: срочно, частичная оплата, нужна доставка, нужен стартовый созвон.
Сценарий для проектной услуги:
- trigger: поле "Оплата подтверждена" изменилось на "Да";
- action: проверить, заполнены ли поля "Состав работ", "Дата старта", "Координатор проекта";
- responsible role: менеджер сделки;
- deadline: заполнить недостающие данные в течение 2 часов;
- result: исполнитель получает не пустую задачу, а понятный пакет вводных.
Если часть полей не заполнена, лучше не запускать исполнение вслепую. Робот может создать задачу менеджеру "Заполнить данные для передачи в работу" и только после этого запускать основной маршрут.
Базовый сценарий: оплата получена → задачи созданы
Самый понятный сценарий строится вокруг одного события. Например: сделка переходит в стадию "Оплачено" или бухгалтер ставит в карточке сделки признак "Оплата подтверждена". Второй вариант часто надежнее, если деньги проверяет не менеджер, а бухгалтерия.
После события Bitrix24 может выполнить цепочку действий:
- сменить стадию сделки на "Передача в исполнение";
- создать задачу координатору на проверку комплекта данных;
- создать задачу исполнителю или руководителю направления;
- уведомить менеджера, что заказ запущен;
- поставить контрольную задачу руководителю, если запуск не подтвержден в срок.
Пример для внедрения сервиса:
- trigger: бухгалтер подтвердил оплату первого счета;
- action: создать задачу координатору "Назначить стартовый созвон";
- responsible role: координатор проекта;
- deadline: 1 рабочий день;
- result: клиент получает дату старта, а менеджер не держит передачу заказа в голове.
Такой сценарий хорош тем, что он не требует сложной разработки. Важнее правильно описать условия: когда запускать, кому назначать и что считать выполненным.
Какие задачи создавать автоматически
Ошибка многих внедрений в том, что после оплаты создается одна общая задача "Передать заказ". Она быстро превращается в мусорную корзину: туда складывают документы, вопросы, доставку, старт работ и контроль клиента. Лучше создать небольшой пакет задач по ролям.
Для типовой компании пакет может выглядеть так:
- бухгалтеру: проверить оплату, закрывающие документы и наличие договора;
- менеджеру: проверить состав заказа и обещания клиенту;
- координатору: назначить исполнителя и дату старта;
- исполнителю: принять задачу в работу и подтвердить срок;
- логисту: подготовить отгрузку, если есть товар или оборудование;
- руководителю: получить уведомление, если запуск не подтвержден вовремя.
Сценарий для обучения:
- trigger: сделка "Курс для команды" оплачена;
- action: создать задачу координатору "Согласовать дату обучения" и задачу менеджеру "Передать список участников";
- responsible role: координатор обучения и менеджер;
- deadline: дата обучения согласована за 1 рабочий день, список участников передан до 17:00;
- result: оплаченная услуга не ждет, пока менеджер вспомнит о запуске.
Количество задач должно соответствовать процессу. Если компания небольшая, часть ролей может быть у одного человека. Но в CRM лучше все равно разделить смысл: документы, запуск, исполнение, контроль.
Как назначать ответственных и дедлайны
Ответственный после оплаты не всегда один и тот же. Для простого заказа это может быть координатор, для сложного проекта - руководитель направления, для отгрузки - логист. Поэтому в Bitrix24 полезно завести условия назначения.
Примеры условий:
- если тип заказа "Поставка", первая задача уходит логисту;
- если тип заказа "Проект", первая задача уходит координатору проекта;
- если сумма выше внутреннего порога, руководитель получает контрольную задачу;
- если нужна доставка, создается отдельная задача на проверку адреса и даты;
- если оплата частичная, менеджер получает задачу согласовать следующий платеж.
Сценарий для заказа с доставкой:
- trigger: сделка оплачена и поле "Нужна доставка" = "Да";
- action: создать задачу логисту "Согласовать доставку" и задачу менеджеру "Проверить адрес клиента";
- responsible role: логист и менеджер;
- deadline: адрес проверить в течение 2 часов, дату доставки согласовать до конца рабочего дня;
- result: клиент получает понятный следующий шаг, а не сообщение "мы уточним".
Дедлайны лучше ставить не абстрактно, а по бизнес-ритму. Для срочных заказов это могут быть 30 минут, для проектного старта - 1 рабочий день, для подготовки документов - до конца дня.
Как контролировать просрочки после оплаты
Автоматизация после оплаты должна не только создавать задачи, но и показывать руководителю, где процесс остановился. Иначе CRM будет аккуратно складывать просроченные задачи, но никто не заметит проблему.
Минимальный контроль:
- задача координатору не выполнена за 1 рабочий день;
- исполнитель не подтвердил срок запуска;
- в сделке нет даты старта;
- клиенту не отправлено сообщение после оплаты;
- оплаченная сделка больше 24 часов находится в стадии "Передача в исполнение".
Сценарий эскалации:
- trigger: задача "Назначить исполнителя" просрочена на 2 часа;
- action: отправить уведомление операционному руководителю и создать контрольную задачу;
- responsible role: операционный руководитель;
- deadline: проверить причину просрочки в тот же рабочий день;
- result: зависание видно до жалобы клиента.
Такой контроль особенно важен, если компания работает с большим потоком небольших заказов. Одна просрочка кажется мелочью, но десять зависших оплат за неделю уже бьют по репутации и повторным продажам.
Типичные ошибки настройки
Первая ошибка - запускать роботов от стадии сделки, которую менеджеры меняют вручную и нерегулярно. Если стадия "Оплачено" ставится с задержкой, автоматизация тоже запустится поздно. Иногда надежнее использовать отдельное поле "Оплата подтверждена" и дать право менять его бухгалтерии или ответственному администратору.
Вторая ошибка - создавать задачи без данных. Если в описании задачи написано только "Заказ оплачен", исполнитель все равно пойдет к менеджеру за подробностями. Значит, в карточке сделки должны быть обязательные поля.
Третья ошибка - назначать все задачи на менеджера. После оплаты менеджер должен оставаться в контуре, но не быть единственным узким местом. Иначе автоматизация просто формализует старую зависимость от одного человека.
Четвертая ошибка - не проверять исключения. Частичная оплата, срочный заказ, отсутствие договора, нестандартная доставка, дополнительное согласование - все это должно либо запускать отдельную ветку, либо ставить задачу на ручную проверку.
Сценарий ошибки:
- trigger: сделка оплачена частично;
- wrong action: робот создал полный пакет задач на исполнение;
- consequence: исполнитель начал работу, хотя второй платеж не согласован;
- correct action: создать задачу менеджеру "Проверить условия частичной оплаты" и не запускать исполнение до подтверждения.
Хорошая автоматизация не должна делать вид, что все заказы одинаковые. Она должна ускорять стандартные случаи и явно подсвечивать исключения.
Как внедрить сценарий без хаоса
Начать стоит с карты процесса на одном листе: что происходит после оплаты в первые 24 часа. Не нужно сразу автоматизировать все варианты. Лучше выбрать самый частый сценарий и проверить его на 10-15 реальных сделках.
Практический порядок:
- Выписать все события после оплаты: подтверждение платежа, документы, старт исполнения, доставка, уведомление клиента.
- Определить одну точку запуска: стадия или поле подтверждения оплаты.
- Указать обязательные поля сделки.
- Разделить задачи по ролям.
- Настроить дедлайны и уведомления.
- Протестировать на копии процесса или на ограниченной группе.
- Проверить отчет по просрочкам через неделю.
Сценарий тестового запуска:
- trigger: в течение недели автоматизация включена только для направления "Поставка";
- action: робот создает задачи логисту, менеджеру и руководителю контроля;
- responsible role: CRM-администратор отслеживает ошибки сценария;
- deadline: первые выводы через 5 рабочих дней;
- result: команда видит, какие поля не заполняются и где нужно поправить маршрут.
После теста можно расширять сценарий на услуги, проекты и повторные продажи. Так автоматизация будет расти от реального процесса, а не от красивой схемы в презентации.
Что сделать дальше
Если после оплаты у вас появляются ручные сообщения, потерянные вводные и вопросы "кто взял заказ в работу", стоит начать с аудита этого участка процесса. Достаточно разобрать несколько оплаченных сделок и посмотреть, где именно теряется ответственность: в подтверждении оплаты, в передаче данных, в назначении исполнителя или в контроле срока.
AcroWeb помогает настраивать такие сценарии в Bitrix24: от карты процесса и обязательных полей до роботов, задач, уведомлений и контроля просрочек. Начать можно с одного маршрута после оплаты, а затем аккуратно расширить его на другие направления.
Автоматизация бизнес-процессов в Bitrix24
AcroWeb помогает описать маршрут после оплаты, настроить обязательные поля, роботы, задачи, уведомления и контроль просрочек без перегруза команды.
Следующий шаг
Если оплаченные заказы у вас запускаются через ручные сообщения и личную память менеджера, начните с разбора 5-10 последних оплат. По ним быстро видно, какие задачи, роли и сроки нужно закрепить в Bitrix24.
Частые вопросы
Можно ли запускать задачи после оплаты без интеграции с бухгалтерией?
Да, если на первом этапе подтверждение оплаты вручную ставит ответственный сотрудник. Например, бухгалтер меняет поле "Оплата подтверждена" на "Да". Это не идеальная автоматизация, но уже лучше, чем передача заказа через чат. Позже можно подключить интеграцию с учетной системой.
Что лучше использовать как trigger: стадию сделки или отдельное поле?
Если менеджеры точно и вовремя переводят сделки в стадию "Оплачено", можно использовать стадию. Если оплату проверяет бухгалтерия или бывают частичные платежи, безопаснее отдельное поле "Оплата подтверждена". Оно снижает риск, что робот запустит исполнение раньше времени.
Кому назначать первую задачу после оплаты?
Первую задачу лучше назначать роли, которая отвечает за запуск исполнения. В маленькой компании это может быть менеджер, в более зрелом процессе - координатор, логист или руководитель направления. Главное, чтобы человек мог принять заказ и передать его дальше по понятному маршруту.
Как понять, что сценарий после оплаты настроен неправильно?
Есть несколько признаков: оплаченные сделки стоят без движения больше рабочего дня, сотрудники уточняют вводные в чатах, руководитель узнает о проблеме от клиента, задачи создаются без описания, а исполнители не понимают, кто должен начать работу. Это сигнал, что нужно проверять поля, условия запуска и правила ответственности.
Краткий вывод
Задачи после оплаты в Bitrix24 должны связывать продажу и исполнение. Хороший сценарий начинается с понятного триггера, создает задачи по ролям, ставит реальные дедлайны и показывает руководителю просрочки до того, как клиент начинает напоминать о себе. Чем точнее описан этот переход, тем меньше оплаченных заказов зависает в ручных договоренностях.
