Сценарии использования

Последнее обновление: 5 июн. 2026 г., 19:30 ≈ 39 минут чтения

Статус: рабочая версия — можно использовать

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

Из этого раздела вы узнаете

по каким принципам описаны сценарии, чтобы их можно было сравнивать и переиспользовать в презентациях
какие роли участвуют в сценариях и кому достаётся ценность
как устроена карта сценариев и что разобрано детально, а что лежит в backlog
как платформа меняет пять ситуаций, среди них переговоры с поставщиком, разбор падения продаж, эффективность промо, управление OOS и межфункциональная встреча
какие сценарии ждут детализации и от чего это зависит

Коротко

В документе разобраны четыре сценария, на которых проще всего показать ценность платформы. Это подготовка к переговорам с поставщиком, разбор падения продаж по категории, анализ эффективности промо и управление OOS. Пятым идёт межфункциональная встреча. Аналитики в ней нет, зато видно, как Напарники договариваются между собой от имени своих сотрудников.

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

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

Принципы описания сценариев

Чтобы сценарии были сравнимыми и переиспользуемыми в презентациях, мы договорились о нескольких правилах.

Язык бизнеса

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

Сравнение с текущим процессом

Без раздела «как это устроено сейчас» цифры и обещания звучат неубедительно. Поэтому в каждом сценарии сначала идёт типичный день без платформы, со всеми переключениями и потерями времени, и только потом изменённая версия.

Ясная граница между Напарником и человеком

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

Реалистичные эффекты

Лучше осторожная цифра с пояснением «зависит от стартовой зрелости заказчика», чем ровные 30% к марже на каждом слайде. Красивые, но плохо измеримые эффекты выносим отдельно как качественные.

Карта сценариев

Карта нужна, чтобы видеть общую картину и понимать, где какие агенты задействованы. Подробно разобраны первые четыре, пятый (межфункциональная встреча) проработан достаточно, чтобы стоять рядом с ними. Остальные в backlog.

| Сценарий | Главный пользователь | Основные агенты | Статус описания | |---|---|---|---| | Подготовка к переговорам с поставщиком | Категорийный менеджер | Переговоры, финансовый эффект, OOS, базы знаний | детально | | Разбор падения продаж по категории | Категорийный менеджер | Факторный анализ, Text2SQL, OOS, промо | детально | | Анализ эффективности промо | Руководитель промо, категорийный менеджер | Промо, финансовый эффект, конкурентный мониторинг | детально | | Управление OOS и доступностью товара | Категорийный менеджер, логист | OOS, прогнозирование, переговоры | детально | | Межфункциональная встреча через Напарников | Любой сотрудник со встречами | Встреч и follow-up, промо, конкурентный мониторинг, финансовый эффект | детально | | День категорийного менеджера с Напарником | Категорийный менеджер | Все приоритетные | backlog | | Подготовка к ассортиментному комитету | Категорийный менеджер, директор по категориям | Ассортимент, финансовый эффект, конкурентный мониторинг | backlog | | Кризисная ситуация (срыв поставки) | Логист, категорийный менеджер | Алерты, OOS, переговоры, встреч и follow-up | backlog | | Онбординг нового менеджера | Новый сотрудник | Базы знаний, организационная память | backlog | | Подготовка управленческого summary | Руководитель направления, директор | Все, через Напарника | backlog | | Поиск и распространение лучших практик | Команда, куратор | Организационная память | backlog |

Шаблон описания сценария

Чтобы сценарии не разъезжались по форме, у каждого детально разобранного один и тот же набор разделов.

Бизнес-ситуация. Конкретная история, в которой оказался сотрудник. Что произошло, в каком контексте и к какому сроку надо отреагировать. Желательно с реалистичным сюжетом, а не с «менеджеру нужно подготовить отчёт».
Участники. Кто из людей вовлечён и какая у каждого роль. Сюда же попадают внешние участники, например поставщик.
Текущий процесс. Как ситуация разбирается сегодня, без платформы. По возможности с реальными временами и числом переключений между системами.
Боли текущего процесса. Что именно болит. Нужны конкретные потери (потерянное время, упущенные аргументы, неиспользованная фактура, забытые договорённости), а не общая формулировка «процесс несовершенен».
Как процесс выглядит с Напарником. Тот же сюжет в новой модели работы. Шаги диалога, что Напарник делает сам и где останавливается за подтверждением человека.
Какие функциональные агенты участвуют. Какие агенты подключаются и за что отвечает каждый. Подробности реализации лежат в 03-agents.
Какие данные используются. Источники, к которым обращается платформа. Обычно это хранилище, BI, регламенты, почта, календарь, внешние индексы.
Какие решения принимаются. Что меняется в рабочем дне сотрудника по итогам сценария и в какой форме это фиксируется (письмо, задача в трекере, документ на согласование).
Где нужен human-in-the-loop. Точки, в которых Напарник ждёт явного подтверждения. Они разные в зависимости от Tier-модели.
Ожидаемый бизнес-эффект. Качественный и, по возможности, количественный. Лучше диапазон с оговорками, чем красивая средняя.
Метрики успеха. Как мы поймём, что сценарий действительно работает в пилоте.

Сценарий 1. Подготовка к переговорам с поставщиком

Бизнес-ситуация

Поставщик Saverio (молочная продукция) присылает письмо. С первого числа следующего месяца он хочет повысить закупочную цену на 5%, ссылается на рост себестоимости. Встреча в среду, у Алексея, категорийного менеджера направления «Молочные продукты», есть полтора рабочих дня на подготовку. Переговоры обещают быть сложными. Saverio занимает 34% полки в категории, его SKU давно знакомы покупателю, прямая замена быстро не находится. Согласие на +5% означает потерю бэк-маржи примерно на 18 миллионов рублей в год (бэк-маржи, не путать с недопоставками). Отказ означает риск ухудшения SLA, который и без того в зоне неопределённости.

