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