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