Участники

Переговоры ведёт категорийный менеджер. По данным он опирается на логиста направления (фактические поставки и SLA) и прайс-менеджера (ценовое позиционирование категории). Финальное решение по уровню компромисса подписывает коммерческий директор. На той стороне стола сидит менеджер по работе с сетями со стороны Saverio.

Текущий процесс

Сегодня подготовка к такой встрече занимает у менеджера от полудня до целого дня и часто остаётся неполной.

Менеджер вытаскивает из BI продажи по SKU Saverio за последние 6–12 месяцев, отдельно по регионам и магазинам. Несколько часов на сборку, скриншоты, сведение в Excel.
Запрашивает у логистов данные по fill rate и недопоставкам. Логисты обещают вернуться завтра, потому что у них свой загруз и свой формат отчётов. Часть данных приходит в почте Excel-вложением.
Идёт в почту искать, что было с Saverio в прошлый раз. Когда повышал цену, на чём согласились, какие были аргументы. Часть переписки потеряна или в архиве, восстановить удаётся только последний раунд.
Звонит коллеге, который раньше вёл этого поставщика. Узнаёт про слабое место Saverio, недавнюю жалобу на упаковку из соседней сети. Записывает в блокнот.
Открывает аналитический Telegram-канал с индексами цен на сырое молоко. Видит, что индекс снизился на 3% за квартал. Делает скриншот.
Собирает аргументационный пакет в Word, частью пересказом, частью копипастой. Отдаёт коммерческому директору на ревью. Тот просит добавить разбор по доле SKU в категории, без него непонятен рычаг давления. Ещё полчаса.
К моменту встречи менеджер чувствует, что готов «процентов на семьдесят». Какую-то часть аргументов не успел собрать, какую-то забыл вытащить из системы.

Боли текущего процесса

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

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

Как процесс выглядит с Напарником

С платформой подготовка идёт по другому маршруту. Письмо от Saverio Напарник заметил сразу, классифицировал как переговорное и подсветил как требующее внимания.

Утро понедельника. В мессенджере менеджер видит сообщение от Напарника. «Saverio запросил +5% к закупочной цене. Встреча у тебя в среду в 14:00 (поставил предварительно). Готовлю досье. По сильным сторонам нашей позиции у нас индекс цен на сырое молоко -3% за квартал, недопоставки на 17 млн ₽ из-за SLA 87% при норме 95%, в сентябре поставщик уже уступал при угрозе делистинга. По слабым сторонам у нас доля SKU в категории 34%, прямой замены без потерь нет. Подготовлю полный пакет к 12:00, согласовать со встречей коммерческому директору?».
К полудню понедельника менеджер получает структурированный документ. Внутри разбор продаж по SKU и регионам, анализ маржинальности, разбор SLA с разбивкой по месяцам, индексы цен на сырьё, прецеденты переговоров (2024, 2025), профиль контактного лица со стороны Saverio (что важно, какие аргументы работали, на что эмоционально реагирует) и оценка финансового эффекта решения «согласиться» против «не согласиться» и против промежуточных вариантов.
Реакция менеджера. Просит Напарника добавить разбор по двум SKU, по которым недавно меняли поставщика, чтобы было видно, что замена возможна. Напарник за минуту дописывает раздел.
Тот же день, 14:00. Менеджер делится черновиком с коллегами через Напарника. Напарник прайс-менеджера и Напарник логиста добавляют свои комментарии. У людей на той стороне это занимает минуты, потому что фактура уже подготовлена.
Среда, 13:50. Перед встречей Напарник присылает сжатую карточку на одну страницу. На ней главные аргументы и финансовый расклад, а отдельной строкой записана точка отступления, до которой менеджер готов уступить.
Среда, 14:00. Встреча идёт онлайн. Поставщик ссылается на рост стоимости упаковки. Напарник в реальном времени подсказывает в боковой канал, что индекс цен на гофрокартон -2% за квартал, а упаковка в структуре себестоимости поставщика около 8%. Менеджер встраивает это в разговор без видимой паузы. Поставщик уходит на аргумент про логистику, Напарник подсказывает SLA по последним трём месяцам и фактический fill rate 87%. Разговор заканчивается компромиссом. Повышение идёт на 1.5% при условии возвращения SLA к 95%, условие фиксируется в дополнительном соглашении.
Среда, 15:30. После встречи Напарник сам делает следующий шаг. Записывает договорённость в личную память, обновляет профиль контактного лица Saverio, ставит задачу логисту начать мониторинг fill rate под новое условие, готовит черновик письма-подтверждения от менеджера. Менеджер читает, нажимает «отправить». Договорённость уходит в коллективную память как кандидат для будущих переговоров. Это успешный паттерн «повышение в обмен на восстановление SLA» с пометкой «нужна валидация куратора перед публикацией».

Какие функциональные агенты участвуют

Главную работу делает агент переговоров. Он собирает досье, профилирует контактное лицо поставщика и формирует аргументационный пакет. Параллельно агент финансового эффекта моделирует варианты решения (что будет с маржой при каждом сценарии), агент OOS приносит фактуру по SLA и недопоставкам, а агент базы знаний достаёт прецеденты прошлых переговоров. На обвязке встречи (календарь, слот, постановка задач после) работает агент встреч и follow-up. Подробное устройство этих агентов лежит в каталоге агентов 03-agents (часть из них на старте реализована как скиллы Напарника, см. там же раздел «Когда агент, а когда скилл Напарника»).

Какие данные используются

