industry · product
ИИ записал клиента. Запись действительно подтверждена?
Определите, что считать успешной записью, прежде чем тестировать администратора, и разделяйте запросы, подтверждения и явку.

Запрос на запись и подтвержденная запись являются разными результатами. Запрос засчитывается, когда сохранена новая запись. Цель «Подтвержденная запись» засчитывается, когда эта новая запись, привязанная к участнику, сохранена со статусом «Подтверждена» или явно отмечена как завершенная в течение периода измерения. Само по себе подтверждение не доказывает, что участник пришел; явная отметка о завершении отдельно подтверждает факт завершения. Автоматический переход в статус pending_completion никогда не засчитывается как подтверждение.
Эту разницу легко упустить, когда команда говорит: «ИИ записал двенадцать человек». Были ли зарегистрированы двенадцать запросов? Были ли приняты двенадцать предложенных дат и времени? Пришли ли двенадцать человек? Для каждого утверждения нужны разные доказательства.
Когда эксперименты включены в вашем платном рабочем пространстве Receptionist, выберите событие записи, которое соответствует вашему решению. Доступ зависит от вашего рабочего пространства и разрешений команды. Примеры гипотетические и не описывают результаты клиентов.
Какой результат записи соответствует решению бизнеса?
Прежде чем менять настройки администратора, выберите этап, который хотите улучшить. Если сотрудникам нужно проверять каждый запрос, полезной целью может быть число запросов. Если ассистент может согласовать время приёма, подтверждённая запись точнее отражает желаемый результат. Если проблема связана с явкой, ни одна из этих целей сама по себе на неё не отвечает.
| Доказательство | Что оно подтверждает | Чего оно не доказывает |
|---|---|---|
| Сохранённая новая запись на приём | Существует запрос на запись | Подтверждение или явку |
| Сохранена со статусом «Подтверждена» или явно отмечена как завершенная | Подтвержденная запись; если есть, завершение фиксируется отдельно | Посещение, определенное только по подтверждению, или оплата |
| Автоматическое изменение статуса после времени приёма | Время прошло | Подтверждение клиентом |
| Последующая отмена или неявка | Отдельное событие на следующем этапе | Что подтверждения раньше не было |
Тест может улучшить один этап, не изменив следующий. Большее число запросов может увеличить нагрузку на сотрудников, если в запросах не хватает данных. Подтверждённых записей может стать больше, но клиенты всё равно могут не прийти. Выберите основную цель, которая соответствует вашему решению, а остальные этапы рассматривайте как дополнительный контекст.
Рекомендации Microsoft по экспериментам советуют измерять широкий спектр результатов, чтобы улучшение одной метрики не скрывало ухудшение других. Поэтому вместе с выбранной целью нужно отслеживать результаты на последующих этапах. Это не повод менять цель после получения результатов. Microsoft Research
Почему данные записи важнее формулировок в чате?
Сообщение «вы записаны» не является записью на приём. Сохранение могло завершиться с ошибкой, запись может всё ещё требовать одобрения, а сообщение может относиться к уже существующей записи. В эксперименте нужно считать событие, которое можно проверить.
Receptionist использует сохранённые деловые события, а не оценку ИИ о том, что чат «выглядит успешным». Запись должна быть новой, связанной с назначенным участником и созданной в пределах допустимого окна. Повторные обновления не превращают одну запись в несколько успешных результатов для того же участника и той же цели.
Важен и источник события. Старая запись, импортированная в систему, не является новой конверсией. Запись по телефонному звонку, через рекламную страницу бронирования или в стороннем календаре нельзя засчитывать в тест переписки лишь потому, что тот же клиент есть в рабочем пространстве.
Это более узкий показатель, чем ценность для всего бизнеса. Он измеряет результат, который можно приписать тесту по заданным для него правилам. Для более широкого финансового анализа нужна оценка окупаемости инвестиций в ИИ; эксперимент даёт одну определённую часть доказательств.
Что означает pending_completion для теста?
В текущем жизненном цикле записи на приём и ожидающие подтверждения, и подтверждённые записи могут перейти в pending_completion после запланированного окончания приёма. Этот таймер не позволяет определить, какие записи были подтверждены до этого.
Для цели «Подтвержденная запись» нужно, чтобы новая запись, привязанная к участнику, была сохранена со статусом «Подтверждена» или явно отмечена как завершенная в течение периода измерения. Ожидающая запись, которая автоматически получает статус pending_completion, не засчитывается. Каждый участник может быть учтен для этой цели один раз. Фраза помощника о подтверждении сама по себе не меняет сохранённый статус записи.
Это уточнение меняет способ измерения успеха. Оно не превращает ожидающую подтверждения запись в подтверждённую, не переписывает старые записи и не утверждает, что клиент пришёл.
Сколько ждать результата?
Выберите окно, достаточное для работы вашего процесса. Доступны окна продолжительностью 24, 72, 168 и 336 часов. Это доступные окна измерения, а не рекомендуемая длительность теста и не гарантия достаточности доказательств.
Период включения участников и окно результата решают разные задачи. Период включения определяет, как долго в тест будут добавляться новые участники. Окно результата определяет, сколько времени у назначенного участника есть для достижения цели. Даже если период включения завершится сегодня, у участника, добавленного ближе к его концу, может ещё оставаться время.
Не записывайте ожидающий результат как неудачу. Отображайте ожидающие результаты, пока не закроются соответствующие окна. Если событие-источник нельзя надёжно отследить, сохраняйте видимой и эту неопределённость. Неизвестный результат и измеренная неудача это разные факты.
Небольшим командам может понадобиться больше времени. Полная календарная неделя не обязательно означает, что трафика хватит для надёжного вывода. Решение также зависит от текущей доли успеха, от того, какую разницу нужно обнаружить, и от полноты отслеживания.
Как клинике оценить завершённый тест?
Начните с названия цели, целевого аккаунта и окна измерения. Затем сравните число участников и успешных результатов, доли достижения цели, неразрешённые записи и расходы. Если ваши разрешения это позволяют, откройте связанные переписки для контекста.
Обратите внимание на практические проблемы, которые могут скрываться за сводной долей: клиентам предлагают неподходящую услугу, сотрудникам приходится исправлять данные или создаются записи для целевой аудитории, которую бизнес не может обслужить. Такие наблюдения могут стать основанием для новой гипотезы. Но они не дают повода выборочно удалять неудобных участников из текущего теста.
Сохраните результат вместе с его настройками. Если команда выбирает вариант B, зафиксируйте причину. Если данных для вывода недостаточно, оставьте вариант A или разработайте новый тест. При последующем восстановлении варианта всё равно нужно проверить актуальную цель и разрешения.
Явку нужно оценивать отдельно. В нашем руководстве о напоминаниях и звонках для подтверждения рассматривается то, что происходит после записи. Не следует приписывать тесту переписки администратора результаты, которые он не измерял.
Что происходит по завершении теста или при отсутствии данных?
В запланированный момент завершения по умолчанию включается обычная маршрутизация. Вместо этого можно заранее явно выбрать сохранённый вариант A, B или C, если он доступен. Для такого запланированного выбора всё равно нужны актуальные проверки доступности теста, целевого объекта и зависимостей. Это не автоматический выбор победителя. Заблокированный выбор требует внимания, и его нельзя считать применённым. Участники, уже включённые в тест, могут продолжать проходить свои окна измерения.
У неизвестных результатов есть важное следствие: даже один неразрешённый неизвестный результат может помешать сформировать статистическую рекомендацию по этому запуску. Описательные результаты и явный выбор пользователя остаются доступными. Если вручную остановить запуск до завершения запланированного периода анализа, это не доказывает, что один из вариантов победил. При переходе на Free доступ к экспериментам и набор новых участников прекращаются, а обработка эксперимента безопасно прерывается. Обычные записи во «Входящих» сохраняются.
Часто задаваемые вопросы
Считается ли запись подтверждённой, если клиент сказал «да»?
Только если в течение периода теста новая запись, привязанная к участнику, сохранена со статусом «Подтверждена» или явно отмечена как завершенная. Формулировка сообщения сама по себе не является сохраненным результатом. Автоматический статус pending_completion никогда не засчитывается.
Может ли один клиент дать несколько успешных результатов?
Основная цель оценивается для каждого участника как достигнутая или недостигнутая. Несколько подходящих событий могут служить доказательствами, но не превращают одного участника в несколько успешных результатов по основной цели.
Подтверждённая запись и состоявшийся приём это одно и то же?
Нет. Само по себе подтверждение не доказывает, что участник пришел или оплатил услугу. Явная отметка о завершении отдельно подтверждает факт завершения. Тест подтвержденных записей сам по себе не позволяет оценить посещаемость или выручку.
Может ли тест учитывать существующие записи?
Цели, связанные с записью, учитывают новые записи, атрибутированные тесту. Существующие записи и события из не связанных с тестом источников исключаются. Это не позволяет считать обычные обновления новым бизнес-результатом.
Обсудите статусы записей, которыми действительно пользуется ваша команда, на встрече по Receptionist. Закажите демонстрацию, чтобы договориться, что считать успешной записью, прежде чем сравнивать версии.
Источники и определения измерений проверены 10 октября 2026 года. Рост показателей или улучшение явки не заявляются.