Подрядчику нужен отчёт. Зачем ему ключи от всего бизнеса?

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

Я предлагаю начинать с результата работы. Человек должен объяснить падение конверсии — значит, ему нужны данные для анализа. Менять настройки ему потребуется, только если вы поручите исправление. Эту разницу стоит зафиксировать до выдачи доступа.

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

Три режима решают три разные задачи

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

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

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

Кейс 1. Подрядчик проверяет рекламу, но ничего не меняет

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

Запрос менеджеру можно сформулировать так: «Нужен просмотр аналитики и воронок; просмотр расходов — для сопоставления затрат с результатом. Редактирование этих разделов не требуется. Доступ к оплате, Тег Менеджеру, оптимизатору и AI-агентам запретить».

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

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

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

Кейс 2. Маркетолог отвечает за результат, аналитик — за измерение

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

Ниже — пример матрицы прав доступа для такого распределения обязанностей. Названия в столбцах обозначают работу людей, а не готовые роли Андаты. «Просмотр», «Редактирование» и «Запрет» — желаемый итоговый доступ, который нужно согласовать с менеджером.

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

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

Проверка: каждый участник выполняет свою рабочую операцию. Затем проверяется одно запрещённое действие в соседнем разделе. Само название должности или роли такой проверки не заменяет.

Кейс 3. Проверить ответы агента — не значит получить управление всей базой знаний

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

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

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

Терминал — отдельный доступ. Его нужно указать в обращении отдельно. Не записывайте «Терминал только для просмотра»: в текущей модели такого самостоятельного режима нет. Открытый Терминал также не заменяет права на остальные объекты.

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

Кейс 4. Интеграция по API тоже зависит от прав пользователя

Допустим, разработчик подключает агента к вашему сервису: сервис отправляет вопрос, получает ответ и показывает его сотруднику. Успешная проверка в браузере ещё не означает, что запросы интеграции будут разрешены.

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

Это помогает точнее поставить задачу: «Нужна интеграция, которая отправляет сообщения агенту и получает результат. Проверьте права владельца используемого токена на агентов и диалоги». Выдавать доступ ко всем разделам, чтобы убрать ошибку, — слишком широкое решение.

Проверка: выполнить предусмотренные сценарием запросы именно с токеном интеграции. Если API отвечает 403, проверить необходимые права владельца токена. Сам токен в переписку с описанием проблемы не вставляйте. Маршруты и примеры запросов есть в справке по внешнему API Андаты.

Кейс 5. Подрядчик закончил работу — доступ нужно пересмотреть

Для временной задачи полезно сразу записать дату пересмотра прав. Например, после приёмки аудита или завершения настройки агента. Это организационное напоминание: автоматическое истечение доступа из такой записи не возникает.

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

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

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

Как запросить права без трёх кругов уточнений

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

Вот шаблон для внешнего специалиста, который анализирует конверсию:

Компания: название вашей компании.
Пользователь: email его учётной записи.
Задача: проанализировать источники трафика и потери между этапами существующей воронки.
Чтение / просмотр: аналитика, воронки, расходы.
Редактирование: не требуется.
Запрет на доступ: оплата, Тег Менеджер, оптимизатор, AI-агенты и их материалы.
Терминал: доступ не требуется.
Текущие назначения: прошу проверить роли и персональные разрешения, чтобы итоговый доступ соответствовал этому запросу.
Пересмотр: после приёмки аудита. Ответственный со стороны компании — имя сотрудника.

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

Как понять, что настройка принесла пользу

Я смотрю на два результата: человек может выполнить порученную работу и не получает лишних возможностей. Проверка только запретов оставляет риск заблокировать работу команды; проверка только разрешений пропускает избыточный доступ.

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

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

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

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