Кейс: Портал подбора и установки шин

Операционный контур шинной сети, где единица работы — заявка на комплект шин: автомобиль, допуски, четыре позиции, резерв и слот установки. Портал замыкает путь от запроса «что подойдёт на мой автомобиль» до подтверждённого комплекта и записи на шиномонтаж.

Карточка проекта

Отрасль
Региональная сеть шинных центров: подбор, резерв и установка комплекта
Основной рынок
Беларусь
Масштаб
4 шинных центра, центральный склад, до 25 сотрудников с заказами, 80–140 обращений в день в сезон — масштаб контура; название компании не раскрывается — NDA
Основная проблема
Диалог, параметры автомобиля, остатки, резерв и слот установки живут в разных каналах; пока менеджер собирает заказ, товар или время занимает другой клиент
Ключевое решение
Заявка на комплект шин: автомобиль, допуски, варианты, физический резерв, запись и следующее действие
Основные пользователи
Клиент, менеджер по продажам, сотрудник склада, администратор шинного центра
Срок внедрения
11–13 недель до поэтапного внедрения
Технологический стек
Laravel, Inertia, Vue 3, TypeScript, PostgreSQL, очередь в БД, локальные файлы, обмен с учётной системой
Статус проекта
Внедрён

Отрасль и клиент

Рынок и задача

Клиент — региональная сеть шинных центров в Беларуси. В сезон замены шин покупатель редко приходит с полностью сформированным заказом. Обычно он знает марку автомобиля, иногда помнит размер и просит «что-нибудь надёжное для ежедневных поездок». Менеджеру нужно выяснить параметры машины, проверить допустимые размеры, найти четыре одинаковые шины, учесть остатки на разных складах, предложить альтернативы и подобрать свободное время на шиномонтаже.

Для автосервиса, который присылает VIN и перечень работ, единица работы — подбор автозапчастей по VIN для автосервисов. Здесь другой контур той же автомобильной ниши: типоразмер, полный комплект из четырёх шин и слот установки, а не версия ремонтного комплекта. Карточка автомобиля с историей обслуживания — основа сценария диагностика батарей электромобилей на СТО.

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

Масштаб первой версии

Шинные центры4
Сотрудники с заказамидо 25
Обращения в сезон80–140 / день
Внедрение11–13 нед.
ПоказательЗначение
ГеографияБеларусь
Шинные центры4
Центральный склад1
Сотрудники, работающие с заказамидо 25
Сезонный поток80–140 обращений в день
Контур пилотаодин шинный центр и ограниченная группа менеджеров
Основной процессОт обращения до зарезервированного комплекта и записи на установку

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

Роли

Клиент

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

Ограничение

Публичная часть не заставляет проходить длинный технический опрос.

Менеджер по продажам

Принимает обращения, уточняет автомобиль, формирует подбор, объясняет различия и контролирует подтверждение.

Ограничение

Главный инструмент — очередь заявок и карточка подбора, а не общий dashboard.

Сотрудник склада

Проверяет физическое наличие и состояние комплекта, подтверждает резерв, собирает заказ или оформляет перемещение.

Ограничение

Короткая очередь задач без доступа к лишним коммерческим данным.

Администратор шинного центра

Управляет загрузкой постов, длительностью работ, переносами и фактом завершения визита.

Ограничение

Нужна готовность товара к визиту, а не только имя клиента в календаре.

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

Как было

Сезон начинается с очереди уточнений

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

Девять шагов из переписки

  1. Менеджер уточняет марку, модель, год, модификацию и диаметр диска.
  2. Ищет допустимые размеры в справочнике или старых заказах.
  3. Открывает учётную систему и проверяет остатки.
  4. Выясняет, действительно ли четыре шины находятся в одном месте и доступны к продаже.
  5. Отправляет клиенту несколько вариантов сообщениями или скриншотами.
  6. После выбора просит кладовщика подтвердить комплект.
  7. Отдельно связывается с шиномонтажом и уточняет свободные интервалы.
  8. Возвращается к клиенту за подтверждением.
  9. Вручную переносит договорённость в календарь или журнал записи.

