Обсудить проект
← Все статьи

Панель управления AI-агентом: что должно быть внутри и почему ее проектируют под каждого клиента

Панель управления AI-агентом: слева список диалогов, справа открытая переписка агента с гостем и кнопка перехвата разговора оператором

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

1. Проблематика: у каждой организации свой масштаб, процессы, нюансы

Клиника с одним филиалом и 30 записями в день это одна история. Сеть из 30 городов с 1000 звонков в день совсем другая. Аквапарк получает до 4000 обращений в месяц без участия операторов, региональный провайдер связи держит первую линию с 300 входящими звонками в день. Каждая ситуация требует своего набора метрик, своих ролей, своих сценариев работы.

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

Разные роли и разные интерфейсы. Директору нужна сводка на одном экране. Оператору регистратуры нужен список инцидентов, требующих вмешательства. Контент-менеджеру нужен интерфейс для быстрой правки базы знаний.

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

2. Что такое панель управления агентом

Панель управления AI-агентом это инструмент для управления его работой и наблюдения за его работой. Через панель клиент видит что делает бот в реальном времени, редактирует его поведение (сценарии, база знаний, роли доступа), отслеживает ключевые метрики и инциденты.

Панель доступна через веб-интерфейс. Каждый сотрудник клиента заходит под своей учетной записью, видит свой набор экранов и функций в зависимости от роли.

3. Роли и задачи пользователей

С панелью работают разные категории сотрудников клиента, у каждой свой набор задач:

  • Руководитель. Смотрит сводку KPI и тренды: сколько диалогов обработал агент за период, какая доля закрыта без оператора, какие темы в топе обращений, где точки роста. Заходит раз в неделю или раз в месяц.
  • Администратор регистратуры или колл-центра. Работает с инцидентами: где агент не смог справиться, где нужно вмешательство, где стоит перенастроить сценарий. Работает ежедневно.
  • Контент-менеджер. Ведет базу знаний, обрабатывает точки роста (вопросы, на которые агент не смог ответить), добавляет новые ответы, редактирует существующие. Работает 1-2 раза в неделю.
  • IT-специалист клиента (если есть). Следит за интеграциями, логами, техническими инцидентами. Работает по мере необходимости.

Каждой роли нужен свой интерфейс. Если руководитель откроет панель и увидит там 200 строк технических логов, он ее закроет и больше не откроет. Если контент-менеджер увидит только сводку KPI без возможности править ответы, он не сможет делать свою работу.

4. Что должно быть в любой панели: базовый функционал

Независимо от отрасли и специфики клиента, есть набор функций, без которых панель бесполезна:

  • Мониторинг диалогов в реальном времени. Клиент видит, что бот отвечает клиентам прямо сейчас, и может вмешаться в любой момент.
  • Ключевые метрики. Количество обработанных обращений, доля закрытых автоматически, средняя длительность диалога, процент подтверждений или отказов (в зависимости от задачи).
  • Статистика работы агента за период. Отчеты за день, неделю, месяц. Динамика: качество работы растет или проседает.
  • База знаний. Просмотр и правка. Клиент может самостоятельно добавить новое правило, обновить цену, изменить график, не обращаясь к разработчику.
  • Работа с точками роста. Список вопросов, на которые бот не смог ответить. По каждому возможность добавить ответ прямо из панели.
  • Управление сценариями. Редактирование логики диалогов, промтов, приветствий.
  • Роли доступа. Разделение прав между сотрудниками клиента.
  • Мониторинг работы сервера. Технические метрики (доступность, время отклика, ошибки), чтобы не допустить простоя или сбоев.

Это базовый набор. Дальше начинается индивидуальная часть.

5. Индивидуальные модули под отрасль

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

Эксперт: сеть диагностических центров, голосовой агент

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

Раздел «Фразы» в панели управления голосовым агентом: форма добавления фразы для синтеза речи и библиотека готовых групп - адреса, время, даты

Аквалоо: аквапарк, чат-бот

Агент работает полностью самостоятельно, без оператора на подхвате, обрабатывает до 4000 обращений в месяц. Значит критично следить за актуальностью базы знаний и появлением новых вопросов, на которые бот не смог ответить. Ситуация в регионе постоянно меняется: погода, сезонные акции, региональные события. У посетителей все время возникают новые вопросы, и панель показывает эти изменения в топ-темах обращений. Контент-менеджер получает список новых запросов и добавляет ответы в базу знаний.

