Задачи проекта

Традиционно, компания Самбери вела бизнес в офлайн. Проект, с которым пришел заказчик - пилотный в компании, от качества проработки решения как на этапе MVP, так и заложенной в него масштабируемости зависит, полетит ли он и насколько быстро начнет приносить пользу.

Задача - реализовать возможность заказа клиентом товара на сайте, проследить его заказ в ЛК, и потом забрать самостоятельно заказ в магазине или оформить доставку.

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

• при заказе товара на сайте можно указать сразу аналоги товаров (чтобы наборщик знал, чем можно заменить товар, если его нет)

• можно указать товар, ключевой в заказе. Если его нет, то набор остальных товаров, сопутствующих ему, не имеет смысла.

• в силу того, что магазины находятся на значительном расстоянии друг от друга, клиент выбирает на сайте, где он будет забирать (или откуда ему будут доставлять) и цены в разных городах могут отличаться на один и тот же товар. Кроме того, цена на сайте в принципе является справочной, а реальные цены в большинстве случаев не превышают её. (система выбирает для сайта максимально возможную цену для данного города).

• при заказе можно указывать, кто будет получать товар. Так, например, можно покупать продукты бабушке и не переживать.

• Ассортимент зависит от города. Товары 18+ не кладутся в корзину, если совершеннолетие пользователя не подтверждено.

В общем, много нестандартного обмена :-)

Система в целом выглядит так: несколько 1С на стороне заказчика, сайт на БУС (параллельно создавала другая студия) и цепочка обработки заказов в Битрикс24. На стороне заказчика работала сильная слаженная команда, которой приходилось координировать действия как с внутренними службами (1С), так с сайтом и нами.

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

Срок реализации был поставлен в 3 месяца (запуск в итоге сдвинулся на 2 месяца, но не по нашей вине).

Идеальный старт для этапа аналитики! Погнали!

Решение

• как решили сделать в Б24

• что было стандартно, что доработка

• почему так решили, плюсы решения

• почему именно Б24

В Б24 задействованы модули CRM, Задачи и уведомления.

Дополнительно были реализованы:

• передача с сайта расширенных данных о заказе

• передача на сайта стадий сделки (в ЛК клиента на сайте)

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

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

• интерфейс окна администратора. Роль администратора - обеспечить быстрый и корректный набор заказа и передача товара в самовывоз/доставку, а также отчетность за переданный клиенту заказ.

• уведомления и напоминания внутри системы

• отправка различных e-mail и SMS в зависимости от состояния заказа.

Основой системы стала цепочка сопровождения заказа. После аналитики решили строить, что называется, “без единого гвоздя” - полное администрирование цепочек с помощью админского интерфейса. Основных цепочек стало через какое-то время 2: цепочка создания заказа и информационная цепочка. Расскажем поподробнее.

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

рис 1. Основная цепочка действий

Информационная цепочка необходима для того, чтобы на каждой стадии/задачи указать причину отмены заказа (неуспешного завершения сделки) и потом, мы ее подставляем в конце, когда сделка завершена (по умолчанию, все плохие сделки завершаются сначала на стадии “Отмена заявки”).

рис 2. Неуспешные стадии сделки, они же причины отмены заказа

Пройдемся по цепочке.

Каждая стадия сделки рождает задачу на ответственного. У задачи есть наблюдатели, крайний срок ее решения, уведомления в случае просрочки. Также, доступна отложенная постановка задачи (когда задача появляется у исполнителя не сразу, а через обозначенный срок, чтобы не мешалась). Закрытие задачи - переносит стадию сделки. Все делаем автоматически.

• сначала Оператор проверяет реальность поступившего с сайта заказа, уточняет детали,

• затем, несколько задач на Администратора, чтобы он подготовил заказ,

• заказ уходит на самовывоз или доставку

• доставка

• клиент забирает товар или ему доставляют

• администратор получает от курьеров отчет о доставке (возврат товара / передача денег)

• в случае отказа по любой причине, заказ либо аннулируется либо расформировывается.

