Сообщение о перевозке редко приходит как готовая карточка. Клиент называет города в одном письме, массу — в следующем, а дату обещает прислать позже. Диспетчер перечитывает переписку, переносит сведения в реестр и выясняет, какие условия ещё не согласованы.
ИИ-помощник может подготовить черновик заявки: выделить маршрут, груз, дату и другие нужные поля, показать источник каждого значения и составить список вопросов. Но заполненная карточка не означает, что перевозка согласована. Машину, цену и коммерческие условия подтверждает диспетчер.
Что теряется при ручном разборе сообщения
Основной риск — не пустая ячейка, а правдоподобное значение без надёжного источника. Сотрудник может принять город за точный адрес, перепутать массу до и после исправления или понять слово «завтра» без учёта времени сообщения. Внешне карточка будет выглядеть полной, хотя часть сведений в ней появилась из догадки.
Поэтому помощник должен сохранять рядом со значением исходную реплику или ссылку на неё. Диспетчер увидит не только «масса — 1,2 т», но и сообщение, из которого взято это значение. Если сведений нет или две реплики противоречат друг другу, система ставит вопрос, а не дописывает наиболее вероятный вариант.
Полезный результат такого разбора — проверяемый черновик. Он помогает быстрее увидеть известные условия и пропуски, но не заменяет расчёт перевозки и решение ответственного сотрудника.
Как договориться о полях заявки
Сначала руководитель и диспетчеры определяют структуру карточки. Универсального набора для всех перевозок нет: обязательность поля зависит от типа груза, маршрута и правил конкретной команды.
| Поле | Что сохранять | Что проверить |
|---|---|---|
| Отправление | Город, точный адрес или несколько точек в формулировке отправителя | Достаточно ли данных для этого этапа; известна ли последовательность точек |
| Назначение | Город, адрес и порядок точек, если их несколько | Не перепутаны ли отправление и назначение |
| Дата и временное окно | Исходную формулировку и подтверждённое календарное значение | Однозначна ли дата; указан ли интервал времени |
| Описание груза | Наименование, упаковку, количество мест | Понятен ли груз диспетчеру; нужны ли дополнительные характеристики |
| Масса | Число, единицу и исходную запись | Не было ли исправления; требуется ли перевод единиц |
| Объём | Число, единицу и источник | Обязательно ли поле в выбранном сценарии |
| Контакт | Переданные имя и способ связи | Есть ли право использовать и сохранять эти сведения в процессе |
| Особые условия | Погрузку, температурный режим и другие прямо указанные требования | Кто подтверждает условие и достаточно ли его описания |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для каждого поля полезно зафиксировать четыре правила: когда оно обязательно, какие единицы допустимы, откуда брать значение и кто решает спорный случай. Тогда отсутствие объёма может быть допустимо для одного этапа и блокировать следующий в другом процессе.
Помощник не должен заполнять пропуск сведениями из похожей заявки. Он может сформулировать конкретный вопрос: «Укажите точный адрес погрузки» или «Нужен ли объём для расчёта этого типа перевозки?» Ответ затем добавляется в историю карточки.
Как обрабатывать уточнения и исправления
Заявка меняется по мере переписки. Новая реплика может исправить только массу, а маршрут и дата останутся прежними. Если просто перезаписать карточку, диспетчер не увидит, почему значение изменилось и какая версия актуальна.
Рабочая последовательность выглядит так:
- Помощник принимает сообщение и сохраняет его как источник.
- Извлекает значения в черновик, не подтверждая перевозку.
- Сверяет поля с исходным текстом и действующей версией заявки.
- Отмечает пропуски, противоречия и неоднозначные формулировки.
- Диспетчер проверяет карточку, задаёт вопросы и подтверждает дальнейшее действие.
Каждое исправление связывается с предыдущей версией. В карточке остаётся старое значение, новая реплика и признак того, какое значение сейчас используется. Такой журнал нужен не ради накопления переписки, а чтобы сотрудник мог восстановить ход изменения условий.
Адрес нельзя молча заменять по похожему названию. Формулировку «завтра» нельзя переводить в календарную дату без времени исходного сообщения и согласованного правила. Если правило не позволяет получить однозначное значение, поле остаётся вопросом для человека.
Повторное сообщение требует отдельной проверки. Система должна отличать исправление от дубля и от новой перевозки по согласованным признакам. Пока таких признаков нет, безопаснее передать совпадение диспетчеру, чем незаметно объединить две заявки.
Учебный пример заявки
Условные сообщения для объяснения, не реальная перевозка и не результат теста системы.
Первое сообщение: «Нужно перевезти коробки из Казани в Самару, масса 800 кг. Дату и адреса уточню».
Второе сообщение: «Исправление: масса 1,2 т, остальное без изменений».
| Поле | Черновик после уточнения | Действие |
|---|---|---|
| Откуда/куда | Казань → Самара | Запросить точные адреса |
| Масса | 1,2 т; исходные 800 кг заменены уточнением | Сохранить связь с исправляющей репликой |
| Дата | Не указана | Уточнить, не подставлять текущую |
| Объём и условия | Не указаны | Проверить обязательность по правилам команды |
| Машина и цена | Не подтверждены | Решает диспетчер |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
В этом примере помощник меняет только массу. Он не рассчитывает транспорт, не подбирает тариф и не делает вывод о подходящей машине. Значение 800 кг остаётся в истории, но текущая версия ссылается на исправляющую реплику с 1,2 т.
Если команде нужен перевод единиц, его стоит показывать отдельно от исходного значения. Например: «1,2 т = 1200 кг — расчёт системы». Так диспетчер различает текст клиента и вычисленное представление. Правило пересчёта и допустимые единицы проверяют на контрольных примерах до рабочего запуска.
Когда заявку должен разобрать человек
Помощник передаёт заявку диспетчеру, если не может получить однозначную карточку по согласованным правилам. Типичные причины:
- указано несколько адресов, но неизвестен их порядок;
- в сообщениях стоят разные даты без явного исправления;
- описание груза не позволяет определить нужные для команды характеристики;
- особое условие сформулировано неясно;
- новая реплика похожа одновременно на исправление и на отдельную заявку;
- реестр или другое место сохранения недоступно.
Человек также сохраняет решения, которые нельзя выводить из заполненности полей. Диспетчер подтверждает цену, наличие транспорта, выбор машины и принятие заказа. Помощник не должен писать клиенту, что перевозка согласована, только потому, что в карточке больше нет пустых строк.
Чем ИИ-агент отличается от бота и интеграции
Формат решения зависит от поведения процесса. Если сотрудник заполняет известную форму, а система всегда передаёт поля в один реестр, может хватить обычной интеграции. Если заявку удобно принимать в диалоге по фиксированным вопросам, интерфейсом может стать бот.
ИИ-агент уместен, когда следующий шаг зависит от содержания сообщения: определить, к какой заявке относится уточнение, выбрать нужную проверку или подготовить вопрос о пропущенном поле. Его действия всё равно ограничивают заранее. Агент не получает право назначать транспорт или соглашаться на условия, если эти решения оставлены диспетчеру.
Switch On AI разрабатывает такие сценарии в рамках услуги AI-агентов. До разработки нужно определить входные сообщения, структуру карточки, разрешённые действия и момент передачи человеку. Если задачу надёжнее решить фиксированным сценарием, агентный подход не нужен.
Подход к извлечению и проверке полей можно также посмотреть в демонстрации обработки транспортных заявок. Это демонстрационный сценарий, а не действующая транспортная система.
Как проверить пилот на своих сообщениях
Проверку начинают с обезличенных примеров, которые отражают обычные и сложные ситуации команды. Для каждого примера заранее записывают ожидаемую карточку, вопросы диспетчеру и запрещённые автоматические действия.
| Проверочная ситуация | Ожидаемое поведение |
|---|---|
| Полная заявка | Значения совпадают с сообщением и имеют источники |
| Пропущена дата | Поле отмечено как отсутствующее; система не подставляет текущую дату |
| Использованы разные единицы | Исходные значения сохранены; пересчёт явно отделён от текста отправителя |
| Пришло исправление | Новое значение связано с репликой, прежнее доступно в истории |
| Указано несколько адресов | Неизвестный порядок отмечен как вопрос |
| Сообщение пришло повторно | Лишняя карточка не создаётся по согласованному правилу обработки дублей |
| Система сохранения недоступна | Ответственный видит ошибку; нет ложного сообщения об успешной записи |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Критерий проверки — не абстрактная «умность» помощника. Нужно убедиться, что значения совпадают с оригиналом, спорные места заметны, исправления не теряются, а повтор не создаёт лишнюю заявку. Универсальный процент точности здесь ничего не докажет: выборку и допустимые ошибки определяют для конкретного процесса.
После изменения правил полей, единиц или сопоставления сообщений затронутые проверки повторяют. Успешный разбор одного примера не подтверждает готовность решения ко всем форматам заявок.
Что подготовить для обсуждения проекта
Для первой оценки соберите несколько обезличенных сообщений: полную заявку, заявку с пропуском и переписку с исправлением. Добавьте текущую таблицу или перечень полей, правила их обязательности и описание того, кто подтверждает перевозку.
Полезно заранее ответить на четыре вопроса:
- Из каких каналов приходят сообщения?
- Где диспетчер хранит карточку и историю изменений?
- Какие поля нужны до расчёта, а какие можно уточнить позже?
- Какие решения всегда остаются за ответственным сотрудником?
Разработка начинается с разбора процесса и требований. Затем готовятся предложение и бесплатный прототип ключевого сценария. Прототип помогает сверить логику, но не равен полноценному внедрению; рабочие подключения и приёмка определяются в ТЗ.
Обсудите с Switch On AI свой процесс: разберём форматы заявок и определим, какие данные можно автоматически готовить для проверки диспетчером.
Вопросы по этой задаче
Подтверждает ли ИИ-помощник перевозку?
Нет. Он готовит проверяемый черновик и отмечает пропуски. Цену, наличие транспорта, выбор машины и принятие заказа подтверждает диспетчер.
Что делать, если в заявке не хватает даты или точного адреса?
Оставить поле незаполненным и сформулировать конкретный вопрос. Подставлять текущую дату, похожий адрес или значение из другой заявки нельзя.
Как учитывать исправление в следующем сообщении?
Новое значение связывают с исправляющей репликой, а прежнее сохраняют в истории. Диспетчер должен видеть, какое значение действует сейчас и почему оно изменилось.
Можно ли разбирать заявки из разных форматов?
Форматы нужно перечислить и проверить на обезличенных примерах проекта. Статья не предполагает универсальную поддержку любых сообщений, файлов и вложений.