В дело идут продажи, маржа и доля поставщика в категории, а также показатели поставок (fill rate, недопоставки, штрафы) из корпоративного хранилища (туда их регулярно выгружает WMS). К ним добавляются внешние индексы цен на сырьё и упаковку. Картину дополняют прецеденты прошлых уступок и стандарты переговоров из корпоративной базы знаний и история переписки с поставщиком из почты. Профиль контактного лица берётся из личной памяти Напарника, а слоты под встречу и follow-up живут в календаре и таск-трекере.

Какие решения принимаются

Менеджер принимает два связанных решения. Первое касается позиции, с которой он садится за стол. Второе касается уровня допустимого компромисса по итогам встречи. По результатам менеджер обновляет условия контракта через стандартный согласовательный маршрут компании (не через Напарника), ставит логисту задачу по мониторингу SLA, и поставщику уходит письмо-подтверждение. Каждое из этих действий проходит через явный клик. Напарник готовит, а решение и кнопку «отправить» нажимает человек.

Где нужен human-in-the-loop

Главная точка остановки находится на итоговой позиции на встрече. Напарник может рекомендовать диапазон, но решение всегда принимает менеджер. Вторая точка касается любого внешнего письма. Черновик готовит Напарник, кнопку «отправить» нажимает человек. Третья, менее очевидная, связана с публикацией паттерна в коллективной памяти. Здесь промежуточным звеном работает куратор организационной памяти, потому что коммерчески значимые решения автоматическая консолидация публиковать не должна. Подробности механизма лежат в 05-architecture, раздел «Память и контекст».

Ожидаемый бизнес-эффект

Доля встреч с подготовленным досье в коммерческой дирекции обычно стартует с 20%. Это наша экспертная оценка по итогам пресейл-интервью с категорийными менеджерами розничных сетей в 2025–2026 годах. С платформой эта доля выходит на 90% и выше уже в пилоте, потому что досье готовится само. На бэк-марже это даёт прямой эффект, лучше подготовленный менеджер чаще выбивает условия в свою пользу. Размер зависит от категории и стартовой позиции сети, но речь идёт о десятках миллионов рублей в год на масштабе крупной сети.

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

Метрики успеха

Мерим долю переговоров, к которым менеджер приходит с готовым досье. Её замеряют до пилота и после, как и время на подготовку. Рядом работает качественная оценка досье менеджером после встречи по 5-балльной шкале. На бизнес-уровне сильнее всего звучит эффект на бэк-маржу, и его удобно мерить когортой подготовленных встреч против неподготовленных. Отдельно стоит держать долю паттернов, попавших в коллективную память и прошедших валидацию куратора. По ней видно, что платформа помогает в конкретной встрече и заодно собирает общий ресурс команды.

Сценарий 2. Разбор падения продаж по категории

Бизнес-ситуация

Понедельник, утренний ритуал. Категорийный менеджер открывает BI и видит «Молочные продукты, Сибирский ФО, март, факт −9.2% к плану». Через неделю еженедельная коммерческая планёрка, на ней нужно объяснить, что произошло, и сказать, что с этим делать. По сети в целом цифра в норме, провал именно в одном регионе.

Участники

Разбор делает категорийный менеджер, и с ним он идёт на планёрку. До платформы такие запросы обычно делегировались аналитику коммерческой дирекции, поэтому он остаётся в сценарии как «человек, которого мы освобождаем». Логист направления отвечает за фактические данные по поставкам в Сибирский ФО, региональный коммерческий руководитель сидит в этом регионе как заинтересованная сторона, а коммерческий директор задаёт вопросы на планёрке.

Текущий процесс

Сегодня разбор идёт в несколько итераций и редко укладывается в один день.

Менеджер видит цифру и формулирует первую гипотезу, что это, вероятно, OOS. Идёт в BI смотреть остатки. По нескольким SKU остатки действительно были низкие, но это не объясняет всего минуса.
Запрашивает у аналитика факторный разбор. Аналитик стоит в очереди, разбор будет «к среде, может, к четвергу».
К среде разбор приходит диаграммой каскада. Главный вклад дают рост закупочных цен Danone +8% и недопоставки трёх SKU. Менеджер хочет провалиться в детали, но в Excel это сложно. Там готовый отчёт, перекроить разрез нельзя.
Идёт к логистам. Те подтверждают недопоставки, обещают прислать таблицу к концу дня. Таблица приходит в формате, не совместимом с Excel менеджера.
К пятнице картина вроде сложилась. Менеджер собирает презентацию. На планёрке коммерческий директор спрашивает, сравнивали ли с конкурентом. Сравнить времени уже не было.
После планёрки менеджер ставит себе задачу провалиться в данные конкурентов. Через неделю это снова не главный приоритет.

Боли текущего процесса

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

Дальше ломается глубина. Аналитик отдаёт готовый отчёт со свёрнутым разрезом, и если на планёрке возникает новый вопрос (а он возникает почти всегда), ответа не будет до следующего цикла. Менеджер отвечает «давайте проверим на следующей неделе», и эта «следующая неделя» означает реальный сдвиг решения в портфеле.

Ещё одна обидная вещь связана с ситуативной слепотой. Менеджер видит вопрос «почему упало», но не видит автоматически смежные. Что с конкурентом, что с промо, что было с матрицей в этом периоде. Их приходится специально вспоминать, и на каждой планёрке находится тема, на которой не вспомнили.

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

Как процесс выглядит с Напарником

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