В спокойный период схема держится на внимательности сотрудников. Во время сезонного пика она начинает давать системные сбои.

Где возникает операционный риск

Наблюдаемая ситуацияЧто происходит в работеПоследствие
Параметры автомобиля зафиксированы в перепискеДругой менеджер не видит, почему предложен конкретный размерПодбор приходится повторять
Остаток показан без состояния товараВ доступные попадает витринная, повреждённая или уже обещанная позицияРезерв срывается после согласования
Альтернатива отправлена без объясненияКлиент видит несколько похожих позиций и не понимает различийРешение откладывается, диалог теряется
Склад и шиномонтаж подтверждают заказ отдельноКомплект есть, но удобного времени уже нет, либо наоборотКлиенту приходится согласовывать всё заново
Срок резерва хранится в голове менеджераОсвобождение товара зависит от ручного контроляОстатки выглядят доступными не для тех клиентов
Заказы из звонков, сайта и мессенджеров ведутся раздельноНет единой очереди и ответственногоЧасть обращений остаётся без следующего действия
Как запрос теряет связь: диалог, остатки, резерв и слот установки собираются вручную

Корневая проблема

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

Центральная сущность продукта — не каталог шин и не сообщение в чате, а заявка на комплект шин.

Решение

Управлять нужно не каталогом, а готовностью заявки: автомобиль, допуски, комплект, резерв, слот и следующее действие живут в одной рабочей области.

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

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

Заявка движется по последовательности: «Новое обращение» → «Нужны данные автомобиля» → «Подбор подготовлен» → «Ждём выбор клиента» → «Комплект выбран» → «Резерв подтверждён» → «Запись назначена» → «Готово к визиту» → «Установлено / выдано». Для отклонений предусмотрены отдельные состояния: нет полного комплекта, нужно подтвердить размер, требуется перемещение, резерв истекает, клиент переносит визит, есть расхождение при приёмке. Статус вычисляется по фактам в карточке, а не выбирается из длинного списка.

Заявка как единый объект: автомобиль, комплект, резерв, визит и следующее действие

Как работает новый процесс

  1. Менеджер создаёт заявку из звонка, формы или сообщения. С первого контакта появляются номер, ответственный и следующее действие. Неполная заявка сохраняется со статусом «Нужны данные автомобиля».
  2. После выбора автомобиля система показывает базовые и альтернативные размеры из внутреннего справочника и источник каждого варианта. При неоднозначной комплектации создаётся проверка, а не автоматический ответ.
  3. Поиск учитывает возможность собрать комплект: четыре единицы одной модели, допустимое состояние, один склад либо реалистичное перемещение, индексы и выбранный центр установки. Менеджер формирует до трёх вариантов с коротким объяснением.
  4. Нажатие «Зарезервировать комплект» создаёт задачу складу. Пока сотрудник не подтвердил четыре единицы, клиенту показывается «Проверяем комплект», а не окончательное обещание.
  5. Система показывает только интервалы, к которым комплект можно подготовить. После выбора времени заявка получает единое подтверждение: комплект, адрес, дата, интервал и перечень работ.
  6. Администратор отмечает прибытие, начало и завершение работ. После выдачи комплект списывается через интеграцию с учётом либо через подтверждаемую ручную операцию на этапе пилота.

Одно подтверждение вместо серии обещаний держит и проект заселения в комнату с соседями: согласие относится к конкретной версии договорённости, а не к переписке.

Основные сценарии

Быстрый подбор по известному размеру

Клиент сообщает 205/55 R16, менеджер фиксирует сезон и приоритет, система показывает доступные комплекты, клиент выбирает, склад подтверждает четыре единицы.

Результат: запрос не распадается на каталог, переписку и ручной резерв.

