Есть ли товар: что ИИ-продавец проверяет до обещания по телефону

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

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

«Есть на складе» может оказаться неправильным ответом

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

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

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

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

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

Физический остаток, доступное количество и обещание клиенту

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

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

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

Сначала найти именно тот товар

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

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

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

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

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

Паспорт ответа: источник, время и область действия

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

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

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

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

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

Что делать, если товара меньше, чем нужно

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

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

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

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

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

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

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

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

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

Условный эпизод: остаток изменился прямо во время звонка

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

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

Как работает связка голосового продавца и CRM

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

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

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

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

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

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

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

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

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

Как определить допустимую давность данных

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

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

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

Какие показатели помогут улучшить продажу

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

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

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