Неструктурированный запрос: как превратить поток слов в проверяемую задачу

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

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

Сначала сохраните исходный смысл

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

Разделяйте прямые слова клиента и интерпретацию. «Нужно что-нибудь тихое для офиса» — это заявленное требование. «Подойдёт модель А» — уже вывод, который должен опираться на актуальный каталог. «Бюджет высокий» — недопустимая догадка, если сумма не названа. В карточке эти типы информации не должны выглядеть одинаково.

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

Спроектируйте минимальную схему

Начните с результата, который нужен следующему участнику процесса. Для сервисной заявки это может быть объект, симптом, срочность, контакт и удобное окно. Для подбора товара — задача, обязательные свойства, ограничения и допустимые альтернативы. Каждое поле должно отвечать на вопрос: кто и для чего его использует?

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

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

Задавайте один вопрос с понятной причиной

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

Формулировка должна объяснять пользу: «Чтобы проверить совместимость, назовите модель устройства» лучше, чем «Укажите модель». Не спрашивайте данные «на всякий случай». Чувствительные сведения собираются только при понятной цели, разрешённом процессе и ограниченном доступе.

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

Моделируемый сценарий

Покупатель пишет: «Здравствуйте, нужен такой же фильтр, как брал весной, но старый шумит, фото позже, желательно забрать завтра». Система не объявляет товар найденным. Она выделяет цель — замена фильтра; наблюдение — старый шумит; предпочтение — самовывоз на следующий день; неизвестные поля — модель, прошлый заказ и совместимость.

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

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

Проверьте отрицательные пути

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

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

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

Следующее действие для команды

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

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

Разбор перед передачей исполнителю

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

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

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

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