Воскресенье ночью агент аномалий замечает значимое отклонение по молочной продукции в Сибири и запускает факторный разбор автоматически.
Утро понедельника, 9:15. В мессенджере короткое сообщение от Напарника. «По молочке в Сибири за март -9.2%. Главная причина в росте закупочных цен Danone на 8% (вклад -5.4 п.п.) и недопоставках трёх SKU из-за SLA 91% (вклад -2.3 п.п.). Эти два фактора покрывают не весь минус, ещё около 1.5 п.п. пока не разложены, копаю. Промо и конкуренты в норме. Доказательная база и отвергнутые гипотезы прикладываю. Через три дня встреча с Danone, готовить досье?».
Менеджер уточняет. «Покажи разрез по магазинам, есть подозрение, что в одной из подсетей проблема». Напарник за тридцать секунд возвращает разрез. Половина минуса концентрируется на 12 магазинах из 87, и все они в одном кластере. По кластеру параллельно идёт ремонт холодильного оборудования.
Менеджер уточняет ещё раз. «Что было бы, если бы не было этой проблемы с холодильниками?». Напарник делает контрфактический расчёт. -9.2% превратились бы в -5.8%, и тогда основным фактором оказывается цена Danone, а проблема холодильников добавляет 3.4 п.п. поверх.
Менеджер просит сравнение с конкурентом. Напарник вытаскивает доступные данные по доле полки и публичные индексы по категории. Делает оговорку, что на квартал у конкурента похожая динамика, но точную цифру по марту дать не может, данные публикуются с задержкой.
Среда. На планёрке менеджер заходит с готовой картинкой. В ней главная причина, второй и третий факторы, контрфактический расчёт, а в рекомендации отдельный план по холодильникам и пересмотр условий с Danone в эту пятницу. Коммерческий директор спрашивает про конкурента, менеджер отвечает по существу. Спрашивает про промо, Напарник в боковом канале мгновенно подсказывает, что промо в марте по молочке в Сибири было два, ROI обоих в норме, каннибализации нет. Менеджер озвучивает.
После планёрки Напарник записывает выводы в личную память. Теперь, если через два месяца возникнет похожая ситуация, он сразу поднимет прошлый разбор по молочке в Сибири с уже проверенными факторами и отвергнутыми гипотезами.

Какие функциональные агенты участвуют

Ядро сценария составляет агент факторного анализа. Он раскладывает отклонение на факторы и формирует диагностическую карточку с главным выводом, доказательной базой, отвергнутыми гипотезами и следующим шагом (структура карточки описана в 03-agents). Дополняют его другие агенты. Text2SQL делает нестандартные срезы по запросу менеджера, агент OOS приносит данные по SLA, а агент промо проверяет, не объясняется ли часть просадки промо-эффектом. Цепочка запускается с одного действия. Агент аномалий первым ловит отклонение и проактивно запускает разбор, не дожидаясь, пока менеджер откроет BI.

Какие данные используются

Базовый набор приходит из того же корпоративного хранилища (связку «хранилище ← WMS» см. в сценарии 1), сюда входят продажи, маржа, остатки, цены, фактические поставки и SLA. К ним добавляются календарь промо вместе с параметрами активных акций и, в той мере, в какой это есть у заказчика, внешние данные о конкурентах. Если в сети есть отдельная система мониторинга оборудования магазинов, она в этом сценарии особенно полезна, без неё связь «провал по кластеру = ремонт холодильников» не возникает автоматически.

Какие решения принимаются

Менеджер решает, как формулировать ситуацию на планёрке и какие действия предложить. По итогам, как правило, выходит несколько связанных шагов. Прежде всего надо назначить разговор с поставщиком (см. сценарий 1). Параллельно запускается отдельный план по холодильному оборудованию через операционный блок, без него часть проблемы продолжит давить на полку. И корректируется план на следующий месяц с учётом того, что эффект ещё не выгорел.

Где нужен human-in-the-loop

Сами разборы Напарник делает на Tier 1 (чтение и подготовка), здесь явное подтверждение не требуется. Внешние действия по итогам разбора (постановка задач, запросы коллегам) идут через явный клик. Обновление коллективной памяти проходит через куратора, как в сценарии 1.

Ожидаемый бизнес-эффект

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

Параллельно меняется качество разбора. У менеджера на руках всегда расширенная картина (с конкурентом, промо, контрфактическим расчётом), а не та, до которой он успел добраться. На планёрке это видно сразу.

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

Метрики успеха

Главная операционная цифра здесь это время до первичного факторного разбора, оно должно сжаться от суток до минут. Дальше интересна доля разборов, к которым менеджер вернулся за уточнениями. Если она высокая, значит, Напарник не выдал «отчёт-кирпич», а работает в диалоге. Точность диагностики проще всего собирать как оценку менеджера по 5-балльной шкале. И последнее, что важно для коммерческой дирекции, это доля планёрок, на которых менеджер мог ответить на любой смежный вопрос без откладывания на потом.

Сценарий 3. Анализ эффективности промо

Бизнес-ситуация

Конец летней промо-кампании по кондитерским изделиям. Девять акций, четыре из них крупные, с инвестицией в маркетинг и в скидку. Через две недели комитет по промо, на нём нужно сказать, что сработало, что нет, и что мы делаем на осень. Параллельно у руководителя промо давление сверху, хочется делать поменьше акций, но более окупаемых, потому что бюджет на следующий год режут на 15%.

Это болезненная ситуация в индустрии. Внешние исследования говорят, что 59–72% трейд-промо в FMCG не окупаются (59% это оценка Nielsen по миру за 2014 год, 72% приводит McKinsey по рынку США), и эта оценка часто повторяется в консалтинговых отчётах разных лет. Реалистично ожидать, что и в этой кампании часть акций окажется в убытке. Открыт вопрос, какие именно и почему.

Участники

Основным заказчиком разбора становится руководитель промо, ему нужны выводы под комитет и под защиту бюджета. Содержательно с ним работает категорийный менеджер по кондитерке, без него сложно интерпретировать, что произошло на полке. Прайс-менеджер смотрит, не размывает ли промо воспринимаемое ценовое позиционирование категории, а маркетинг приходит со своей частью (коммуникационным разбором и медиа-бюджетом). Финальное слово по осеннему плану остаётся за коммерческим директором.

Текущий процесс

