Кейс: магазин электроники ускорил гарантийные возвраты с 3 дней до 4 часов
Кто клиент
Рознично-онлайн магазин смартфонов, ноутбуков, наушников и аксессуаров. Две торговые точки, интернет-магазин и небольшой сервисный отдел. Часть товаров ремонтируется внутри компании, часть отправляется поставщику или авторизованному сервисному партнёру.
Магазин принимал 80–120 обращений в месяц. На регистрацию уходило немного времени, но определение продажи, проверка комплектации и выбор маршрута могли занять несколько дней.
Что было до внедрения
Покупатель приносил устройство или писал в мессенджер. Сотрудник искал чек по телефону, дате, модели или примерной сумме. IMEI иногда был записан в комментарии, иногда — только на бумажном гарантийном талоне.
Дальше создавалась строка в таблице. Фотографии и переписка оставались в телефоне сотрудника. Клиент не получал автоматических уведомлений и регулярно спрашивал: «Что с моим устройством?»
Что было
- поиск продажи вручную;
- IMEI в комментариях;
- рекламации в таблице;
- фото в личных чатах;
- статус сообщается вручную.
Что внедрили
- серийный учёт;
- сканирование IMEI;
- смарт-процесс рекламаций;
- обязательный чек-лист;
- уведомления ChatApp.
Что изменилось
- видна исходная продажа;
- понятен маршрут устройства;
- контролируются сроки;
- клиент знает статус;
- есть история каждого серийника.
Цель проекта
Создать единый путь:
обращение → проверка серийного номера → исходная продажа → приём устройства → диагностика → решение → ремонт или возврат поставщику → выдача клиенту.
Сотрудник должен был за один экран понимать, что за устройство принято, когда и кому его продали, где оно находится и кто отвечает за следующий шаг.
Шаг 1. Включили учёт по серийным номерам
Для смартфонов использовали IMEI, для ноутбуков и аксессуаров — серийный номер производителя. В МоемСкладе номер стал обязательным в приёмках, отгрузках, возвратах и перемещениях.
Это позволило связать конкретное устройство с движениями:
- поступление от поставщика;
- перемещение в торговую точку;
- продажа покупателю;
- возврат;
- передача в сервис или поставщику;
- повторная выдача.
Перед включением серийного учёта проверили данные: тип учёта нельзя менять без последствий для процесса, поэтому пилот начали с одной товарной группы.
Шаг 2. Настроили карточку рекламации
В Битрикс24 создали отдельный смарт-процесс. Карточка включала:
- клиента и контакты;
- модель, IMEI или серийный номер;
- ссылку на исходную продажу;
- дату покупки и срок гарантии;
- заявленный дефект;
- внешнее состояние и комплектность;
- фото при приёмке;
- текущий адрес хранения;
- ответственного и контрольную дату;
- решение и документы выдачи.
Шаг 3. Разделили статусы и юридическое решение
Физическое движение устройства нельзя смешивать с решением по обращению. Поэтому использовали два набора признаков.
Статус процесса: принято, проверка документов, диагностика, согласование, ремонт, готово к выдаче, закрыто.
Решение: ремонт, обмен, возврат денег, отказ с основанием, отправка поставщику, негарантийный ремонт.
Так руководитель видел, где находится устройство и какое решение принято, не пытаясь вместить всё в одну длинную воронку.
Шаг 4. Добавили чек-лист приёмки
До перехода на диагностику сотрудник обязан был заполнить:
- серийный номер;
- дату и канал продажи;
- описание дефекта словами клиента;
- комплектность;
- следы повреждений и состояние;
- фотографии;
- согласие с актом приёма;
- контакт для уведомлений.
Если продажа не найдена, обращение не блокировалось. Оно переходило в отдельную очередь проверки документов, чтобы сотрудник не принимал решение на глаз.
Шаг 5. Настроили маршруты
Для каждой товарной категории определили:
- кто проводит первичную диагностику;
- куда отправляется устройство;
- какие документы нужны поставщику;
- какой срок контролируется;
- кто согласует возврат денег или обмен;
- где хранится товар на каждом этапе.
Робот создавал задачу и напоминание. Просроченное обращение попадало в отчёт руководителя, а не оставалось в личной переписке мастера.
Шаг 6. Связали Битрикс24 и МойСклад
При сканировании IMEI интеграция искала устройство и возвращала исходную продажу, дату, покупателя и движения. Из рекламации в учётную систему передавалось основание для возвратного документа.
Из МоегоСклада обратно поступали:
- номер документа возврата;
- текущий склад;
- перемещение в сервисную зону;
- возврат поставщику;
- выдача или обмен.
CRM управляла обращением и коммуникацией, а МойСклад оставался источником движения конкретной единицы товара.
Шаг 7. Подключили уведомления через ChatApp
Клиент получал сообщения при значимых событиях:
- обращение зарегистрировано;
- устройство принято на диагностику;
- нужны дополнительные данные;
- принято решение;
- устройство готово к выдаче;
- напоминание о получении.
Сообщение содержало номер обращения, но не раскрывало лишние персональные данные. Вопрос клиента попадал в привязанный диалог, и оператор видел историю.
Как контролировали сроки
Для каждого этапа задали внутренний норматив. Руководитель видел:
- новые обращения без первичного решения;
- устройства без движения;
- ожидание ответа поставщика;
- готовые, но не выданные товары;
- повторные обращения по тому же серийному номеру;
- причины отказа и возврата.
Внутренний норматив не подменял требования законодательства. Юридические сроки и формулировки компания согласовала со специалистом по защите прав потребителей.
Как проходило внедрение
- Аудит. Разобрали 150 прошлых возвратов и точки ожидания.
- Данные. Проверили серийные номера и документы продаж.
- Пилот. Включили новый процесс для смартфонов.
- CRM. Настроили карточку, стадии, задачи и права.
- Интеграция. Связали серийник, продажу и возвратные документы.
- Коммуникации. Подключили шаблоны ChatApp.
- Масштабирование. Добавили ноутбуки, наушники и другие категории.
Как рассчитан модельный эффект
Время считалось от регистрации обращения до зафиксированного первичного решения: принять на диагностику, запросить документы, направить поставщику или передать ответственному. Срок самого ремонта в показатель не включался.
Связь с исходной продажей считалась успешной, если карточка содержала документ и совпадающий серийный номер. Повторными вопросами о статусе считались сообщения и звонки клиента до следующего планового уведомления.
Сравнивались три месяца до и три месяца после запуска. Показатели являются моделью ожидаемого эффекта при аналогичном объёме обращений.
Что можно повторить
- Сделать серийный номер обязательным во всех складских движениях.
- Связывать возврат с исходной продажей.
- Разделить статус устройства и принятое решение.
- Ввести чек-лист и фотографии при приёмке.
- Определить маршрут каждой товарной категории.
- Хранить рекламацию в CRM, а движение — в учётной системе.
- Автоматически уведомлять клиента о значимых этапах.
- Контролировать просрочку на дашборде.
Как помогает KULPS
KULPS проектирует процесс возврата, настраивает серийный учёт в МоемСкладе, смарт-процесс в Битрикс24, интеграцию, ChatApp и отчётность. Начинаем с одной категории, проверяем документы и только после этого масштабируем решение.
Если сотрудники ищут продажу по переписке, а клиент узнаёт статус только после звонка, закажите аудит. Покажем, как связать каждый гаджет, документ и обращение в одну прослеживаемую цепочку.