Сделка идёт по воронке стадиями: первый контакт, КП, согласование, договор, оплата. На каждой стадии от менеджера нужен следующий шаг. Когда шага нет, сделка просто стоит - и стоит молча.
Мы сделали робота, который по каждой живой сделке считает, сколько дней она висит на текущей стадии, и если дольше порога - ставит ответственному задачу с подсказкой под эту стадию. Робот ставится на ваш отдел продаж в Битрикс24 или другой CRM.
Что было до
Сделка застывает там, где у менеджера не дошли руки. КП отправлено - клиент молчит, и письмо лежит без напоминания. На согласовании висит возражение, которое некому снять. Договор готов, а оплаты нет - и сделка тихо стоит неделями.
Никто её не двигает: в воронке десятки сделок, и зависшая ничем не выделяется среди остальных. Замечают её, когда о ней вспомнят. Чем дольше тишина, тем холоднее клиент.
Как это работает
Робот берёт каждую живую сделку в рабочих воронках продаж и смотрит реальную дату входа в текущую стадию - момент, когда сделка на неё встала. Дату создания и дату последней правки он игнорирует: правка полей омолаживает карточку, и по дате правки застрявшая сделка выглядит живой. Дальше робот считает, сколько дней сделка стоит на этой стадии.
У каждой стадии свой порог. Ранние стадии короткие: на отправленное КП ответ нужен быстро. Поздние длиннее: согласование договора идёт дольше. Перешагнули порог - ответственный получает задачу с подсказкой ровно под эту стадию: "КП отправлено - добей ответ", "Согласование - сними возражение", "Договор - доведи до оплаты". Менеджер видит конкретный шаг, без сухого "сделка стоит".
Сделка переехала на новую стадию - отсчёт начинается заново, и при новом застревании придёт новая задача. Стоит на той же стадии - робот повторно не дёргает: одна стадия - одно напоминание, пока сделка не сдвинулась.
Техническая сторона
Несколько решений, без которых робот либо молчал бы, либо заваливал менеджеров дублями:
- →Стек. Python на стандартной библиотеке, без внешних зависимостей. Робот - таймер на сервере: раз в сутки забирает живые сделки через REST Битрикс24 и считает по ним возраст стадии.
- →Возраст стадии - по реальному входу. Сколько сделка стоит, робот считает от момента входа в стадию по истории. Дату последней правки он не берёт. Пример тихой поломки: менеджер поправил сумму в карточке, дата правки обновилась - и застрявшая сделка выглядит свежей. По истории стадий видно правду.
- →Порог свой для каждой стадии. Ранние стадии короче, поздние длиннее - порог задаётся отдельно по каждой стадии, без общего срока на всю воронку.
- →Подсказка под стадию. Текст задачи зависит от стадии, на которой встала сделка: КП - добей ответ, согласование - сними возражение, договор - доведи до оплаты.
- →Без дублей. Задача несёт метку со стадией: новая стадия - новое напоминание, та же стадия - повторной задачи нет. Сделку не заваливает одинаковыми напоминаниями, пока она стоит на месте.
- →Только рабочие воронки продаж. Робот считает живые сделки в рабочих воронках, старьё и архив не трогает - напоминания приходят по сделкам, которые надо двигать.
Что это даёт
Сделка перестаёт зависать без внимания. Робот сам замечает, что она стоит на стадии дольше порога, и кладёт ответственному задачу: где КП без ответа, где висит возражение, где договор без оплаты. Менеджер не держит всю воронку в голове.
Робот проходит по воронке раз в сутки, поэтому застрявшая сделка всплывает на следующий день после того, как перешагнула порог - пока клиент ещё помнит и КП, и разговор с менеджером.
