Возможны проблемы с телефонией, пишите своему менеджеру или на почту sales@itpanda.ru
Создание и продвижение сайтов
Внедрение CRM и сквозной аналитики
Конвейер конструкторов

Конвейер конструкторов

Александр Паздников
Александр Паздников
Специалист по внедрению Битрикс24
Зачем в команде менеджер проекта и куратор?

Кейс №1. Система автоматического назначения конструкторов

Читайте до конца, и вы узнаете, как мы начали экономить клиенту 50000 рублей в год и сократили время обработки заказов от двух часов до суток.

Проблема, что нужно сделать

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

Необходимо реализовать автоматическое назначение конструктора на сделку по принципу револьвера, т.е. передавать сделки одному за другим по очереди. После того, как сделка передана последнему в списке, следующая передается снова первому, и так по кругу.

Попутные задачи:

  1. Желательно так сделать, чтобы администратор клиента мог самостоятельно вносить некоторые коррективы в работу алгоритма;

  2. Иметь возможность во время отпуска или больничного остановить распределение сделок на сотрудника;

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

  4. Необходимо лимитировать одновременное число сделок в работе у конструктора, видеть какой лимит у сотрудника и сколько сделок в данный момент у него в работе;

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

  6. В случае, когда система не может назначить конструктора, т.е. все условия для всех конструкторов не позволяют это сделать, то система должна периодически 1 раз в час проверять не освободился ли конструктор.

 

Как мы это реализовали

Для решения задачи целесообразно использовать Универсальные списки.

1 список. Храним соответствие Номер лида – Конструктор.


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

2 список. Список конструкторов.


Первым элементом этого списка делаем «технологический элемент», где во множественном поле вручную нужно сформировать список ID соответствующих конструкторов в списке. Именно этот элемент будет определять порядок следования конструкторов.

Остальными элементами заносим собственно конструкторов, где храним всю необходимую информацию для работы алгоритма.

А именно:

Индекс следующего (0 или 1) – указание того, на кого следующего будет распределена сделка;

Назначать сделки – «Да» - сотрудник участвует в распределении сделок, «Нет» - не участвует. Используется для временного или постоянного выведения сотрудника из процесса распределения сделок;

До какой даты – дата и время, до которой алгоритм должен игнорировать сотрудника, если дата не указана, то сотрудник исключен из работы алгоритма постоянно. Если дата указана, то при наступлении этого момента алгоритм распределения, автоматически меняет значение поля «Не назначать сделки» и «До какой даты» и сотрудник возвращается к процессу распределения;

Лимит – количество сделок, которое одновременно можно передать данному конструктору.

Сделок в работе – количество сделок, находящихся в данный момент в работе у конструктора, добавляется в момент постановки первой задачи, вычитается в момент закрытия последней задачи конструктора в основном бизнес-процессе работы со сделками;

Штраф за просрочку – при наличии штрафа за просрочку хотя бы по одной сделке конструктор исключается из алгоритма распределения пока не закроет просроченные задачи. «Да» - есть штраф, «Нет» - сделок со штрафом нет.

Сделок со штрафом – количество сделок, где есть просроченные задачи конструктором, по мере закрытия просроченных сделок, количество уменьшается, после того как закрыта последняя просроченная сделка автоматически меняется значение поля «Штраф за просрочку».

Бизнес-процессы

При создании любого лида, создаем элемент списка, где храним соответствие Номер лида - Конструктор, Id элемента списка пишем в специально созданное для этого поле лида.

Есть такой аспект, что элемент списка можно формировать только при создании, а не при конвертации. Есть особенность, что если поле заполнено в момент конвертации, то оно в сделку не передается. Т.е. в списке будет регистрироваться все лиды, поэтому придется список периодически чистить вручную от нецелевых лидов.

При создании сделки на основании лида, id элемента списка переходит в сделку.

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

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

Если это первая сделка на основании лида, то на стороне сделки в момент подбора конструктора обращаемся к списку по известному адресу id = 16, записываем значение поля «Список ID» в множественную переменную. Прогоняем ее через итератор, последовательно обращаемся ко всем элементам, находим индекс следующего равный 1.

Это значит, что он – кандидат на назначение, проверяем нет ли сделок со штрафом, не включен ли для него признак «не назначать сделки», если включен, то проверяем дату и время, если дата и время не заполнены, то пропускаем этого сотрудника и переходим к следующему элементу. Если дата и время заполнены, проверяем прошла она или нет. Если не прошла, то пропускаем этого сотрудника и переходим к следующему элементу. Если дата прошла, то меняем значение признака «Не назначать сделки», стираем прошедшую дату и переходим к проверке лимита.

Если значение текущего количества сделок в работе у сотрудника + 1 больше лимита, то переходим к следующему. Если не больше лимита, то назначаем сделку данному сотруднику. Устанавливаем следующему в списке индекс следующего и записываем новое значение сделок в работе.

Если последний рассмотренный конструктор был последним в очереди, индекс следующего приобретает первый элемент.

 


Если алгоритм прошел 2 итерации, а конструктор так и не назначен, т.е. у всех конструкторов в списке сработали какие-то условия, не дающие им назначить сделку, бизнес-процесс переходит в режим ожидания и каждый час проверяет не изменились ли условия и пробует назначить конструктора. Такие сделки зависают на стадии Банк заказов, т.е. всем заинтересованным видно, что распределение конструкторов остановлено и нужно принимать меры (увеличивать лимиты, закрывать задачи и т.п.)

По итогу работы алгоритма конструктора записываем в поле сделки Конструктор и дальше используем уже значение этого поля для постановки задач и переводим сделку на следующую стадию, где ставим задачу данному конструктору.

 

Результат и эффект

1. Экономический эффект. Сэкономлено в среднем 30 минут в день работы сотрудника, ответственного за назначение конструктора (при ЗП около 50 т.р.), назначение происходило ежедневно, раз в день. Кроме этого, руководитель должен был контролировать и направлять распределяющего и плюс разбираться с конфликтами и ошибками в среднем 20 минут в неделю (при ЗП около 100 т.р.). Таким образом, в месяц это 10 часов работы ответственного за распределение + 1,3 часа руководителя, в год это суммарно 136 человеко-часов, которые сэкономлены благодаря внедрению такой доработки.

Годовой экономический эффект от внедрения составляет порядка 50000 рублей в год, исходя из приблизительной заработной платы специалиста, отвечающего за распределение.

2. Исключен «человеческий фактор» при распределении сделок на конструкторов. Функция назначения конструкторов больше не тормозит процесс, назначение происходит мгновенно, как только сделка доходит до нужной стадии. Что позволяет, как минимум, в 50% случаев увеличить скорость обработки заказов на 1 день.

3. У конструкторов отсутствует возможность повлиять на распределяющего и получить себе сделку «пожирнее»

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

5. Исключение конструктора из процесса распределения при просрочке задач повышает дисциплину и обеспечивает выполнение задач в срок, а следовательно, на порядок увеличить качество сервиса в работе с Клиентами. Что, в конечном итоге, сказывается на NPS.


Поделиться в соцсетях:

Возврат к списку

Получайте новые статьи первыми
Оставьте адрес электронной почты, чтобы мы сообщили вам о новых статьях

Здравствуйте, я Олейник Виктор, Директор IT Panda. Если у Вас есть предложения или жалобы по работе нашей компании,
Вы можете сообщить их по указанным контактам:
dir@itpanda.ru
+7 (965) 548-28-69