23 октября 2019 года
Как снизить влияние человеческого фактора в интернет-магазине
Избегаем ошибок сотрудников с помощью валидации. 11 готовых примеров, которые вы можете применить прямо сейчас
Человеческий фактор — основная причина проблем в интернет-магазинах. Из-за него не сходится статистика в системе, увеличиваются затраты на доставку, теряется лояльность клиентов и не только.
Когда интернет-магазин небольшой, можно попытаться найти очень ответственного менеджера. С ростом магазина можно сделать систему обучения со сложным тестированием и допускать к работе только после 100% прохождения тестов. Или внедрить систему штрафов, да такую, что менеджеры будут очень внимательно заполнять данные и забудут о своей главной задаче — общении с клиентами и продажах. Бывает и так, что руководители отделов продаж в интернет-магазинах делают ручную проверку по каждому заказу.
Когда интернет-магазин небольшой, можно попытаться найти очень ответственного менеджера. С ростом магазина можно сделать систему обучения со сложным тестированием и допускать к работе только после 100% прохождения тестов. Или внедрить систему штрафов, да такую, что менеджеры будут очень внимательно заполнять данные и забудут о своей главной задаче — общении с клиентами и продажах. Бывает и так, что руководители отделов продаж в интернет-магазинах делают ручную проверку по каждому заказу.
Попробуйте retailCRM в действии
Первые 14 дней бесплатно
Нажимая на кнопку, вы соглашаетесь с условиями пользовательского соглашения
Чтобы не ставить себе палки в колёса, лучше просто настроить валидации в retailCRM. Валидация — это автоматическая проверка изменений в заказах и клиентах, которые вносит пользователь.
В этой статье будут готовые коды валидаций, которые вы сможете просто скопировать в настройки своего аккаунта. Все настройки валидаций будут для группы пользователей «Менеджеры» (символьный код "manager"). О том, как создать группу пользователей, написано в документации.
В этой статье будут готовые коды валидаций, которые вы сможете просто скопировать в настройки своего аккаунта. Все настройки валидаций будут для группы пользователей «Менеджеры» (символьный код "manager"). О том, как создать группу пользователей, написано в документации.
Как настраивается валидация в retailCRM
Чтобы создать новую валидацию, проверяющую определённое условие, нужно зайти в раздел «Администрирование» → «Настройки» → «Валидация».
Все условия валидации будут для заказа. Галочка на активности по умолчанию включена.
В строке «Название» пишем имя для валидации. Можете использовать заголовки из примеров ниже.
Символьный код — это код с разрешёнными латинскими символами, чтобы синхронизация с сайтом проходила без ошибок. Его можно не заполнять, система автоматически создаст код из названия.
Условие — сюда мы и будем вставлять коды из примеров.
Сообщение — текст, который будет выводиться в случае срабатывания валидации.
Символьный код — это код с разрешёнными латинскими символами, чтобы синхронизация с сайтом проходила без ошибок. Его можно не заполнять, система автоматически создаст код из названия.
Условие — сюда мы и будем вставлять коды из примеров.
Сообщение — текст, который будет выводиться в случае срабатывания валидации.
Подпишитесь на нашу рассылку
Кейсы, полезные материалы, примеры настроек, обновления системы
Нажимая на кнопку, вы соглашаетесь с условиями пользовательского соглашения
11 примеров валидаций
1. Менеджеру нельзя менять статус оплаты
Условие:
changeSet.hasChangedField("payments.status")
and user().hasGroup("manager")Не включайте валидацию до настройки эквайринга, так как, к примеру, Яндекс.Касса проставляет статус «Оплачен» автоматически.
Валидация сработает в момент, когда менеджер вручную изменит статус оплаты. Но возможно такое, что менеджер, при создании заказа, добавит оплату сразу со статусом «Оплачен», тогда валидация не сработает. Исключаем это следующей.
Валидация сработает в момент, когда менеджер вручную изменит статус оплаты. Но возможно такое, что менеджер, при создании заказа, добавит оплату сразу со статусом «Оплачен», тогда валидация не сработает. Исключаем это следующей.
2. Добавлена оплата сразу со статусом «Оплачен»
Условие:
((changeSet.isCreate() or order.status.code == "new")
and order.payments | contains(item => item.type.code == "bank-card"
and item.status.code == "paid"))Валидация сработает, если в заказе со статусом «Новый» менеджер добавит оплату банковской картой (символьный код "bank-card") сразу со статусом «Оплачен».
3. Нельзя сохранить заказ без указания способа оплаты
Условие:
(order.payments | length) < 1
and user().hasGroup("manager")Валидация сработает, если менеджер забыл добавить способ оплаты в заказ.
4. Сумма оплаты не совпадает с суммой заказа
Условие:
not (order.payments | reduce( (sum, x) => sum + x.amount ) == order.totalSumm)
and user().hasGroup("manager")Заказ не получится изменить, если менеджер добавил сумму оплаты не на всю сумму заказа. Исключается риск неоплаченного до конца заказа.
5. Менеджеру нельзя проставлять скидку в заказе и в целом менять общую сумму заказа
Условие:
changeSet.hasChangedField("total_summ")
and user().hasGroup("manager")Валидация сработает, если менеджер изменит общую сумму заказа, например, проставит скидку. Это подойдёт и при изменении суммы доставки.
Включайте, если заказы приходят с сайта сразу с корректными данными и менеджер не делает допродаж.
Включайте, если заказы приходят с сайта сразу с корректными данными и менеджер не делает допродаж.
6. Нельзя передавать на сборку неоплаченный заказ
Условие:
changeSet.hasChangedField("status")
and changeSet.newValue("status").code == "assembly"
and order.payments | contains(item => item.type.code == "bank-card"
and not item.status.code == "paid")Валидация сработает, если статус заказа поменяется на «Передан на сборку» (символьный код "assembly"), а статус оплаты банковской картой (символьный код "bank-card") не «Оплачен» (символьный код "paid").
7. Нельзя изменять заказ, который уже передан на сборку или доставляется
Условие:
order.status.groupCode in ["assembly", "delivery"]
and changeSet.isUpdate()
and user().hasGroup("manager")Валидация сработает, если заказ находится в одном из статусов группы «Комплектация» (символьный код "assembly") или «Доставка» (символьный код "delivery") и менеджер внёс в него изменения.
8. Нельзя передавать заказ на сборку, если не выбран способ доставки
Условие:
changeSet.hasChangedField("status")
and changeSet.newValue("status").code == "assembly"
and not order.deliveryTypeВалидация сработает, если заказ переведён в статус «Передан на сборку» (символьный код "assembly") и не указан тип доставки.
9. Запрет сохранения без указания комментария к статусу
Условие:
order.status.code == "cancel"
and not order.statusCommentВалидация сработает при смене статуса на «Отменён» (символьный код "cancel"), если менеджер забыл указать комментарий к статусу. Это используется службой контроля качества: по комментариям к статусам собирается обратная связь.
10. Плохой клиент, запрет отправлять заказ без 100% предоплаты
Условие:
order.customer.bad
and order.payments | contains( item => item.type.code == "cashondelivery"
and item.status.code != "paid")
and changeSet.hasChangedField("status")
and changeSet.newValue("status").code == "assembly"Валидация сработает, если у клиента проставлена метка BAD и в его заказе указана оплата при получении (символьный код "cashondelivery"). Тут мы разрешаем отправлять заказы таким клиентам только после 100% предоплаты.
11. Нельзя сохранить заказ без товаров, только если это не отмена
Условие:
order.quantity < 1
and not order.status.groupCode == "cancel"Валидация сработает, если заказ сохраняется без товаров во всех группах статусов кроме группы «Отмена» (символьный код "cancel").
Наталья Искандарова
Системный аналитик TARDECK
Оцените статью
Поделитесь статьёй в соцсетях
Попробуйте retailCRM в действии
Первые 14 дней бесплатно
Нажимая на кнопку, вы соглашаетесь с условиями пользовательского соглашения