Подбор по автомобилю при неоднозначной комплектации

Система видит несколько допустимых размеров и создаёт вопрос о диаметре диска. Клиент прикладывает фото маркировки, менеджер подтверждает размер, подбор продолжается только после фиксации решения. Подбор по подтверждённым параметрам, а не по карточке витрины, держит и проект покупки загородного дома: там досье объекта, здесь — карточка автомобиля и допуск размера.

Результат: неопределённость становится управляемой проверкой, а не скрытым риском.

Комплект находится на другом складе

Система обнаруживает четыре единицы в другом подразделении, рассчитывает дату готовности, склад подтверждает перемещение. Заявка связывает резерв, задачу перевозки и будущий визит. Склад здесь — место хранения товара, а не объект аренды: площадку под процесс подбирает портал складских и производственных помещений.

Результат: менеджер не обещает установку раньше физического прибытия товара.

При проверке найдены только три шины

Склад отклоняет подтверждение, заявка попадает в очередь «Нет полного комплекта», система предлагает остальные доступные варианты того же размера, менеджер согласовывает замену.

Результат: проблема обнаруживается до визита клиента и не исчезает в личной переписке.

Клиент переносит запись

Администратор выбирает новый интервал, система проверяет, покрывает ли резерв новую дату, при необходимости создаёт задачу менеджеру или складу и отправляет обновлённое подтверждение.

Результат: перенос времени не разрывает связь между товаром и услугой.

Выдача без монтажа

Для самовывоза комплекта запись на пост не требуется. Клиент получает подтверждённый резерв и адрес центра. Выдачу без сервисного слота закрывает и заказ корма с самовывозом.

Результат: способ получения не ломает единую заявку: слот появляется только когда нужна установка.

Главный интерфейс: очередь менеджера

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

Каждая строка показывает клиента, автомобиль, размер, этап, время без действия, готовность комплекта и следующее действие. Цвет используется только для исключений: просроченного ответа, заканчивающегося резерва и неподтверждённого перемещения.

При открытии заявки менеджер остаётся в одном workspace. Слева — факты об автомобиле и потребностях. В центре — варианты подбора и выбранный комплект. Справа — резерв, визит и таймлайн. Ключевая кнопка меняется вместе с этапом: «Запросить данные», «Отправить подбор», «Зарезервировать», «Назначить визит», «Подтвердить клиенту».

Очередь менеджера: следующее действие, готовность комплекта и исключения

Клиентский сценарий

Публичная часть предлагает два пути: указать автомобиль или ввести размер с боковины шины. Затем клиент отвечает на несколько практических вопросов: сезон, тип поездок, ожидаемый пробег и приоритет — тишина, управляемость, ресурс или сбалансированный вариант. Эти ответы не используются для автоматического «идеального» выбора. Они помогают менеджеру объяснить различия между совместимыми комплектами.

Результат показывает только варианты, которые можно реально собрать или быстро переместить: размер и индексы, краткое объяснение сценария, наличие полного комплекта, доступность установки по центрам и срок подтверждения. Если точный размер не определён, появляется проверка: прикрепить фото маркировки или записаться на бесплатную проверку размера. В MVP фотография не распознаётся автоматически.

Клиентский подбор: совместимые комплекты без перегруженного конфигуратора

Бизнес-правила

Совместимость

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

Комплект

По умолчанию комплект состоит из четырёх одинаковых шин одной модели, размера, индексов и исполнения. Различающийся год производства выводится как предупреждение. Витринные, повреждённые, возвращённые и уже зарезервированные позиции не считаются свободным остатком. Неполный комплект нельзя перевести в состояние «Готово к визиту». Связанный состав до резерва держит и закупочный проект сантехники для монтажных бригад.

Резерв

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

Запись

