Штатум

База знаний

Найдите информацию о сотрудниках, интеграциях и работе платформы.

Сотрудники

Как цифровые сотрудники работают вместе

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

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

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

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

Общая логика

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

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

Но права на эти ресурсы задаются отдельно.

Пример: от лида до поддержки

Клиент оставляет заявку на сайте.

Максимус принимает ее, задает квалификационные вопросы, использует базу знаний и создает лид в CRM.

После сделки клиент обращается в Telegram по вопросу обслуживания.

Адриан видит разрешенный контекст и помогает с типовым вопросом.

Если позже маркетинговой команде нужен кейс, Маркус может использовать утвержденную фактуру, но не обязан получать доступ ко всей переписке клиента.

Так одна компания использует несколько ролей, не смешивая их зоны ответственности.

Общая база знаний

Некоторые знания используются сразу несколькими сотрудниками.

Например: описание услуг, прайс, FAQ, tone of voice и политика работы с клиентами.

При этом есть закрытые разделы: юридические документы, внутренние финансовые данные, чувствительные сведения и материалы конкретного отдела.

Поэтому общая база знаний не равна открытому доступу.

Подробнее: Кто видит знания компании.

Передача контекста

Главная ценность handoff - не просто сообщить человеку или другому процессу "есть задача", а передать подготовленный контекст.

Например:

Максимус -> менеджер

"Клиент интересуется поставкой на 20 точек. Город - Казань. Срок - октябрь. Бюджет не назвал. Просит индивидуальный расчет. Стандартный прайс показан. Нужен менеджер".

Такой handoff полезнее, чем переслать всю переписку без структуры.

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

Нельзя создавать бесконечную цепочку агентов

Много ролей не всегда лучше.

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

Каждая новая передача увеличивает сложность: больше прав, больше состояний, больше точек отказа, сложнее аудит и сложнее понять причину ошибки.

Поэтому совместная работа строится только там, где есть реальная бизнес-граница между задачами.

Пример: продажи и маркетинг

Максимус видит повторяющиеся вопросы лидов.

Маркус может использовать агрегированную информацию как сигнал для контента:

"За месяц 30 клиентов спросили, как проходит внедрение".

Из этого появляется тема статьи или FAQ.

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

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

Пример: поддержка и база знаний

Адриан регулярно передает оператору вопросы, которых нет в FAQ.

Это сигнал, что база знаний неполная.

После анализа команда добавляет новый материал.

Теперь аналогичный вопрос можно закрывать без оператора.

Так взаимодействие сотрудников и данных постепенно улучшает процесс.

Пример: Алиса и внутренние команды

После встречи Алиса готовит протокол и создает задачи.

Маркус может получить утвержденную задачу на маркетинговый материал.

Юриус - задачу проверить документ.

Но Алиса не должна автоматически передавать каждому сотруднику весь протокол, если там есть лишняя или чувствительная информация.

Передача должна учитывать роль и права.

Права важнее удобства

Самая опасная ошибка в мультиагентном сценарии - открыть всем сотрудникам все системы, чтобы "проще работало".

Это упрощает прототип, но ухудшает безопасность и контроль.

Правильнее отдельно определить, какие данные сотрудник может читать, какие действия может выполнять, что может передавать, кому может передавать и что требует подтверждения.

Как контролировать совместную работу

История должна помогать восстановить цепочку:

  1. Что произошло.
  2. Какой сотрудник получил задачу.
  3. Какие данные использовал.
  4. Какое действие выполнил.
  5. Что передал дальше.
  6. Где подключился человек.

Это особенно важно, если одна клиентская ситуация проходит через несколько ролей.

Какие KPI смотреть

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

Цель не в том, чтобы увеличить количество взаимодействий между агентами. Цель - сделать процесс короче и понятнее.

Когда добавлять второго сотрудника

Хороший момент - когда первый сценарий уже стабилен и появляется следующая отдельная функция.

Например, Максимус устойчиво обрабатывает лиды, а команда поддержки по-прежнему перегружена. Тогда запускается Адриан.

Если же первый процесс еще регулярно ломается, добавление второго сотрудника усложнит диагностику.

Типовая архитектура

Упрощенно цифровой штат можно представить так:

Каналы -> цифровые сотрудники -> база знаний и рабочие системы -> human approval -> люди -> история и аналитика.

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

Что читать дальше

Общая концепция: Как устроен цифровой штат Штатум.

Права: Права доступа.

Передача человеку: Как сотрудник передает задачу человеку.

Связанные материалы