Инструмент 03
ИИ-администратор для приёма обращений и записи
Администратор отличается от справочного бота тем, что доводит обращение до результата: уточняет недостающее, оформляет заявку и передаёт её человеку. Поэтому проект — это правила записи, расписание и момент передачи сотруднику, а не выбор модели.
Когда ИИ-администратор оправдан, а когда нет
- Обращения приходят круглосуточно, а отвечает человек в рабочие часы
- Вопросы повторяются: услуги, цены, часы работы, свободное время, подготовка к визиту
- Есть письменные правила записи и актуальное расписание, к которому можно обратиться
- Понятно, кто принимает заявку от системы и отвечает за подтверждение
- Обращений мало, и сотрудник успевает отвечать сам — автоматизировать нечего
- Правил записи не существует: каждый случай решается устной договорённостью
- Ответ требует профессионального суждения — диагноз, юридическая позиция, оценка стоимости работ
- Расписание живёт в голове администратора и нигде не ведётся
- Telegram, MAX, VK
- Виджет на сайте
- Голосовые сообщения в мессенджерах
- Голосовой канал через телефонию — отдельным этапом
- CRM: amoCRM, Битрикс24
- Системы записи и расписания
- Каталог услуг и прайс
- Почта как канал уведомлений
Набор определяется после разбора задачи. На пилоте администратор обычно получает один канал и одну область данных — расписание либо каталог услуг, — а не доступ ко всему сразу.
Запрос «ии администратор» по Яндекс Wordstat собирает 693 показа в месяц по России по широкому соответствию и 38 по точному. Разница обычная: спрос живёт в хвостах, и они прямо называют, кто ищет, — администратор для салона красоты, для стоматологии, для приёма звонков. Отдельно в хвостах сидит системный администратор, к нашей теме отношения не имеющий; это тот случай, когда широкую цифру нельзя брать за размер рынка. Но состав оставшихся запросов однозначен: ищут не технологию, а замену человеку на первой линии, где сотрудник дорог, а обращения идут круглосуточно.
Где проходит граница
Администратор ведёт обращение до понятного результата: ответ, заявка или запись. Он не заменяет специалиста и не принимает решений, которые стоят денег или здоровья. Всё, что требует профессионального суждения — диагноз, юридическая позиция, оценка сложности работ по фотографии, — уходит человеку вместе с контекстом переписки.
Отсюда простое правило проекта: сначала пишется список тем, по которым система отвечает сама, и список тем, по которым она обязана передать обращение. Второй список важнее первого, и составляет его заказчик, а не исполнитель.
Что закрывает инструмент
1. Ответы на повторяющиеся вопросы
Часы работы, адрес, состав и стоимость услуг, подготовка к визиту, условия отмены. Это основной объём первой линии, и он же — самая скучная часть работы администратора. Ответы берутся из вашего каталога и правил, а не сочиняются: если сведений нет, система говорит об этом и зовёт человека.
2. Приём заявок
Система собирает то, без чего заявку нельзя обработать: услуга, удобное время, имя, способ связи. Недостающее уточняется в диалоге, а не оставляется пустым полем в карточке. Готовая заявка уходит сотруднику и в CRM.
3. Запись и напоминания
Свободное время сверяется с расписанием, а после подтверждения клиент получает напоминание накануне. Напоминание — самая дешёвая часть проекта и обычно самая окупаемая: неявка стоит компании полного слота.
4. Круглосуточная первая линия
Обращение, пришедшее ночью или в выходной, получает ответ сразу, а не утром понедельника. Для части бизнесов это единственная причина внедрения: клиент, не получивший ответа за час, уходит к тому, кто ответил.
5. Голосовые сообщения вместо переписки
Клиенты диктуют, а не печатают, — особенно с телефона и особенно пожилые. Голосовое сообщение расшифровывается и обрабатывается так же, как текст: тот же разбор, та же заявка, тот же момент передачи человеку. Это дешевле телефонии и не требует ни номера, ни SIP, поэтому в мессенджерах включается сразу.
6. Телефонный канал
Тот же администратор способен отвечать на звонок, а не только в переписке, но это отдельный этап: нужна телефония с доступом по SIP, и требования к задержке и к качеству распознавания там жёстче, чем в переписке. Поэтому голос мы подключаем после того, как текстовый канал показал результат, а не одновременно с ним. Разбор записей разговоров и работа с качеством диалогов — соседняя задача, она описана на странице внедрения речевой аналитики.
Как устроен
Знания отдельно от поведения
Правила общения и границы ответственности задаются один раз. Сведения об услугах, ценах и расписании подключаются как источник и обновляются вместе с вашими системами. Это разделение позволяет менять прайс, не переписывая администратора, и наоборот.
Передача человеку как штатный сценарий
Момент передачи — часть проекта, а не признак поломки. Он срабатывает по теме обращения, по прямой просьбе клиента и по числу неудачных попыток понять вопрос. Сотрудник получает не «клиент недоволен», а всю переписку и то, что система успела выяснить.
Права на действия
Читать расписание и писать в него — разные права, и выдаются они по отдельности. На старте система обычно только читает. Всё, что меняет данные, логируется: кто, что, когда и на основании какого запроса клиента.
Что входит в пилот
Пилот ограничивается одним каналом и одним набором услуг. Этого достаточно, чтобы получить проверяемую цифру: какая доля обращений закрывается без сотрудника и сколько заявок доходит до подтверждения.
В пилот входит разбор реальных обращений за прошлый период, список тем для самостоятельных ответов и список тем для передачи человеку, подключение одного канала, сбор заявок в вашу CRM и отчёт по метрикам за период наблюдения.
Не входит: интеграция со всеми системами сразу, право самостоятельно менять расписание и перенос на все каналы до того, как первый показал результат.
Из чего складывается стоимость
Работы начинаются от 100 000 ₽. В эту сумму входит разбор обращений, описание границ ответственности, подключение одного канала, сбор заявок в вашу систему и наблюдение за метриками на пилоте.
Бюджет увеличивают: голосовой канал, несколько площадок одновременно, право записи в расписание, интеграция с учётной системой и требование разместить модель в вашем контуре. Стоимость эксплуатации зависит от объёма обращений и считается отдельно от внедрения.
Если после разбора выясняется, что обращений мало или они не повторяются, мы говорим об этом до начала работ. Диалоговая система на десять обращений в неделю не окупается ничем.
По каким метрикам принимаем решение
Доля обращений, закрытых без участия сотрудника. Время до первого ответа. Доля записей, дошедших до визита. Число обращений, потерянных вне рабочих часов.
Все четыре считаются до внедрения, иначе сравнивать будет не с чем. Отдельно считается доля обращений, ушедших человеку: её рост — не провал, а сигнал, что границы заданы честно.
Чего мы не обещаем до анализа
Мы не обещаем, что администратор закроет большую часть обращений: доля зависит от того, насколько они повторяются, и видна только на ваших данных. Не обещаем полной замены первой линии — сложные и конфликтные обращения остаются человеку. Не обещаем, что система заменит отсутствующие правила записи: если правил нет, проект начинается с них, а не с модели.
Куда идти дальше
Если задача шире переписки и системе нужно самостоятельно ходить в рабочие системы — это ИИ-агенты. Если обращения приходят преимущественно в мессенджеры — чат-бот с ИИ. Если цель — рост выручки, а не разгрузка администратора, начните с увеличения продаж.
Частые возражения
Что спрашивают до пилота
Чем ИИ-администратор отличается от чат-бота, который у нас уже стоит?
Сценарный бот отвечает по заранее заданному дереву и на шаг в сторону отвечает «не понял». Администратор понимает вопрос в свободной формулировке, сам собирает недостающие данные и доводит обращение до заявки. Разница видна не в диалоге, а в отчёте: у сценарного бота основная метрика — доля дошедших до конца ветки, у администратора — доля обращений, закрытых без сотрудника. Если ваши вопросы действительно укладываются в дерево из десяти веток, менять его на модель незачем.
Что будет, если клиент спросит то, чего администратор не знает?
Он должен сказать, что не знает, и передать обращение человеку — это настраивается как обязательное поведение, а не как пожелание в промпте. Придуманный ответ про цену или срок дороже несостоявшегося: клиент приходит с ожиданием, которое компания не подтверждала. Поэтому в проекте отдельно описывается список тем, по которым отвечает только сотрудник, и способ передачи с сохранением всей переписки.
Он сможет сам записывать клиентов в наше расписание?
Технически да, если расписание доступно по API и правила записи формализованы. Но на первом этапе мы обычно не даём администратору писать в расписание: он собирает заявку и передаёт её сотруднику на подтверждение. Причина в обратимости — ошибочная запись занимает чужое время и обнаруживается, когда клиент уже пришёл. Право на самостоятельную запись выдаётся после того, как на потоке видно, что заявки собираются корректно.
Клиент поймёт, что говорит с программой?
Да, и это заявляется прямо в первом сообщении. Скрывать это невыгодно самой компании: разговор с «сотрудником», который вдруг не понимает простого уточнения, ощущается хуже, чем честно представленный автоматический помощник. Кроме того, в ряде каналов сокрытие прямо запрещено правилами площадки.
Мы работаем с записью клиентов — это же персональные данные?
Да, и относиться к каналу нужно соответственно. Имя, телефон и повод обращения — данные клиента, а переписка хранится там, где живёт канал. До запуска нужно понимать, какие поля вообще собираются, где они оседают, сколько хранятся и кому доступны. Мы разбираем это до внедрения, а не после, и по возможности сокращаем состав до необходимого минимума.
Первый шаг бесплатный
Начинаем с задачи, а не с технологии
Опишите операцию, её объём за месяц, текущую проверку и метрику, которую нужно изменить. Ответим с предварительной оценкой применимости и следующего шага.
Описать задачу