Вертикальная CRM для заказных пассажирских перевозок и экскурсий

Как устроен бизнес заказных перевозок и почему он операционно сложный

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

Занятость парка. Машин конечное число. У каждой свой график, ТО, ремонт, выходной водителя. Свободна ли «Хайгер» на субботу в 8 утра, диспетчер держит в голове или в табличке, которую правят пятеро. Отсюда двойные брони.

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

ОСГОП. Обязательное страхование ответственности перевозчика перед пассажирами по 67-ФЗ. Полис оформляется на каждое транспортное средство отдельно, не один на весь парк. Кончился полис на конкретной машине. Выпускать её в рейс с пассажирами нельзя.

Детские группы. Школьная экскурсия это не «посадили класс и поехали». Это требования ПП-1527 к организованной перевозке детей. Список детей, сопровождающие, медосмотр водителя, иногда уведомление и сопровождение. Школа не примет рейс без бумаг.

Документы и деньги. КП, договор, акт, обмен с 1С, предоплата, выручка по источникам. Бухгалтер хочет цифры, директор хочет цифры, а они в голове у диспетчера и в десяти файлах.

Пять ниток на каждую заявку. Десятки заявок в неделю. Один человек в голове. Вот вся сложность.

Проблема до системы

Учёт жил в трёх местах. Excel с занятостью, телефон и мессенджеры с заявками, голова диспетчера со всем остальным.

Что из этого получалось на практике.

• Двойная бронь. Две группы на один автобус в одну субботу. Узнаёшь утром в день рейса, когда уже поздно. Одну группу везёшь, второй ищешь машину в панике или срываешь подачу. Клиент, которому сорвали выпускной, не возвращается никогда.
• Цена на глаз. Менеджер называл сумму по памяти. Забыл загородный пробег в обе стороны, забыл простой между подачей и возвратом, забыл второго водителя на дальнем плече. Рейс ушёл в минус. В другой раз перестраховался, задрал цену, спугнул клиента.
• Compliance вспоминали на штрафе. Полис ОСГОП на машине кончился, а узнаёшь от ГИБДД на проверке. Документы на детскую группу собирали в последний вечер.
• Потерянные заявки. Заявки падали в почту, в WhatsApp, в Telegram, на телефон. Часть терялась между каналами. Сколько именно потеряли, не знал никто, потому что нигде не считалось.
• Нечем показать цифры. Директор спрашивает выручку за квартал по источникам и средний чек. Ответа нет, есть только ощущения.

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

Решение в одном абзаце

Я собрал веб-приложение, в котором живёт вся операционка перевозчика. Заявка с жизненным циклом и номером. Шахматка занятости парка, где база физически не даёт посадить два рейса на одну машину внахлёст. Авторасчёт цены и времени по тарифу и маршруту. Подбор машины из своего парка и от подрядчиков со страховым гейтом на выпуск. Экскурсионный блок с гидами, объектами и программами. Детские группы по ПП-1527 со списками, сопровождающими и медосмотром. Документы с обменом в 1С. Отчёты по деньгам и воронке. Роли разделены, вход без паролей, всё на одном сервере в России.

Сквозной сценарий заявки. Две дорожки

Один и тот же скелет системы работает на двух очень разных задачах. Покажу обе. Контраст специально.

Дорожка А. Трансфер. Скорость и один ввод на весь цикл

Корпоративный клиент просит подать автобус на 45 человек к отелю, отвезти делегацию на завод за городом и вернуть. Менеджер вводит данные один раз.

1. Заявка. Откуда, куда, когда, сколько человек. Заявке присваивается номер вида KB-2026-NNNNNN. Черновик сохраняется сам, ничего не теряется.
2. Подбор машины и водителя. Система показывает, что свободно на эту дату по шахматке. Менеджер выбирает машину нужной вместимости и водителя. Занятость закрывается сразу, машина больше не предложится другому на это окно.
3. Расчёт цены. Маршрут загородный, тариф межгород. Система считает пробег в обе стороны с коэффициентом, добавляет время в пути и простой. Цена не из головы, а из маршрута.
4. Разнаряд. Рейс попадает в разнаряд на день. Водитель видит задачу, диспетчер видит загрузку.
5. Документы. КП, договор, потом акт. Выгрузка в 1С без двойного ввода.

Один ввод данных проходит весь цикл от заявки до 1С. Менеджер не перебивает одно и то же в пять мест.

Дорожка Б. Школьная экскурсия. Глубина и управление сложностью

Школа заказывает экскурсию для класса. «Заповедник плюс смотровая площадка». Тут одной заявки мало, под неё собирается конструкция.

