Несколько товаров в одном чате: как не потерять состав запроса

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

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

В переписке было три позиции, а в заявке осталась одна

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

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

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

Товар и строка разговора — не одно и то же

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

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

В Schema.org OrderItem отдельная строка заказа имеет идентификатор, предмет и количество. Это пример явной структуры, а не готовая логика вашего чата. Для рабочего диалога дополнительно нужны источники изменений и понятные состояния неопределённости.

Условный черновик может содержать строку L1 «блок питания, модель уточняется, два штуки» и строку L2 «лента, тёплый свет, десять метров». Когда выясняется модель блока, изменяется L1. L2 остаётся прежней. Такой порядок кажется очевидным человеку, но для автоматизации его нужно спроектировать и проверить, а не предполагать из разговорчивости модели.

Разберите реплику на действие, которое можно проверить

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

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

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

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

Количество всегда приходит вместе с единицей

Десять метров, десять катушек и десять комплектов — разные запросы. Если в карточке остаётся только число 10, самая важная часть уже потеряна. У единицы должен быть такой же явный статус, как у количества. Её нельзя брать из типового заказа другого покупателя или угадывать по привычной упаковке.

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

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

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

Подбор варианта не должен менять предмет без разрешения

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

Сопоставление полезно показывать в достаточной форме: название, существенный вариант и, если уместно, изображение или ссылка. Не нужно требовать, чтобы человек переписывал артикул вручную. Но он должен понимать, какой предмет попадёт в результат. Если вариант ещё не выбран, это видно и покупателю, и менеджеру.

Shopify описывает строки чернового заказа как варианты каталога либо отдельные пользовательские позиции. Это возможность конкретной платформы. Для проектирования полезна граница: строка с произвольным описанием не становится подтверждённым товаром только из-за появления в черновике.

Отдельного согласования требует замена. «Этот вариант недоступен, есть похожий» — предложение, а не уже выполненное изменение. Альтернатива может отличаться по размеру, назначению, сроку и стоимости. Чат должен сохранять эти различия. Молчаливая подстановка удобна для заполнения таблицы и неудобна для реального получения товара.

Один короткий диалог лучше общего обещания понимать контекст

Посмотрим на вымышленный эпизод. Покупатель: «Два комплекта А и десять метров кабеля». Черновик получает две строки. Ответ: «Комплект А — две штуки, кабель — десять метров. Для кабеля уточним исполнение». Система не делает вид, что вопрос решён полностью, но и не теряет уже известные данные.

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

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

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

Не собирайте все уточнения в один экзамен

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

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

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

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

Цена и наличие имеют свою границу знания

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

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

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

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

Черновик состава — самостоятельный рабочий документ

Минимальная таблица не должна быть шире экрана бухгалтерского монитора. Для диалога достаточно короткой строки и доступных подробностей. Важные поля можно собирать в два уровня: понятный состав для покупателя и служебные основания для команды.

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

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

Подтверждение относится к показанному составу

Перед передачей нужно показать, что именно будет отправлено: строки, определённые условия и оставшиеся вопросы. GOV.UK Design System рекомендует дать пользователю проверить ответы до отправки. Для заказа это полезный принцип, а не готовая коммерческая форма или гарантия юридической силы.

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

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

И сама доставка обращения должна быть проверена. Нажатая кнопка и запись у ответственного — разные события. Если передача не завершилась, человек видит понятное состояние и доступное продолжение. Менеджер получает сохранённую версию состава, чтобы позднее уточнение в чате не изменило прошлую отправку без уведомления.

Приёмка на неудобных фразах

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

Отдельно дайте реплику, в которой один товар назван точно, второй приблизительно, третий указан только как функция. Система должна сохранить все три состояния, не достраивая неизвестное. Затем измените порядок строк и попросите убрать «второй». Если интерфейс не даёт однозначной привязки, требуется уточнение. Номер в истории и номер в текущем списке могут различаться.

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

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

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

Экономия появляется там, где не приходится собирать заказ заново

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

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

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

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