Представим: у вас есть салон красоты, и вы приходите к подрядчику по AI-видимости с задачей: «Хотим, чтобы по запросу "найди аппаратный маникюр рядом с домом до 4000 рублей" Алиса предлагала записаться в наш ближайший филиал».
Такой сценарий уже доступен российским пользователям: 23 июня 2026 года Яндекс запустил в Алисе AI-агента «Бронирование». На старте через него можно было записаться примерно в 40 тысяч организаций сферы услуг и забронировать столик более чем в 30 тысячах ресторанов. Поэтому сквозным примером в статье станет запись через Алису, но сам подход к подготовке данных и проверке пути клиента можно применять и к другим AI-агентам бронирования.
Итогом такого сценария должна стать подтвержденная запись на подходящую услугу, в удобном филиале и на свободное время. Это значит, что AI-системе нужно определить ближайшую точку, сопоставить услугу с актуальной ценой и расписанием, а затем создать запись — и расхождения в адресах, названиях услуг или свободных слотах могут прервать этот путь. Но возможен и другой сценарий: сама по себе онлайн-запись исправна, однако AI-система выбирает конкурента из-за неполных или противоречивых данных о компании.
Поэтому проверять нужно весь маршрут: от распознавания компании до появления записи в рабочем интерфейсе сотрудника. В статье разберем, какие данные и системы задействованы на каждом этапе и где чаще всего возникают сбои.
Маршрут агента опирается на шесть блоков данных
Для выбора и записи агенту нужны шесть блоков — понятных и логически связанных друг с другом, в том числе с помощью разметки на сайте.
Блок |
Что проверить |
|---|---|
Компания |
Название, категория, контакты, территория обслуживания, официальный сайт |
Филиал |
Отдельный профиль, точное местоположение, график, контакты и услуги конкретной точки |
Услуга |
Понятное название, описание, цена, длительность, ограничения и филиалы, где она доступна |
Исполнитель |
Специализация, список услуг, филиал и личное расписание, если клиент может выбрать специалиста |
Время |
Часы работы, праздничный график, технические перерывы, свободные слоты и часовой пояс |
Запись |
Выбранные параметры, создание, подтверждение, перенос, отмена и обработка ошибок |
Отдельно стоит учитывать репутацию компании и результаты записи через AI-агента. Рейтинг и отзывы помогают пользователю сравнивать организации. Яндекс объясняет, как рассчитывается рейтинг в Картах, однако его влияние на выбор Алисы публично не раскрыто. Аналитика показывает, сколько рекомендаций завершилось записью, визитом или отменой и какую выручку они принесли; эти данные нужны для оценки результата и поиска сбоев.
За каждым блоком стоит закрепить владельца. Обычно управляющий филиалом отвечает за адрес, контакты и график точки; маркетинг или контент-менеджер — за каталог услуг и публичные цены; операционная команда — за специалистов и расписание; IT — за интеграцию, статусы и ошибки; аналитик — за связь записи с визитом и выручкой.
Все источники должны описывать одно состояние бизнеса
Расхождения появляются, когда системы обновляют независимо друг от друга. Маркетолог изменил цену на сайте, администратор удалил услугу из CRM, агентство оставило старую позицию в карточке.
И клиент, и AI-агент теперь видят несколько версий одного предложения. Например:
-
услуга осталась в карточке после удаления из каталога;
-
цена на сайте отличается от цены в форме записи;
-
специалист указан в нескольких филиалах, хотя принимает в одном;
-
общий график сети подменяет часы конкретной точки;
-
свободный слот отображается, но запись в CRM не создается;
-
форма открывается без выбранного города, филиала или услуги.
Для каждого типа данных нужно назначить основную систему.
Данные |
Основной источник |
|---|---|
Адреса, контакты и график |
Система управления филиалами или Яндекс Бизнес |
Услуги и цены |
Каталог услуг, CRM или утвержденный прайс-лист |
Специалисты и слоты |
Система онлайн-записи |
Описания и ограничения |
CMS или утвержденная база контента |
Результат и статус записи |
CRM или журнал бронирований |
Остальные площадки получают сведения из основной системы либо обновляются по регламенту.
Порядок поиска конфликтующих версий фактов и распределения ответственности подробнее мы описали в статье «Контентная гигиена: как проверить факты о компании в AI-ответах».
Формат цены зависит от канала передачи. В обычном прайс-листе Яндекс Бизнеса требуется точная цена: позиция без цены или с нулевым значением не публикуется. API онлайн-записи допускает диапазон. Яндекс Бизнес поддерживает ручное заполнение, XLS/XLSX и YML; сведения также могут поступать от партнера.
Для сетей особенно важна связь записи с конкретной точкой. При прямой API-интеграции Яндекс рекомендует передавать permalink филиала — идентификатор его карточки в Картах. Ошибка в этом поле приводит к неверному сопоставлению, и записи могут отображаться у другой организации. Автоматический матчинг фида занимает от двух до семи дней, поэтому загрузку нужно завершать проверкой результата.
Сайт тоже помогает системам распознавать компанию и филиалы. Для страниц точек можно использовать Schema.org: LocalBusiness для адреса и графика, Service для услуг. Яндекс не публиковал данных о роли этой разметки в выборе агента «Бронирование», поэтому мы рассматриваем это как часть общей технической доступности сайта и подробнее описываем их в статье «Разметка Schema.org для AI-поиска: что внедрить на сайт».
Для крупных изменений пригодится журнал правок. В нем достаточно фиксировать:
-
что изменили;
-
в какой системе;
-
кто отвечает за обновление;
-
когда сведения должны появиться на внешних площадках;
-
кто проверил результат.
После изменения одной тестовой услуги полезно замерить, через сколько новая цена или длительность появится в карточке и форме записи. Так команда узнает реальную задержку своей цепочки обновлений.
Канал записи задает требования к маршруту
Яндекс Бизнес позволяет подключить онлайн-запись через партнера или API; Алиса также может заполнить форму на сайте заведения и отправить заявку, — и эти маршруты требуют разных проверок.
Подключение онлайн-записи в Яндекс Бизнесе само по себе не подтверждает доступность организации в Алисе: агент работает в бета-режиме и охватывает часть заведений, поэтому возможность выбора и бронирования нужно проверять отдельно на реальных запросах.
Партнерский сервис
Яндекс Бизнес поддерживает подключение через партнеров, включая YCLIENTS, DIKIDI, Altegio, Битрикс и другие системы. Компания подключается к сервису, включает онлайн-запись в его кабинете и проходит модерацию. После этого в профиле появляется кнопка действия.
Бизнесу нужно выяснить, какие данные партнер передает в Яндекс: филиалы, услуги, сотрудников, цены, длительность и свободные окна. Присутствие сервиса в списке партнеров не подтверждает корректность настроек конкретной компании.
Прямой API
Прямое подключение подходит организациям с фактическим адресом: крупным сетям с собственной CRM и разработчикам CRM-систем, к которым уже подключено более 300 компаний. Потребуются актуальные профили организаций, фид, постоянная тестовая среда, API бронирований и синхронизация статусов.
При создании записи система должна вернуть bookingId и статус confirmed либо pending, если это предусмотрено договором. Перенос изменяет существующую запись, отмена передается со статусом cancelled. Вебхуки сообщают Яндексу об изменениях, включая итоговый статус посещения. Полные требования Яндекс собрал в инструкции по подключению API.
Форма на сайте
Если услуга доступна только на сайте заведения, Алиса может заполнить форму и отправить заявку. Для такого маршрута нужны понятные подписи полей и кнопок, доступные сообщения об ошибках и однозначный статус после отправки.
Рекомендации web.dev поясняют, что браузерные агенты могут анализировать скриншот, HTML и дерево доступности. Поэтому связанные с полями подписи, корректные роли элементов, семантический HTML и стабильное расположение интерфейса снижают риск сбоя.
Требования к страницам для краулеров и пользовательских агентов подробнее мы разбирали в статье «Как открыть сайт для AI: что делают маркетолог, SEO и разработчик».
После отправки клиент должен понимать, создана подтвержденная запись или заявка передана администратору. Формулировка «Вы записаны» допустима только после подтверждения со стороны системы бронирования.
Проверки нужно повторять в сопоставимых условиях
Одной контрольной записи недостаточно. Соберите тестовый набор из реальных пользовательских задач, например:
-
записаться сегодня после 19:00;
-
найти услугу дешевле заданной суммы;
-
выбрать ближайший филиал;
-
найти точку с парковкой или другой важной особенностью;
-
записаться к конкретному специалисту;
-
подобрать два места подряд, если бизнес обслуживает двух клиентов одновременно;
-
выбрать другое время, если исходный слот занят;
-
перенести или отменить запись.
По сути, такой набор сценариев — своеобразный промпт-сет: он фиксирует реальные пользовательские потребности и позволяет повторять проверки в сопоставимых условиях. Только здесь запросы описывают действия в рамках выбранной категории бизнеса, конкретной компании или ее филиала: найти подходящий вариант, записаться, перенести или отменить запись. Составить такой промпт-сет поможет наша подробная инструкция. А если вы хотите передать эту задачу специалистам, можно обратиться к нам за продвижением бизнеса в нейросетях.
Для каждого сценария используйте единую карточку теста. В ней фиксируйте:
-
дату, устройство, аккаунт или тип сессии, местоположение;
-
запрос и ожидаемый результат;
-
появилась ли компания среди вариантов и какой филиал выбран;
-
правильно ли распознаны услуга, ограничения, цена и длительность;
-
показаны ли подходящие специалисты и актуальные слоты;
-
появилась ли запись в основной системе, какой ID и статус она получила;
-
получил ли клиент подтверждение, доступны ли перенос и отмена;
-
где прервался маршрут и потребовался ли администратор.
Отдельно проверьте ситуацию, когда слот заняли во время диалога. Система должна сообщить, что время уже недоступно, и предложить другие варианты. В API Яндекса отсутствие слотов передается пустым списком {"availableTimeSlots": []}; пустое тело ответа или null считаются ошибкой.
Повторяйте сценарии в сопоставимых условиях. Для независимой проверки выбора используйте чистую сессию, а при сравнении результатов сохраняйте одинаковыми местоположение, формулировку запроса и другие контролируемые параметры. Один ответ Алисы не показывает устойчивость результата и не позволяет определить причину выбора.
Подробнее о повторных замерах мы писали в статье «GEO-гипотезы: как проверить влияние правок на AI-видимость».
Метрики должны показывать этап потери клиента
Результаты тестов и реальные операции полезно оценивать по четырем группам показателей.
Техническая доступность
-
доля проверок, в которых компания появилась среди вариантов;
-
доля попыток, в которых агент получил актуальные данные и начал маршрут записи;
-
переходы в профиль или на сайт, если для них доступна отдельная атрибуция.
Статистика Яндекс Бизнеса дает общий контекст по просмотрам и действиям с профилем. Без отдельной метки ее нельзя считать статистикой агента Алисы.
Качество выбора
-
доля правильно выбранных филиалов;
-
доля запросов с корректно распознанной услугой и ограничениями;
-
доля результатов, где совпали цена, длительность и время.
Прохождение маршрута
-
начатые и завершенные бронирования;
-
конверсия из начала операции в подтвержденную запись;
-
доля технических ошибок и их распределение по этапам;
-
записи с неверным филиалом, услугой, специалистом или временем;
-
доля обращений, потребовавших участия администратора;
-
время восстановления после сбоя.
Переносы и отмены стоит учитывать отдельно: они могут отражать обычное решение клиента. То есть занятый слот — это ошибка, если система продолжила показывать его как доступный или не предложила замену.
Бизнес-результат
Что можно считать результатом:
-
состоявшиеся визиты и неявки;
-
выручка и средний чек;
-
повторные записи;
-
доля подтвержденных записей, завершившихся визитом.
Основной источник этих данных — CRM и система бронирования. Если отдельная атрибуция Алисы недоступна, это ограничение нужно указать в отчете и оценивать технический маршрут отдельно от общей статистики профиля.
Регулярный контроль помогает системе продолжать работать
Стартовый регламент может выглядеть так:
-
после изменения цены, услуги, графика или состава филиалов проверить затронутые площадки;
-
раз в месяц выполнить контрольную запись от запроса до подтверждения;
-
после обновления CRM, виджета или API повторить сквозной тест;
-
разбирать каждую серию ошибок с владельцем соответствующего блока данных;
-
хранить историю изменений и результаты проверок.
Тестовую запись стоит пометить в рабочей системе и после проверки отменить, если это допускает сценарий. Так она не займет реальный слот и не исказит статистику визитов.
Локальный бизнес готов к AI-записи, когда агент может определить организацию и филиал, понять услугу и условия, получить актуальные слоты, создать бронирование и вернуть понятный статус. Такая подготовка не обещает компании место в каждой подборке, но сокращает число сбоев на этапах, которыми бизнес может управлять.
Читайте также:
AI-агенты входят в клиентский путь: как подготовить данные, сайт и процессы
Контентная гигиена для AI-ответов: как навести порядок в фактах о компании