Антон — владелец сети детейлинг-центров (BB Detailing). Компания работает комплексно: детейлинг, полировка, нанесение защитных покрытий, оклейка плёнкой, шумоизоляция, установка дополнительного оборудования, тонировка, пошив ковров, а также сопровождение клиентов по ГАИ, страховке и продаже автомобилей.
К одному автомобилю в течение производственного цикла прикасается большое количество людей: внутренние мастера разных квалификаций, отдельные ИП по видам деятельности, аутсорс-исполнители, фотографы, маркетологи, администраторы, бухгалтерия.
Масштаб на момент внедрения:
- 5 производственных объектов;
- до 19–22 проектов (автомобилей в работе) одновременно на одном объекте;
- в каждом проекте — порядка 30 разделов (этапов, цехов, направлений работ);
- в каждом разделе — от 5 до 10 задач с подзадачами, исполнителями, проверяющими и дедлайнами.
Задача
Раньше учёт работ по каждому автомобилю вёлся в бумажном заказ-наряде и в Google-инструментах (календарь, таблицы, почта, чаты). С ростом потока и числа исполнителей этого стало не хватать:
- в одном заказ-наряде — 14–16 и более позиций работ, к каждой подключается несколько человек;
- работа идёт в две точки контроля: мастер цеха и мастер-приёмщик, плюс управляющий контролирует весь заказ-наряд целиком;
- часть работ выполняют отдельные ИП и аутсорсеры — их нужно встроить в общий процесс, но изолировать от чужой зоны ответственности;
- нужно было перевести услугу из «ремесла» в производственную модель — многокомпонентную, многоуровневую, с прозрачным контролем на каждом этапе.
«Мы услугу поставили в область производства. Мы производим услугу многокомпонентно, многоуровнево, с большим количеством точек контроля».
Почему выбрали Strive
Антон рассматривал несколько таск-менеджеров и в течение двух недель тестировал, изучал и адаптировал выбранный продукт под свои процессы. В итоге выбор остановился на Strive — по нескольким причинам.
1. Гибкость и адаптируемость под сложные бизнес-процессы
«Это единственное приложение, которое можно было адаптировать под наши бизнес-процессы».
Структура Strive позволила смоделировать движение автомобиля по цехам, распределить ответственность между исполнителями разных квалификаций и сохранить две точки контроля.
2. Понятная иерархия: пространства → проекты → разделы → задачи
Архитектура продукта легла на реальную логику работы: автомобиль как единица производства, цеха как этапы, конкретные операции как задачи с исполнителями, проверяющими и дедлайнами.
3. Встроенный мессенджер по каждой задаче
Возможность вести переписку прямо в задаче оказалась сильным аргументом — обсуждение по конкретной операции не теряется в общих чатах.
«Если бы мне сразу сказали, что тут ещё вшит внутри мессенджер, которым легко пользоваться, — это бы меня сразу заинтересовало».
4. Интеграции с Telegram и МAX
Уведомления приходят в привычные мессенджеры, исполнители быстро получают новые задачи без необходимости постоянно держать рабочее приложение открытым.
5. Локализация и надёжность
Strive находится в реестре отечественного ПО, серверы расположены в Москве и Санкт-Петербурге — для бизнеса в РФ это снимает риски, связанные с зарубежными сервисами.
Как Strive адаптировали под производство услуг
Главная задача внедрения была не просто «перенести задачи в приложение», а воспроизвести в Strive реальную логику производства: движение автомобиля между цехами, разделение зон ответственности, две точки контроля и изоляцию исполнителей друг от друга. Для этого иерархия продукта — пространства, проекты, разделы и задачи — была сопоставлена с реальной структурой бизнеса: подразделениями, автомобилями в работе, этапами обработки и конкретными операциями. Ниже — как именно это устроено.
Архитектура: пространство = подразделение, проект = автомобиль или направление
Чтобы исполнители из разных цехов не видели чужую работу и не отвлекались на «не свои» этапы, рабочее пространство было разделено по подразделениям:
- Пространство «Заказ-наряды» — здесь работают администратор, бухгалтер и мастер-приёмщик. Создаются проекты-автомобили, ставятся задачи, ведётся общая логистика.
- Пространство «Цех детейлинга» — мойщики, полировщики, специалисты по нанесению составов.
- Пространство «Цех арматурных работ» — разбор/сбор салона, доп. оборудование, шумоизоляция.
- Пространство «Цех плёнки» — оклейка кузова, полиуретановая плёнка, плёнка на лобовое стекло, тонировка.
- Пространство «Аутсорс» — внешние ИП и самозанятые исполнители.
Внутри проекта — реальная логика автомобиля
В пространстве заказ-нарядов проект соответствует конкретному автомобилю (например, Mercedes V-класс или Toyota Land Cruiser). Внутри проекта разделы — это цеха и этапы, через которые проходит машина. В каждом разделе — конкретные задачи с исполнителями, проверяющими, дедлайнами и комментариями.
Маршрутизация задач между пространствами
Ключевая возможность, на которой держится вся схема, — перемещение задачи в другой проект и пространство через меню «три точки». Мастер-приёмщик создаёт задачу в заказ-наряде, выбирает целевое пространство (цех), целевой проект и раздел — задача «улетает» исполнителю в его рабочую среду, при этом он не видит остальные этапы по этому автомобилю и не пересекается с чужими процессами.
Роли под реальную иерархию
- Владелец организации — собственник бизнеса, держит верхнеуровневый контроль.
- Администратор — мастер-приёмщик, управляющий объектом.
- Участник — старший мастер цеха: ставит, перемещает и контролирует задачи внутри своего раздела.
- Исполнитель — конкретный сотрудник в рамках своего проекта (мойщик, полировщик, оклейщик, установщик и т.д.).
- Наблюдатель — роль для контроля без права изменений (например, под задачи прозрачности для клиента).
Подзадачи и шаблоны
Крупные операции — например, оклейка кузова или полная шумоизоляция — раскладываются на подзадачи с собственными номерами и исполнителями. Повторяющиеся комплексы работ оформляются как шаблоны: при заезде типового автомобиля проект собирается из готовых блоков, а не вручную с нуля.
Возможности Strive, которые сработали в этом сценарии
- Гибкая иерархия «пространство → проект → раздел → задача» позволяет описать любой производственный конвейер, а не подгонять бизнес под жёсткий шаблон.
- Перемещение задач между пространствами сохраняет конфиденциальность: исполнитель видит только то, что относится к его зоне ответственности.
- Двухуровневый контроль: исполнитель закрывает задачу, проверяющий подтверждает выполнение — это совпадает с реальной моделью «мастер цеха + мастер-приёмщик».
- Подзадачи с отдельной нумерацией — позволяют дробить сложные комплексы работ без потери ответственности.
- Шаблоны проектов ускоряют запуск типовых заказ-нарядов.
- Встроенный мессенджер — переписка по каждой задаче не теряется в общих чатах.
- Интеграции с Telegram и МАКС — задачи доходят до исполнителей в привычных каналах.
- Регламенты при входе сотрудника — новый участник заполняет профиль, фото, подключает уведомления до того, как приступит к работе.
- Реестр отечественного ПО, серверы в РФ — закрывает вопросы безопасности и долгосрочной устойчивости для российского бизнеса.
Что в итоге?
Strive стал для детейлинг-центра инструментом, который позволил оцифровать производственный конвейер услуг: десятки автомобилей в работе одновременно, сложная маршрутизация между цехами, прозрачные точки контроля и изолированные зоны ответственности исполнителей.
Ключевая ценность продукта в этом сценарии — гибкость структуры и возможность перемещать задачи между пространствами, что позволило встроить таск-менеджер в реальные бизнес-процессы, а не наоборот.
Следующий шаг — масштабирование внедрения на остальные объекты сети и отработка предложенных доработок совместно с командой Strive.
