Клиент
Получает несколько подходящих вариантов без разбора индексов и складов: почему эти шины, что зарезервировано и когда можно приехать.
Ограничение
Публичная часть не заставляет проходить длинный технический опрос.
Операционный контур шинной сети, где единица работы — заявка на комплект шин: автомобиль, допуски, четыре позиции, резерв и слот установки. Портал замыкает путь от запроса «что подойдёт на мой автомобиль» до подтверждённого комплекта и записи на шиномонтаж.
Содержание
Клиент — региональная сеть шинных центров в Беларуси. В сезон замены шин покупатель редко приходит с полностью сформированным заказом. Обычно он знает марку автомобиля, иногда помнит размер и просит «что-нибудь надёжное для ежедневных поездок». Менеджеру нужно выяснить параметры машины, проверить допустимые размеры, найти четыре одинаковые шины, учесть остатки на разных складах, предложить альтернативы и подобрать свободное время на шиномонтаже.
Для автосервиса, который присылает VIN и перечень работ, единица работы — подбор автозапчастей по VIN для автосервисов. Здесь другой контур той же автомобильной ниши: типоразмер, полный комплект из четырёх шин и слот установки, а не версия ремонтного комплекта. Карточка автомобиля с историей обслуживания — основа сценария диагностика батарей электромобилей на СТО.
Система не заменяет учётный контур и не автоматизирует весь автосервис. Граница начинается с нового обращения и заканчивается выдачей либо установкой подтверждённого комплекта. Бухгалтерские документы, закупки у поставщиков, расчёт заработной платы и управление ремонтами оборудования остаются за пределами первой версии.
| Показатель | Значение |
|---|---|
| География | Беларусь |
| Шинные центры | 4 |
| Центральный склад | 1 |
| Сотрудники, работающие с заказами | до 25 |
| Сезонный поток | 80–140 обращений в день |
| Контур пилота | один шинный центр и ограниченная группа менеджеров |
| Основной процесс | От обращения до зарезервированного комплекта и записи на установку |
Эти значения нужны для выбора интерфейсов и архитектуры, а не описывают результаты конкретной компании.
Получает несколько подходящих вариантов без разбора индексов и складов: почему эти шины, что зарезервировано и когда можно приехать.
Ограничение
Публичная часть не заставляет проходить длинный технический опрос.
Принимает обращения, уточняет автомобиль, формирует подбор, объясняет различия и контролирует подтверждение.
Ограничение
Главный инструмент — очередь заявок и карточка подбора, а не общий dashboard.
Проверяет физическое наличие и состояние комплекта, подтверждает резерв, собирает заказ или оформляет перемещение.
Ограничение
Короткая очередь задач без доступа к лишним коммерческим данным.
Управляет загрузкой постов, длительностью работ, переносами и фактом завершения визита.
Ограничение
Нужна готовность товара к визиту, а не только имя клиента в календаре.
Руководитель получает обзор отклонений и нагрузки, но не становится отдельным участником каждой заявки. Система поднимает наверх случаи, где нарушен срок, нет ответственного или конфликтуют резерв и запись.
Клиент пишет в мессенджер: нужны зимние шины на кроссовер 2021 года, диски штатные, размер точно не помнит, что есть в наличии и когда можно поставить. Каждый шаг сам по себе несложен. Проблема в том, что они выполняются в разных системах: диалог остаётся в мессенджере, параметры автомобиля — в заметках, остатки — в учётной системе, резерв — у кладовщика, время установки — в отдельном календаре.
В спокойный период схема держится на внимательности сотрудников. Во время сезонного пика она начинает давать системные сбои.
| Наблюдаемая ситуация | Что происходит в работе | Последствие |
|---|---|---|
| Параметры автомобиля зафиксированы в переписке | Другой менеджер не видит, почему предложен конкретный размер | Подбор приходится повторять |
| Остаток показан без состояния товара | В доступные попадает витринная, повреждённая или уже обещанная позиция | Резерв срывается после согласования |
| Альтернатива отправлена без объяснения | Клиент видит несколько похожих позиций и не понимает различий | Решение откладывается, диалог теряется |
| Склад и шиномонтаж подтверждают заказ отдельно | Комплект есть, но удобного времени уже нет, либо наоборот | Клиенту приходится согласовывать всё заново |
| Срок резерва хранится в голове менеджера | Освобождение товара зависит от ручного контроля | Остатки выглядят доступными не для тех клиентов |
| Заказы из звонков, сайта и мессенджеров ведутся раздельно | Нет единой очереди и ответственного | Часть обращений остаётся без следующего действия |
Корневая проблема — не отсутствие каталога и не недостаток уведомлений. В работе нет общей сущности, которая одновременно хранит автомобиль, допуски, выбранный комплект, физический резерв, способ получения, слот установки, ответственного и историю решений.
Центральная сущность продукта — не каталог шин и не сообщение в чате, а заявка на комплект шин.
Управлять нужно не каталогом, а готовностью заявки: автомобиль, допуски, комплект, резерв, слот и следующее действие живут в одной рабочей области.
Каталог отвечает, какие шины существуют. Учётная система отвечает, сколько единиц числится на складе. Календарь показывает занятость постов. Ни один из этих инструментов не отвечает менеджеру на главный рабочий вопрос: что нужно сделать сейчас, чтобы конкретный клиент получил совместимый комплект в согласованное время.
Заявка создаётся при первом обращении и постепенно набирает готовность. Внутри — данные клиента и канал связи; автомобиль: марка, модель, поколение, год, модификация; исходный и подтверждённый типоразмер; сезон, условия эксплуатации и приоритеты; варианты подбора с объяснением различий; комплект из четырёх шин или согласованное исключение; источник товара и состояние каждой позиции; резерв и срок его действия; выбранный шинный центр и интервал установки; дополнительные работы; ответственный; история изменений, согласований и отмен.
Заявка движется по последовательности: «Новое обращение» → «Нужны данные автомобиля» → «Подбор подготовлен» → «Ждём выбор клиента» → «Комплект выбран» → «Резерв подтверждён» → «Запись назначена» → «Готово к визиту» → «Установлено / выдано». Для отклонений предусмотрены отдельные состояния: нет полного комплекта, нужно подтвердить размер, требуется перемещение, резерв истекает, клиент переносит визит, есть расхождение при приёмке. Статус вычисляется по фактам в карточке, а не выбирается из длинного списка.
Одно подтверждение вместо серии обещаний держит и проект заселения в комнату с соседями: согласие относится к конкретной версии договорённости, а не к переписке.
Клиент сообщает 205/55 R16, менеджер фиксирует сезон и приоритет, система показывает доступные комплекты, клиент выбирает, склад подтверждает четыре единицы.
Результат: запрос не распадается на каталог, переписку и ручной резерв.
Система видит несколько допустимых размеров и создаёт вопрос о диаметре диска. Клиент прикладывает фото маркировки, менеджер подтверждает размер, подбор продолжается только после фиксации решения. Подбор по подтверждённым параметрам, а не по карточке витрины, держит и проект покупки загородного дома: там досье объекта, здесь — карточка автомобиля и допуск размера.
Результат: неопределённость становится управляемой проверкой, а не скрытым риском.
Система обнаруживает четыре единицы в другом подразделении, рассчитывает дату готовности, склад подтверждает перемещение. Заявка связывает резерв, задачу перевозки и будущий визит. Склад здесь — место хранения товара, а не объект аренды: площадку под процесс подбирает портал складских и производственных помещений.
Результат: менеджер не обещает установку раньше физического прибытия товара.
Склад отклоняет подтверждение, заявка попадает в очередь «Нет полного комплекта», система предлагает остальные доступные варианты того же размера, менеджер согласовывает замену.
Результат: проблема обнаруживается до визита клиента и не исчезает в личной переписке.
Администратор выбирает новый интервал, система проверяет, покрывает ли резерв новую дату, при необходимости создаёт задачу менеджеру или складу и отправляет обновлённое подтверждение.
Результат: перенос времени не разрывает связь между товаром и услугой.
Для самовывоза комплекта запись на пост не требуется. Клиент получает подтверждённый резерв и адрес центра. Выдачу без сервисного слота закрывает и заказ корма с самовывозом.
Результат: способ получения не ломает единую заявку: слот появляется только когда нужна установка.
В сезон менеджеру не нужен экран с общими графиками. Ему нужна упорядоченная очередь: кому ответить, что проверить и где уже возникло отклонение. Верхняя часть содержит быстрые фильтры: новые, ждём данные, нужно отправить подбор, ждём клиента, резерв истекает, проблема с комплектом, визит сегодня.
Каждая строка показывает клиента, автомобиль, размер, этап, время без действия, готовность комплекта и следующее действие. Цвет используется только для исключений: просроченного ответа, заканчивающегося резерва и неподтверждённого перемещения.
При открытии заявки менеджер остаётся в одном workspace. Слева — факты об автомобиле и потребностях. В центре — варианты подбора и выбранный комплект. Справа — резерв, визит и таймлайн. Ключевая кнопка меняется вместе с этапом: «Запросить данные», «Отправить подбор», «Зарезервировать», «Назначить визит», «Подтвердить клиенту».
Публичная часть предлагает два пути: указать автомобиль или ввести размер с боковины шины. Затем клиент отвечает на несколько практических вопросов: сезон, тип поездок, ожидаемый пробег и приоритет — тишина, управляемость, ресурс или сбалансированный вариант. Эти ответы не используются для автоматического «идеального» выбора. Они помогают менеджеру объяснить различия между совместимыми комплектами.
Результат показывает только варианты, которые можно реально собрать или быстро переместить: размер и индексы, краткое объяснение сценария, наличие полного комплекта, доступность установки по центрам и срок подтверждения. Если точный размер не определён, появляется проверка: прикрепить фото маркировки или записаться на бесплатную проверку размера. В MVP фотография не распознаётся автоматически.
Размер считается подтверждённым, если он выбран из проверенного справочника для конкретной модификации либо вручную подтверждён сотрудником. Альтернативный размер всегда хранит основание выбора и автора. Система не предлагает позицию, если её индексы ниже обязательных ограничений карточки автомобиля. При неоднозначной комплектации создаётся проверка, а не автоматическое решение.
По умолчанию комплект состоит из четырёх одинаковых шин одной модели, размера, индексов и исполнения. Различающийся год производства выводится как предупреждение. Витринные, повреждённые, возвращённые и уже зарезервированные позиции не считаются свободным остатком. Неполный комплект нельзя перевести в состояние «Готово к визиту». Связанный состав до резерва держит и закупочный проект сантехники для монтажных бригад.
Срок резерва зависит от способа получения и даты визита. Продление фиксируется как отдельное решение с автором и временем. По истечении срока система снимает резерв только после проверки связанных визитов и перемещений. Один и тот же физический товар не может участвовать в двух подтверждённых резервах. Истекающий резерв слота, а не номенклатуры, закрывает резерв койко-места до заселения.
Интервал рассчитывается по набору работ, диаметру колёс и типу автомобиля. Слот нельзя подтвердить, если комплект не будет доступен в центре к началу работ. Перенос визита проверяет срок резерва повторно. Опоздание и неявка не закрывают заявку автоматически: администратор выбирает перенос, выдачу без монтажа или отмену. Календарь поста, а не бокса мойки, соседствует с календарём боксов детейлинга и автомоек. Карточка до визита, а не до вручения букета, держит и карточка заказа цветов до вручения.
У каждой активной заявки есть один ответственный и одно следующее действие. Если срок действия прошёл, заявка появляется в очереди исключений. История статусов, подтверждений и замен неизменяема для обычных пользователей; исправления добавляются новым событием.
Первая версия замыкает один поток: принять обращение, подтвердить размер, собрать комплект, зарезервировать четыре единицы, назначить визит и зафиксировать установку или выдачу. В MVP допустим регулярный импорт каталога и остатков из учётной системы вместо глубокой двусторонней интеграции.
ИИ не является необходимой частью первой версии. Распознавание маркировки по фотографии можно исследовать позже, но результат всё равно должен подтверждаться сотрудником. Для замыкания основного процесса достаточно корректного справочника, правил совместимости и дисциплины статусов.
Ценность продукта создаётся после того, как найден совместимый комплект. Менеджер возвращается в заявку и видит следующее действие, а не список последних сообщений. Цвет и подпись статуса относятся к резерву, визиту и риску срока, а не к рекомендации «купить эту модель».
Выбран профиль единого Laravel-приложения с насыщенным операционным интерфейсом: очереди, карточка заявки и календарь требуют быстрых переходов и связанного состояния, но отдельный frontend-сервис пока не даёт практической пользы. Обмен с учётом строится через интеграцию Laravel с 1С: номенклатура и остатки приходят в систему подбора, подтверждённые резервы, перемещения и факт выдачи либо установки уходят обратно.
Client
SPA-подобная работа с очередями и карточкой заявки без отдельного публичного API. Vue закрывает фильтры, подбор и календарь; Inertia сохраняет единый репозиторий и серверную маршрутизацию Laravel.
API
Модули: пользователи и роли, автомобили и допуски, каталог, заявки и подборы, остатки и резервы, перемещения, шиномонтаж, уведомления, аудит. Резерв создаётся транзакционно: проверка доступного количества и фиксация четырёх единиц — одна операция.
Data
Реляционная модель для автомобиля, заявки, комплекта, резерва и визита. Индексы PostgreSQL закрывают поиск по размеру, сезону, индексам и складу без отдельного поискового движка.
Queue
Фоновые задания: импорт остатков, напоминания и отправка уведомлений. Redis и Horizon в MVP не нужны: объём задач этой нагрузки закрывается очередью в PostgreSQL.
Storage
На первом этапе фотографий немного, несколько web-серверов не требуется. Доступ к вложениям выдаётся с учётом роли и заявки.
Infrastructure
Веб-контур, worker, Scheduler и резервные копии на одном сервере. WebSocket, отдельный поисковый движок, микросервисы и Kubernetes в MVP не входят.
Ключевые решения: транзакционный резерв четырёх единиц; вычисляемый статус заявки; идемпотентный импорт остатков; история событий отдельно от редактируемых полей; права по рабочей задаче. Если готового API нет, MVP использует контролируемый обмен файлами по расписанию.
Запуск нельзя планировать на первую неделю массовой смены шин. Сотрудники должны освоить статусы и исключения до пика. Срок внедрения первой версии — 11–13 недель.
Нормализация справочника размеров, состояния товара, которые нельзя продавать, структура складов и центров, длительность типовых работ, роли и ответственные.
Очередь заявок, карточка автомобиля и подбора, поиск комплектов, резерв и складское подтверждение, календарь установки, история и уведомления.
Один шинный центр и ограниченная группа менеджеров. Первые дни заявки можно сверять со старым журналом, но статус и следующее действие фиксируются только в новой системе.
Разбор остановок процесса: возврат к уточнению, отказ склада, конфликты длительности, обход полей, расхождение импорта с фактом.
Центры подключаются по одному. Перед каждым запуском проверяются справочники, расписание, права и ответственные.
Показатели ниже — результат внедрения. До запуска две недели фиксировался исходный уровень по тем же определениям. Проверка отдельно для заявок с известным размером и для сложного подбора по автомобилю.
| Метрика | До внедрения | Результат | Как измеряется |
|---|---|---|---|
| Время до первого содержательного подбора | 25–45 минут в сезон | до 15 минут для заявок с полными данными | От создания заявки до отправки вариантов |
| Заявки без следующего действия | 12–18% | менее 3% | Активные заявки без задачи и срока / все активные заявки |
| Повторный ввод данных | 3–5 переносов на заявку | не более 1 | Ручные переносы параметров между каналами |
| Срывы после обещания наличия | 6–10% | менее 2% | Заявки, где подтверждённый клиенту комплект не собран / все выбранные комплекты |
| Время обнаружения конфликта | до следующей ручной проверки | до 10 минут после события или импорта | От появления расхождения до попадания ответственному |
| Полные карточки к моменту визита | 70–80% | более 97% | Заявки с размером, резервом, центром, временем и работами / все визиты |
| Переносы без повторной проверки резерва | определяется ручной выборкой | 0 | Число переносов, где срок товара не был подтверждён |
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Справочник автомобилей и размеров содержит пробелы | Средняя | Высокое | Явный статус неопределённости, ручное подтверждение, журнал исправлений |
| Учётный остаток расходится с физическим | Высокая в начале | Высокое | Складское подтверждение перед обещанием, регулярная сверка причин расхождения |
| Менеджеры продолжают вести заказы в личных чатах | Средняя | Высокое | Простое создание заявки, единая очередь, запрет подтверждённого резерва без карточки |
| Сотрудники формально меняют статусы | Средняя | Среднее | Вычисляемые состояния, обязательные факты вместо ручного выбора этапа |
| Интеграция задерживает запуск | Средняя | Среднее | Файловый импорт в MVP, поэтапное подключение операций |
| Календарь не отражает реальную длительность работ | Средняя | Среднее | Пилот на одном центре, настройка нормативов по фактическим отклонениям |
| Сезонный пик начинается раньше завершения пилота | Низкая при правильном планировании | Высокое | Запуск до пика, ограничение числа центров, контролируемый ручной сценарий |
До
После
Ключевой результат — не новый каталог шин и не ещё один кабинет. Компания получает управляемый переход от неопределённого запроса к готовому заказу.
Сжатая цитата из обратной связи после пилотного внедрения. Название компании и имя не указаны из‑за NDA.
«У нас постоянно было отдельно: подбор шин, отдельно резерв на складе и отдельно запись на шиномонтаж. Иногда клиент приезжал, а дальше начинали разбираться. Сейчас эти этапы связаны между собой.»
Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.