Руководитель промо запрашивает у аналитики разбор по кампании. Тот формирует Excel с продажами в промо, продажами до и после, скидкой, инвестицией и ROI. Около недели.
Параллельно категорийный менеджер делает свой разбор. Что у него на полке, как менялась маржа, не было ли каннибализации между SKU. Отдельный Excel.
Прайс-менеджер вносит свой кусок, ценовое позиционирование и сравнение с конкурентом в период промо. Третий Excel.
Маркетинг присылает свой отчёт с охватами, медиа-миксом и эффективностью каналов. Четвёртый.
Кто-то (обычно руководитель промо) пытается всё это свести. Сводка получается крупными мазками. Общий ROI кампании, две-три иллюстрации. Детальный разбор по каждой акции с учётом каннибализации, эффекта на маржу категории и ценового позиционирования собрать не получается, не хватает времени.
На комитете доклад звучит как «общий ROI 12%, в целом успешно». Через месяц одна из акций оказывается в реальности в минусе по марже категории, потому что переключила покупателей с маржинального SKU на менее маржинальный. Это всплывает уже после, когда кто-то случайно посмотрел.

Боли текущего процесса

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

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

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

Как процесс выглядит с Напарником

В платформе разбор идёт сразу как сводный, и за каждым выводом закреплена цифровая фактура.

Понедельник. Напарник руководителя промо приносит сводный разбор летней кампании. «9 акций, 4 крупные. Чистый ROI с учётом каннибализации составляет +21% (две акции), +6% (две акции), -4% (одна акция), -12% (две акции). Главный фактор отрицательного ROI это каннибализация на собственный маржинальный SKU. Подробный разбор по каждой акции прикладываю».
В разборе по каждой акции есть единый блок. Он сводит вместе цель акции, фактический результат, чистый эффект на категорию, разрезы по каннибализации и маржинальности, влияние на ценовое позиционирование и медиа-вклад. Каждая цифра кликабельна, можно провалиться к источнику.
Руководитель промо ставит вопрос. «А что было бы, если бы убрали из плана две убыточные акции и оставшийся бюджет перераспределили на три самые сильные?». Агент финансового эффекта пересчитывает за минуту, что прирост составит +9 п.п. к общему ROI кампании, при этом охват сокращается на 18%. Развилка теперь стоит вокруг того, как сбалансировать маржу и охват, а вопрос «делать ли промо вообще» с повестки уходит.
Категорийный менеджер кондитерки через своего Напарника подключается к разбору. Видит свою часть, добавляет комментарий, что акция №7 каннибализировалась на собственный новый бренд, который пытались разогнать, и на осень эту пару акций нужно разнести по времени.
Прайс-менеджер видит своими глазами, что одна из акций просадила воспринимаемый ценовой уровень на 8% за категорию в целом и эффект продержался ещё месяц после акции. Это раньше никто не считал, потому что лень.
Среда, комитет. Доклад идёт по сводной картинке. На ней видно, что окупилось и почему, а что нет. Отсюда вырастает план на осень с учётом разбора. Сеть отказывается от двух исторически слабых форматов и перебрасывает бюджет на три, плюс одна экспериментальная новая. Сравнение с прошлым годом теперь идёт по реальному эффекту на маржу категории, а общий ROI уходит на второй план.
После комитета Напарник кладёт паттерн каннибализации между конкретной парой SKU в коллективную память. В следующий раз при планировании любой акции по этой паре Напарник предупредит автоматически.

Какие функциональные агенты участвуют

Главным здесь работает агент промо. Он считает чистый эффект акции с учётом каннибализации, эффекта на маржу категории и ценового позиционирования. Рядом подключаются агент финансового эффекта (моделирует альтернативные сценарии вроде «убрать две убыточные акции и перераспределить бюджет») и агент конкурентного мониторинга, добавляющий внешний контекст по ценам и ассортименту конкурентов. Text2SQL даёт доступ к нестандартным срезам, а подготовку комитета берёт на себя агент встреч и follow-up.

Какие данные используются

Большую часть данных даёт корпоративное хранилище. Это продажи, маржа, остатки и цены до акции и после. К нему подключаются параметры акций и план из систем промо-планирования, а также медиа-часть из маркетинг-систем (бюджеты, охваты, креативы). Внешние данные о конкурентах участвуют в той мере, в какой они вообще подключены к платформе у заказчика.

Какие решения принимаются

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

Где нужен human-in-the-loop

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

Ожидаемый бизнес-эффект

Прямой эффект в том, что неэффективных акций становится меньше. По индустриальным цифрам (те же оценки Nielsen и McKinsey), значительная часть промо в продуктовом ритейле не приносит прибыли при аккуратном подсчёте. На платформе такой расчёт получают по каждой акции, и заметная часть планируемых промо просто не доходит до запуска. Это сразу высвобождает бюджет, при этом доля категории на полке не падает. Наоборот, освободившиеся деньги идут на сильные форматы.

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

Метрики успеха

Базовая методологическая метрика это доля промо, по которым посчитан чистый эффект с учётом каннибализации. Она обычно стартует с единиц процентов, целевое значение близко к 100%. На бизнес-уровне работает динамика общего ROI промо-портфеля категории и доля бюджета, перераспределённого с неэффективных форматов на эффективные. Отдельно стоит замерять скорость подготовки разбора. Она в этом сценарии падает от недель до часов, и это ощутимо снимает нагрузку с аналитики.

Сценарий 4. Управление OOS и доступностью товара

Бизнес-ситуация

