Перейти к содержимому

Логистика · ИИ

Vezira

Транспортная компания со смешанным автопарком: ассистент понимает запрос диспетчера, собирает данные из CRM, TMS и телематики, проверяет ограничения и делает разрешённое.

Роль
Бэкенд, интеграции, ИИ-ассистент
Срок
6 недель
Стек
NestJS · PostgreSQL · OpenAI API

Что изменилось

11 → 4,2 минуты
на обработку новой заявки. Данные для неё собирает теперь не диспетчер.
14% → 3,8%
заявок требуют ручного исправления. Ошибки переписывания уходят вместе с переписыванием.
43%
типовых операций диспетчер делает через ассистента, не переходя между системами.
+21%
заявок обрабатывает один диспетчер за смену.

Цифры сняты за неделю пилота — пять диспетчеров из семнадцати. Компания осталась на своих системах: CRM, TMS и телематика работают там же и так же, никого не переселяли в новый продукт. AI-интерфейс встал поверх имеющейся инфраструктуры, а значит, её ограничения достались ассистенту вместе с данными.

Что было до

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

  • Больше 4 800 заявок на перевозку в месяц проходило через диспетчерскую. Ни одна из систем на пути заявки не держала её целиком: она складывалась только у того, кто её вёл.
  • Семнадцать диспетчеров переносили данные между CRM, TMS, почтой и мессенджерами. Это была не работа с грузом и не разговор с клиентом, а набор одного и того же в следующем окне.
  • Одиннадцать минут в среднем занимала обработка новой заявки. При потоке в 4 800 заявок в месяц это не задержка одного человека, а расписание всей диспетчерской.
  • 14% заявок требовали исправлений: адрес, дата, стоимость или параметры груза приезжали в следующую систему не теми. Это ошибки не решения, а переписывания — каждая появлялась в момент, когда данные набирали во второй раз.

Что сделали

  • Один API поверх трёх систем: CRM, TMS и телематика отвечают на вопрос диспетчера вместе, а не по очереди в трёх окнах.

  • Слой инструментов вместо доступа к базе: модель просит вызов, а права, параметры и бизнес-правила проверяет наш код.

  • Журнал каждого действия: кто попросил, какой инструмент вызван, с какими параметрами и что вышло — по нему же правились промпты.

Результат

Диспетчер спрашивает — ассистент собирает ответ из CRM, TMS и телематики, проверяет ограничения и делает то, что разрешено этому сотруднику. Новая заявка занимает 4,2 минуты вместо одиннадцати, а исправлять приходится 3,8% заявок вместо 14%. Системы при этом остались прежними: изменился не учёт, а способ до него добраться. Выбор между вариантами по-прежнему делает человек.

Кто заказчик

Транспортная компания: возит грузы собственными машинами и привлечёнными. Заявки, водители и рейсы ведутся в CRM и TMS, координаты машин приходят из телематики. Диспетчерская — семнадцать человек и больше 4 800 заявок в месяц.

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

Задача

Как ставил заказчик
«Чат с GPT для диспетчеров»: окно, в которое сотрудник пишет „Найди машину на завтра из Москвы в Казань“ и получает ответ. В такой постановке проект выглядел как подключение готового чата к рабочему месту.
Как задача выглядела после разбора
Сам чат почти ничего не решает. Настоящий запрос звучит не как „найди машину“, а как „найди свободную фуру до 20 тонн, которая завтра будет не дальше 100 км от Подольска, и предложи три варианта с минимальным холостым пробегом“. Такой ответ собирается из нескольких систем: понять запрос, получить данные, проверить ограничения, предложить варианты, выполнить разрешённое. Не чат, а AI-слой поверх работающей инфраструктуры.

Почему нельзя было в лоб

Слой строился не на пустом месте: CRM, TMS и телематика уже работали, факты лежали по разным местам, а часть действий нельзя было доверить модели в принципе. Шесть условий, и каждое видно в архитектуре.

