ИИ-Напарник работает как персональный агент конкретного сотрудника. У каждого менеджера свой Напарник, и он живёт в том же мессенджере, где менеджер уже общается с коллегами и поставщиками. Напарник знает приоритеты и историю решений своего человека, имеет доступ к корпоративным данным и системам в рамках его прав, координирует функциональных агентов и видит следующий шаг.
С точки зрения сотрудника всё проще, чем звучит. У него появляется один собеседник, к которому можно прийти со словами «почему упала молочка в Сибири» или «подготовь к завтрашней встрече», и в ответ получить готовый разбор с рекомендацией. Под капотом для этого может задействоваться пять разных агентов и три системы, но менеджеру это знать не обязательно.
ИИ-Напарник работает как персональный ИИ-агент сотрудника. Формула простая. Один сотрудник, один Напарник. Категорийный менеджер, прайс-менеджер, руководитель направления, директор имеют каждый своего.
У Напарника есть три свойства, и важны они все вместе. Если убрать любое, на руках остаётся либо чат-бот, либо copilot внутри одного приложения, либо функциональный агент из третьей эпохи.
Персональность
Напарник закреплён за конкретным сотрудником. Он знает его роль, портфель ответственности, KPI, активные переговоры, стиль коммуникации и историю решений. Напарник менеджера A не имеет доступа к данным менеджера B, кроме случаев явной коммуникации между сотрудниками.
Единая точка входа
Один интерфейс ко всей корпоративной среде. Сотрудник не выбирает, к какой системе или агенту обратиться. Он формулирует задачу обычным языком, а Напарник сам определяет, кого подключить и в каком порядке.
Партнёрская позиция
Вместе с ответом Напарник предлагает следующий шаг. У него нет своей повестки внутри компании, поэтому он может прямо сказать «здесь цифры не сходятся» или «в прошлый раз похожее решение просадило маржу».
Здесь же видна разница с ассистентами внутри отдельных приложений. Copilot в BI помогает работать с BI, copilot в почте помогает с почтой. Напарник работает с ситуацией сотрудника целиком, и корпоративные системы для него остаются инструментами, а не средой обитания.
Категорийный менеджер сегодня держит в голове карту систем. Где смотреть продажи, где остатки, где промо, где переговоры, где регламенты, где задачи. Часть из этих систем дублирует друг друга, часть конфликтует, часть периодически ломается. Само переключение между ними съедает часы рабочего времени и регулярно теряет контекст. Зашёл за цифрой, отвлёкся на письмо, к цифре уже не вернулся, потому что письмо породило ещё три задачи.
Напарник убирает эту карту из головы сотрудника. Менеджер пишет в мессенджер «дай продажи по молочке за март по регионам» и получает ответ. За этим ответом могут стоять Text2SQL-агент, обращение к DWH, проверка через агента базы знаний, но всё это происходит на стороне Напарника. Точно так же менеджер спрашивает «что у нас по поставщику X», «есть ли свободный час с Ивановым на четверг», «найди регламент по делистингу». Везде один и тот же канал и обычный язык.
Базовый канал устроен как корпоративный мессенджер с мобильной и десктопной версиями. Веб-интерфейс и дашборды добавляются позже, под конкретные сценарии. Голосовой ассистент на переговорах остаётся отдельной историей, она описана в 04-usecases.
Часть полезной работы Напарник делает сам, без запроса. Это возможно, потому что у него есть расписание сотрудника, понимание его приоритетов и доступ к потокам данных.
Утренний брифинг
Что произошло за ночь, какие алерты сработали, какие письма требуют действия, какие встречи в календаре. При этом фильтр идёт через приоритеты сотрудника. Большое письмо от вендора, который ему сейчас неинтересен, может вообще не попасть в брифинг.
Подготовка к встречам
За день до значимой встречи Напарник готовит досье. Если впереди переговоры с поставщиком, в досье попадают индексы цен, история уступок, статусы SLA, доля SKU в категории. Если встреча с коллегой, в досье попадают повестка, открытые вопросы и хвосты прошлого разговора.
Алерты по аномалиям
Резкое отклонение по категории, сорванная поставка, просадка по конкретным SKU. Напарник не пересылает менеджеру голый алерт, а сначала сам прогоняет разбор и приходит с диагностикой и вариантами действий.
Контроль договорённостей
На прошлой встрече Иванов обещал расчёт к среде. В среду утром Напарник сам напоминает Иванову, и менеджеру не приходится переключаться в роль контролёра, который ходит по людям и спрашивает, где результат.
Проактивность обязательно настраивается под конкретного сотрудника. Менеджер задаёт пороги чувствительности (например, «не дёргай, если отклонение меньше 5%») и определяет приоритеты по категориям, поставщикам, SKU. Если этого не сделать, Напарник довольно быстро превращается в источник шума, и им перестают пользоваться.
У менеджера на столе обычно лежат не отдельные задачи, а ситуации. Реплика «поставщик просит +5% к закупочной цене» уже описывает ситуацию, и одной задачи здесь не хватит. Чтобы её разобрать, нужны одновременно анализ продаж этого поставщика, индексы цен на сырьё, история переговоров, прецеденты уступок, оценка доли SKU в категории, и хорошо бы посмотреть в календарь.
Напарник распознаёт ситуацию по входящему сигналу. Это может быть письмо, реплика в чате, точка в календаре, аномалия в данных. Дальше он сам собирает под эту ситуацию контекст. Менеджеру не нужно держать в голове, что её закрывают четыре функциональных агента и две интеграции. Он просто получает собранный пакет, например, «вот аргументация, рекомендую начать с SLA, там сильная позиция, готовлю слайды?».
Менеджер открывает мессенджер. Там короткий брифинг от Напарника. Один из пунктов критичный, а именно «пожар на РЦ в Казани, под угрозой поставки 12 SKU». Напарник уже разослал алерт логистам и забронировал антикризисный звонок на 9:30. Менеджеру остаётся подтвердить и при необходимости поправить.
Планёрка через час. «Собери презу по категории за февраль». Напарник за пару минут вытаскивает данные из хранилища, наполняет корпоративный шаблон, помечает аномалию по трём SKU. Менеджер добавляет свой комментарий, что там был ещё демпинг конкурента. Напарник запоминает эту поправку.
Встреча с поставщиком молочной продукции. Поставщик просит +5%. Досье пришло заранее, и сейчас Напарник в реальном времени подсказывает, что индекс цен на сырое молоко -3% за квартал, fill rate 87% при SLA 95%, и в прошлый раз поставщик уступил при угрозе делистинга.
«Собери статусы по промо у маркетологов и логистов». Напарник обращается к Напарникам коллег, те собирают данные у своих сотрудников, валидируют и возвращают ответ. Через двадцать минут у менеджера сводная картина, и для этого никому не пришлось собираться в общий чат на пятнадцать человек.
Менеджер ушёл домой. Напарник заметил отклонение по пяти SKU в категории «Кондитерские изделия», запустил факторный анализ, подготовил разбор. Утром менеджер увидит сразу готовый отчёт с рекомендацией, без отдельного шага в стиле «прочитал алерт, запросил разбор, дождался».
Напарник полезен ровно в той мере, в какой он понимает контекст конкретного сотрудника. Это контекст не из одной сущности, у него несколько слоёв, и у каждого свои правила обновления.
Первый слой Роль и зона ответственности. Категории, ключевые KPI, портфель поставщиков, активные проекты, плановые показатели, рамки полномочий. Этот слой обновляется редко и опирается на корпоративные системы вроде HR, оргструктуры и BI.
Второй слой Приоритеты и оперативная картина. Что сейчас на столе, какие переговоры активны, какие дедлайны горят, какие письма ещё не закрыты. Здесь обновления идут ежедневно. Частично данные приходят от самого сотрудника, частично Напарник вытаскивает их из почты, календаря и трекеров.
Третий слой История решений. Как менеджер вёл себя в похожих ситуациях раньше, какие аргументы у него обычно срабатывают на переговорах, какие промо он запускал и с каким результатом, по каким поставщикам принимал жёсткие решения и чем это закончилось. Этот слой накапливается из переписки с Напарником и из логов его действий. Именно за счёт него «Напарник, которого включили вчера» сильно отличается от «Напарника, который работает с менеджером полгода».
Четвёртый слой Стиль коммуникации. Как сотрудник пишет письма, как формулирует поручения, каких формулировок избегает, какую длину ответов любит. Это нужно, чтобы черновики от Напарника не приходилось переписывать с нуля.
Пятый слой Профили. Сюда же, в личную память Напарника, естественно ложатся профили контрагентов и коллег, с которыми работает менеджер. Профиль конкретного поставщика, проявленный в десятках встреч и переписок, по сути представляет собой частный случай истории решений. Когда уступал, на чём настаивал, какие аргументы у него работают, а какие нет. У Напарника другого менеджера будет свой профиль того же поставщика, потому что он наблюдает его в своих переговорах, в своём контексте.
Часть персонализации живёт не в памяти, а в индивидуальных скиллах Напарника. Это короткие декларативные инструкции о том, как работать именно с этим человеком. Например, «отчёты собирай в формате с разрезом до и после промо», «по поставщикам категории X сразу добавляй долю SKU в категории», «при отклонениях меньше 5% не дёргай». Скиллы отличаются от поправок в памяти тем, что в них живут правила, а не накопленная история решений. Платформенный механизм скиллов разобран в 05-architecture, раздел «Скиллы».
Сам Напарник не делает факторный анализ, не пишет SQL и не ищет по регламентам. Эту работу он делегирует специализированным функциональным агентам. Каталог агентов лежит в 03-agents, раздел «Классификация функциональных агентов», а здесь интересно, как именно Напарник ими управляет.
Типовой цикл выглядит примерно так.
Сотрудник формулирует ситуацию обычным языком, например «почему упала молочка в Сибири».
Напарник распознаёт класс ситуации и собирает план разбора. В простом случае хватит одного агента, в сложном понадобится два-три, работающих параллельно. План остаётся внутренним, сотрудник его не видит, если сам не попросит показать.
Напарник делегирует агентам. Каждому уходит конкретная задача с параметрами, например период, регион, категория, набор гипотез. Агенты работают независимо и параллельно.
Напарник собирает результаты в единый ответ. Это именно синтез, с главным выводом, доказательной базой, отвергнутыми гипотезами и предлагаемым следующим шагом, а не склейка трёх отчётов через слово «также».
Сотрудник получает результат вместе с предложением действия. Если он валидирует вывод или поправляет его, Напарник запоминает поправку и в следующий раз учтёт её в похожей ситуации.
Сложные ситуации обычно требуют нескольких таких циклов. Менеджер уточняет, Напарник дозапрашивает агентов, возвращает уточнённый разбор. Всё это происходит в одном диалоге в одном чате, без переключения интерфейсов.
Ещё одно важное свойство в том, что добавление нового функционального агента не увеличивает когнитивную нагрузку на сотрудника. Появился агент по эластичности цен, и у Напарника просто становится на одну возможность больше, а интерфейс остаётся прежним.
Помимо аналитики Напарник закрывает три повседневные нагрузки сотрудника. Это задачи, коммуникации и решения. У него есть набор шаблонных действий по каждой из них и память о том, как сотрудник обычно ведёт себя в похожих ситуациях.
С задачами Напарник умеет работать в трёх режимах. Он умеет ставить, отслеживать и напоминать. Менеджер диктует голосовое «попроси Иванова прислать расчёт промо до среды», это превращается в письмо или сообщение в трекере, в среду утром Напарник сам пингует Иванова и при отсутствии ответа эскалирует. По встречам Напарник разбирает транскрипты и расшифровки. Выделяет договорённости, ставит задачи на исполнителей, бронирует следующие шаги в календарях.
С коммуникациями Напарник работает в нескольких режимах сразу. Готовит черновики писем и сообщений в стиле сотрудника. Ведёт профили адресатов в личной памяти Напарника, фиксируя там стиль человека, его типичные вопросы и чувствительные темы. На встречах работает живой подсказкой, давая цифры, контраргументы, ссылки на прошлые договорённости. Подсказки идут в боковой канал, отдельный экран или мессенджер на втором устройстве, чтобы не сбивать живой разговор. Внешние сообщения от имени сотрудника Напарник без явного клика никогда не отправляет.
С решениями режима два. Справочный режим помогает показать данные, прецеденты, регламенты. И режим второго мнения, в котором Напарник перед значимым решением играет адвоката дьявола. «В прошлый раз при похожих условиях ты принял аналогичное решение, и через три месяца маржа по категории просела на 2 п.п., вот доказательная база». У Напарника нет повестки внутри компании и нет мотивации соглашаться, чтобы не портить отношения. Такого собеседника менеджеру в реальной жизни обычно и не хватает.
Опыт сотрудника не должен исчезать вместе с его уходом из компании. И опыт сильного сотрудника не должен оставаться внутри одной головы, пока коллеги в соседнем отделе изобретают то же самое заново. Эту задачу решает организационная память. Это слоистое хранилище контекста и опыта, к которому у Напарника есть доступ.
Корпоративная база знаний
Регламенты, стандарты, прецеденты, аналитические отчёты, нормативные документы. Курируется людьми. Источник того, как должно быть, и того, как это уже когда-то делалось.
Личная память Напарника
История диалогов и решений конкретного сотрудника. Поправки, которые он делал. Стиль формулировок. Активные переговоры. Профили контрагентов и коллег, с которыми работает менеджер. Этот слой остаётся с сотрудником, изолирован от других сотрудников и подчиняется политике хранения.
Коллективная память
Паттерны успешных решений, выявленные на масштабе команды. «Когда поставщик грозит уходом, в 7 случаях из 10 сработал аргумент Y». Сюда попадают только обезличенные паттерны. Если речь идёт о коммерчески значимых решениях, наполнение коллективного слоя проходит через куратора.
Преемственность строится за счёт коллективной памяти и базы знаний. Когда сильный менеджер уходит, его личная память не передаётся новому сотруднику автоматически. Это было бы странно и небезопасно. Передаётся то, что уже стало паттерном, а именно проверенные подходы, типовые аргументы, разборы кейсов. Преемник получает их с первого дня и не восстанавливает по обрывкам файлов и устным рассказам.
Профили контрагентов представляют собой отдельный сюжет на стыке слоёв. Базово профиль конкретного поставщика лежит в личной памяти Напарника того менеджера, который с ним работает. Это правильное поведение, потому что разные менеджеры видят поставщика по-разному, и склеивать их наблюдения автоматически было бы ошибкой. По мере зрелости платформы становится разумно наводить мост, чтобы общие факты и устойчивые паттерны поведения поставщика выносились в коллективную память через куратора и становились доступны всем менеджерам сети. Этот мост требует отдельного архитектурного решения. Подробно он описан в 05-architecture, раздел «Память и контекст», там же лежат правила консолидации остальных слоёв.
Напарник не вводится одним релизом. Он растёт по уровням, и каждый следующий уровень опирается на зрелость предыдущего, на работающие интеграции, накопленную обратную связь и выстроенные правила безопасности. Эту лестницу удобно использовать на пресейле, чтобы договориться с заказчиком об ожиданиях от пилота и обозначить, куда внедрение движется дальше.
| Уровень | Что Напарник делает | Что становится возможно |
|---|---|---|
| 1. Операционный помощник | Рутина по почте, календарю, голосу, транскриптам, поиску по корпоративным источникам. | Освобождается до 30–40% рабочего времени сотрудника от механической работы. |
| 2. Аналитический помощник | Доступ к данным и BI, факторный анализ, генерация презентаций, проактивный мониторинг. | Нестандартные срезы данных за минуты вместо спринта дата-инженеров. |
| 3. Коммуникационный помощник | Профили контактов, симулятор коммуникаций, реалтайм-подсказки на встречах, второе мнение перед решением. | P&L-эффект на переговорах и заметный рост качества внутренних коммуникаций. |
| 4. Мультиагентный координатор | Общение Напарников между собой, горизонтальный обмен паттернами, вертикальная агрегация. | Корпоративная среда работает как сеть взаимодействующих агентов. Преемственность экспертизы. |
Базовый слой. Напарник снимает рутину, которая в крупной сети съедает значительную часть дня. Сортирует входящую почту по срочности и теме, эскалирует критичные сигналы поставщиков. Подбирает время для встреч с учётом календарей и предпочтений сотрудника. Расшифровывает голосовые в текст и превращает их в действия (письмо, задачу, поиск). Разбирает транскрипты совещаний на договорённости и дедлайны. Отвечает на вопросы вида «где найти регламент Y» или «по какому шаблону подаётся заявка X».
Видимый эффект на этом уровне обычно появляется раньше всего, поэтому он хорошо подходит на первые недели пилота. Метрики тоже простые. Время на типовую операцию до и после. Количество писем, обработанных без участия сотрудника. Доля встреч с автоматически сформированной повесткой.
Напарник получает доступ к корпоративным данным и BI. Появляются Text2SQL для нестандартных срезов, факторный анализ для разбора отклонений, генерация презентаций по корпоративному шаблону на живых данных. Включается проактивный мониторинг, и Напарник в фоновом режиме следит за ключевыми метриками сотрудника и сам приходит с разбором, когда замечает значимое отклонение.
Главное обещание этого уровня в том, что время от вопроса до обоснованного ответа сокращается на порядок. Запрос, который сегодня требует постановки задачи дата-инженерам и спринта ожидания, выполняется в минутах. Параллельно с этим начинает работать петля обратной связи. Сотрудник помечает разбор как верный или неверный, Напарник запоминает поправку и учитывает её в следующий раз.
Напарник начинает работать с людьми вокруг сотрудника. Ведёт профили контактов в личной памяти, и в этих профилях лежат поставщики, коллеги из смежных подразделений, руководители. В профиле фиксируется стиль аргументации, чувствительные темы, прецеденты успеха и неудач, типичные триггеры уступок. Перед значимой коммуникацией Напарник работает как симулятор и предупреждает, например, «коммерческий директор спросит про каннибализацию, у тебя нет этого раздела». Во время встречи он становится реалтайм-подсказчиком. Перед решением играет адвоката дьявола.
Эффект на этом уровне уже прямой, P&L-метрики начинают двигаться. Лучше подготовленные переговоры дают доли процента бэк-маржи, и на масштабе крупной сети это десятки миллионов рублей в год. Метрики тоже сдвигаются в эту сторону. Доля встреч с подготовленным досье, эффект на маржу категорий, количество итераций при согласовании внутренних документов.
Напарники разных сотрудников начинают разговаривать между собой по управляемой политике межагентского взаимодействия. Менеджер просит свой Напарник собрать статусы по промо у коллег. Напарники коллег идут к своим сотрудникам, собирают данные, валидируют и возвращают ответ. Между подразделениями появляется аудируемый поток запросов, и он сам по себе становится данными о том, как работает организация.
На этом уровне начинает работать горизонтальный обмен паттернами. Удачный подход одного менеджера после валидации куратором становится доступен Напарникам всей команды. Так коллективная память переходит из описания в реальный рабочий механизм. Уровень 4 не включается рывком, он добавляется поверх первых трёх и требует отдельной проработки правил, а именно кто кому может писать и по каким поводам.
Напарник и функциональный агент относятся к разным сущностям, и на словах их легко перепутать. Поэтому имеет смысл зафиксировать разницу явно.
| Критерий | ИИ-Напарник | Функциональный агент |
|---|---|---|
| За кем закреплён | За конкретным сотрудником | За классом задач |
| Сколько в системе | По одному на сотрудника | Один общий, используется всеми Напарниками |
| Как вызывается | Сотрудник пишет в обычный мессенджер | Вызывается Напарником, не сотрудником |
| Что знает | Контекст и историю своего человека | Свою предметную область и инструменты |
| Что возвращает | Результат с рекомендацией следующего шага | Структурированный ответ по своей задаче |
| Доступ к данным | Через права своего сотрудника | По узкой инструментальной политике |
| Видим ли сотруднику | Да, постоянный собеседник | Обычно нет, работает «под капотом» |
В обычный рабочий день сотрудник может вообще ни разу не вызвать функционального агента напрямую. Все обращения идут через Напарника, и так получается удобнее. Это свойство модели, а не запрет, и при необходимости менеджер может работать с конкретным агентом сам. Подробное описание самих агентов лежит в 03-agents, а шаблон карточки агента описан в 03-agents, раздел «Шаблон карточки агента».
Напарник работает как компетентный партнёр, но всё же не самостоятельный игрок. На критичных решениях он сотрудника не подменяет и в обход корпоративных правил не действует.
Граница автономии описывается через Tier-модель.
Tier 1. Чтение и черновики
Сбор данных, анализ, подготовка черновиков писем, презентаций, сообщений. Разрешено по умолчанию. Никаких внешних эффектов.
Tier 2. Действие после санкции
Отправка черновика, изменение в учётной системе, бронирование встречи с внешним участником. Каждое такое действие требует явного подтверждения сотрудника.
Tier 3. Автономные действия по правилам
Стандартные операции по расписанию или триггеру в заранее согласованных границах. Сюда входят утренние брифинги, контроль договорённостей, рутинные напоминания. Включается точечно, после периода доверия и согласования с compliance.
Помимо Tier-модели у Напарника есть несколько ограничений по содержанию работы.
С цифрами Напарник работает как передатчик, а не источник истины. Любая цифра, которую он показывает, ссылается на источник в корпоративном хранилище (таблицу, период, набор фильтров). Сотрудник может в один клик провалиться в источник и проверить.
Решения Напарник за сотрудника не принимает. Он рекомендует, обосновывает, предупреждает, но финальный выбор остаётся за человеком. Особенно в вопросах, где помимо фактуры нужно управленческое суждение.
В обход прав сотрудника Напарник тоже не работает. Если у менеджера нет доступа к данным соседнего подразделения, Напарник этих данных тоже не получит. Подробности лежат в 05-architecture, раздел «Безопасность и права доступа».
Несколько коротких иллюстраций того, как диалог с Напарником выглядит на практике. Это не сценарии бизнес-использования, те разворачиваются полностью в 04-usecases. Здесь интересует именно форма разговора.
Менеджер. «Почему упала молочка в Сибири за март?»
Напарник. «Главная причина в росте закупочных цен Danone на 8% и недопоставках трёх SKU из-за SLA 87% при норме 95%. Совокупный эффект на категорию -9,2%. Доказательная база и отвергнутые гипотезы лежат в карточке ниже. Через три дня встреча с Danone, могу подготовить досье».
Менеджер. «Подготовь. И добавь в разбор демпинг конкурента, мы это видели в марте».
Напарник. «Принял. Учту в следующих похожих разборах».
Менеджер. «Saverio просит +5% к закупочной цене, встреча завтра в 14:00».
Напарник. «Готовлю досье. Аргументы против повышения такие. Индекс цен на сырьё -3% за квартал, недопродажи 17 млн ₽ из-за SLA 95%, на встрече в сентябре поставщик уступил при угрозе делистинга, доля SKU в категории 34%. Рекомендую начать с SLA, это самая сильная позиция. Слайды нужны?»
Менеджер. «Собери у маркетинга и логистики статусы по летнему промо».
Напарник. «Отправил запросы Напарникам Петровой и Иванова. Жду ответы, обычно собирается за 20–40 минут. Пришлю сводку, как только всё валидируют».
Через 35 минут.
Напарник. «Сводка готова. По двум промо из четырёх есть отставание от плана с указанием причин. Отдельно отметил, что у Иванова открытый вопрос по бюджету, ждёт твоего решения».
Менеджер. «Поставь встречу с Петровой на этой неделе на 30 минут, обсудить промо в кондитерке».
Напарник. «Договорился с её Напарником. Свободный слот пришёлся на четверг 11:30. Поставил, повестку добавил. К началу встречи пришлю короткий бриф, в нём будет, что у Петровой по этой категории сейчас и какие открытые вопросы остались с прошлого раза».
В реальном разговоре будет больше уточнений, поправок и переключений, здесь это всё убрано для краткости. Зато хорошо видна форма, ради которой Напарник и затевался. Один канал, обычный язык, ответ вместе с предложением следующего шага.
Метрики удобно разносить по трём уровням, а именно операционные, бизнес-метрики и пользовательские. Нужны все три. Если смотреть только на бизнес-метрики, картина пилота будет неполной. Если показывать только операционные, разговор с коммерческим директором не сложится.
| Уровень | Метрика | Как измеряется |
|---|---|---|
| Операционный | Время на типовой аналитический запрос | Замер до и после на одинаковом наборе вопросов |
| Операционный | Доля встреч с подготовленным досье | Отметка в календаре или подтверждение от менеджера |
| Операционный | Время от аномалии до алерта | Лог появления отклонения и времени уведомления |
| Бизнес | Эффект на маржу категории | Сравнение когорт менеджеров с Напарником и без |
| Бизнес | Дополнительная бэк-маржа в переговорах | Отдельная отметка по подготовленным переговорам |
| Бизнес | Время онбординга нового менеджера | До выхода на целевой KPI категории |
| Пользовательский | NPS менеджеров | Регулярный замер 1–2 раза в месяц |
| Пользовательский | Доля задач, в которых менеджер обращается к Напарнику | Лог обращений / общий объём типовых задач |
| Пользовательский | Качество диагностик | Оценка менеджера по 5-балльной шкале на каждом разборе |
Документ описывает пользовательскую модель Напарника. Техническая реализация разобрана в 05-architecture. Каталог функциональных агентов лежит в 03-agents, раздел «Классификация функциональных агентов». Бизнес-сценарии собраны в 04-usecases.