3 необычных кейса использования RetailCRM

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

Артём Данильчик, основатель компании-интегратора Radis, рассказал, что задача партнёра в таких случаях — настроить функционал оптимально для клиента. Чтобы максимально задействовать CRM и минимизировать издержки. В статье Артём поделился тремя необычными кейсами, как Radis помогли клиентам грамотно адаптировать RetailCRM под свой бизнес.

Задача

Клиент Radis производит и продаёт женское нижнее бельё. В поисках точек роста компания решила вывести на рынок новый продукт — подписку на товары.

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

Решение

Radis реализовали механику подписки в RetailCRM. Старт её происходит на сайте, а дальше процесс идёт внутри CRM-системы.

Как работает:

1. В специальной форме на сайте клиент оставляет свои данные: размеры, какой материал предпочитает, цвет, дополнительные параметры.

2. В блоке оплаты он вводит данные карты, которые уходят в процессинговый центр.

3. Когда на сайт возвращается информация, что деньги сняты и подписка создана, это отражается в карточке клиента в RetailCRM. В пользовательском поле «Подписка оформлена» появляется «Да»:

Все дополнительные параметры — размер, цвет, пожелания — также переносятся в пользовательские поля RetailCRM.

4. В момент появления параметра «Подписка оформлена» в RetailCRM автоматически создаётся заказ. Менеджер забирает его и обрабатывает: собирает состав заказа и передаёт в доставку.

5. Через 30 дней автоматически создаётся ещё один заказ, потом ещё, и так до тех пор, пока клиент на сайте не отменит подписку. А если он её отменяет, в RetailCRM передаётся параметр «Подписка отменена», и триггеры перестают работать.

Задача

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

Чтобы расширить ассортимент, в компании придумали делать наборы с уже готовой едой. Доставлять такие заказы нужно сразу, день в день. То есть, моментально реагировать и не пропускать их.

Изначально Radis настроили работу кухни в окне RetailCRM. Но из-за шума повар мог пропустить заказ или не успеть отправить его на доставку. Клиенты были недовольны, лояльность снижалась.

Решение

Сначала клиент попросил добавить для новых заказов громкий звук. Повара сразу его услышат и проверят новые заказы в RetailCRM. Но Radis пошли дальше и сделали монитор событий.

«Мы обратились к примерам сильных игроков фуд-рынка — Додо Пицца, Бургер Кинг. У них везде стоят мониторы, на них отображаются составы заказов и статусы. Они меняют цвета, а дальше уже сами повара работают с заказами прямо на экране. Мы пошли тем же путём. Сделали монитор событий»

Работникам кухни больше не нужно было пользоваться RetailCRM напрямую. Всё свелось в один дашборд в зоне кухни.

Работа стала строиться так:

1. Сотрудник включает систему. Далее на экране всплывают текущие заказы, которые пока не обработаны и не приготовлены. Для них указаны номер, тип доставки, блюдо, его количество и комментарий клиента. Например, если у него аллергия, комментарий об этом отобразится в заказе.

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

3. У заказа есть 2 кнопки — «Печать» и «Готово». Если нажать «Готово», заказ удалится с монитора, а в RetailCRM перейдёт из статуса «Передано в производство» в статус «Произведено».

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

Задача

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

Решение

Механизм реализовали с помощью пользовательских полей и триггеров в RetailCRM. Вот какие настройки сделали:

1. Создали в RetailCRM два скрытых нередактируемых пользовательских поля. Первое — «Первоначальная сумма товаров по заказу с сайта». Второе — «Продажа | допродажа по заказу менеджером». Оба поля с типом Число.

2. Затем сделали несколько триггеров, которые формировали механизм расчёта.

Первый триггер заполняет поле «Первоначальная сумма товаров по заказу с сайта» при поступлении нового заказа из корзины. Если появляется новый заказ со способом оформления через корзину, то в пользовательское поле идёт вся сумма заказа.

3. На следующем этапе фиксировали первоначальную сумму по товарам в заказах, которые перешли из статуса заказа «Брошенная корзина» в статус «Новый заказ» по API. То есть, что именно покупатель оформил заказ на сайте, а не менеджер дооформил после звонка.

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

4. Третий триггер рассчитывает сумму продаж и допродаж менеджером. Фиксирует её в пользовательском поле «Продажа | допродажа по заказу менеджером».

Триггер отслеживает момент изменения заказа и момент, когда меняется общая сумма. Если заказ пришёл с сайта, то в поле запишется дельта между новой суммой и той, которую зафиксировали ранее в поле «Первоначальная сумма». То есть, допродажа.

Если заказ оформлен вручную, то в пользовательское поле попадёт вся сумма. То есть, продажа.

В истории заказа фиксируется, что триггер отработал:

5. Первоначальная итоговая сумма по заказу в будущем может уменьшиться. Поэтому настроили четвёртый триггер, который обнулял сумму допродажи менеджера. Менеджер не сможет заменить товары или как-то ещё повлиять на показатели, и ему не начислится лишний KPI.

6. Ещё нужно было учесть, что если заказ отменяется из любого статуса, то поле допродажа менеджером также обнуляется. Триггер был такой:

В истории заказа работа триггера выглядит так:

7. Последний этап — расчёт бонуса менеджеру. Когда заказ переходит в статус «Выполнен», добавляется расход «Бонусы сотрудникам». Значение берётся как 10% от суммы в пользовательском поле «Продажи | допродажи менеджерами»:

Бонусы начисляются в течение месяца. В конце месяца руководитель заходит в аналитику по менеджерам и смотрит, сколько каждому сотруднику дополнительно KPI прилетело по допродажам.


Все триггеры по третьему кейсу вы можете настроить в RetailCRM самостоятельно. А если появятся вопросы, напишите нам в Telegram. Вместе с партнёрами поможем справиться с любой нестандартной задачей.