RetailCRM + 1С для федеральной ювелирной сети

Ювелирный бренд федерального уровня. Интернет-магазин плюс 46 розничных салонов на момент проекта. Онлайн-продажи ведутся от двух юридических лиц.
Отдел продаж интернет-магазина — 20 менеджеров, разбитых на 5 команд.

Цели:

• Увеличить конверсию заказа в продажу.
• Ускорить обработку заказов.
• Снизить расходы на обработку заказов, не теряя эффективности.

Задачи:

• Внедрить RetailCRM и связать с 1С и сайтом.
• Автоматизировать распределение звонков и заказов по нестандартному сценарию двойной очереди.
• Автоматизировать резервирование изделий на розничных точках.
• Автоматизировать визирование перемещений в 1С.
• Автоматизировать учет бронирования товара под клиента.
• Автоматизировать формирование реестров для службы доставки.
• Автоматизировать коммуникацию между интернет-подразделением и розничными точками по всей России.

Живая очередь управлялась вручную руководителями

Когда поступал новый заказ, письмо приходило на общую почту. Его видели все менеджеры, но никто не мог взять его в работу без команды руководителя. Директор онлайн-торговли и пять РОПов вручную следили за очередностью: кто получил прошлый заказ, какая команда следующая, какой менеджер внутри команды свободен. То же самое со звонками.

Чтобы прослушать запись разговора, нужно было отправить запрос системному администратору, который скачивал нужный файл с сервера и пересылал на почту. Каждый такой запрос стоил компании денег и времени.

Просто взять и послушать звонок никто не мог: ни РОП, ни директор онлайн-торговли, ни владелец бизнеса.

Учет заказов в Google-таблицах с цветовым кодированием

После получения команды от руководителя менеджер открывал письмо и вручную переносил данные в Google-таблицу. Способ оплаты кодировался цветом ячейки: наличными — синий, наложенный платеж — красный, оплата онлайн — зеленый, самовывоз — горчичный. Никакого справочника — все цвета держали в голове.

Параллельно нужно было зайти в 1С, узнать, к какому юридическому лицу относится конкретный товар, и внести это в таблицу отдельным цветом. Несколько окон, несколько систем, ни одной системной подсказки — ошибки были неизбежны и являлись нормой работы.

Запросы брони уходили в Skype и там же терялись

Чтобы зарезервировать изделие, менеджер писал запрос в Skype-чат нужного салона в произвольной форме. Ответить мог любой, кто случайно увидел сообщение. Назначенного ответственного не было. Подтверждение могло прийти через час, а могло не прийти совсем — и это нельзя было отследить иначе как вручную перечитывая переписку.

Продавцы салонов скрывали товар от интернет-магазина

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

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

Документы для доставки заполнялись вручную

Перед каждой отправкой менеджер создавал реестр для курьерской службы и вручную вносил туда данные заказов. Критически важная деталь: у каждого салона был свой номер договора с курьерской службой — ошибка означала заявку от неверного юридического лица и проблемы с отгрузкой. Готовый реестр отправлялся на почту службы доставки и дублировался в Skype-чат салона.

Все операции в 1С создавались вручную по каждому заказу

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

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

Ключевой механизм — статус активности менеджера через API. Если менеджер работает в системе, он в очереди на получение звонка. Если статус — «неактивный» (т.е. отошел от компьютера) — менеджер временно исключается из очереди распределения, пока не вернется. Звонок от клиента, который уже есть в базе, всегда попадает к тому менеджеру, с которым клиент общался в прошлый раз, если этот менеджер на месте, иначе направляется согласно очереди.

Реализовали механизм подстраховки: если заказ, поступивший через сайт, не взят в работу за 5 минут — он открывается для всей команды, а не только для того менеджера, чья очередь обрабатывать заказ. Если никто из команды не взял заказ в работу за 7 минут — переходит к следующей команде в очереди.
Все настройки очередей, команд и телефонии собраны в едином веб-интерфейсе, разработанном нами персонально для клиента. Руководитель может менять логику самостоятельно, без запроса к системному администратору, в любое время. Запись любого разговора стала доступна прямо из карточки заказа.

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

Убрали у продавцов материальный стимул скрывать товар. Изделие, которое числилось в салоне «отложенным под покупателя» более трех дней без выкупа, влекло снижение бонусного вознаграждения для всего салона. Продлить резерв без предоплаты тоже стало невозможно.

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

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