Утро среды, среднее время приезда товара по плану два дня. Категорийный менеджер видит в BI, что по категории «Молочные продукты» три SKU вышли на нулевой остаток в шести магазинах одного кластера. Если ничего не делать, в выходные (пиковый день по категории) на полке будут пустые места. Прямые потери от классического OOS в продуктовом ритейле оцениваются примерно в 4% продаж. Эта цифра идёт из классического международного исследования Corsten и Gruen (GMA, 2002 год), которое до сих пор остаётся отраслевым ориентиром. До четвёртого июня (пятницы) короткий период, в который нужно либо переключиться на альтернативный РЦ, либо подгонять экстренный заказ, либо временно подменить SKU.

Участники

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

Текущий процесс

Менеджер замечает проблему сам в обычной утренней рутине, открыв BI. Это уже удача. Чаще проблему замечают, только когда прилетает жалоба от регионального руководителя.
Звонит логисту. Тот сейчас занят другой проблемой. Обещает посмотреть.
Логист через час перезванивает. Альтернативный РЦ есть, но переключить машину туда займёт два дня, и к выходным товар поспеет в притык, а часть магазинов останется без него.
Менеджер звонит поставщику, договаривается об экстренной партии. Поставщик подтверждает, но fill rate у него в этом квартале уже 84%, доверия не стопроцентное.
Менеджер просит операционного руководителя кластера временно расширить выкладку соседних SKU.
К пятнице картина следующая. На двух магазинах из шести товара нет, на четырёх есть, но мало. В выходные продажи категории в этом кластере проваливаются на 18% против обычного.
В понедельник менеджер разбирает случившееся. Первичный вывод сводится к недопоставке, второй к тому, что не успели переключиться. О том, что сигнал был во вторник вечером (а не в среду утром), узнают только когда смотрят логи.

Боли текущего процесса

Главное в реактивности. OOS сегодня обнаруживается, когда уже почти поздно. Пока сигнал доходит до человека, окно для манёвра сокращается с 48 часов до 12, а на коротком окне почти все варианты дороже. У менеджера почти не остаётся выбора, он просто гасит то, что доступно.

Параллельно мешает разрозненность данных. Чтобы оценить серьёзность ситуации, менеджеру нужны одновременно остатки в магазинах, прогноз спроса, статус поставки, fill rate поставщика и календарь промо. Эти пять кусков информации лежат в четырёх разных системах, и одна только их сборка занимает у человека полчаса.

Хуже того, плохо видна системность. Конкретный OOS воспринимается как «случай», и каждый эпизод закрывается отдельно. А то, что у конкретного поставщика fill rate на 8 п.п. ниже SLA уже три квартала подряд, остаётся паттерном, который никто не собирает в одном месте, разные люди видят разные эпизоды и каждый в своей голове считает «у меня было дважды».

И как следствие, в переговоры с поставщиком про SLA приходится идти с общими словами, без жёсткой фактуры. У поставщика всегда находится ответ «ну это случай», и без накопленной картины спорить с ним сложно.

Как процесс выглядит с Напарником

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

Вторник, 18:30. Агент OOS видит, что по трём SKU в шести магазинах одного кластера прогноз остатка к утру среды уходит в ноль. С учётом календаря промо и сезонности по выходным это даст потерю выручки порядка 2.4 млн ₽ за уикенд. Запускает поиск решения.
Вторник, 18:35. Напарник менеджера приходит с уже собранным пакетом. «Прогноз OOS по 3 SKU в кластере N к утру среды. Через альтернативный РЦ A переключимся за 36 часов, успеваем. Поставщик может прислать экстренную партию физически, но fill rate у него за квартал 84%, рекомендую как страховку, не как основной вариант. Подмена соседними SKU согласована операционным руководителем кластера ещё в апреле. По оптимальному плану переключаемся на РЦ A, делаем страховочный заказ и расширяем выкладку в шести магазинах. Запросить у Напарника логиста подтверждение?».
Вторник, 18:40. Менеджер подтверждает. Напарник логиста за десять минут получает добро от своего сотрудника. Переключение на РЦ A инициируется. Операционному руководителю кластера уходит уведомление с предложенной выкладкой.
Среда и пятница. Агент OOS отслеживает движение. Товар вышел с РЦ A в указанное время, доехал в магазины в пятницу к утру. Категорийный менеджер на этом этапе вообще не вовлечён, кроме одного автоматического статус-сообщения в среду вечером, что всё идёт по плану.
Выходные. Полка не пустая, продажи в норме. О ситуации, которая в старой модели стоила бы ему всей недели, менеджер только знает, что она была.
Понедельник. Напарник приносит короткий разбор. «Эпизод OOS вторник-пятница закрыт. Корневая причина в недопоставке от поставщика B, fill rate которого за последние шесть месяцев колеблется около 84%. С июля у нас семь похожих эпизодов по этому поставщику. Готов добавить в досье следующих переговоров с ним». Менеджер подтверждает.

Какие функциональные агенты участвуют

Главную работу делает агент OOS. Он и проактивно ловит проблему, и оркеструет варианты решения. К нему подключается агент прогнозирования (он даёт оценку спроса с учётом промо и сезонности, без неё непонятно, насколько критична нехватка) и агент финансового эффекта, оценивающий стоимость каждого варианта в рублях. Параллельно идёт фоновая работа агента переговоров. Он не вмешивается в сам инцидент, но копит фактуру по поставщику для следующего разговора. За уведомления и эскалации отвечает агент аномалий, для которого алертинг это встроенная функция. Подробное устройство этих агентов лежит в 03-agents.

Какие данные используются

Из корпоративного хранилища (связку «хранилище ← WMS» см. в сценарии 1) берутся остатки на РЦ и в магазинах, продажи, прогноз спроса, поставки, графики, фактические даты прихода и SLA поставщиков с разбивкой на fill rate, отказы и замены. К ним подключаются календарь промо и карта альтернативных маршрутов между РЦ. Карта маршрутов нужна, чтобы агент мог сам предложить переключение, а не просить логиста собрать варианты руками. В сценариях, где задержка в выгрузке принципиально мешает работе (например, оперативная картина по конкретному РЦ в момент срыва поставки), допускается точечное прямое подключение к WMS, согласованное с владельцем системы.

