RailMarket: маркетплейс заявок на железнодорожные перевозки

В логистике железнодорожных грузоперевозок поиск вагона или груза долго держался на звонках, таблицах и личных связях. Отправитель не видел свободный подвижной состав целиком. Оператор не видел заявки на перевозку по станциям и датам в одном окне. Документооборот — от цены до договора и формы ГУ-12 — собирали вручную.

Клиенту нужна была площадка, где грузоотправители и операторы подвижного состава находят друг друга онлайн, договариваются о цене и доводят сделку до подписанных документов. На старте проект шёл под рабочим именем eVagon; в релиз и в дизайн вышел как RailMarket — веб-сервис под рынок железнодорожных перевозок в России и СНГ.

6 мес.

от аналитики до релиза

3

личных кабинета

5

статусов сделки

ГУ-12

в контуре сделки

01. Задача

Собрать приложение для логистики ж/д грузоперевозок, в котором:

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

Срок — шесть месяцев. В работе участвовали четыре специалиста WAPP: аналитика, дизайн, фронтенд и бэкенд.

02. Три кабинета — три роли

В продукте не один «общий» личный кабинет, а три контура с разными задачами в цепочке грузоперевозок.

Кабинет грузоотправителя

Регистрация компании, профиль, список заявок на перевозку. Сценарий «Отправить груз»: станции отправления и назначения, тип груза, тип вагонов, даты подачи. В результатах — подходящий подвижной состав; дальше заявка уходит оператору на расчёт. Есть поиск на карте (Яндекс.Карты) и переговоры по статусам заявки.

Регистрация: отправитель или оператор

Разделение ролей на входе — без этого ломается вся модель прав и видимости заявок.

Кабинет оператора подвижного состава

Управление парком вагонов, сценарий «Найти груз», фильтры по станциям, датам, типу груза и статусу. Из карточки заявки оператор отправляет предложение: даты подачи, стоимость без НДС, сообщение отправителю. Статусы сделки: новая → оформление → выполняется → выполнена (плюс отмена).

Подвижной состав

Оператор ведёт список вагонов: тип, станции, доступность — без этого matching «груз ↔ вагон» пустой.

Администрирование в продукте

Помимо кабинетов отправителя и оператора, в сервисе есть контур управления сотрудниками компании (роли, активация, доступы). Отдельно была платформенная админ-панель на React Admin: компании, заявки, переписки, вагоны и технические перевозки — для поддержки и супервизоров площадки.

03. Что сделали в продукте

Регистрация, профиль и заявки на перевозку

Форма регистрации разделяет роли sender и operator. В кабинете видны заявки и предложения, смена статуса и история переписки. Уведомления — в интерфейсе и по почте.

Профиль компании

Реквизиты и контакты подтягиваются в договор и счёт — без повторного ввода при каждой сделке.

Поиск с фильтрами и картой

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

Переговоры и предложение цены

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

Документооборот: ГУ-12, договоры, комиссия и НДС

Это сердце кейса с точки зрения отраслевой компетенции — сильнее списка фреймворков.

После взаимного согласия RailMarket не «забывает» сделку в чате:

1. Договор собирается автоматически в PDF из данных заявки на перевозку и реквизитов сторон (шаблоны под нормы работы с ОАО «РЖД»).
2. Счёт на оплату считается с учётом комиссии площадки и НДС — формулы зафиксированы в API, а не в Excel у менеджера.
3. Стороны скачивают документы, подписывают и загружают сканы обратно в сервис.
4. Отправитель указывает номер формы ГУ-12 — заявка на перевозку грузов железнодорожным транспортом; номер виден контрагенту в карточке сделки.
5. Оба кабинета видят этап документооборота онлайн: кто подписал, что загружено, на каком статусе перевозка.

Так площадка закрывает не только matching «вагон ↔ груз», но и финальный контур, без которого ж/д логистика в России не считается закрытой сделкой.

Наблюдаемость

На клиенте — Google Tag Manager (воронка и действия пользователей). Бэкенд: Express и MongoDB, почта через Yandex SMTP; для сопровождения — Telegram-бот. Деплой через PM2.

04. Технологии

Стек по репозиториям 2019–2020 (клиент на React/Next, не на Vue).

Клиент (кабинеты отправителя и оператора): Next.js 9, React 16.9, Material-UI 4, Redux / Redux-Saga, Яндекс.Карты, GTM.

Админ-панель: React Admin 2.x, Material-UI, русская локализация.

API: Node.js, Express 4, MongoDB / Mongoose 5, JWT, генерация PDF (html-pdf + EJS), Nodemailer, node-schedule, Telegram Bot API, Swagger.

05. Результат

Клиент получил рабочий маркетплейс логистики ж/д грузоперевозок: заявки на перевозку, поиск вагонов и груза, переговоры, отраслевой документооборот (ГУ-12, договоры, комиссия и НДС) и прозрачный статус сделки. Три кабинета закрывают отправителя, оператора и команду площадки.

Для WAPP кейс — якорь рядом с управлением флотом SWAPPZ и хабом автоматизации логистики. Если смотрите на электронный документооборот перевозок сейчас — см. разбор электронных путевых листов и ЭТрН с сентября 2026.

Нужна площадка или кабинет под перевозки?

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

Обсудить проект — также решения для логистики, кейс SWAPPZ и статья об ЭПЛ и ЭТрН.