Передача клиента между отделами: договор сам запускает задачи пяти команд

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

Как было: пять команд и передача по памяти

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

Что из этого получалось:

• Финансы узнавали о договоре с задержкой, хотя учёт долгосрочной аренды надо начинать сразу. Они просили уведомлять их в момент подписания
• Документы на субсидию шли через почту и Excel. Налоговые декларации и данные компании пересылали вложениями и собирали в таблицу
• Статус приходилось выяснять по командам. Чтобы понять, где застрял клиент, нужно было спрашивать и напоминать, и это одна из самых затратных строк в расчёте ниже

Время здесь уходит не на сами шаги, а на ожидание между ними: договор подписан, а задача ещё не дошла до нужного человека.

Что сделали: договор запускает передачу сам

Точка старта одна: в CRM сделка переходит в «договор подписан». Дальше без участия людей:

1. Онбординг получает номер. У каждого договора свой идентификатор, по нему видно все события от подписания до первой поставки
2. Договор уходит финансам. PDF договора сохраняется в общее хранилище, финансы сразу получают письмо с файлом
3. Клиент появляется во внутренней платформе. Аккаунт создаётся через API, его номер записывается обратно в CRM, чтобы системы не разошлись. Если такой пользователь уже есть, создание не останавливается
4. Пять команд получают задачи. Проект собирается из шаблона: семь этапов, у каждой команды свои задачи, уже заполненные данными клиента
5. Документы на субсидию собираются формой. Клиент заполняет форму, файлы раскладываются по папкам, в задаче появляется отметка. Сами документы проверяет человек
6. Клиент получает письма в нужный момент. Приветственное после подписания и финальное после поставки, по шаблонам

Сверху два механизма, которые держат передачу, когда люди заняты:

• Напоминания по зависшим задачам. Каждое утро система ищет задачи без движения пять дней и пишет владельцу задачи в рабочий мессенджер
• Бот статусов. Любой в команде спрашивает в мессенджере «где клиент такой-то» или «что просрочено» и получает ответ из трекера, не опрашивая команды

Что стало: около 25 минут вместо 3,5 часа

Я расписал шаги, которые раньше делал человек: завести аккаунт и связать его с CRM, раздать задачи пяти командам, отправить договор финансам и письма клиенту, собрать документы на субсидию, перенести осмотр техники с бумаги, выяснять статусы. С примерным временем на каждый выходит около 3,5 часа ручной работы на один договор. После запуска остаётся около 25 минут: проверка документов и редкие вопросы по статусу. Обе цифры это расчёт по шагам процесса, замера в проекте не делали.

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

Передачу запускает событие: три принципа для вашей компании

Инструменты в проекте были международные, но схема к ним не привязана. В России её можно собрать на amoCRM или Битрикс24 с задачами в той же CRM или в Яндекс Трекере, с 1С для учёта и Telegram вместо рабочего мессенджера. Пять команд тоже не обязательны: в компании с тремя-четырьмя отделами схема проще.

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

Как это может выглядеть у компании с продажами, складом и монтажом: сделка переходит в «оплачено», склад сразу получает задачу собрать заказ, бригада получает задачу на монтаж с адресом и составом, клиент получает письмо с датой. Если задача склада стоит три дня, напоминание приходит не клиенту, а начальнику склада.

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

Смежное: тот же стык между продажами и монтажом в посте про CRM для строительной компании и мобильная форма осмотра техники из этого же проекта в посте про осмотр по чек-листу с телефона.