Товар с монтажом: что ИИ-продавец должен разделить в заказе

Клиент покупает оборудование с монтажом, а в системе появляется одна строка на общую сумму. Через неделю товар на складе, площадка не обследована, бригада не назначена, и непонятно, что именно обещали к сроку.

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

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

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

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

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

Microsoft в описании заказа и связанных строк предлагает рассматривать заказ как набор позиций с собственными параметрами, а не как монолитную запись (создание и обработка заказа). Это не доказывает, что в конкретной CRM так настроено по умолчанию, но задаёт ориентир: у каждой составляющей сделки должны быть свои атрибуты и свой статус. Для нашей темы это означает, что монтаж получает собственную строку с объёмом работ, а не прячется в примечании к оборудованию.

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

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

Что ИИ-продавец уточняет до того, как назвать цену монтажа

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

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

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

Готовность площадки как отдельное состояние, а не галочка

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

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

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

Скрытые работы и материалы: где заканчивается согласованная цена

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

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

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

Изменились габариты: почему заказ нельзя «подправить по-тихому»

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

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

Услуга субподрядная: кто отвечает перед клиентом

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

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

Приёмка товара и приёмка монтажа в разное время

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

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

Рабочий объект: что должно быть в карточке связанной сделки

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

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

Интерфейс для сотрудника: что видно, а что требует решения

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

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

Где ИИ-продавец останавливается и передаёт задачу

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

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

Трудные исключения, которые ломают простую схему

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

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

Как проверить, что схема работает

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

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

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

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

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

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

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

Что уточнить у поставщика решений до пилота

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

Рекомендации по формулировкам в сценарии

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

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

Итог: один шаг проверки

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

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

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