Покупка в подарок: что ИИ-продавец уточняет у заказчика

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

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

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

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

Заказчик и получатель — две разные роли в одном заказе

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

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

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

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

Сюрприз — это ограничение на контакты, а не обещание молчания

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

Практичнее разделить режим сюрприза на несколько признаков: скрывать ли факт заказа, скрывать ли цену, можно ли звонить получателю, что говорить при сервисном контакте и кто снимает режим. Тогда сотрудник видит не эмоцию заказчика, а набор правил. Если правило не заполнено, агент не достраивает его по догадке.

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

Что ИИ-продавец уточняет у заказчика до первого обещания

В согласованном сценарии ИИ-продавец сначала выясняет, для кого покупка: получатель совпадает с заказчиком или это другой человек. Затем — как получатель узнает о доставке: заранее, в момент вручения или не должен узнать до определённой даты. После этого уточняется, что можно говорить при сервисном звонке и что делать, если получатель задаст вопрос о цене.

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

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

Форма рабочего объекта: карточка подарка, а не примечание «сюрприз»

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

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

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

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

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

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

Цена в руках получателя: где заканчивается сюрприз и начинается документ

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

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

Второй условный эпизод: неполный адрес и другой человек на пороге

Другой условный заказ: заказчик указывает адрес «как в прошлый раз», без квартиры и кода домофона. Агент не находит полный адрес в карточке, но заказчик торопится и говорит: «Там разберутся, получатель дома». Агент фиксирует ответ как есть и передаёт задачу сотруднику, потому что «разберутся» не описывает, кого искать и что делать при отсутствии получателя.

В день доставки дверь открывает другой человек — родственник получателя. Курьер передаёт набор, потому что адрес совпал, а правило замены не было заполнено. Получатель later говорит, что ничего не просил и не готов принимать доставку. Формально посылка вручена, фактически сюрприз и согласие на передачу не проверены.

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

Трудные исключения: когда подарок перестаёт быть сюрпризом

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

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

Интерфейс сотрудника: что видно до звонка и после

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

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

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

Полномочия и журнал: кто может изменить правила раскрытия

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

В проектных требованиях стоит разделить роли агента, сотрудника поддержки и руководителя. Агент может читать карточку и создавать задачу, но не менять режим сюрприза. Сотрудник может подтвердить адрес и контакт в пределах своих полномочий. Руководитель — изменить правило, если оно противоречит применимым документам. Журнал показывает, кто и на каком основании это сделал.

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

Проверка сценария на тестовых заказах

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

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

Практикум: один условный заказ и шесть проверок

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

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

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

Соседний вопрос разобран отдельно: Покупатель звонит за другого: кого ИИ-продавец считает клиентом. Здесь основной предмет — покупатель и получатель подарка, скрытие сюрприза и допустимые сервисные контакты; не покупатель-представитель.