Права доступа в CRM настраиваются за 12 часов работы инженера, но начинаются не в системе, а на листе бумаги: нужна матрица, где по строкам — роли, по столбцам — что роль видит, что редактирует и что может выгрузить. Пока матрицы нет, любая настройка сводится к спору «а почему мне не видно», и заканчивается он выдачей администраторских прав половине отдела.
Из всего объёма работ два действия дают больше половины эффекта и занимают около 20 минут: включить журнал действий пользователей и запретить массовую выгрузку списков. Первое даёт доказательства, второе убирает самый быстрый способ унести базу. Остальные шаги — про аккуратность и удобство, и их можно делать постепенно.
Ниже — порядок для модельной компании: 40 человек, из них 12 менеджеров продаж, база 6 400 контактов, около 1 200 активных клиентов. Ставки в расчётах: инженер — 3 000 ₽/час, полный час рядового сотрудника — 700 ₽. Про то, во что обходится сама утечка и какие каналы кроме выгрузки существуют, мы писали отдельно в разборе пяти каналов утечки клиентской базы; здесь — только процедура настройки.
Что подготовить до первой настройки
Настройка встаёт не на технике, а на нерешённых вопросах. Три из них решаются только руководителем, и лучше решить их заранее.
- Ответ на вопрос, кто владелец клиентской базы — компания или менеджер. Пока он не проговорён вслух, любое ограничение видимости читается отделом как недоверие. Это разговор на десять минут, но без него настройку саботируют.
- Список ролей по факту, а не по штатному расписанию. Роль — это набор прав, а не должность: два менеджера с одинаковой должностью могут работать по-разному, и тогда ролей две.
- Перечень интеграций и служебных учётных записей: телефония, почта, сайт, обмен с учётной системой. Каждая где-то ходит под чьим-то логином, и после смены прав половина из них отвалится, если не разобраться заранее.
- Права администратора системы у того, кто настраивает, и договорённость, что администраторов будет двое: основной и запасной. Один — это единая точка отказа в отпуске.
- Регламент увольнения хотя бы в виде списка из шести пунктов. Настроить права и не закрыть день увольнения — значит сделать половину работы.
Матрица ролей: один лист, который решает всё
Матрица заполняется до входа в систему. Правило заполнения простое: по умолчанию в клетке стоит «нет», и каждое «да» кто-то должен обосновать процессом. Это ровно принцип минимальных прав, применённый к одной таблице.
| Роль | Какие сделки видит | Что редактирует | Выгрузка |
|---|---|---|---|
| Менеджер | Свои и общий поток нераспределённых | Свои сделки: сумма, этап, комментарии; контакт может добавить, но не изменить | Печать одной карточки; экспорт списков запрещён |
| Руководитель группы | Все сделки своей группы | Всё в группе, включая смену ответственного | До 100 строк, каждая выгрузка попадает в журнал |
| Маркетолог | Обезличенный срез: источник, сумма, этап, дата | Ничего | Экспорт без телефонов и адресов почты |
| Бухгалтер | Только закрытые сделки с суммами и реквизитами | Поля оплаты и документов | Реестр оплат |
| Руководитель компании | Все | Все | Полная выгрузка с уведомлением второму администратору |
| Служебная учётная запись интеграции | Только объекты, которые трогает обмен | Только свои поля обмена | По API, с ограничением по объёму за сутки |
| Администратор системы | Все | Все, включая настройки и роли | Полная; изменение ролей пишется в журнал |
Обмены и телефония почти всегда настраивают «под живым человеком», потому что так быстрее. В день, когда этот человек увольняется и его учётную запись отключают, встают обмен с учётной системой, всплывающая карточка звонка и выгрузка заявок с сайта — одновременно и без внятного сообщения об ошибке. Служебная учётная запись под каждую интеграцию снимает весь этот класс аварий.
Таблица-матрица из семи строк и четырёх столбцов в чертёжном стиле. Строки: менеджер, руководитель группы, маркетолог, бухгалтер, руководитель компании, служебная учётная запись интеграции, администратор системы. Столбцы: «видит сделки», «редактирует», «выгружает», «меняет настройки». Клетки заполнены отметками разного веса: пусто, частично, полностью. Отдельно выделены две клетки с подписями «до 100 строк, пишется в журнал» и «экспорт без телефонов». Внизу подпись: «по умолчанию — нет».
Шесть шагов настройки
- 1Шаг 1. Завести роли и назначить по одной на человека
Роли создаются по матрице, каждому сотруднику назначается ровно одна. Получилось, если в списке пользователей нет ни одного человека с двумя ролями и ни одного администратора «на всякий случай». Права двух ролей у большинства систем складываются, а не пересекаются: вторая роль молча возвращает то, что убрала первая.
- 2Шаг 2. Ограничить видимость чужих сделок
Менеджеру оставляем свои сделки и общий поток нераспределённых. Получилось, если вы зашли под учётной записью самого менеджера (не под администратором) и в списке сделок видите только его. Проверка из-под администратора показывает картину, которой не существует, — это самая частая ошибка приёмки.
- 3Шаг 3. Закрыть контакты от копирования из списков
Телефон и почта маскируются в списках и отчётах, полностью видны только в карточке своей сделки. Получилось, если в общем списке вместо номера отображается маска вида «+7 (9xx) xxx-xx-14», а в своей сделке — полный номер. Так менеджер работает как работал, но выгрузить 6 400 номеров глазами нельзя.
- 4Шаг 4. Запретить массовый экспорт и оставить одно исключение
Экспорт списков закрывается для всех, кроме двух ролей, и для них — с лимитом. Получилось, если попытка выгрузить список из-под менеджера возвращает отказ, а разрешённая выгрузка руководителя группы появляется в журнале строкой с именем, временем и числом строк.
- 5Шаг 5. Включить журнал действий
Журнал фиксирует просмотры карточек, экспорт, печать, изменение ролей и вход в систему. Получилось, если вы сделали тестовую выгрузку и через минуту нашли её в журнале. Если журнал есть, но пуст — он включён не на те события; проверьте, пишутся ли просмотры, а не только правки.
- 6Шаг 6. Настроить три еженедельных письма
Три коротких списка на почту руководителю: кто массово просматривал чужие карточки, кто выгружал, у кого менялись права. Получилось, если через неделю письма пришли и в них есть строки. Пустые письма тоже результат: значит, сигнализация работает и событий не было.
Ориентир для сравнения. В модельной компании 1 200 активных клиентов на 12 менеджеров — портфель одного человека около 100 клиентов. Если привлечение одного клиента обходится компании в 3 200 ₽, повторный набор такого портфеля стоит 320 000 ₽. Настройка прав — 38 800 ₽, то есть примерно 12 % стоимости одного портфеля. Это не гарантия от ухода менеджера с базой, но это разница между «мы подозреваем» и «у нас есть журнал с датами и числом строк».
Журнал: что смотреть раз в неделю
Журнал бесполезен, пока в него не смотрят. Полчаса в неделю достаточно, если смотреть не всё подряд, а три среза. Признаки подготовки к уводу базы почти всегда выглядят одинаково.
- 1Массовый просмотр чужих карточек. Сотрудник за день открыл 200 карточек, из которых 180 не его. Один такой день — повод спросить; три подряд — повод смотреть внимательно.
- 2Экспорт и печать в нерабочее время. Выгрузка в субботу в 23:40 отличается от выгрузки во вторник днём не объёмом, а намерением. Здесь важен сам факт, а не размер файла.
- 3Изменение прав и появление новых администраторов. Любая строка «роль изменена» должна совпадать с чьей-то заявкой. Не совпала — разбираемся в тот же день.
Если журнал лежит внутри той же системы и администратор может его очистить, доказательной силы у него немного. Практическое решение — выгружать журнал во внешнее хранилище хотя бы раз в сутки, тем же контуром, которым вы настраивали резервное копирование. И отдельно: журнал действий пользователей — это тоже персональные данные сотрудников, о его ведении и сроке хранения людей надо уведомить, а не ставить перед фактом.
День увольнения: шесть действий за час
- 1Отключить учётную запись, но не удалять. Удаление обезличивает историю сделок и журнал: комментарии превращаются в записи от «пользователь удалён», и доказательства исчезают вместе с человеком.
- 2Завершить активные сессии и отвязать мобильное приложение. Отключённая учётная запись с живой сессией в телефоне остаётся рабочей до перезахода.
- 3Переназначить ответственного по открытым сделкам и сохранить список на дату — он понадобится, если через месяц клиенты начнут уходить.
- 4Сменить пароли служебных и общих учётных записей, которые сотрудник знал: почтовый ящик отдела, кабинет площадки, доступ к телефонии.
- 5Просмотреть журнал за 30 дней до заявления об увольнении — по трём срезам выше. Это единственный момент, когда журнал читают целенаправленно.
- 6Убрать из рассылок, групповых чатов и списков получателей отчётов. Это же касается подрядчиков: забытые учётные записи живут в системах годами.
Что пойдёт не так: шесть поломок и что они значат
| Что видите | Что это значит | Что делать |
|---|---|---|
| «Недостаточно прав для выполнения операции» у менеджера при обычной работе | Роль урезана глубже процесса: закрыто поле, которое сотрудник обязан заполнять | Свериться с матрицей и вернуть конкретное право, а не выдавать роль администратора |
| После настройки встали обмен и всплывающая карточка звонка | Интеграция ходила под учётной записью человека, а не служебной | Завести служебную учётную запись под каждую интеграцию с доступом только к нужным объектам |
| Менеджер по-прежнему видит чужие сделки | Проверяли из-под администратора либо у сотрудника две роли и права сложились | Проверять под его учётной записью и убедиться, что роль ровно одна |
| Отчёты руководителя опустели после смены ролей | Отчёт строится от имени открывающего, а у роли нет доступа к чужим сделкам | Строить отчёты на служебной учётной записи или вынести их в отдельную роль |
| Экспорт запрещён, но база всё равно уходит | Копирование по одной карточке, печать в PDF, скриншоты, пересылка на личную почту | Техникой не закрывается: остаются журнал, лимит просмотров в день и юридический контур |
| «Пользователь не найден», история сделок обезличилась | Учётную запись уволенного удалили вместо отключения | Восстанавливать из резервной копии; на будущее — только отключение |
Где без инженера дальше не пройти
Матрица, назначение ролей, включение журнала и еженедельные письма — работа руководителя и грамотного сотрудника. Четыре вещи требуют инженера, и попытка обойтись без него обычно кончается либо дырой, либо вставшей работой.
- Маскирование контактов в списках и отчётах. В большинстве систем это не галочка, а настройка на уровне объекта или доработка представлений. Сделанное наполовину маскирование даёт ложное спокойствие: в списке номер скрыт, а в выгрузке отчёта — нет.
- Перевод интеграций на служебные учётные записи с минимальным набором объектов. Здесь надо понимать, что именно трогает каждый обмен, иначе служебная учётка получает права администратора и смысл теряется.
- Вынос журнала во внешнее хранилище так, чтобы его не мог почистить администратор системы.
- Права в смежных системах. CRM закрыта, а записи разговоров лежат в открытой папке телефонии, сканы договоров — в общем облаке, а выгрузки — в почтовом ящике отдела. Разграничение имеет смысл только по всему контуру сразу.
Карта связей из пяти узлов вокруг центрального блока «Клиентские данные». Узлы: «CRM — роли настроены», «Телефония — записи разговоров», «Общая почта отдела», «Файловое хранилище со сканами договоров», «Выгрузки и отчёты». У первого узла отметка «закрыто», у остальных четырёх — отметка «часто открыто всем». На стрелках подписи, что именно уходит: телефон, имя, сумма сделки, запись разговора. Внизу подпись: «разграничение имеет смысл по всему контуру сразу».
Когда жёсткие права мешают
Ограничения стоят не только денег на настройку. Они стоят скорости: каждое «не вижу» превращается в заявку, а каждая заявка — в час чужого времени. Есть три ситуации, где полную схему разворачивать не надо.
- Команда из трёх-четырёх человек, где все ведут всех. Закрывать видимость дороже риска: заявок на доступ будет больше, чем клиентов. Рабочий минимум здесь — те самые 20 минут: журнал плюс запрет массового экспорта, около 6 000 ₽ работы.
- Сервисная модель, где клиента обслуживает первый свободный. Жёсткая привязка сделки к ответственному ломает сам процесс. Тогда ограничивают не видимость, а выгрузку и редактирование контактов.
- Сезонный пик с ежедневными подменами. В горячий месяц ограничения снимают по заранее описанному правилу и возвращают после — а не героически раздают администраторские права и забывают их отобрать.
Общее правило для всех трёх случаев: доступ расширяется на срок и по заявке, а не навсегда и не устно. Заявка с датой окончания — единственный механизм, который сам возвращает систему в исходное состояние. Без неё через год у половины отдела права руководителя, и никто не помнит почему.
Права проверяются под учётной записью сотрудника. Из-под администратора видно всё — и потому не видно ничего.
