1. Главная
  2. Блог
  3. Кейсы
  4. Автоматизация Call центра обеспечение товарами (Битрикс24 коробочная версия)

Автоматизация Call центра обеспечение товарами (Битрикс24 коробочная версия)

1 Апреля 2019
318

Входящие данные: 

  • Клиент - торгующая организация;
  • Коробочная версия Bitrix 24;
  • Call центр состоящий из восьми сотрудников;
  • Отдел обеспечение (категорийные менеджеры) шесть сотрудников.

Цель:

  • Автоматизировать процесс получения информации о возможности поставить товар с указанием сроков и контролем исполнения;
  • Автоматизировать список заказа товара для менеджеров обеспечения;
  • Автоматизировать возврат неликвидного товара поставщику в кратчайшие сроки;
  • Свести к минимуму общение в мессенджерах;
  • Обеспечить контроль исполнения заявок на обеспечение;
  • Ускорить работу за счет ограничения по времени на исполнение и обработку;
  • Вести учет просроченных сделок;
  • Ускорить работу отделов.

Ситуация:

 
В компании существует два отдела которые тесно взаимодействуют между собой по средствам телефонной связи и общением в различных мессенджерах (Битрикс/Viber). Call центр принимает заявки на продажу товаров, создает сделку в ней же присутствуют необходимые товары требуемые к обеспечению (товарные позиции разные, информация об остатках отсутствует), в последствии связывается с отделом обеспечения (категорийные менеджеры) и запрашивает в чате информацию по товарам в сделке, ожидает ответ и принимает решение о дальнейшей судьбе сделки.

Поиск решений:

На сегодняшний день CRM Bitrix имеет огромный функциональный запас для работы почти в любой сфере и структуре, однако некоторые моменты требует доработки, иногда достаточно существенной.
При детальном изучении поставленной задачи мы рассматривали множество решений, начиная от внедрения чат бота ответственного за проработку каждой товарной позиции до написания комплексной системы обеспечения заявок.

Остановимся подробнее на некоторых прорабатываемых вариантах.

Бизнес процесс в ленте:

Наверно одним из самых простых вариантов реализации, бизнес процесс в ленте при запуске которого достаточно ввести товар, идентификатор сделки после чего создавалась бы задача на группу ответственных менеджеров где сотрудники отдела обеспечения самостоятельно определяют кому следует обработать данный товар, принимают к выполнению, где дают ответ по заявке.
С технической стороны это выглядело бы просто:
Бизнес процесс в ленте > Блок утверждение документа > Блок Задача (создается задача и вперед, либо отклонение процесса с описанием причины). 
В этой схеме все ничего, но контроль времени здесь можно получить только за счет ограничений по времени задачи, нет возможности контролировать принятие Бизнес процесса, для получения результата сотруднику Call центра нужно будет пройти цепочку ссылок, а это лишние клики, промахи, нервы. Несомненно можно сказать, что сюда бы добавить запись в свойство Сделки тем же бизнес процессом, добавить уведомления и так далее, но чем же упростит работу данная схема? Верно, особо ни чем.

Бизнес процессы для Сделок:

Идея имеет место быть, ручной запуск бизнес процесса который собственно получает список товаров данной сделки (только вариант Блок PHP код), создает задачу для отдела, кстати в данном варианте можно было бы установить таймер проверки результата закрытия задачи, и в случае если задачу успешная к примеру сменить стадию Сделки, написать комментарий или внести запись о выполнение в свойство сущности Сделка. И тут тоже появляется много подводных камней, таких как:
    1. Как узнать результат обработки заявки не выходя из просмотра карточки сделки?
    2. Как контролировать сроки обработки, видеть этапы?
    3. Как указать комментарий для менеджера (если вдруг нужно)?
    4. И много, много, много другого

Чат бот:

