Повторить прошлый заказ: что ИИ-продавец проверяет заново

Клиент просит повторить прошлый заказ, но в истории два похожих заказа с разными условиями. ИИ-продавец должен взять состав, а цену, доступность, упаковку, адрес и реквизиты проверить заново.

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

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

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

Повтор — это новый заказ, а не возврат к закрытой сделке

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

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

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

Короткий прикладной разбор: клиент просит только часть прошлой поставки

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

Затем сотрудник видит не просто набор товаров, а разницу: что взято из истории, что клиент убрал, что требует нового подтверждения. Если в прошлом заказе была строка с исключением, она не переезжает в новый автоматически. Исключение — это условие, а не свойство артикула.

Что именно копируется из истории: состав, а не обязательства

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

Первый подробный эпизод: снятый артикул и новая фасовка

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

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

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

Второй подробный эпизод: два похожих заказа и изменившаяся площадка

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

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

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

Трудные исключения: снятый артикул, новая упаковка, частичный повтор

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

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

Цена и срок: что подтверждается заново, а что берётся из истории

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

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

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

Резерв и доступность: прошлое количество не равно будущему

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

В карточке повтора полезно показывать три величины: сколько клиент просит, сколько доступно для новых обязательств и сколько уже выделено под этот новый заказ. Если доступность не подтверждена, ИИ-продавец не должен говорить «товар есть». Он может сказать: «Состав понятен, доступность проверяет сотрудник». Это менее эффектно, зато не создаёт обещание, которое потом придётся отменять.

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

Интерфейс сотрудника: очередь подтверждений, а не поток обещаний

Сотруднику нужен экран, на котором видно не «ИИ что-то сделал», а что именно требует решения. Верхний блок — источник и новый заказ. Ниже — состав с подсветкой расхождений. Рядом — коммерческие условия, доступность и исключения. Кнопки должны называть действия прямо: «подтвердить состав», «запросить цену», «проверить доступность», «передать менеджеру», «вернуть клиенту вопрос».

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

Проверки перед отправкой повторного заказа

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

Практикум на другом примере: повтор с изменённой фасовкой и адресом

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

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

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

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

Что считать завершением задачи и где остановиться

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

Остановиться стоит там, где начинается чужое полномочие. ИИ-продавец может собрать запрос, показать различия и передать задачу. Он не должен сам менять сумму, этап, ответственного или коммерческое исключение. Это ограничение не мешает разговору, а делает его предсказуемым: клиент получает ответ, который компания действительно готова исполнить.

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

Соседний вопрос разобран отдельно: Повторно открыть сделку в CRM: исправление или новая продажа. Здесь основной предмет — копирование конкретного состава предыдущего заказа с новыми условиями исполнения; не переоткрытие старой сделки.