Задача
До того как коробка с контроллером поедет в сервис, о ней нужно знать вполне определённые вещи: кто отправитель и от какой компании, какой это part number и serial number, что именно не работает, по какому адресу вернуть отремонтированное. Если этих данных нет в момент отправки, они собираются потом — письмами, и оборудование ждёт на складе, пока переписка сойдётся.
Обратная сторона той же проблемы — статус. Клиент спрашивает «где мой ремонт», координатор ищет ответ в почте, а единого места, где видно состояние заявки, не существует. При этом заявки нельзя просто сложить в общий список: обращения одной компании не должны быть видны другой, а знание reference number не может само по себе давать доступ к чужой записи.
Нужен был процесс, который собирает полные данные до отправки оборудования, присваивает заявке постоянный идентификатор и дальше показывает обеим сторонам одно и то же состояние.
Решение
Мастер из пяти шагов. Repair Request → Shipping Information → Product Information → Confirmation → Complete. На первом шаге создаётся черновик, чтобы введённое не потерялось между шагами. Shipping подставляет company information из профиля и позволяет указать отдельный shipping contact и адрес; переключатель «shipping info is the same» убирает повторный ввод одних и тех же данных. Product Information требует part number, serial number и описание неисправности, а состав дополнительных полей зависит от категории продукта и причины обращения. Сервер перепроверяет обязательные данные до подтверждения — валидации на клиенте недостаточно, когда от полноты формы зависит, поедет ли оборудование зря.
Снимок данных на момент подтверждения. Confirmation фиксирует контактные, shipping и product details именно такими, какими они были при отправке. Клиент потом сменит адрес или контактное лицо в профиле — уже созданная RMA от этого не переписывается, и сервис отправит оборудование туда, куда договаривались.
Защита от дубля. Повторная отправка страницы не создаёт вторую заявку. То же правило действует в интеграции: безопасный повтор передачи не порождает вторую RMA во внутренних сервисных системах.
Статусы и документы. Check Repair Status показывает список заявок с reference number, датой отправки, числом позиций, текущим статусом и действиями View и PDF. Жизненный цикл — Draft → Pending request → Open / In progress → Waiting for customer или Waiting for equipment → Resolved → Closed, а конкретный набор статусов и допустимые переходы настраиваются администратором, а не зашиты в код. Каждое изменение попадает в историю и может запускать уведомление. PDF формируется из серверных данных, а не из произвольного пользовательского HTML, и служит стабильным подтверждением: reference, company и shipping information, product details и актуальные инструкции.
Операторская панель. Dashboard показывает open и total requests, долю resolved, количество пользователей, activity feed, новые, недавно обновлённые и завершённые позиции и сводку RMA по статусам. Навигация разложена по рабочим срезам: Pending Requests, View All Requests, Requests by Type, by Statuses, by Reasons. Оператор ищет заявку по reference, компании, контакту, part или serial number, проверяет полноту данных, меняет статус по разрешённому переходу, назначает ответственного, запрашивает недостающие сведения, формирует или перевыпускает PDF и закрывает завершённый процесс.
Разделение комментариев. Внутренний комментарий и сообщение клиенту фиксируются раздельно. Это мелочь на уровне интерфейса и принципиальная вещь на уровне процесса: диагностика и внутренние оценки не уезжают заказчику вместе со статусом.
Классификация вместо свободного текста. Заявка размечается по product line, request type и reason, и эти признаки работают на очередь и на отчётность, а не остаются строкой в описании. Из них же собирается картина, какие изделия и по каким причинам возвращаются чаще.
Изоляция и уведомления. Клиент видит только обращения своей организации; прямой URL или известный reference number не открывает чужую заявку без проверки прав. Письмо содержит reference и ссылку на портал, но не раскрывает закрытые данные без авторизации. Изменение статуса, скачивание документа и просмотр чувствительных полей пишутся в аудит.
Интеграция. Портал связывает клиентскую заявку с внутренними сервисными операциями: передаёт нормализованные contact, shipping, product и trouble details и получает обратно операционный статус и связанные с reference обновления. Журнал интеграционных ошибок и идемпотентная передача нужны здесь ровно затем, чтобы сбой канала не превращался в две записи об одном ремонте.
Результат
Заявка приходит в сервис укомплектованной: с part и serial number, описанием неисправности, компанией, адресом возврата и типом обращения — то есть с тем набором, без которого ремонт не начинается.
У клиента появился self-service вместо переписки: он видит свои RMA списком, статус каждой и скачивает PDF-подтверждение в любой момент. У сервисной команды — очередь с приоритетами, назначениями и историей действий, где статус меняется по разрешённым переходам, а не по договорённости.
Обе стороны ссылаются на один reference number, и по нему поднимается вся история: что было отправлено, что запрашивали дополнительно, кто менял статус и когда ремонт был завершён.