• Автобус нужного класса под количество детей и категорию перевозки.
• Водитель с категорией D и действующими документами.
• Гид под специализацию. Не любой свободный, а тот, кто ведёт именно природу и заповедник. У гида в карточке тип, языки, специализация, ставка за экскурсию.
• Программа по объектам. Маршрут собирается из точек каталога. Заповедник, смотровая, штольни. У каждого объекта свои данные.
• Список детей. Поимённо. Это требование к организованной перевозке, без списка школа не отпустит.
• Сопровождающие по ПП-1527. На каждый автобус положены взрослые. На большую группу у каждой двери. Система ведёт это по дверному принципу, а не «впишите сколько-нибудь».
• Медосмотр и ОСГОП. Медосмотр водителя и действующий полис на конкретную машину. Без этого выезд не оформить.

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

Шахматка и гарантия без пересечений

Сердце системы это шахматка занятости парка. По вертикали машины, по горизонтали время. Видно сразу, кто на рейсе, кто свободен.

Гарантию «не встанет два рейса на одну машину внахлёст» держит сама база данных. Это ограничение на пересечение интервалов занятости машины (констрейнт order_vehicles_no_overlap). Не валидация в коде приложения, которую можно обойти кривым запросом или забытой проверкой, а правило в Postgres. Машина с пересекающимся окном просто не запишется. Физически.

Радар горящих заявок

Отдельный экран триажа собирает заявки под угрозой в три блока по остроте.

Это не отчёт для красоты. Это рабочий лист диспетчера на утро. Сразу видно, где сейчас рвётся.

Разнаряд на день

Отдельно живёт утренний разнаряд. Сколько сегодня рейсов, сколько водителей, кто в рейсе со вчера. Лист печатается. Можно листать вчера, сегодня, завтра. Диспетчер планирует день не по памяти, а по экрану. И если диспетчер заболел, разнаряд открывает любой, кто на смене.

Автоценообразование по тарифам

Цена считается не «как обычно берём», а по тарифу под тип рейса.

Время окончания рейса и цена тянутся из маршрута. Для межгорода настраивается скорость, по которой система оценивает время в пути (километры делятся на скорость с коэффициентом). Развилки расчёта вынесены в настройки, чтобы директор выбирал политику, а не программист.

Экскурсии, гиды, объекты, маршруты. Почему это вертикаль, а не «ещё модуль»

Вот тут видно, чем узкая отраслевая система отличается от коробки. В коробке экскурсия это «заказ с полем комментарий». Здесь под неё заведены отдельные сущности.

• Каталог программ. «Программы для групп, продаём группе целиком». Не сборная группа из отдельных билетов, а класс или родительский комитет целиком. Под бизнес перевозчика это принципиально, индивидуальных мест он не продаёт.
• Объекты. Достопримечательности с данными. Заповедник, штольни, смотровая, музей. Из них собирается программа.
• Гиды. Карточка с ФИО, типом, телефоном, языками, ставкой за экскурсию и специализацией. Гид назначается под заявку по профилю, а не «кто свободен».
• Назначение под заявку. Программа, гид и объекты цепляются к конкретной заявке и едут с ней в разнаряд и документы.

Это не «добавили вкладку». Это отдельная предметная область со своими справочниками. Поэтому система и называется вертикальной. Она знает язык отрасли, а не общий язык продаж.

Compliance встроен в поток, а не висит отдельной папкой

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

ОСГОП. Страховой гейт на выпуск

ОСГОП это обязательное страхование ответственности перевозчика перед пассажирами по 67-ФЗ. Полис оформляется на каждую машину отдельно. Когда заявку переводят в работу, система контролирует, что у назначенных машин действуют и ОСГОП по 67-ФЗ, и ОСАГО по 40-ФЗ. Полис кончился. Это видно до рейса, а не на проверке.

Цена вопроса реальная. По части 1 статьи 11.31 КоАП РФ штраф юридическому лицу за перевозку пассажиров без надлежащего ОСГОП составляет от 500 000 до 1 000 000 ₽. Страховая сумма по ОСГОП за вред жизни пассажира не менее 2 025 000 ₽ на человека. Это не та статья, где экономят на полисе.

Детские группы. ПП-1527

Для организованной перевозки детей система ведёт список пассажиров поимённо, сопровождающих по дверному принципу на каждый автобус (на большую группу у каждой двери) и медосмотр водителя. Это требования постановления Правительства РФ № 1527. Школа без этих бумаг рейс не примет, и система не даёт уехать в экскурсию с незакрытыми пунктами.

Медосмотр и роли

Предрейсовый медосмотр водителя по приказу Минздрава 266н фиксируется в системе. И тут важная вещь про роли. Система их разделяет, а не сваливает в кучу.

Диспетчер диспетчеризирует. Бухгалтер считает. Каждый видит своё. Это не ограничение, это порядок. Медика осматривает медик, его подпись это его подпись, система её не подменяет.

152-ФЗ

В системе есть личные данные. Пассажиры, дети, контакты клиентов. Поэтому в ней живёт обработка запросов субъектов персональных данных по статьям 14, 20, 21 со сроком ответа 10 рабочих дней и журнал аудита критичных действий, который только дополняется и не переписывается задним числом. Попытку изменить или удалить запись журнала отклоняет сама база, тем же способом, что и пересекающиеся брони.

