Личный кабинет транспортной компании: заявки, статусы и документы

Теоретический пример. У транспортной компании 40 постоянных клиентов. Каждый день менеджеры получают 70–80 звонков и сообщений: «где машина», «пришлите УПД», «когда выгрузка». Ответ менеджер ищет в 1С и почте или спрашивает логиста. Клиент ждёт час, хотя статус груза в учёте уже был.

Личный кабинет снимает такие вопросы, если компании есть что показать: подтверждённые этапы и документы. Пустой экран с надписью «в работе» только добавит звонков.

Какие вопросы должен решать кабинет

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

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

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

Откуда берётся статус перевозки

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

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

Полезно разделить фактическую дату, план и прогноз. «Плановая доставка 21 октября» отличается от «груз выдан 21 октября в 14:20». При отсутствии свежих данных кабинет показывает последнюю подтверждённую информацию и способ уточнения. Нельзя создавать видимость непрерывного мониторинга, если такого источника нет.

Частичная доставка и несколько исполнителей

Условный пример: из десяти мест восемь доставлены, два ожидают следующей отправки. Для клиента единый статус «доставлено» будет неверным. В модели нужны части отправки, их количество и отдельные этапы, а на экране понятная сводка по всему заказу.

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

До разработки пройдите ещё три случая: отмена части заказа, повреждение с отдельным обращением и возврат. Если первая версия не поддерживает операцию, пользователь должен увидеть понятный способ передать её менеджеру. Такой переход сохраняет номер заказа и содержание вопроса.

ИИ‑сводка по событиям заказа

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

Условный пример. Клиент спрашивает: «Всё уже довезли?». В данных указано: восемь мест выданы, два находятся на терминале, подтверждённого срока дальнейшей отправки нет. Черновик ответа: «Выданы восемь из десяти мест. Два остаются на терминале. Дата дальнейшей отправки пока не подтверждена». Рядом показываются события, на которых основан текст.

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

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

Заявки и документы без лишней ручной работы

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

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

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

Права доступа нужно проверить на сложных случаях

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

Минимальный набор проверок перед запуском:

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

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

Кабинет поверх действующего учёта

Проверьте готовый клиентский сервис вашей TMS. В отраслевом транспортном решении 1С личный кабинет клиента указан среди возможностей. Если он закрывает задачу, разумно настроить его. Собственная надстройка оправдана особым интерфейсом или ИИ‑сценарием, которого не хватает.

Возможная связка: разрешённые события из TMS → кабинет и ИИ‑сводка → проверка менеджером → ответ клиенту. Для компаний, отправляющих через ПЭК, отдельно существует документация API личного кабинета: она описывает получение статусов и документов. Подключение любого аккаунта документация не гарантирует: права, условия доступа и нужные методы проверяют до разработки. Запись изменений требует отдельного согласованного сценария.

Что делать, если клиент видит устаревшие данные

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

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

Как запустить и измерить пользу

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

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

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

С чего начать обсуждение

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

Источники

• ПЭК: возможности личного кабинета, описание собственного клиентского сервиса; проверено 18.10.2026.

• 1С: возможности отраслевого транспортного решения, проверено 18.10.2026.
• ПЭК: документация API личного кабинета, проверено 18.10.2026.

Смежные разборы: Автоматизация международной логистики: этапы и отклонения; Контроль документов по перевозкам: комплектность, подписи и оплата.