Короткий вывод

В январе 2026 года поставщик Replify описал внедрение виртуального администратора HeyLibby в сети Seattle Sun Tan и Desert Sun. На странице кейса указано, что около 74% типовых деловых обращений — вопросы о графике работы и процедурах — система закрывала без передачи сотруднику. В более точной формулировке той же страницы приводится 74,4%; для вопросов о часах работы указано 85,5%, о процедурах — 61,9%.

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

Что именно описано

Seattle Sun Tan и Desert Sun — две региональные сети салонов в штате Вашингтон. В публикации Replify указано, что группа обслуживает более 60 точек. Повторяющиеся вопросы, обращения после закрытия и звонки, которые отвлекали сотрудников в зале, названы исходной проблемой.

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

Важна и формулировка знаменателя: 74,4% относится к «деловым обращениям», определённым в кейсе как вопросы о часах работы и процедурах. Это не доля всех звонков, не процент продаж и не показатель разрешения сложных жалоб. На той же странице встречается округлённое 74%, а также отдельные 85,5% и 61,9% для двух категорий. В публикации лучше сохранять это различие, а не складывать метрики в более громкое обещание.

Почему этот сценарий может подойти небольшой компании

У салона, мастерской, студии, пункта выдачи или локальной сети часто есть небольшой набор вопросов, которые повторяются каждый день:

  • когда открыта конкретная точка и как меняется график в праздники;
  • какие услуги или товары доступны и сколько они стоят;
  • как записаться, перенести запись или узнать статус заказа;
  • куда обратиться с вопросом, который требует сотрудника.

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

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

Как повторить подход без копирования процента

1. Сначала посчитайте поток и разметьте обращения

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

Разделите обращения хотя бы на четыре группы:

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

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

2. Подготовьте источник истины

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

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

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

3. Ограничьте действия агента

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

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

4. Проверьте качество на реальных примерах до запуска

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

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

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

Метрика «ответил без человека» не равна «решил вопрос». Хорошая система иногда переводит звонок — это может быть правильным исходом, а не провалом автоматизации.

Модельная экономика пилота

Ниже — только пример расчёта, не цифры из кейса Replify. Допустим, за месяц приходит 1 000 обращений по справочным вопросам; система действительно закрывает 35% из них; сотрудник тратил на такое обращение в среднем 3 минуты; полная стоимость часа его рабочего времени для компании принята равной 600 ₽.

В этом сценарии высвобождается примерно 17,5 часа в месяц: 1 000 × 35% × 3 минуты ÷ 60. Их модельная стоимость — 10 500 ₽. Если лицензия, телефония, интеграция, контроль качества и поддержка вместе стоят дороже этой суммы, прямой эффект на рабочем времени не покрывает затраты. Тогда нужно отдельно и измеримо оценить дополнительную пользу: меньше потерянных заявок после закрытия, быстрее запись или меньше повторных звонков. Нельзя подменять эти показатели обещанной выручкой без атрибуции.

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

Практический план на месяц

  • Неделя 1: собрать статистику обращений и выбрать один-два простых сценария.
  • Неделя 2: привести справочник к единому виду, определить владельца и правила обновления.
  • Неделя 3: испытать систему на тестовых примерах и в режиме подсказок сотруднику.
  • Неделя 4: включить ограниченную долю трафика или одну точку, оставить быстрый перевод человеку и ежедневно проверять ошибки.

До начала зафиксируйте базовые значения: число обращений, пропущенные звонки, среднее время ответа, повторные контакты и затраты. После запуска сравнивайте те же определения на сопоставимом периоде. Иначе проценты будут эффектными, но не объяснят, стало ли клиенту и бизнесу лучше.

Ограничения и вывод

Опубликованные 74,4% относятся к узкой группе вопросов и исходят от поставщика решения; независимой проверки результатов в доступных материалах нет. Компания-клиент названа, но подробности модели, цены, архитектуры и методики измерения не опубликованы. Это полезный ориентир для постановки вопросов, не доказательство будущей экономии вашей компании.

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

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