# Согласования для агентства: права, SLA и ответственность по клиентским кабинетам

> Для агентства — кто в команде может одобрять изменения в кабинете клиента, как строить SLA на скорость реакции на заявки и как разграничить ответственность при отклонении.

published: 2026-08-05T22:32:00+03:00
updated: 2026-08-05T22:32:00+03:00

Раздел «Согласования» — то самое место, где вы даёте явное «да» на любое изменение в маркетплейсе,
предложенное ИИ-агентом, интерфейсом или внешней интеграцией. Жёсткое правило платформы: **агент
(и даже интерфейс/API) только СОЗДАЁТ намерение** — реально применяет изменение в WB/Ozon отдельный
исполнитель, и только после того, как человек с достаточными правами это одобрил.

## Откуда данные

- **Что может предложить агент** — узкий и явный список типов действий (изменить цену, изменить
  остаток, поставить/снять рекламную кампанию с паузы, изменить ставку в рекламе, изменить габариты
  карточки, подключить товар к акции и другие). Список задан в коде платформы, а не в промпте агента.
  Часть действий (например, полное удаление рекламной кампании) требует более высокой роли —
  Администратор, а не Менеджер.
- **Карточка «было → станет»** — «было» это снимок реального состояния, снятый в момент возникновения
  намерения; «станет» — то, что предлагается поставить. Если снимок «до» не удалось получить —
  честно показывается «текущее значение неизвестно», а не выдуманный ноль.
- **Статус заявки** — живая очередь в базе данных: ожидает одобрения → одобрено → исполняется →
  применено, либо ошибка/откачено/отклонено.
- **Источник намерения** — ИИ-агент в чате, вы сами через интерфейс, внешняя интеграция по API или
  MCP-агент.

## Как читать экран

- **Действие** — что предлагается изменить и где, плюс diff «было → станет» прямо в строке.
- **Кабинет** — в каком магазине маркетплейса это произойдёт.
- **Источник** — ИИ-агент / Интерфейс / API / MCP-агент.
- **Статус**: *Ожидает одобрения* (нужно решение), *Одобрено/Исполняется*, *Применено*, *Ошибка*,
  *Откачено* (было применено, потом отменено обратной заявкой), *Отклонено*.

## Честно про режим исполнения

Сейчас исполнитель, который реально вызывает маркетплейс, работает в **тестовом (dry-run) режиме**:
одобренные заявки проходят весь цикл, но реального вызова WB/Ozon не происходит. Включение боевого
режима — отдельное явное решение владельца платформы, не то, что включается само по мере
использования.

## Частые вопросы

- **Я одобрил заявку, но ничего не изменилось в WB/Ozon — почему?** Скорее всего исполнитель ещё
  работает в тестовом режиме — см. раздел выше.
- **Можно ли отменить уже применённое изменение?** Да, но не напрямую — кнопкой «Откатить», которая
  создаёт обратную заявку-компенсацию, снова ждущую одобрения. Необратимые типы действий (например,
  удаление рекламной кампании) отката не имеют — ограничение самого маркетплейса.
- **Кто может одобрять заявки?** Роль Менеджер и выше (Менеджер, Администратор, Владелец). Роли
  Наблюдатель и Аналитик видят список, но без кнопок «Одобрить/Отклонить».

## Коротко

- Очередь согласований отдельна по каждой организации-клиенту — заявки разных клиентов не смешиваются и не видны друг другу.
- Одобрять заявки может роль Менеджер и выше — решите заранее, кто из сотрудников агентства имеет это право для конкретного клиента.
- Стройте SLA клиенту на основе полей «Ожидает одобрения» и времени реакции — это измеримая база для обещания скорости.
- Используйте поле «Источник», чтобы разграничить ответственность между заявкой от ИИ-агента и заявкой напрямую через интерфейс или API клиента.
- Объясняйте клиенту тестовый (dry-run) режим исполнителя явно — статус «Применено» технически означает успешный цикл согласования, но не реальное изменение на площадке.

## Боль: клиент должен доверять, что агентство не меняет цены и рекламу самовольно

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

## Как работать по шагам

<details>
<summary>Подробно: работа с согласованиями по клиентским кабинетам</summary>

1. **Помните, что очередь согласований — отдельная по каждой организации-клиенту.** Переключаясь
   между клиентами через переключатель организации, вы видите и одобряете заявки только той
   организации, которая выбрана — заявки разных клиентов не смешиваются и не видны друг другу.
2. **Настройте роли команды агентства под реальную ответственность в каждом клиентском кабинете.**
   Одобрять заявки может роль Менеджер и выше — решите заранее, кто из сотрудников агентства имеет
   это право для конкретного клиента, а не выдавайте эту роль всем по умолчанию.
3. **Стройте SLA на основе полей «Ожидает одобрения» и времени реакции.** Клиенту важно знать не
   только что заявки одобряются, но и как быстро — используйте очередь как измеримую базу для
   обещания клиенту («заявки на изменение цены рассматриваются в течение часа в рабочее время»).
4. **Используйте поле «Источник», чтобы разграничить ответственность** — заявка от ИИ-агента,
   созданная по запросу сотрудника агентства в чате клиента, отличается от заявки, созданной
   напрямую через интерфейс или внешнюю интеграцию клиента по API. Это помогает быстро понять, кто
   инициировал изменение, если у клиента возникнет вопрос.
5. **Объясняйте клиенту тестовый (dry-run) режим исполнителя явно**, если он ещё активен для его
   кабинета — статус «Применено» технически означает, что цикл согласования прошёл успешно, но
   реального изменения на площадке пока не произошло; это решение владельца платформы, а не агентства,
   и не должно восприниматься клиентом как невыполненная работа.
6. **Раз в неделю по каждому клиенту разбирайте отклонённые и упавшие с ошибкой заявки** — системная
   проблема с одним типом действия у одного клиента (например, повторяющаяся ошибка при обновлении
   цены) стоит отдельного разговора с клиентом или технической поддержкой платформы.

</details>

## Ценность

Раздел даёт агентству готовый, показываемый клиенту механизм контроля: ничего не применяется в
кабинете клиента без одобрения, роли определяют, кто конкретно в команде агентства несёт
ответственность за решение, а очередь с полями источника и времени — материал для прозрачного SLA
вместо общих слов «мы всё контролируем».

## Частые вопросы

**Может ли сотрудник агентства одобрять заявки сразу по всем клиентам из одного окна?**
Нет, очередь и права привязаны к организации-клиенту — переключение между клиентами происходит через
переключатель организации, одобрение всегда происходит в контексте одного клиента за раз.

**Кто должен иметь право одобрять заявки в кабинете клиента — весь отдел или один ответственный?**
Решение за агентством, но платформа даёт инструмент: назначайте роль Менеджер и выше только тем, кто
реально должен нести ответственность за это конкретное решение в конкретном клиентском кабинете, а не
всей команде по умолчанию.

**Как объяснить клиенту задержку между «Одобрено» и «Применено»?**
Между одобрением и применением заявка проходит фактический вызов маркетплейса отдельным
исполнителем — небольшая задержка ожидаема; если статус долго остаётся «Исполняется», стоит уточнить
у поддержки платформы.

**Что делать, если клиент лично отклонил заявку, которую предложил ИИ-агент?**
Причина отклонения (если указана) попадает в аудит и помогает ИИ-агенту точнее формулировать
предложения в следующий раз — обсудите с клиентом, что именно не подошло, чтобы скорректировать
дальнейшие запросы к агенту.

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