Права менеджеров в CRM почти никогда не настраивают заново после внедрения системы: разворачивают amoCRM или Bitrix24, всем сотрудникам выдают одинаковую роль «менеджер», и на этом настройка доступа заканчивается. Через год-два выясняется, что любой продавец может выгрузить всю базу контактов в Excel одним кликом и унести её при увольнении. У меня на практике был случай: агентство с полутора десятками менеджеров держало базу в amoCRM без единого ограничения по ролям, и после ухода одного из продавцов клиенты начали получать звонки от конкурента с теми же именами, суммами сделок и историей переписки. С тех пор я закладываю разграничение доступа отдельным этапом настройки CRM, а не пунктом «доделаем потом».
Зачем разграничивать доступ, если менеджеров всего трое-пятеро
Возражение «у нас маленькая команда, все свои» я слышу почти на каждом втором внедрении. Работает оно ровно до первого конфликта или увольнения. Дело не в недоверии к конкретным людям, а в том, что CRM хранит не только контакты, а всю историю отношений с клиентом: звонки, переписку, суммы сделок, историю скидок, иногда платёжные данные, если подключён приём онлайн-оплаты. Если у каждого менеджера открыт доступ ко всей базе, утечка происходит не через взлом системы, а через обычный экспорт в CSV перед уходом с текущего места работы.
Есть и вторая причина, не связанная со злым умыслом. Чем больше людей имеет полный доступ к CRM, тем выше шанс, что кто-то случайно изменит стадию чужой сделки, удалит контакт или выгрузит не тот сегмент базы для рассылки. Разграничение прав снижает количество таких бытовых ошибок само по себе.
Третья причина - аналитика. Если у РОПа есть право смотреть отчёты по всем менеджерам, а у рядового сотрудника нет доступа к чужим показателям, воронка продаж перестаёт быть предметом обсуждения в курилке и превращается в рабочий инструмент для управления отделом.
Роли пользователей в CRM: менеджер, РОП и администратор
В большинстве CRM базовый набор ролей одинаковый: менеджер, руководитель отдела продаж и администратор аккаунта. Разница между ними не в названии роли, а в том, какой уровень доступа назначен на каждое действие со сделками, контактами и отчётами.
В amoCRM права настраиваются через отдельную вкладку с ролями: для каждой роли включается уровень видимости сделок (свои, сделки группы, все сделки), право редактировать и удалять чужие карточки, право экспортировать данные. В Bitrix24 матрица прав детальнее: доступ настраивается отдельно по каждой сущности CRM, лидам, сделкам, контактам, компаниям, счетам, и у каждого действия свой уровень: нет доступа, личные записи, записи отдела, все записи. Экспорт там тоже вынесен отдельным правом, которое можно полностью отключить для роли.
Вот как я обычно распределяю права на старте проекта.
| Действие | Менеджер | РОП | Администратор |
|---|---|---|---|
| Просмотр своих сделок | Да | Да | Да |
| Просмотр сделок отдела | Нет | Да | Да |
| Просмотр всех сделок компании | Нет | Нет | Да |
| Редактирование чужих сделок | Нет | Да, в своём отделе | Да |
| Удаление сделок и контактов | Нет | Нет | Да |
| Экспорт базы в CSV или Excel | Нет | По согласованию | Да |
| Доступ к отчётам по отделу | Только личная | По отделу | Полный |
РОПу я почти никогда не даю право безусловного экспорта, даже если формально он старший в отделе. Право выгрузки базы стоит привязывать не к должности, а к конкретной задаче: настроить рассылку, передать список в бухгалтерию, сделать сверку с 1С. В остальное время экспорт закрыт для всех, кроме администратора.
Что видит менеджер по чужим сделкам и контактам
Отдельная тема, которую часто упускают, это не сделки, а карточки контактов и компаний. Даже если менеджер не видит чужую сделку в общем списке, он может найти контакт клиента через поиск и открыть его карточку, если права настроены только на уровне сделок, а не на уровне контактов. И в Bitrix24, и в amoCRM права нужно выставлять отдельно на сделки, отдельно на контакты и отдельно на компании, потому что это разные сущности со своей матрицей доступа.
Второй момент - поля внутри карточки. Телефон, email, реквизиты компании, историю платежей можно скрыть даже от менеджера, у которого есть доступ к самой карточке. В Bitrix24 это делается через настройку прав на уровне полей для конкретной роли. Полезно, когда с клиентом работает один менеджер, а звонки принимает дежурный оператор, которому не обязательно видеть платёжные реквизиты. В amoCRM тонких настроек по отдельным полям меньше, чем в Bitrix24, поэтому там обычно ограничивают доступ на уровне всей карточки целиком.
Третий момент - история изменений. В обеих системах есть журнал событий по карточке: кто и когда поменял стадию сделки, кто удалил контакт, кто выгружал данные. Я всегда советую клиентам заглядывать в этот журнал хотя бы раз в квартал, а не только когда уже случилась пропажа клиентов.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Экспорт базы: главная дыра, через которую уходит клиентская база
Из всех прав именно право на экспорт стоит закрывать первым и восстанавливать последним. Просмотр чужой сделки неприятен, но не критичен: украсть базу одним взглядом на экран нельзя. А выгрузка в CSV или Excel уходит на флешку или в личную почту за считаные секунды.
Практика, которая у меня отработана на нескольких проектах: право экспорта есть только у администратора аккаунта. Если менеджеру или РОПу нужно выгрузить список для рассылки или сверки, они формируют фильтр и присылают запрос, а выгружает уже человек с полным доступом. Да, это на пару минут дольше, чем выгрузить самому. Но именно эти лишние минуты и есть цена, за которую база остаётся у компании, а не переезжает вместе с уволившимся сотрудником.
Второй слой защиты - ограничение объёма выгрузки за один раз. В большинстве CRM лимит на такие операции проще закрыть регламентом, а не настройками интерфейса: любая выгрузка больше определённого объёма согласуется отдельно, а не делается по факту нажатия кнопки.
Третий момент, который часто забывают: доступ к резервным копиям и выгрузкам, которые CRM формирует автоматически для интеграций. Если у компании настроена синхронизация с 1С или таблицей для бухгалтерии, эта выгрузка обычно лежит в общей папке на диске, доступной куда большему числу людей, чем сама CRM. Стоит проверить, кто на самом деле имеет доступ к этим файлам, а не только к интерфейсу CRM.
Интеграции, боты и API-ключи: скрытые лазейки в доступе
Права, настроенные аккуратно внутри интерфейса CRM, ничего не значат, если рядом висит забытая интеграция с полным доступом к аккаунту. Я регулярно нахожу у клиентов старые API-ключи от сценариев в n8n или самописных скриптов, которые в своё время настраивал ушедший подрядчик, и эти ключи по-прежнему имеют права администратора, хотя автор скрипта давно не работает в компании.
Типичные точки утечки:
- Telegram-бот на aiogram, который шлёт менеджерам уведомления о новых лидах: если бот дёргает CRM по ключу с полным доступом, а токен бота лежит в коде на GitHub или в переписке, доступ к базе получает любой, кто найдёт токен
- Сценарий в n8n, синхронизирующий заявки с сайта на Tilda с CRM через вебхук: ключ интеграции обычно один на всю цепочку и не привязан к роли конкретного сотрудника
- Формы на сайте, которые пишут заявки напрямую в CRM через API: если ключ статичный и нигде не меняется, он живёт годами и попадает в старые бэкапы кода
Правило, которое я применяю: у каждой интеграции свой отдельный API-ключ с минимально необходимым набором прав, а не общий ключ администратора «чтобы не разбираться». Если сценарий в n8n должен только создавать новые лиды, у его ключа не должно быть прав на экспорт или удаление. Отдельно стоит хотя бы раз в полгода смотреть список активных интеграций в настройках CRM и отключать те, которыми никто не пользуется.
Как настроить права один раз и не переделывать через полгода
Права, которые настроили один раз и забыли, живут ровно до первого нового отдела, нового филиала или ухода ключевого сотрудника. Чтобы не переделывать матрицу заново каждый раз, я закладываю несколько принципов сразу.
- Права назначаются на роль, а не на конкретного человека. Уволился менеджер - его логин просто отключается, а не разбирается вручную, что у него было можно, а что нет
- Новый сотрудник получает права через готовую роль, а не копированием прав коллеги. Копирование почти всегда тянет за собой лишние разрешения, которые никто потом не проверяет
- Раз в квартал кто-то один, обычно РОП или администратор, проходит по списку ролей и сверяет, не накопились ли лишние права у отделов, которые расширились или сократились
- Список активных интеграций и API-ключей хранится отдельно от общей документации по CRM, потому что про него забывают в первую очередь
Если встроенных ролей CRM объективно не хватает, например нужно показывать разным франчайзи только их часть базы или скрывать финансовые показатели по нестандартной логике, проще не выкручивать это через десяток пользовательских полей, а вынести часть логики в отдельную кастомную CRM-панель на React поверх основной базы, где права описываются кодом, а не набором чекбоксов в настройках. Это оправдано именно тогда, когда стандартной матрицы ролей не хватает под структуру бизнеса, а не как замена настройке штатных прав.
Частые вопросы
Можно ли скрыть от менеджера телефон клиента, но оставить доступ к остальной карточке?
Да, в Bitrix24 такие ограничения настраиваются на уровне полей для конкретной роли: карточка сделки остаётся видимой целиком, а конкретное поле, например телефон или реквизиты компании, показывается только определённым ролям. В amoCRM гибкости по отдельным полям меньше, там проще ограничить доступ на уровне всей карточки контакта.
Как понять, что менеджер перед увольнением выгрузил базу?
Проверяю журнал событий CRM за последние недели перед увольнением: там видны факты экспорта, если это право у сотрудника вообще было. Если права были закрыты заранее, как я советую выше, вопрос снимается сам собой, выгружать нечего физически. Дополнительно стоит посмотреть логи интеграций: иногда выгрузка происходит не через кнопку в интерфейсе, а через забытый API-ключ.
Стоит ли давать РОПу право экспорта всей базы?
На практике почти никогда не даю его безусловно. РОПу нужен доступ к отчётам и сделкам всего отдела, но не обязательно право выгружать контакты в файл. Если экспорт действительно нужен регулярно, например для еженедельной сверки с бухгалтерией, лучше выделить это отдельным правом на конкретное действие, а не включать в общий пакет «руководитель».
Что делать, если несколько менеджеров годами работают под одним общим логином?
Разделять логины в первую очередь, до любой настройки прав. Общий аккаунт означает, что после ухода одного из сотрудников всё равно приходится менять пароль всем, а понять, кто именно из группы делал экспорт или удалял сделки, невозможно в принципе: журнал событий покажет одного и того же пользователя вне зависимости от того, кто фактически сидел за компьютером.