Это наверно самая интересная идея для решения задачи. Давайте представим себе Чат бота, который отвечает за все это, принимает заявки от Call центра, передает их в отдел обеспечений, контролирует время, при желании может вносить изменения в сделки это ведь круто да?
Да, круто звучит, круто выглядит, но работать не практично. Мы привязываем Call центр опять-таки к чату, мы попросту обяжем каждого сотрудника работать в чате, копировать в чат товары, писать им ответы, а это запутает любого человека. Также не забываем про вопрос формирования списков заявок, хранению истории.
Эти все моменты можно решить благодаря RestAPI но по сути мы создаем отдельную сущность для хранения данных, товаров, запросов. Тайминги уже должны работать не на стороне Б24, а на стороне приложения, распределение прав доступа также попадает под вопрос, в общем эту идею мы были вынуждены тоже отодвинуть.

Встраиваемое приложение:

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

Что получилось и как решили:

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

Встраиваемое приложение в табы для сущности CRM сделки в которой будет отображаться список товаров присутствующих в сделке с отображением кнопки "Обеспечить" и возможностью добавить комментарий к каждой позиции.

В сущность CRM Сделки добавить свойство:

Список - Статус товаров к обеспечению (Нет товаров к обеспечению, Ожидает обеспечения, Обеспечена)
Статусы товара внешнее приложение попавшего к обеспечению может быть "Не обработан", "Обработан", "Предзаказ", "Отменен":
Не обработан - статус у вновь созданной заявки на обеспечение товара.
Обработан - статус у обработанной заявки с установленной датой поставки.
Предзаказ - статус у товара на который требуется предзаказ с длительным ожиданием.
Отменен - статус товара которого нет в наличии, невозможно заказать или при отмене сделки.
Универсальный список Обеспечение товаров с полями:
  1. Имя - Товар
  2. Число - Количество товаров
  3. Число - Цена товара
  4. Текст - Ссылка на сделку
  5. Число - ID Сделки (Скрытое)
  6. Связь с пользователем - Ответственный (Скрытое)
  7. Список - Статус
  8. TEXT/HTML - Комментарий менеджера
  9. TEXT/HTML - Комментарий Call центра
  10. Дата/Время - Дата создания (Скрытое)
  11. Дата/Время  - Дата изменения (Скрытое)
  12. Список - Поставщик
  13. Дата - Дата поставки
  14. Список - Заказать поставщику
  15. Список - Заказан поставщику
  16. Список - Предзаказ
  17. Список - Неликвидный товар
  18. Список - Вернуть поставщику
  19. Список - Обеспечение подтверждено (Скрытое)
  20. Список - Товар забран клиентом
  21. Список - Товар вернули поставщику

Универсальный список Просрочки по сделкам с полями:
  1. Имя - Название товара
  2. Число - ID Сделки
  3. TEXT/HTML - Описание
  4. Число - Баллы

В Универсальном списке Обеспечение товаров создать пресеты фильтров:
  • Заявки
  • Ожидает подтверждение заказа
  • Необходимо заказать
  • Заказано
  • Вернуть поставщику
  • Вернули поставщику
  • Предзаказ
  • Отказ клиента
  • Отменен
Тем самым вопрос с правами доступа решается сам собой, в рамках приложения мы разграничиваем доступ пользователей, в рамках Универсального списка мы также можем разграничить права доступа как того требует внутренний распорядок клиента.

Список товаров для заказа будет вестись в универсальных списках, почему так? Да все потому, что там уже есть все необходимое, возможность создания любых типов полей, возможность создания пресетов фильтрации, а также Бизнес процессы!

Далее


  После добавления к обеспечению перевести сделку в статус "Обеспечение товара", запустить 30 минутный таймер обеспечения сделки, после 20 минут оповестить ответственного за сделку о возможной просрочке и необходимости принять меры (ускорить менеджеров, запросить продление), еще через 10 минут проверить стадию сделки, если стадия сделки изменена завершить таймер, иначе внести запись в Универсальный список просрочек по сделкам.