У TMS нет внешнего API
Нормального внешнего API у TMS не было, а рейсы и машины ведутся именно там. Обращаться к ней из ассистента было не через что: сначала пришлось построить свой backend, и разговаривает с TMS только он.
Факты разложены по трём системам
Часть информации о заявке была только в CRM, часть — в TMS, а актуальные координаты машин приходили из отдельной телематической системы. Ни один вопрос диспетчера не отвечался из одного источника, поэтому единый слой понадобился раньше ассистента.
Часть договорённостей — в переписке
То, о чём договорились по рейсу, оставалось в Telegram-чатах: текстом, а не полями. Такие данные не выбираются условием запроса, их приходится искать по смыслу — и уметь это должен был тот же слой инструментов.
Модели нельзя доверить запись
Критичные данные — заявка, рейс, стоимость — не могли меняться по решению модели. Поэтому прямого доступа к базе AI не получил вообще: он может попросить вызвать инструмент, а что инструмент сделает с базой, написано нами, а не подсказано моделью.
Права — не свойство разговора
Ассистент действует от имени сотрудника, и позволено ему ровно то, что позволено этому сотруднику. Проверка прав не может жить в промпте: о чём попросила модель и что ей разрешено выполнить — два разных списка, и сводит их слой инструментов до вызова.
Ограничения груза и рейса — правила компании
Тоннаж, расстояние, параметры груза — не пожелания внутри фразы, а условия, которые обязаны выполниться. Модель может ошибиться в числе, инструмент — нет: параметры и бизнес-правила он проверяет сам, до того как что-то произойдёт.

Как шла работа

  1. 01

    Аудит процессов и интеграций

    Неделя 1

    Разбирали, что именно делает диспетчер: какие системы открывает, в каком порядке и ради какого ответа. Итог недели — карта действий диспетчера: список операций, каждая из которых потом стала либо инструментом ассистента, либо тем, что осталось человеку.

  2. 02

    Единый бэкенд поверх систем

    Недели 2–3

    Две недели ушли на API, которого не существовало: CRM, TMS и телематика оказались за одним интерфейсом, с общими понятиями заявки, машины и рейса. Ассистента здесь ещё нет — слой сначала научился отвечать на вопросы сам, обычным REST.

  3. 03

    Ассистент, инструменты, права

    Неделя 4

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

  4. 04

    Автоматические сценарии и журнал

    Неделя 5

    Часть операций перестала требовать вопроса: типовые сценарии выполняются сами. Всё, что ассистент сделал, пишется в журнал — кто попросил, какой инструмент вызван, с какими параметрами и что вышло. Без журнала действия модели нечем разбирать.

  5. 05

    Пилот и правка промптов

    Неделя 6

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

Технические решения

Стек отвечает на одно условие: модель не ходит в чужие системы сама. NestJS держит слой инструментов и границу, за которую модель не проходит, PostgreSQL хранит данные и журнал, OpenAI API отвечает только за понимание запроса.

  • Один API вместо трёх дверей

    Ассистент не знает ни CRM, ни TMS, ни телематику: он знает наш backend, а тот уже разбирается, у кого что спрашивать. У трёх систем появился один словарь — заявка, машина, рейс — и один ответ на вопрос, который раньше собирался из трёх окон.

  • Слой инструментов, а не доступ к базе

    Между моделью и корпоративными системами стоит собственный слой инструментов. Модель может только попросить вызов с параметрами; вызывает NestJS, проверяя права сотрудника, сами параметры и бизнес-правила. Ошибка модели в этой схеме — отклонённый вызов, а не изменённая заявка.

  • Журнал вызовов

    Каждое действие ассистента — строка: сотрудник, запрос, инструмент, параметры, результат. Это единственный способ ответить, почему рейс выглядит так, если часть шагов сделала модель. По этому же журналу видно, что вызывается чаще всего, и по нему на пилоте правили промпты.

  • Что делается без вопроса

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

  • Текст переписки рядом с таблицами

    Часть фактов о рейсах лежит в чатах, поэтому в PostgreSQL рядом с обычными таблицами живёт векторный индекс (pgvector): инструмент поиска возвращает фрагменты, относящиеся к вопросу, а не всю ветку. Модель получает их как данные, а не как право что-то менять.

Что осталось за рамками

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

  • Замена корпоративных систем. CRM, TMS и телематику не переписывали и не переносили: работа заканчивалась на границе слоя, который к ним обращается.

  • Прямая запись из модели. Ни один инструмент не отдаёт базу наружу: новое действие пишут и разрешают руками, а не объясняют в промпте.

  • Выбор между вариантами. Ассистент собирает варианты и показывает их, решение принимает диспетчер: правила, по которому можно выбрать за него, за шесть недель не появилось.

  • Весь поток. Шестая неделя — пилот на пяти диспетчерах, и промпты правились по их работе. Что покажут все 4 800 заявок в месяц, шесть недель не отвечают.

Работа, которая не кончается вместе с проектом: правила и промпты правятся по журналу вызовов — там видно, какие запросы ассистент понял не так, и другого источника для этих правок нет.

Другие проекты

Все проекты

Контакты

Пришлите описание задачи

Ответ с объёмом работ, сроками и оценкой бюджета придёт в течение 24 часов.

Получить оценку

Первый звонок — 30 минут, без обязательств с вашей стороны.