Какие будут поставлены задачи - настраивается в админке. Сами задачи ставятся на основании шаблонов, там задается название, описание, чек-листы, инструкции и прочее. (ТС означает тайм-слот, это промежуток, в который должна быть сделана задача, диапазон времени, соответственно, настраивать можем как от нижней границы так и от верхней):

рис 3. Админский интерфейс постановки задач

А вот когда будут поставлены задачи - указывается в настройках завершения задач и перехода на следующую стадию:

рис 4. Админский интерфейс настройки завершения задач и стадий сделок

Для того, чтобы это работало, мы немного доработали задачи (конечно, они обновляются!) - добавили кнопку “Неуспешное завершение заказа”, нажатие на которое запускает сделку по маршруту отказа (в зависимости от того, когда она нажата - могут быть разные маршруты, см. рис. 4). Также, тут видно, что на определенных стадиях можно добавить в задачу кнопку, со своим текстом и цветом, нажатие на которую позволяет выбрать стадию, на которую нужно перейти (есть пара мест, где автоматика невозможна, нужен ограниченный человеческий выбор).

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

рис.5. Админский интерфейс указания причин

И тут еще одно изящное решение. Администратор или Оператор - это роли, у каждой свой набор причин, а сами причины - это стадии сделок (неуспешные). Эти стадии появляются у соответствующей роли при нажатии на кнопку в задаче “Неуспешное завершение”. Они не переводят сделку в эту стадию, просто она сохраняется в сделке, сама сделка идет по цепочке из рис.4, а когда она завершается - мы подставляем сохраненную причину в стадию сделки. И таким образом, стандартным отчетом по воронке сделок - видим полную  картину происходящего.

Ну и конечно, уведомления клиентские (на основании почтовых шаблонов и шаблонов SMS):

рис.6. Админский интерфейс настройки уведомлений клиенту

И внутренние для менеджеров:

рис.7. Админский интерфейс настройки уведомлений менеджеру

Окно Оператора было сделано для оперативной работы Оператора (казалось бы!) с заказами. Все поля фильтруются и сортируются, и конечно, обновляются моментально.

рис.8. Окно Оператора

И схожее с ним, но Администратора.

рис.9. Окно Администратора

Ожидаемый эффект

• технологический

Сохранить, естественно, обновляемость портала. Сделано.

Так как проект пилотный - обеспечить максимальную гибкость без программных доработок. Сделано, на протяжении 3 недель с момента запуска нам не пришлось дописать ни единой строчки кода. То есть, решение логически чистое.

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

• финансовый

Избегаем излишних звонков наборщиков и менеджеров клиенту, что требует особой осознанности и чёткости действий, а главное, своевременной передачи информации по всем звеньям цепочки исполнения заказа.

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

• управленческий

Проект является независимым структурным подразделением компании: это не интернет-магазин, а сервис доставки, работающий при гипермаркете. В проекте заняты отдельные кассиры, отдельные менеджеры и сотрудники колл-центра. Соответственно, и отчётность по проекту отдельная от общего объёма продаж и финансового потока.

Этапы работы

• аналитика

Аналитика в основном заключалась в исследовании формализованных алгоритмов бизнес-процессов и проектировании их реализации в портале. Отдельной задачей было спроектировать новые пользовательские интерфейсы: окно оператора и окно менеджера.

• концепция

Концепция на уровне бизнес-процессов была тщательно проработана заказчиком заранее. Заслуга УЛЬЯ в стройной элегантной концепции настройки и связки бизнес-процессов,

• установка и настройка

• доработки

• обучение, документация

Обучение было проведено на стороне заказчика, но на основе документации, предоставленной нами. Линейный персонал проходил обучение на тестовых кейсах.

Результаты

Сделано было все, что запланировали.

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

Небольшие правки в логику нам пришлось внести в паре моментов:

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

• СМС пока передаются с сайта, так как необходимо передавать номер заказа (с сайта), а не сделки (из Б24), а модуль отправки СМС (который выбрал заказчик) - не позволял отправлять дополнительные поля (в CRM номер заказа с сайта для нас является допполем).

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