Запретить смену стадии сделки, если есть не обеспеченные товары.

Далее


 - После добавления товара в Универсальный список Обеспечение товаров оповестить в общий чат Менеджеров обеспечения о появлении новой заявки, с возможностью перехода в редактирование заявки из чата по ссылке, с отображением информации о пользователе открывшим ссылку или открывшим товар из списка внутри интерфейса Битрикс24 Универсальные списки, после обработки очистить сообщение со ссылкой на товар к обеспечению.
 - Параллельно запустить таймер на 15 минут для созданного товара в списке с оповещением в чат о возможной просрочке через 10 минут, если не обработан еще через 5 минут внести запись о просроченной заявке к обеспечению. 

Далее


 - После смены статуса сделки с "Обеспечение товара" на "Отгрузка" в заявке Универсального списка Обеспечение товаров на товар со свойством Заказать поставщику сменить свойство Обеспечение подтверждено - Да для перехода в пресет фильтра Необходимо заказать.

Далее


 - При отмене сделки и наличию в ней неликвидного товара по информации из Универсального списка Обеспечение товаров с пометкой вернуть поставщику, оповестить в общий чат Возврат товара, внести изменение в свойство Статус - Отменен.

 - При успешном завершении сделки и наличии в нем заявки с товаром в Универсальном списке Обеспечение товаров внести изменение в свойство Товар забран клиентом - Да.

 - При успешном завершении сделки и наличии в нем заявки с товаром в Универсальном списке Обеспечение товаров внести изменение в свойство Статус - Отменен.


Теперь про принцип работы

Сотрудник Call Центра создает сделку добавляет товары.

Переходит во вкладку "Обеспечение товаров" приложение:

Обеспечение товаров


На необходимых товарах кликнет кнопку Обеспечить (добавляя при необходимости комментарий):

Заявка на обеспечение


Сотрудники отдела обеспечения видят в чате новую заявку, эту же заявку видно и в Универсальном списке Обеспечение в пресеты фильтра Заявки:

Список заявок

Заявка_чат


Менеджер обеспечения ответственный за группу товаров открывает заявку, обрабатывает:

Обработка заявки


Сотрудник Call центра получает уведомление об обработанных всех товарах, или фильтрует по свойству сделки Статус обеспечения:

Фильтр


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

Если сделка согласована:
Заявка в универсальном списке переходит в пресет фильтра Необходимо заказать
Сотрудник отдела обеспечения создает заказ у поставщика и отмечает свойство Заказан поставщику - Да

Если по сделке отказ:
Заявка в универсальном списке меняем свойство Статус - Отменен, переходит в пресет фильтра Отменен

Если по сделке отказ после успешного завершения сделки:
Если в заявке Универсального списка свойство Вернуть поставщику - Да, присылаем оповещение в чат возвратов, меняем свойство Статус - Отменен


Фильтр списка

Рисковый



Техническая реализация

  • Разработано выстаиваемое приложение с использованием RestAPI которое отвечает за подачу заявок к обеспечению.
  • Разработан робот работающий по RestAPI, регулярно опрашивает Универсальные списки и следит за появлением новых записей, шлет сообщения в чат, контролирует открытие документов, вносит изменения в сообщения/удаляет сообщения (раз в 30 секунд).
  • Внешнее приложение работающее по RestAPI подписанное на изменение в Универсальных списках и Сделках следит за статусами товаров в универсальных списках и двигающее их по пресетам фильтров внося изменения на основании совокупности условий.
  • Бизнес процессы для Универсальных списков следят за таймингами и пишут сообщения о просрочках в универсальные списки.
  • Бизнес процессы для Универсальных списков, расставляют статус заявок в списках на основании заполненных полей (Дата поставки/поставщик)
  • Бизнес процессы для сделок следят за таймингами и пишут сообщения о просрочках в универсальные списки.


Посмотрите как это выглядит

Что мы использовали

+38 (095) 583-88-22
ответим на Ваши вопросы