Учет времени сделки на каждой стадии для подсчета KPI

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

ИНТЕРВОЛГА с удовольствием работает над нестандартными и сложными задачами.

Наш постоянные клиенты — представители крупной энергетической государственной компании из Черногории Cedis — обратились к нам за очередной доработкой коробочного решения Битрикс24.

Компания Cedis обрабатывает большой поток входящих заявок абонентов, на подключение, подачу документов, различные запросы населения. Им не удобно использовать в своей работе с СРМ задачи, так как с задачей сложно работать последовательно по этапам. 

Поэтому основной инструмент для них — сделки. 

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

Мы с интересом взялись решить эту задачу, и сразу выделили несколько важных аспектов, о которых расскажем в статье. 

Одна стадия может инициироваться несколько раз

Во-первых, необходимо было учитывать, что сделка может находиться на определенной стадии более одного раза. 

Например:

1. сделка в стадии Х (1 день)

2. сделка переходит в стадию Y 

3. возвращается на стадию X (2 ч) 

Отсюда возникает сразу несколько вопросов:

1. Правильно ли рассчитывать суммарное время, которое сделка проводит на определенной стадии или разбивать время в таблице? 

2. Будет ли тогда длительность нахождения сделки в стадии X равна 1 дню и 2ум часам или 26 часам — если рассматривать суммарное время?

Клиент хотел видеть полную историю по этапам. 

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

Учет времени по текущей сделке

Во-вторых, важно было учитывать, что пока сделка находится в текущей стадии — время на нее расходуется, и его тоже нужно учитывать, чтобы исключить подвисание сделок. 

Наш клиент пытался самостоятельно реализовать необходимый ему расчет времени, которое сделка проводит на одной стадии. 

Для этого они использовали бизнес-процесс со множеством пользовательских полей и функцией datediff.

По процессу обновление времени происходило только после перехода сделки в другую стадию. 

Из-за этого узнать время, уже затраченное на текущий этап сделки было нельзя.

Специалисты ИНТЕРВОЛГИ реализовали вариант подсчета времени, в котором поле Transition OUT остается пустым для сохранения видимости, что сделка все еще находится в текущей стадии и время на нее еще расходуется.

Модуль также добавляет агента в настройках для автоматических обновлений раз в час — скрипт проходит по открытым сделкам и обновляет затраченное время по стадиям.

Пользовательские поля и количество стадий сделки

Мы предложили и реализовали вариант хранения данных о продолжительности нахождения сделки на стадии в пользовательских полях.

Для каждой стадии каждой сделки мы добавили 2 пользовательских поля (длительность в стадии, время в стадии).

Но у этого метода были недостатки:

У клиента существовало около 20 направлений сделок, в каждом из которых было разное количество стадий (максимальное не превышало 15). Это значило, что нужно создать ~200 пользовательских полей.

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

Мы решили эту задачу: 

1. модуль проверяет все направления;

2. для каждого направления модуль подсчитывает существующие этапы и находит максимум;

3. затем модуль создает Пользовательские поля до тех пор, пока количество Пользовательских полей не будет соответствовать максимальному количеству Этапов;

4. при каждом обновлении модуль проверяет, требуется ли больше полей. Если это так, модуль создает новые поля, а затем выполняет обновление.

Стадии можно менять и удалять без особых трудностей. Это может привести к потере данных в пользовательских полях. Например, администратор или ответственный за сделку может удалить какое-нибудь поле по ошибке. 

Чтобы избежать потери данных, поля модуль только добавляет, но не удаляет.  

Что реализовали:

1. автоматическое создание пользовательского поля при установке модуля (для каждого направления);

2. модуль автоматически проверяет новые этапы и отслеживает информацию по ним;

3. возможность обновления затраченного времени для одной Сделки;

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

5. возможность пересчета затраченного времени для всех сделок.

Выводы

Мы реализовали новый механизм работы со сделками. 

Сделки стали более информативными, теперь можно вести учет времени сотрудников и считать их KPI, чтобы планировать график компании и видеть узкие места.

ИНТЕРВОЛГА готова помочь вам решить наболевшие бизнес-задачи. Мы не только хорошо программируем, но и умеем разбираться в сути бизнеса, чтобы найти наиболее подходящее решение для каждой задачи. 

Есть сложности или нестандартные задачи? Пишите, мы поможем вам выстроить механизмы грамотной аналитики с помощью СРМ-системы Битрикс24 и доработаем системы под вас!