Какие решения принимаются

В моменте идут три связанных подтверждения от людей. Переключение машины на альтернативный РЦ (логист), экстренный заказ у поставщика (логист) и временное расширение выкладки соседних SKU (операционный руководитель кластера). На горизонте дольше принимается решение включить накопленный паттерн по fill rate этого поставщика в досье следующих переговоров. Его принимает категорийный менеджер уже после того, как эпизод закрыт.

Где нужен human-in-the-loop

Любое физическое движение товара (переключение РЦ, экстренный заказ, подмена SKU) идёт через явный клик соответствующего сотрудника. Напарник готовит, человек подтверждает. На уровне Tier 3 со временем можно вынести в автономный режим тривиальные случаи, например стандартное переключение между двумя ближайшими РЦ при остатке ниже X дней, но это включается точечно, после периода доверия. Подробности лежат в 05-architecture, раздел «Human-in-the-loop».

Ожидаемый бизнес-эффект

Главный эффект в снижении длинного OOS, то есть случаев, которые длятся больше суток. Именно они успевают увести покупателя к конкуренту и дают непропорционально большой вклад в потери. В исследовании Corsten и Gruen около 3% самых ходовых позиций дают порядка 17% всех потерь от нехватки, поэтому гасить в первую очередь нужно именно их. С платформой длинные OOS почти не возникают, проблему замечают за часы, а не за дни.

Второй эффект связан с возвратом фактуры в переговоры. Когда у менеджера есть систематическая картина по fill rate каждого поставщика, с разрезом по месяцам, SKU и кластерам, переговорная позиция меняется. Это, в свою очередь, входит в сценарий 1 как одна из самых сильных аргументационных цепочек.

Метрики успеха

Первая метрика здесь это время от события OOS до алерта. Оно должно перейти из часов и суток в минуты. Следом идёт доля длинных OOS длительностью больше 24 часов, и здесь целевая динамика к нулю. На горизонте полугода становится виден сдвиг по fill rate проблемных поставщиков, в их сторону начинает идти регулярная фактура. И отдельно стоит держать долю OOS-инцидентов, закрытых без вовлечения категорийного менеджера сверх одного подтверждения. По ней видно, насколько процесс действительно автоматизирован, а не просто оснащён красивыми алертами.

Сценарий 5. Межфункциональная встреча через Напарников

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

Бизнес-ситуация

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

Участники

Встречу инициирует категорийный менеджер, приглашёнными участниками идут прайс-менеджер и руководитель промо. У всех троих свои Напарники, и в этом сценарии вся настройка встречи происходит между ними, а не между людьми.

Текущий процесс

Сегодня это занимает по-человечески обидное количество шагов.

Менеджер пишет обоим в мессенджере, что нужна встреча на 30 минут на следующей неделе, есть что обсудить по акции.
Один отвечает «попробую посмотреть, перезвоню». Второй через два часа просит дать слот, который он подберёт. Менеджер пишет, у кого какие свободные слоты он видит в общем календаре. Тот говорит «не подходит, давай в четверг утром». Первый говорит «я по утрам в четверг занят». Идёт переписка.
Менеджер ставит встречу в четверг днём, оба соглашаются. Повестку формулирует в стиле «обсудим летнее промо по конфетам».
Никто из участников не готовится. Все приходят с тем, что помнят.
Встреча начинается с того, что каждый вытаскивает свой контекст. Менеджер пересказывает ситуацию с поставщиками, прайс-менеджер добавляет картину по ценам, руководитель промо подтягивает свой медиа-бюджет. Уходят первые 15 минут из 30.
До решения дело доходит, но вскользь. Договариваются вернуться к этому ещё раз через неделю.

Боли текущего процесса

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

И самое скучное в том, что на сборку самого факта встречи в календарях уходит несколько перепалок и рабочих часов трёх человек.

Как процесс выглядит с Напарниками

В новой модели встреча собирается между Напарниками и готовится автоматически.

Менеджер говорит своему Напарнику. «Поставь встречу с прайс-менеджером и руководителем промо на следующей неделе на 30 минут. Хочу обсудить летнее промо по линейке шоколадных конфет».
Напарник менеджера обращается к Напарникам прайс-менеджера и руководителя промо. Они согласовывают слоты, проверяя у своих сотрудников предпочтения (кто-то не любит ставить встречи до 11:00, кто-то блокирует пятницу под планёрку). Через две минуты у менеджера в мессенджере приходит результат, что договорились на четверг 15:00, встреча поставлена, повестка добавлена.
Накануне встречи каждый из трёх Напарников готовит своему сотруднику короткий бриф под эту встречу, каждый со своей оптики. Категорийный менеджер получает по линейке прирост 4% к прошлому году, отметку, что две из трёх SKU участвовали в весеннем промо с ROI 9% и -2%, и напоминание, что в феврале поставщик просил +3% к закупочной цене, отбили. У прайс-менеджера своя картина, по этой линейке сеть дороже конкурента в своём ценовом сегменте на 3%, чем и объясняется часть провала по объёму, а уход в промо ниже на 7% вывел бы на конкурентный уровень. Руководителю промо важнее бюджет, летом по кондитерке его порезали на 15%, выгоднее вложиться в две акции вместо обычных трёх, и тогда стоит решить, какую из обсуждаемых линеек брать.
Встреча. У всех троих перед глазами свой бриф. Никто не пересказывает контекст друг другу, он у всех в голове. Обсуждение начинается сразу с предмета. Брать ли линейку в летнее промо, какой формат, какой уровень скидки, как избежать каннибализации. За 30 минут принимается решение.
После встречи Напарник категорийного менеджера фиксирует договорённости в виде задач. Подготовить запрос поставщику на дополнительные объёмы, согласовать с ценообразованием окончательную скидку, отправить в маркетинг бриф на креатив. Каждая задача попадает к нужному сотруднику через его Напарника. Никто из людей не тратит на эту обвязку ни минуты.