Интервал рассчитывается по набору работ, диаметру колёс и типу автомобиля. Слот нельзя подтвердить, если комплект не будет доступен в центре к началу работ. Перенос визита проверяет срок резерва повторно. Опоздание и неявка не закрывают заявку автоматически: администратор выбирает перенос, выдачу без монтажа или отмену. Календарь поста, а не бокса мойки, соседствует с календарём боксов детейлинга и автомоек. Карточка до визита, а не до вручения букета, держит и карточка заказа цветов до вручения.

Ответственность

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

MVP

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

В первой версии

Роли: менеджер, сотрудник склада, администратор шинного центра, руководитель с доступом к отклонениям
Приём и очередь заявок с ответственным и следующим действием
Справочник автомобилей и допустимых размеров
Каталог и поиск комплектов из четырёх доступных единиц
Подбор, объяснение вариантов и согласование клиента
Резервирование и складское подтверждение состояния товара
Календарь шиномонтажа с учётом готовности комплекта
Уведомления, журнал событий и очередь отклонений

Осознанно отложено

Автоматическое распознавание маркировки шины по фотографии
Динамическое управление закупками
Программа лояльности и хранение шин клиентов
Оптимизация маршрутов межскладских перемещений
Отдельное мобильное приложение
Сложная персонализация рекомендаций и расширенная BI-аналитика

ИИ не является необходимой частью первой версии. Распознавание маркировки по фотографии можно исследовать позже, но результат всё равно должен подтверждаться сотрудником. Для замыкания основного процесса достаточно корректного справочника, правил совместимости и дисциплины статусов.

UX, стек и план

Очередь вместо витрины

Ценность продукта создаётся после того, как найден совместимый комплект. Менеджер возвращается в заявку и видит следующее действие, а не список последних сообщений. Цвет и подпись статуса относятся к резерву, визиту и риску срока, а не к рекомендации «купить эту модель».

Архитектура

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

Client

  • Inertia
  • Vue 3
  • TypeScript
  • адаптивный веб

SPA-подобная работа с очередями и карточкой заявки без отдельного публичного API. Vue закрывает фильтры, подбор и календарь; Inertia сохраняет единый репозиторий и серверную маршрутизацию Laravel.

API

  • Laravel
  • модульный монолит

Модули: пользователи и роли, автомобили и допуски, каталог, заявки и подборы, остатки и резервы, перемещения, шиномонтаж, уведомления, аудит. Резерв создаётся транзакционно: проверка доступного количества и фиксация четырёх единиц — одна операция.

Data

  • PostgreSQL
  • заявки
  • резервы
  • слоты
  • история
  • поиск

Реляционная модель для автомобиля, заявки, комплекта, резерва и визита. Индексы PostgreSQL закрывают поиск по размеру, сезону, индексам и складу без отдельного поискового движка.

Queue

  • Laravel Jobs
  • очередь в БД
  • Scheduler
  • уведомления

Фоновые задания: импорт остатков, напоминания и отправка уведомлений. Redis и Horizon в MVP не нужны: объём задач этой нагрузки закрывается очередью в PostgreSQL.

Storage

  • локальные файлы
  • фото маркировки
  • резервные копии

На первом этапе фотографий немного, несколько web-серверов не требуется. Доступ к вложениям выдаётся с учётом роли и заявки.

Infrastructure

  • один сервер
  • Nginx
  • PHP-FPM
  • queue worker
  • резервные копии

Веб-контур, worker, Scheduler и резервные копии на одном сервере. WebSocket, отдельный поисковый движок, микросервисы и Kubernetes в MVP не входят.

Ключевые решения: транзакционный резерв четырёх единиц; вычисляемый статус заявки; идемпотентный импорт остатков; история событий отдельно от редактируемых полей; права по рабочей задаче. Если готового API нет, MVP использует контролируемый обмен файлами по расписанию.

Модульный монолит: заявка, резерв, запись и обмен с учётом остаются в одном контуре

План на 11–13 недель

Запуск нельзя планировать на первую неделю массовой смены шин. Сотрудники должны освоить статусы и исключения до пика. Срок внедрения первой версии — 11–13 недель.

