Digital-трансформация клиентского сервиса сети гипермаркетов «Самбери»

1. Вводная задача от заказчика, проблематика, цели

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

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

• Пользователь при заказе товара указывает аналоги: готовит окрошку — отмечает, что квас можно заменить кефиром.
• Пользователь указывает ключевой товар в заказе: нет кваса — не нужно огурцов, яиц и картофеля.
• Магазины находятся на значительном расстоянии друг от друга, и цены на товар отличаются в разных городах. Клиент выбирает на сайте гипермаркет, где он заберет или откуда ему доставят заказ. Цена на сайте справочная, а реальная не превышает ее (система выбирает для сайта максимальную цену для данного города).
• При заказе пользователь указывает, кто будет получать товар. Купил продукты бабушке — указал, что пакеты заберет она.
• Ассортимент зависит от города.
• Товары 18+ нельзя положить в корзину, если совершеннолетие пользователя не подтверждено.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Мы задействовали модули CRM, Задачи и Уведомления. Основой системы стала цепочка сопровождения заказа. После аналитики решили строить «без единого гвоздя» — полное управление цепочками с помощью админского интерфейса.

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

• передача с сайта расширенных данных о заказе;
• передача на сайт стадий сделки (в личный кабинет клиента);
• цепочка сопровождения заказа. Каждая стадия сделки порождает задачу ответственному за данный этап заказа. Завершение задачи переводит сделку на следующую стадию. Задача может завершиться как успешно, так и не успешно (отмена заказа по любой причине). Причины необходимо хранить в сделке для маркетингового анализа;
• интерфейс окна Оператора. Задача Оператора — сопровождать заказ до завершения. Все данные, необходимые для оперативного контроля, доступны в одном окне. С клиентом общается только Оператор (за исключением доставки, где клиенту может позвонить курьер);
• интерфейс окна Администратора. Роль Администратора — быстро и правильно набрать заказ, передать товары в самовывоз/доставку, а затем — отчитаться за выполненный заказ;
• уведомления и напоминания внутри системы;
• отправка e-mail и SMS в зависимости от состояния заказа.

Основных цепочек сопровождения заказа две: цепочка создания заказа и информационная цепочка.Основных цепочек сопровождения заказа две: цепочка создания заказа и информационная цепочка.

Цепочка создания заказа

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

Информационная цепочка

Необходима, чтобы на каждой стадии указать причину отмены заказа — неуспешного завершения сделки. Причина отображается на своей стадии, когда сделка завершена (по умолчанию все плохие сделки завершаются сначала на стадии «Отмена заявки»).

Накопление данных о причине отмены строится на стадиях сделок (как и все решение). Заказ может быть не выполнен по следующим причинам:

• Отказ клиента. Об этом знает только Оператор, поскольку клиент отказывается по телефону. Оператор должен быстро и безошибочно донести эту информацию и сохранить ее в CRM.
• Технические причины. Нет товара, нет ключевого товара или иное. Хозяин этого процесса — Администратор. Информация также должна быстро дойти до Оператора и остаться в сделке.
• Причины при доставке. Отвечает за эти причины курьер — он указывает их при неудачном завершении задачи на доставку.

Мы расширили блок «Причины неудачного окончания» в сделке, указав там все ситуации отмены. Теперь маркетологи «Самбери» при анализе воронки получают максимум информации из стандартных отчетов.

При неуспешном закрытии сделки необходимо выбрать причину, причем их набор отображается в зависимости от роли в системе. Оператор может выбрать только клиентские причины, Администратор — только технические, а курьер — только причины при доставке.

Как переносятся стадии сделки

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

• Оператор проверяет, реален ли заказ с сайта, уточняет детали.
• Администратор получает несколько задач на подготовку заказа.
• Заказ уходит на самовывоз/доставку — Администратор снова получает задачу.
• Администратор успешно закрыл задачу — получил задание отчитаться. Задача отчитаться может быть закрыта только успешно; после нее сделка закрывается как успешная.
• Неуспешно закрытая задача ставит задачу расформировать заказ (может быть закрыта только успешно, но сделка после нее становится неуспешно закрытой: денег-то не получили).

Как и когда ставятся задачи

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

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

Для этого мы доработали задачи:

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

Уведомления: для клиента и для менеджера

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

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

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

3. Результаты сотрудничества

Проект не завершился: стоят задачи по созданию дополнительных отчетов, в которых отображалось бы время между операциями — так, маркетинг «Самбери» получит новое поле для работы и улучшения сервиса. Также планируются сервисные доработки окон Оператора и Администратора (цветовое кодирование, добавление полей). Отдельно мы работаем над механизмом реализации тайм-слотов, который будет синхронизирован с сайтом, чтобы обеспечивать обратную связь по загрузке сотрудников.

Наряду с поддержкой портала Улей будет поддерживать и развивать сайт «Самбери». Благодаря этому мы ожидаем гармоничного развития экосистемы продаж.