Какие функциональные агенты участвуют

Этот сценарий особенный тем, что одного главного агента в нём нет. Логистику встречи (поиск общего слота, бронирование, повестку, приглашения) берёт на себя календарный скилл каждого Напарника, а сами слоты Напарники согласовывают между собой напрямую по A2A. Содержание брифов собирают предметные агенты, каждый со своей оптики. Категорийному менеджеру готовит выжимку агент промо, прайс-менеджеру агент ценообразования и конкурентного мониторинга, руководителю промо агент финансового эффекта. Follow-up после встречи, когда договорённости превращаются в задачи, на старте тоже остаётся за Напарником.

Вся эта содержательная обвязка (бриф до встречи, фиксация договорённостей во время, задачи после) и есть будущая зона агента встреч и follow-up. В стартовой сборке отдельного такого агента ещё нет, его работу закрывают скиллы Напарника. Полноценным агентом с расшифровками встреч и таск-трекером он становится на следующем шаге.

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

Какие данные используются

Главный набор данных составляют календари трёх сотрудников и корпоративный мессенджер, на них держится сама механика встречи. Содержание брифов берётся из хранилища (продажи, цены, маржа) и параметров промо-плана, дополняется внешними данными о конкурентах в той части, в какой они подключены. Поверх всего лежит личная память каждого Напарника со своими хранимыми мелочами, такими как предпочтения сотрудника по слотам, привычный стиль брифа, чувствительные темы, которые лучше не выносить в общий чат.

Какие решения принимаются

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

Где нужен human-in-the-loop

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

Ожидаемый бизнес-эффект

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

Метрики успеха

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

Backlog сценариев

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

День категорийного менеджера

Не аналитический сценарий, а сюжетный. Один полный рабочий день человека с Напарником, от утреннего брифинга до вечернего проактивного разбора в фоне. Полезен на демо как обобщающая иллюстрация, в которой все остальные сценарии встречаются маленькими фрагментами. Заметка для будущей детализации лежит в 02-partner, раздел «Рабочий день, в котором Напарник работает сам», там уже есть рабочий каркас.

Подготовка к ассортиментному комитету

Раз в квартал категорийный менеджер защищает изменения в матрице. Сценарий объединяет работу нескольких агентов, среди них ассортимент, финансовый эффект, ценообразование и конкурентный мониторинг, факторный анализ. Похож на разбор продаж, но горизонт длиннее и решения тяжелее. Листинг и делистинг относятся к необратимым шагам, и здесь особенно важна Tier 2 граница автономии.

Кризисная ситуация

Сюда попадают срыв поставки, пожар на РЦ, проблема с регуляторикой по группе SKU. Общая черта в том, что внутренний таймер сжат до часов. Здесь хорошо видно ценность проактивного агента алертов и сценарий «9:00, утром в мессенджере уже забронирован антикризисный звонок», описанный в исходных материалах концепта. Подробное описание появится, когда станет понятно, какие именно типы кризисов наиболее частые у конкретного заказчика.

Онбординг нового менеджера

Когда сильный категорийщик уходит, новый человек первые недели восстанавливает картину по обрывкам. Платформа меняет это. Личная память Напарника предшественника не передаётся напрямую (это было бы небезопасно), но коллективная память и базы знаний открывают новому менеджеру доступ к проверенным паттернам с первого дня. Сценарий привязан к зрелости коллективной памяти и куратора, поэтому подробное описание разумно делать на втором-третьем этапе внедрения.

Подготовка управленческого summary

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

Поиск и распространение лучших практик

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

Открытые вопросы

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

Опорные числа сценариев это внешние индустриальные оценки и наблюдения практиков, а не замеры в контуре конкретной сети. Рост доли подготовленных досье с 20% до 90% это наша экспертная оценка, опубликованного источника под ней нет. Цифра 59–72% неокупаемых промо опирается на Nielsen (мир, 2014 год) и на McKinsey с данными Nielsen по США. Потери около 4% продаж от OOS идут из исследования Corsten и Gruen (GMA, 2002 год). Более свежие замеры (Circana по промо за 2023 и 2024 годы, NielsenIQ по пустым полкам за 2021 год) подтверждают направление, но часть из них завышена пандемийными перебоями поставок, поэтому за базовые мы берём прежние бенчмарки. На пресейле эти числа нужно подавать как ориентир и порядок величины, а не как обещание. Честная защита требует отдельно проговорить, на каких допущениях держится оценка, и заранее договориться, как тот же показатель будет замеряться в пилоте.

В сценарии 1 Напарник подсказывает менеджеру в боковой канал прямо во время встречи. Технически это самый недоказанный элемент. Непонятны допустимая латентность, способ незаметной доставки подсказки, поведение при онлайн- и офлайн-встрече, а также приватность (запись и расшифровка живого разговора с внешним участником поднимает юридический вопрос). Сценарий уже опирается на эту механику, хотя её осуществимость на стороне заказчика ещё предстоит подтвердить.

Ответы вида «что было бы, если бы не было проблемы с холодильниками» (сценарий 2) и пересчёт ROI при снятии двух акций (сценарий 3) полностью зависят от качества модели атрибуции факторов. Риск в том, что платформа уверенно назовёт ошибочный фактор главным, а менеджер примет это за факт и пойдёт с этим на планёрку. Где проходит граница между обоснованным расчётом и правдоподобной выдумкой и как помечать неуверенность, концепт пока не фиксирует.

📄 Скачать эту страницу в Markdown (.mdx) — для ИИ-агентов и оффлайн-чтения