Задача
До того как коробка с контроллером поедет в сервис, о ней нужно знать конкретные вещи: кто отправитель и от какой компании, какой у изделия каталожный номер (part number) и серийный номер, что не работает, по какому адресу вернуть отремонтированное. Если этих данных нет в момент отправки, их собирают потом письмами, и оборудование ждёт на складе, пока переписка сойдётся.
Обратная сторона той же проблемы — статус. Клиент спрашивает «где мой ремонт», координатор ищет ответ в почте, а единого места, где видно состояние заявки, не существует. При этом заявки нельзя просто сложить в общий список: обращения одной компании не должны быть видны другой, а одного знания номера заявки не должно хватать для доступа к чужой записи.
Нужен был процесс, который собирает полные данные до отправки оборудования, присваивает заявке постоянный идентификатор и дальше показывает обеим сторонам одно и то же состояние.
Решение
Мастер из пяти шагов. Repair Request → Shipping Information → Product Information → Confirmation → Complete. На первом шаге создаётся черновик, чтобы введённое не потерялось между шагами. Шаг Shipping подставляет данные компании из профиля и позволяет указать отдельное контактное лицо и адрес доставки; переключатель «shipping info is the same» убирает повторный ввод одних и тех же данных. Шаг Product Information требует каталожный и серийный номер и описание неисправности, а состав дополнительных полей зависит от категории продукта и причины обращения. Сервер перепроверяет обязательные данные до подтверждения: от полноты формы зависит, поедет ли оборудование зря, и проверки в браузере здесь мало.
Снимок данных на момент подтверждения. Шаг Confirmation фиксирует контакты, данные доставки и сведения об изделии такими, какими они были при отправке. Если клиент потом сменит адрес или контактное лицо в профиле, уже созданная RMA не изменится, и сервис отправит оборудование туда, куда договаривались.
Защита от дубля. Повторная отправка страницы не создаёт вторую заявку. То же правило действует в интеграции: безопасный повтор передачи не порождает вторую RMA во внутренних сервисных системах.
Статусы и документы. Экран Check Repair Status показывает список заявок с номером, датой отправки, числом позиций, текущим статусом и действиями View и PDF. Жизненный цикл: Draft → Pending request → Open / In progress → Waiting for customer или Waiting for equipment → Resolved → Closed. Конкретный набор статусов и допустимые переходы настраивает администратор, в код они не зашиты. Каждое изменение попадает в историю и может запускать уведомление. PDF собирается только из серверных данных, без произвольного пользовательского HTML, и служит стабильным подтверждением: номер заявки, данные компании и доставки, сведения об изделии и актуальные инструкции.
Операторская панель. Главный экран показывает число открытых и всех заявок, долю решённых и количество пользователей. Рядом лента действий, новые, недавно обновлённые и завершённые позиции и сводка RMA по статусам. Навигация разложена по рабочим срезам: Pending Requests, View All Requests, Requests by Type, by Statuses, by Reasons. Оператор ищет заявку по её номеру, компании, контакту, каталожному или серийному номеру изделия и проверяет полноту данных. Дальше он меняет статус по разрешённому переходу, назначает ответственного, запрашивает недостающие сведения, формирует или перевыпускает PDF и закрывает завершённый процесс.
Разделение комментариев. Внутренний комментарий и сообщение клиенту фиксируются раздельно. В интерфейсе это мелочь, а для процесса важная вещь: диагностика и внутренние оценки не уезжают заказчику вместе со статусом.
Классификация заявок. Заявка размечается по продуктовой линейке, типу обращения и причине, и эти признаки работают на очередь и на отчётность. Из них же собирается картина, какие изделия и по каким причинам возвращаются чаще.
Изоляция и уведомления. Клиент видит только обращения своей организации; прямая ссылка или известный номер заявки не открывают чужую запись без проверки прав. Письмо содержит номер заявки и ссылку на портал, но закрытые данные без авторизации не раскрывает. Изменение статуса, скачивание документа и просмотр чувствительных полей пишутся в журнал аудита.
Интеграция. Портал связывает клиентскую заявку с внутренними сервисными операциями: передаёт нормализованные данные о контакте, доставке, изделии и неисправности и получает обратно операционный статус и обновления по номеру заявки. Журнал интеграционных ошибок и идемпотентная передача нужны, чтобы после сбоя канала не появлялась повторная запись об одном ремонте.
Результат
Заявка приходит в сервис с полным набором данных, без которого ремонт не начинается: каталожный и серийный номер, описание неисправности, компания, адрес возврата и тип обращения.
У клиента появилось самообслуживание вместо переписки: он видит свои RMA списком, статус каждой и в любой момент скачивает PDF-подтверждение. У сервисной команды есть очередь с приоритетами, назначениями и историей действий, где статус меняется только по разрешённым переходам.
Обе стороны ссылаются на один номер заявки, и по нему поднимается вся история: что было отправлено, что запрашивали дополнительно, кто менял статус и когда ремонт был завершён.
