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