Дилеру по телефону разрешили вернуть изделие. Менеджер отметил вопрос решённым, склад ничего не получил, а сервис уже заказал комплектующие для ремонта. Через неделю дилер спрашивает о замене, которую никто не поставил в план. В каждом отделе есть правдивая часть истории, но общего состояния рекламации нет.
Система управления рекламациями нужна, чтобы связать обещание клиенту, движение конкретного изделия и фактическое выполнение решения. Начинать стоит с одного вида продукции и понятного маршрута. Общая очередь сообщений полезна, однако сама по себе не отвечает, что вернули, кто проверил основание и чем закончилась ситуация.
Разделите четыре разных события
Обращение зарегистрировано означает, что производитель получил сообщение. Оно ещё не подтверждает причину неисправности или согласие с требованием заявителя.
Решение принято означает, что уполномоченный сотрудник определил дальнейшее действие: запросить сведения, принять на проверку, организовать ремонт, замену или другой согласованный вариант.
Изделие получено означает физический факт на конкретной площадке. Он может произойти раньше окончательного решения или значительно позже разрешения возврата.
Решение исполнено означает, что выполнено обещанное действие и сохранено подтверждение. Отправка замены и её получение дилером тоже могут быть отдельными событиями. Не пытайтесь выразить всё одним статусом «Закрыто».
Найдите изделие и исходную поставку
Карточка должна отвечать, к чему относится обращение. Для серийного оборудования это конкретный экземпляр, для расходной продукции — номенклатура, партия и количество. Номер рекламации не заменяет идентификатор изделия.
Подготовьте обязательные поля:
- заявитель и контакт для уточнений;
- исходный заказ или документ поставки;
- модель, серийный номер либо партия;
- заявленное количество и описание наблюдаемой проблемы;
- фотографии и другие необходимые материалы;
- местонахождение изделия;
- желаемое действие заявителя;
- ответственный за следующий шаг и согласованная дата.
Отсутствующий номер поставки должен вести в очередь уточнения, а не вынуждать сотрудника выбирать случайный заказ. У нескольких поставок одному дилеру могут совпадать модели, даты обращения и внешне похожие номера.
Учебный пример: два насоса из одной поставки
Представим условного производителя насосных блоков. Это модель процесса, а не описание проекта ExtentLab. Дилер получил десять блоков и сообщает о проблеме с двумя: Н-041 и Н-042. К обращению приложена фотография только первого.
В системе создают одну рекламацию с двумя отдельными позициями. По Н-041 данных достаточно, чтобы разрешить возврат для проверки. По Н-042 запрашивают фотографию маркировки и описание условий обнаружения проблемы. Нельзя автоматически распространить решение по первому экземпляру на второй.
Через три дня склад принимает Н-041 без кабеля из исходного комплекта. Он фиксирует фактический состав, состояние упаковки и дату. Это не отменяет прежнее разрешение и не доказывает причину неисправности: появились новые сведения для ответственного.
После проверки согласована замена Н-041 на Н-118. Отгрузку связывают с исходной позицией рекламации. После подтверждения получения Н-118 дилером замену отмечают выполненной. Вторая позиция остаётся на уточнении. В отчёте видно одно обращение, две позиции, одну выполненную замену и одно открытое действие.
Как не потерять частичный возврат
Одна рекламация может включать несколько изделий с разными решениями. Поэтому состояние обращения лучше получать из состояния его позиций и незавершённых действий. Общая отметка руководителя не должна скрывать незавершённую замену.
Для каждой позиции сохраните заявленное, разрешённое к возврату, фактически полученное и отправленное количество. Эти величины нельзя складывать как независимые потери: они описывают этапы движения одной продукции.
Если из пяти разрешённых изделий приехали три, остаются два ожидаемых. Если один из трёх относится к другой партии, его нужно отдельно идентифицировать. Склад не должен молча исправлять исходное обращение, чтобы количество совпало.
Внутренняя карточка помогает организовать данные. Состав документов и полномочия участников определяют по действующим условиям работы компании, а не по названию статуса в программе.
Зафиксируйте решение и его основание
В решении нужны выбранный вариант, автор, дата, основания и условия исполнения. Формулировка «согласовано» без предмета бесполезна: согласовать можно получение на диагностику, ремонт или отправку другого изделия.
Разрешение на возврат должно содержать адрес, ожидаемый состав, идентификатор обращения и контакт принимающей стороны. При изменении решения сохраняют предыдущий вариант и причину пересмотра. Это позволяет понять, что именно обещали на момент звонка.
Отдельно определите, кто вправе согласовать исключение. Например, отправку замены до поступления исходного экземпляра. Тогда система показывает две связанные обязанности: отгрузить замену и получить возвращаемое изделие. Выполнение первой не закрывает вторую.
Готовая система или разработка под процесс
Начните с проверки возможностей действующей CRM, сервисной или учётной системы. Готового решения может хватить, если оно связывает обращение с поставкой, поддерживает позиции, необходимые роли и понятную историю.
Заказной модуль имеет смысл обсуждать, когда критичные связи приходится ежедневно восстанавливать вручную. Например, склад и сервис работают в разных программах, замена имеет новый серийный номер, а одно обращение содержит различные маршруты по изделиям.
Проверяйте не количество экранов, а сквозной пример. Попросите показать частичный возврат, неизвестный экземпляр и замену до получения оригинала. Если ограничение можно устранить настройкой и рабочим правилом, разработка с нуля может оказаться лишней.
Что включить в первую версию
Для старта достаточно одного подразделения, ограниченной группы изделий и нескольких согласованных решений. Нужны карточка обращения с позициями, очередь уточнений, решения с полномочиями, регистрация получения, связанные действия по ремонту или замене и контроль открытых обязательств.
Связь со складом можно начать с проверяемого обмена идентификаторами и подтверждения ответственным, если такой порядок допустим. Автоматическую интеграцию оцените отдельно: источник факта получения должен быть один.
В первую версию необязательно включать автоматическое определение причин, прогнозирование отказов и сложные рейтинги дилеров. Сначала добейтесь того, чтобы участники одинаково понимали судьбу конкретного изделия и следующий шаг.
Какие исключения проверить на демонстрации
Подготовьте небольшой набор ситуаций, которые регулярно вызывают переписку:
- дилер повторно прислал те же фотографии;
- серийный номер не относится к указанной поставке;
- приехало другое изделие;
- возвращена только часть комплекта;
- решение изменилось после диагностики;
- замена отправлена, но доставка не подтверждена;
- сотрудник ушёл в отпуск с открытыми действиями.
Для повторного обращения покажите связь с прежним, не удаляя новое сообщение. Для ошибки идентификации сохраните факт исправления. Для отсутствующего ответственного задайте понятный маршрут передачи, чтобы очередь не зависела от личной почты одного человека.
Как проверить, что процесс стал управляемым
Выберите несколько обезличенных обращений и пройдите их от первого сообщения до последнего подтверждения. По каждому другой сотрудник должен восстановить изделие, основание решения, полученный состав и остающееся действие без устных пояснений автора.
Считайте отдельно время до первого содержательного ответа, ожидание сведений, ожидание возврата и выполнение решения. Общий срок без этапов не объяснит, где находится задержка. Закрытие карточки должно проверяться по принятому правилу, а не использоваться для улучшения отчёта.
Для подготовки обсуждения пригодится бриф внутренней системы. В ExtentLab можно принести одну обезличенную рекламацию с письмами и движением изделий: на ней проще определить границы первой версии, нужные связи и вопросы, которые следует решить до оценки разработки.