Подробнее в кейсе Аквалоо.

СКТВ: провайдер связи, голосовой агент

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

График тематик обращений к голосовому агенту по дням: отдельные линии для аварий, баланса, техподдержки и других интентов

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

6. Как мы проектируем панель под клиента

Наш процесс проектирования из четырех шагов.

Шаг 1. Интервью с ключевыми ролями клиента. По 20-30 минут с каждой ролью: руководитель, администратор регистратуры или колл-центра, контент-менеджер, IT-специалист (если есть). Что сейчас мешает в работе, что хотелось бы видеть, какие решения принимаются на основе каких данных. Часто на этом этапе выясняется, что часть задач можно закрыть не панелью, а изменением сценария бота, и мы экономим силы всем.

Шаг 2. Определение главных метрик с руководителем. Отдельная встреча с директором или собственником: 3-5 главных цифр, которые он хочет видеть при открытии панели. Это самое сложное: руководитель обычно хочет видеть все сразу, а наша задача выделить то, что действительно приводит к решениям.

Шаг 3. Прототип интерфейса и согласование. Мокапы вкладок, экранов, ключевых элементов. Показываем каждой роли клиента, проверяем, что каждый находит свое в интерфейсе. Обычно проходим 2 итерации согласования.

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

7. Безопасность и разделение прав

RBAC (разделение доступа по ролям): каждый сотрудник видит только те данные и функции, которые нужны для его работы. Оператор регистратуры не видит финансовые метрики. Контент-менеджер не может изменить настройки серверов. Руководитель не видит персональные данные конкретных клиентов, только агрегаты.

Аудит действий: любое изменение в панели (кто и когда обновил базу знаний, изменил сценарий, экспортировал отчет) фиксируется в отдельном логе. Это критично для внутренних расследований и соответствия внутренним политикам клиента.

Соответствие 152-ФЗ: панель показывает данные клиентов вашей организации в защищенном контуре. Разделение доступа к персональным данным прописывается в договоре поручения обработки.

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

8. Интеграции с системами клиента

Панель управления встраивается в существующую IT-инфраструктуру клиента. Основные точки интеграции:

  • Медицинские информационные системы (для клиник и медсетей)
  • CRM для сервисных бизнесов
  • Телефония (SIP, АТС)
  • 1С для передачи заказов и других данных
  • Экспорт в BI-инструменты клиента
  • Единый вход (SSO), если у клиента есть корпоративная система авторизации

9. Реализация, тестирование, поддержка

Как мы сдаем панель клиенту: сценарии тестирования (что должно работать в базовом сценарии), ролевые прогоны с реальными сотрудниками (администратор проходит свои задачи, контент-менеджер свои), финальная приемка руководителем.

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

10. Что спросить у вендора, предлагающего AI-агента

Если вы выбираете вендора для внедрения AI-агента, чек-лист вопросов, которые стоит задать:

  1. Как я буду наблюдать за работой агента? Есть ли панель управления? У большинства вендоров ее нет, работа агента непрозрачна.
  2. Как править сценарии и базу знаний? Можно ли делать это самостоятельно, или каждое изменение требует обращения к разработчику?
  3. Как разделяется доступ между моими сотрудниками? Есть ли роли, аудит действий?
  4. Как обеспечивается соответствие 152-ФЗ? Где хранятся данные, как передаются, какая модель обезличивания?
  5. С какими системами интегрируется агент? МИС, CRM, 1С, телефония. Есть ли готовые коннекторы или нужна разработка под каждый?
  6. Кто отвечает за инциденты и какое время реакции? Если бот дал сбой в понедельник в 9 утра, что делаем?
  7. Кто платит за LLM-модели и минуты звонков? Включено в цену или отдельные счета?
  8. Как решение масштабируется при росте нагрузки? Что произойдет, если поток обращений вырастет в 2-3 раза?

Ответы на эти вопросы дают понимание, работаете ли вы с зрелым продуктом или получаете «настроим прототип, а дальше сами разберетесь».

Нужен разбор похожей задачи?

Обсудить проект