Автосервис Ярцево: цифровой маршрут от предварительной заявки до истории ремонта

Исходная задача

Простая запись по телефону не создаёт структурированной истории. При повторном обращении приходится заново выяснять автомобиль, пробег и предыдущие работы. Во время приёмки легко пропустить фотографии повреждений или запутаться, что уже согласовано. Одновременно нельзя заставлять клиента заполнять техническую анкету, которую он не понимает.

Что разработано

1. Публичная заявка по симптомам

Клиент выбирает близкую ситуацию или вариант «Не знаю / Другое», указывает автомобиль, состояние «на ходу / не на ходу», описывает симптом и прикладывает полезные материалы. Форма собирает достаточно данных для первого решения, но не выдаёт предварительную заявку за заказ-наряд.

2. Разделение входящего обращения и ремонтной записи

Заявка с сайта остаётся входящим обращением. Клиент, автомобиль и полноценная ремонтная запись создаются только на этапе фактического осмотра или согласованного ремонта. Это предотвращает засорение базы случайными обращениями.

3. Упрощённая приёмка автомобиля

Сценарий приёмки переработан так, чтобы мастер понимал следующий шаг. Видимые повреждения, фотографии, VIN, пробег и дополнительные сведения заполняются последовательно, а не одной перегруженной формой.

4. Карточки и связи

Внутренняя система связывает:

• клиента;
• автомобиль;
• ремонтную запись;
• работы;
• запчасти;
• оплаты;
• согласования;
• фотографии;
• напоминания и историю.

5. Роли сотрудников

Предусмотрены роли руководителя, мастера и клиента. Сотрудникам не требуется доступ в обычный wp-admin: для ежедневной работы используется отдельная CRM-панель.

6. MAX и уведомления

Система поддерживает клиентский и внутренний контур уведомлений, чтобы подтверждения и изменения статуса не зависели только от устной передачи информации.

7. Запчасти

Заявки на подбор запчастей рассматриваются как входящие и не создают автоматически клиента, автомобиль или ремонт. После принятия решения данные связываются с нужной записью.

Как работает маршрут

Клиент описывает симптом
→ сервис оценивает, подходит ли задача
→ назначается осмотр
→ при приёмке создаются клиент, автомобиль и запись
→ фиксируются состояние и фотографии
→ согласуются работы и запчасти
→ меняются статусы ремонта
→ сохраняются оплаты, документы и история

UX-задача

Важная часть проекта — не количество полей, а момент, когда они появляются. VIN, пробег и фотографии нужны при ремонте, но не должны блокировать первичную заявку. Сценарий был разделён по этапам, чтобы не усложнять вход клиенту и не лишать мастера необходимых данных.

Результат

Публичный сайт помогает клиенту описать проблему своими словами, а внутренний контур превращает принятое обращение в управляемую историю автомобиля и ремонта.