Это техническая часть. Уведомление в Роскомнадзор, политика обработки персональных данных и согласия это процесс на стороне перевозчика. Его помогаю выстроить, но одной кнопкой в системе он не закрывается.

Документы и обмен с 1С

Заявка доходит до бумаг без повторного ввода. КП собирается по шаблону. Дальше договор, потом УПД или акт. Номенклатура услуг единая, чтобы в 1С приходили те же наименования, что в CRM. Обмен идёт через CommerceML, плюс ЭДО. Бухгалтер не перебивает заявку руками в учётную систему.

Под типовые заказы есть шаблоны. Свадьба, корпоратив, школьная программа. Менеджер не собирает КП с нуля каждый раз.

Отчёты и деньги

Директор спрашивает цифры. Теперь есть чем ответить.

• Выручка за период. 30, 90, 180, 365 дней.
• Заявок выполнено и средний чек.
• Источники заявок. Откуда пришли. В демо-наборе около 29 % заявок приходят с сайта автоматом, минуя ручной ввод.
• Воронка. Лид, дальше по этапам, до выигрыша. Этапы синхронны статусу заявки, а не ведутся отдельно руками.
• Выгрузка в xlsx.

Отдельно стоит сказать про приём с сайта. Раньше заявка с сайта это письмо, которое кто-то должен прочитать и завести. Теперь форма с сайта приходит в систему сама и становится заявкой с номером. Воронка её сразу считает. Те самые потерянные заявки между каналами перестают теряться, потому что появляется один вход и счётчик.

Инциденты

Поломка, болезнь водителя, ДТП, форс-мажор фиксируются в отдельном журнале. Это нужно для трёх вещей. Аналитика, что и почему срывалось. Материал для страховых случаев. И запись действий, кто и когда менял замену машины по инциденту. Сорвалась машина, замена оформляется через инцидент, а не «по-тихому переписали».

Архитектура и эксплуатация коротко

Без воды. Стек выбран под масштаб одной конторы, а не под красивое резюме.

• Frontend. Next.js 16, App Router, React 19, серверные actions.
• Backend. Серверные actions, PostgreSQL 18, Drizzle ORM.
• Auth. Auth.js v5, вход по magic-link без паролей.
• UI. Tailwind 4 плюс Shadcn.
• Инфраструктура. Один VPS в России. Атомарные релизы с авто-откатом. Журнал аудита только на дозапись. Бэкап.

Kubernetes нет. На этот масштаб он добавляет операционных расходов больше, чем приносит пользы. Один сервер, один процесс развёртывания, обслуживается без отдельной команды эксплуатации.

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

Одну вещь подчеркну отдельно, потому что она про доверие. Гарантия «без двойных броней» это ограничение в базе данных, а не проверка в коде. Проверку в коде можно обойти, забыть, сломать рефакторингом. Ограничение в базе не обойти из приложения. База просто не примет пересекающиеся записи. Это разница между «мы стараемся не допускать» и «это технически невозможно».

Вход по magic-link отдельно. Пользователю не нужен пароль. На почту приходит ссылка, по ней он входит. Меньше паролей, меньше украденных паролей. Подаю это как удобство, без громких слов про банковский уровень.

Кому это подходит и когда не нужно

Эта система не «всем перевозчикам», а узкому профилю.

Подходит

• Заказные пассажирские перевозки со своим парком и подрядчиками, где занятость надо вести по машинам и есть риск двойных броней.
• Экскурсионное обслуживание с гидами, программами и объектами, где под заявку собирается конструкция, а не «одна услуга».
• Школьные и детские перевозки, где compliance по ПП-1527 это ежедневная работа, а не разовая бумага.
• Смешанный поток. Корпоратив, свадьбы, межгород, школа в одной конторе. Разные тарифы, разные документы, один диспетчер.

Общий знаменатель один. Занятость парка важнее воронки продаж, и есть compliance, который нельзя забывать. Если это про вас, коробка с Kanban-воронкой будет мешать, а не помогать.

Не нужно

• Один-два автобуса и владелец сам диспетчер. Excel и телефон дешевле, держать систему незачем.
• Регулярные маршруты по расписанию. Это другой жанр и другой закон (220-ФЗ), не заказные перевозки. Система заточена под заказ под клиента.
• Чистые продажи без операционки. Если автопарка нет, а есть только звонки и сделки, берите обычную sales-CRM.
• Нет внутреннего владельца. Если за справочниками, тарифами и полисами в системе никто не следит, она протухнет за полгода. Нужен человек, который ведёт данные.

Итог

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

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

И ещё. Это не коробка на продажу. Это пример того, как я проектирую систему под отрасль. Под вашу задачу разберём отдельно. Может, хватит донастроить то, что уже есть. Может, строить узкое под вас.

FAQ