Настройка бизнес-процесса
по учету времени работы
на стадиях сделки в Битрикс24:
кейс IT-компании
Задача клиента
Клиенту требовался инструмент для контроля времени работы менеджеров на каждой стадии работы со сделкой. Руководству важно было видеть, где сделки задерживаются, понимать причины таких задержек и вовремя выявлять случаи, требующие вмешательства.
О клиенте
NGENIX - IT-компания, занимается развитием облачной платформы, защитой от DDoS, ботов и взломов.
Проблема
На момент обращения сотрудники компании работали с воронками продаж в Битрикс24, но время работы на каждом этапе сделки не фиксировалось. Руководство не видело на какой стадии возникают проблемы и время работы затягивается, поэтому было сложно понять причину — особенности самой сделки или действия менеджера. В результате проблемные сделки могли оставаться без внимания дольше необходимого, а руководителям было сложнее контролировать работу команды и вовремя реагировать на отклонения от регламента.
Требуется понять, где возникают задержки в работе со сделками? Оставьте заявку на консультацию по настройке бизнес-процесса по учету времени работы на каждом этапе сделки в Битрикс24.
Почему выбрали Битрикс24
Компания уже использовала Битрикс24 в работе, требовалось расширить функционал в части контроля работы со сделками. Руководству необходимо видеть, какое количество времени сделка была на каждой стадии, чтобы в дальнейшем анализировать полученную информацию в разрезе каждого сотрудника, отделов, и выявлять слабые стороны в отработке сделок, отлаживать скорость реакции сотрудников на каждом из этапов. В Битрикс24 можно настроить бизнес- процесс, который позволит отслеживать изменение стадии в сделке и фиксировать общее время нахождения на каждой из стадий.
Какие задачи поставили в работу для решения проблемы клиента?
- Настроить бизнес-процесс «Учет времени нахождения сделки на стадии»
Что было сделано
Настроили бизнес-процесс «Учет времени нахождения сделки на стадии»
Бизнес-процесс работает на создание и изменение сделки. Подсчет времени настроен для двух воронок по следующему сценарию:
2. Проверка смены стадии. Поверка реализована через пользовательское техническое поле «Предыдущая стадия (техническое поле)». Если текущая «Стадия» не равна значению в поле «Предыдущая стадия (техническое поле)», значит, стадия поменялась, либо это новая сделка. Переход к следующему этапу. Если значения этих полей равны, значит, стадия, не менялась, бизнес-процесс завершается.
3. Проверка технического поля «Дата смены стадии». Если это поле не заполнено, значит, сделка является новой, в поле «Дата смены стадии» заносится текущая дата, в поле «Предыдущая стадия (техническое поле)» заносится текущая стадия. Бизнес-процесс завершается. Далее на этой сделке бизнес-процесс будет срабатывать на изменение и сразу завершаться, пока в ней не поменяется стадия.
4. Как только в этой сделке сменится стадия, снова происходит проверка воронки, смены стадии, даты смены стадии. В этом случае «Дата смены стадии» заполнена, поэтому происходит подсчет количества месяцев, дней, часов с моменте смены стадии. Подсчёт осуществляется с помощью следующих функций:
– datediff({=System:Now}, {{Дата смены стадии (техническое поле)}}, '%m month')
– datediff({=System:Now}, {{Дата смены стадии (техническое поле)}}, '%d days')
– datediff({=System:Now}, {{Дата смены стадии (техническое поле)}}, '%h hours')
Отдельно вычисляется количество месяцев, дней и часов между текущей датой и датой, когда в последний раз менялась стадия. Полученные результаты заносятся в переменные.
5. Далее проверяется значение поля «Предыдущая стадия (техническое поле)». Для каждой стадии создано поле, куда заносится количество часов, которое прошло с момента попадания на данную стадию. В это поле количество часов добавляется с помощью следующей формулы:
Таким образом, каждый раз после смены стадии в пользовательское поле добавляются часы, которые сделка провела на данной стадии.
- Проверка воронки. Если воронка подходящая, переход к следующему этапу
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}
Таким образом, каждый раз после смены стадии в пользовательское поле добавляются часы, которые сделка провела на данной стадии.
6. Заполнение поля «Логирование даты изменения стадий». Это множественное строчное поле, в которое заносится дата изменения стадии, с какой стадии на какую произошло изменение и кто ее изменил:
{=System:Now} Стадия изменена: {{Предыдущая стадия (воронка новые) (техническое поле) > printable}} -> {{Стадия (текст)}} пользователем {=Template:TargetUser > printable}
7. Заполнение поля «Количество часов на всех стадиях». Это множественное строчное поле. Сначала поле очищается бизнес-процессом от предыдущих значений. Далее в множественную строчную переменную «Количество часов на всех стадиях» заносятся значения для всех стадий по следующей логике:
И так далее для последующих стадий.
Таким образом, в множественной строчной переменной появляется несколько строчных элементов, отображающих количество часов.
Далее с помощью действия бизнес-процесса «Итератор» бизнес-процесс берёт значение каждого элемента переменной «Количество часов на всех стадиях» и заносит в множественное строчное поле. В итоге в одном поле появляется актуальная информация о количестве часов нахождения сделки на всех стадиях.
8. После подсчета времени для каждой стадии, логирования даты и заполнения общего поля бизнес-процесс фиксирует текущее время в поле «Дата смены стадии» и текущую стадию в поле «Предыдущая стадия (техническое поле)», после чего завершается.
{=System:Now} Стадия изменена: {{Предыдущая стадия (воронка новые) (техническое поле) > printable}} -> {{Стадия (текст)}} пользователем {=Template:TargetUser > printable}
7. Заполнение поля «Количество часов на всех стадиях». Это множественное строчное поле. Сначала поле очищается бизнес-процессом от предыдущих значений. Далее в множественную строчную переменную «Количество часов на всех стадиях» заносятся значения для всех стадий по следующей логике:
Новая: {{Количество часов на стадии «Новая» в воронке «Новый клиент» (техническое поле)}} часов
Назначен пресейл: {{Количество часов на стадии «Назначен пресейл» в воронке «Новый клиент» (техническое поле)}} часов.
И так далее для последующих стадий.
Таким образом, в множественной строчной переменной появляется несколько строчных элементов, отображающих количество часов.
Далее с помощью действия бизнес-процесса «Итератор» бизнес-процесс берёт значение каждого элемента переменной «Количество часов на всех стадиях» и заносит в множественное строчное поле. В итоге в одном поле появляется актуальная информация о количестве часов нахождения сделки на всех стадиях.
8. После подсчета времени для каждой стадии, логирования даты и заполнения общего поля бизнес-процесс фиксирует текущее время в поле «Дата смены стадии» и текущую стадию в поле «Предыдущая стадия (техническое поле)», после чего завершается.
Настроили систему фильтров для составления отчетов по времени работы со сделками
В фильтрах можно указать ответственного, выбрать время для этапа (например, больше допустимого) и увидеть список сделок, в которых итоговое время превышает регламентированное значение.
Результат внедрения
- Повышение прозрачности работы менеджеров. Руководители получили возможность видеть фактическое время, которое менеджеры затрачивают на работу со сделками, и сопоставлять его с этапами воронки. Это позволило перейти от оценки процесса «по ощущениям» к более объективному анализу работы команды.
- Быстрое выявление проблемных сделок. Данные об активности на стадиях воронки продаж и затраченном времени помогают замечать сделки, на которых работа занимает слишком много времени и оперативно находить причины задержек.
Нужно видеть, на каких сделках и этапах менеджеры теряют время? Оставьте заявку, чтобы обсудить настройку учета времени при работе с воронками продаж в Битрикс24.
Необходимо сделать контроль работы со сделками более системным?
Оставьте свою заявку. Мы перезвоним в рабочее время.