Самовывоз по телефону: что ИИ-продавец выясняет до поездки

Клиент говорит, что оплатил и готов забрать сегодня, но склад закрыт, а часть заказа не собрана. ИИ-продавец должен выяснить готовность, склад, получателя и правила выдачи до поездки.

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

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

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

Счёт оплачен, а самовывоз ещё не разрешён

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

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

Три состояния, которые нельзя склеивать в слове «готово»

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

В справочнике Microsoft по созданию и обработке заказа описан словарь строк, количеств и состояний заказа. Это полезно как дисциплина полей, но не доказывает, что конкретный склад уже собрал конкретные коробки. Внешний справочник задаёт язык, а не факт выдачи.

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

Карточка самовывоза: поля, которые удерживают разговор от фантазии

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

Форма рабочего объекта важна не для красоты отчёта. Она не даёт ИИ-продавцу превратить разговор в устный договор, которого нет в учётной системе. Если поле пустое, сценарий должен вести себя как пустое поле, а не как оптимистичный менеджер.

Склад закрылся, а клиент уже у ворот

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

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

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

Тяжёлый груз меняет не только маршрут, но и вопросы в звонке

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

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

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

Часть заказа не готова: честный ответ вместо героического «приезжайте»

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

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

Платёж не сопоставлен: что можно сказать до сверки

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

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

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

Получатель и водитель: два разных человека

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

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

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

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

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

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

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

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

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

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

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

Закрытый склад, неподтверждённая оплата и другой получатель

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

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

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

Испытания выдачи: готовность заказа, получатель и окно склада

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

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

Практикум: один звонок, который заканчивается задачей, а не обещанием

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

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

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