Запись на замер с ИИ: согласовать выезд, а не обещать результат

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

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

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

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

Замер как отдельное обязательство, а не как «звонок с деталями»

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

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

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

Что должно быть в карточке выезда до подтверждения

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

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

Платный выезд, который клиент принял за бесплатный

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

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

Неподготовленный объект и отсутствие контактного лица

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

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

Несколько объектов в одной заявке

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

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

Перенос, который не должен превращаться в новую договорённость с нуля

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

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

Предварительная оценка не равна исполнению

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

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

Интерфейс для сотрудника: что видно перед нажатием «подтвердить»

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

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

Согласование изменения этапа и ответственного

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

Согласования и состояния: как не потерять решение

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

Трудные исключения, которые ломают гладкий сценарий

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

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

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

Проверять стоит не то, как складно ИИ-продавец говорит, а то, что остаётся в системе после разговора. Ниже — пример набора проверок; конкретные значения компания задаёт сама.

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

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

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

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

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

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

Что остаётся, когда разговор закончился

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

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

Один шаг проверки

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

Маршрут замерщика: свободный час ещё не подтверждает выезд

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

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

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

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