Аналитика времени по этапам сделки в Битрикс24 - кейс из сферы IT

О клиенте

NGENIX - IT-компания, занимается развитием облачной платформы, защитой от DDoS, ботов и взломов.

Почему выбрали Битрикс24

Компания уже использовала Битрикс24 в работе, требовалось расширить функционал в части контроля работы со сделками. Руководству необходимо видеть, какое количество времени сделка была на каждой стадии, чтобы в дальнейшем анализировать полученную информацию в разрезе каждого сотрудника, отделов, и выявлять слабые стороны в отработке сделок, отлаживать скорость реакции сотрудников на каждом из этапов. В Битрикс24 можно настроить бизнес- процесс, который позволит отслеживать изменение стадии в сделке и фиксировать общее время нахождения на каждой из стадий.

Какие задачи поставили в работу для решения проблемы клиента?

1. Настроить бизнес-процесс «Учет времени нахождения сделки на стадии»

Что было сделано

1. Настроили бизнес-процесс «Учет времени нахождения сделки на стадии»

   Бизнес-процесс работает на создание и изменение сделки. Подсчет времени настроен для двух воронок по следующему сценарию:

   1. Проверка воронки. Если воронка подходящая, переход к следующему этапу

   2. Проверка смены стадии. Поверка реализована через пользовательское техническое поле «Предыдущая стадия (техническое поле)». Если текущая «Стадия» не равна значению в поле «Предыдущая стадия (техническое поле)», значит, стадия поменялась, либо это новая сделка. Переход к следующему этапу. Если значения этих полей равны, значит, стадия, не менялась, бизнес-процесс завершается.

   3. Проверка технического поля «Дата смены стадии». Если это поле не заполнено, значит, сделка является новой, в поле «Дата смены стадии» заносится текущая дата, в поле «Предыдущая стадия (техническое поле)» заносится текущая стадия. Бизнес-процесс завершается. Далее на этой сделке бизнес-процесс будет срабатывать на изменение и сразу завершаться, пока в ней не поменяется стадия.

   4. Как только в этой сделке сменится стадия, снова происходит проверка воронки, смены стадии, даты смены стадии. В этом случае «Дата смены стадии» заполнена, поэтому происходит ​​подсчет количества месяцев, дней, часов с моменте смены стадии. Подсчёт осуществляется с помощью следующих функций:

   – datediff({=System:Now}, {{Дата смены стадии (техническое поле)}}, '%m month') – datediff({=System:Now}, {{Дата смены стадии (техническое поле)}}, '%d days') – datediff({=System:Now}, {{Дата смены стадии (техническое поле)}}, '%h hours')

   Отдельно вычисляется количество месяцев, дней и часов между текущей датой и датой, когда в последний раз менялась стадия. Полученные результаты заносятся в переменные.

   5. Далее проверяется значение поля «Предыдущая стадия (техническое поле)». Для каждой стадии создано поле, куда заносится количество часов, которое прошло с момента попадания на данную стадию. В это поле количество часов добавляется с помощью следующей формулы:

   ={{Количество часов на стадии «Создан NMD аккаунт» в воронке «Новый клиент» (техническое поле)}}+{=Variable:Variable1}*720+{=Variable:Variable2}*24+{=Variable:Variable3}

   Таким образом, каждый раз после смены стадии в пользовательское поле добавляются часы, которые сделка провела на данной стадии.

1. 6. Заполнение поля «Логирование даты изменения стадий». Это множественное строчное поле, в которое заносится дата изменения стадии, с какой стадии на какую произошло изменение и кто ее изменил: {=System:Now} Стадия изменена: {{Предыдущая стадия (воронка новые) (техническое поле) > printable}} -> {{Стадия (текст)}} пользователем {=Template:TargetUser > printable}

   7. Заполнение поля «Количество часов на всех стадиях». Это множественное строчное поле. Сначала поле очищается бизнес-процессом от предыдущих значений. Далее в множественную строчную переменную «Количество часов на всех стадиях» заносятся значения для всех стадий по следующей логике:

   Новая: {{Количество часов на стадии «Новая» в воронке «Новый клиент» (техническое поле)}} часов

   Назначен пресейл: {{Количество часов на стадии «Назначен пресейл» в воронке «Новый клиент» (техническое поле)}} часов.

   И так далее для последующих стадий.

   Таким образом, в множественной строчной переменной появляется несколько строчных элементов, отображающих количество часов.

   Далее с помощью действия бизнес-процесса «Итератор» бизнес-процесс берёт значение каждого элемента переменной «Количество часов на всех стадиях» и заносит в множественное строчное поле. В итоге в одном поле появляется актуальная информация о количестве часов нахождения сделки на всех стадиях.

   8. После подсчета времени для каждой стадии, логирования даты и заполнения общего поля бизнес-процесс фиксирует текущее время в поле «Дата смены стадии» и текущую стадию в поле «Предыдущая стадия (техническое поле)», после чего завершается.

2. Настроили систему фильтров для составления отчетов по времени работы со сделками

   В фильтрах можно указать ответственного, выбрать время для этапа (например, больше допустимого) и увидеть список сделок, в которых итоговое время превышает регламентированное значение.

Результат внедрения

1. Повышение прозрачности работы менеджеров.

   Руководители получили возможность видеть фактическое время, которое менеджеры затрачивают на работу со сделками, и сопоставлять его с этапами воронки. Это позволило перейти от оценки процесса «по ощущениям» к более объективному анализу работы команды.

2. Быстрое выявление проблемных сделок.

   Данные об активности на стадиях воронки продаж и затраченном времени помогают замечать сделки, на которых работа занимает слишком много времени и оперативно находить причины задержек.