0 нед 13 нед
  1. 2 нед
    1

    Подготовка данных

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

  2. 4 нед
    2

    Основной процесс

    Очередь заявок, карточка автомобиля и подбора, поиск комплектов, резерв и складское подтверждение, календарь установки, история и уведомления.

  3. 2 нед
    3

    Пилот в одном центре

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

  4. 1–2 нед
    4

    Исправление отклонений

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

  5. 2–3 нед
    5

    Подключение остальных центров

    Центры подключаются по одному. Перед каждым запуском проверяются справочники, расписание, права и ответственные.

Метрики

Показатели ниже — результат внедрения. До запуска две недели фиксировался исходный уровень по тем же определениям. Проверка отдельно для заявок с известным размером и для сложного подбора по автомобилю.

МетрикаДо внедренияРезультатКак измеряется
Время до первого содержательного подбора25–45 минут в сезондо 15 минут для заявок с полными даннымиОт создания заявки до отправки вариантов
Заявки без следующего действия12–18%менее 3%Активные заявки без задачи и срока / все активные заявки
Повторный ввод данных3–5 переносов на заявкуне более 1Ручные переносы параметров между каналами
Срывы после обещания наличия6–10%менее 2%Заявки, где подтверждённый клиенту комплект не собран / все выбранные комплекты
Время обнаружения конфликтадо следующей ручной проверкидо 10 минут после события или импортаОт появления расхождения до попадания ответственному
Полные карточки к моменту визита70–80%более 97%Заявки с размером, резервом, центром, временем и работами / все визиты
Переносы без повторной проверки резерваопределяется ручной выборкой0Число переносов, где срок товара не был подтверждён

Риски и выводы

Риски

РискВероятностьВлияниеСнижение
Справочник автомобилей и размеров содержит пробелыСредняяВысокоеЯвный статус неопределённости, ручное подтверждение, журнал исправлений
Учётный остаток расходится с физическимВысокая в началеВысокоеСкладское подтверждение перед обещанием, регулярная сверка причин расхождения
Менеджеры продолжают вести заказы в личных чатахСредняяВысокоеПростое создание заявки, единая очередь, запрет подтверждённого резерва без карточки
Сотрудники формально меняют статусыСредняяСреднееВычисляемые состояния, обязательные факты вместо ручного выбора этапа
Интеграция задерживает запускСредняяСреднееФайловый импорт в MVP, поэтапное подключение операций
Календарь не отражает реальную длительность работСредняяСреднееПилот на одном центре, настройка нормативов по фактическим отклонениям
Сезонный пик начинается раньше завершения пилотаНизкая при правильном планированииВысокоеЗапуск до пика, ограничение числа центров, контролируемый ручной сценарий

Развитие после устойчивого MVP

  1. Прогнозировать загрузку шинных центров по размерным группам и датам.
  2. Предлагать межскладское перемещение с учётом будущих визитов.
  3. Напоминать клиенту о сезонной замене на основе истории установленного комплекта.
  4. Добавить хранение шин как продолжение карточки автомобиля.
  5. Распознавать маркировку по фотографии с обязательным подтверждением сотрудника.
  6. Собирать причины отказа от предложенных вариантов и показывать узкие места по этапам и центрам.

Как изменилась работа

До

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

После

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

Ключевой результат — не новый каталог шин и не ещё один кабинет. Компания получает управляемый переход от неопределённого запроса к готовому заказу.

Обратная связь после внедрения

Сжатая цитата из обратной связи после пилотного внедрения. Название компании и имя не указаны из‑за NDA.

«У нас постоянно было отдельно: подбор шин, отдельно резерв на складе и отдельно запись на шиномонтаж. Иногда клиент приезжал, а дальше начинали разбираться. Сейчас эти этапы связаны между собой.»

Администратор шинного центра

Обсудить проект

Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.

Связаться