Малому бизнесу полезно регулярно проверять, кто имеет доступ к CRM, корпоративной почте, рекламным кабинетам, телефонии и каналам общения с клиентами. Такая ревизия помогает убрать лишние учётные записи, закрыть доступ бывшим сотрудникам и подрядчикам, а также понять, кто может менять настройки или выгружать данные. В статье — практический чек-лист: как составить список сервисов, проверить роли, обновить пароли и закрепить понятный порядок выдачи доступов.
Почему доступы начинают работать против компании?
В небольшой компании доступы часто выдаются по ситуации. Новому менеджеру отправляют пароль в чате, подрядчику дают учётную запись владельца, а после завершения проекта никто не вспоминает отключить пользователя. Через несколько месяцев трудно установить, кто менял воронку CRM, запускал рассылку или редактировал рекламную кампанию.
Проблема появляется и при разрозненной работе каналов. Заявки приходят с сайта, из телефонии, социальных сетей и мессенджеров, а сотрудники получают права в каждом сервисе отдельно. При этом один человек может видеть только обращения клиентов, а другой получает доступ к настройкам интеграции и массовым действиям. Чем больше сервисов подключено к CRM, тем важнее вести единый список доступов.
Интеграция CRM с сайтом, рекламными кабинетами и другими системами обычно использует отдельные ключи или токены. Если их хранит бывший подрядчик или сотрудник, компания не всегда замечает это сразу. Отдельно полезно проверить API-доступы и порядок их замены: как не сломать интеграцию сайта с CRM из-за токена API.
С чего начать ревизию доступов?
Начните с таблицы. Для каждой системы заведите отдельную строку и укажите владельца, пользователей, уровень доступа, способ входа и дату последней проверки. В список обычно попадают:
- CRM и связанные с ней сервисы автоматизации;
- корпоративная почта и облачное хранилище;
- сайт, домен, хостинг и панель управления;
- телефония и записи разговоров;
- каналы переписки с клиентами;
- сервисы SMS- и email-коммуникаций;
- рекламные кабинеты и веб-аналитика;
- конструкторы форм, интеграции и сервисы отчётности.
Затем соберите второй список, уже по людям. В нём должны быть сотрудники, руководители, бухгалтер, внешний маркетолог, разработчик и любой подрядчик, который когда-либо получал доступ. Напротив каждого имени укажите, зачем человеку нужен сервис сейчас. Формулировка «доступ был выдан раньше» для ревизии не подходит.
| Что проверить | Какой вопрос задать | Что сделать по итогам |
|---|---|---|
| Учётная запись | Человек всё ещё работает с этим сервисом? | Оставить, изменить или отключить доступ |
| Роль | Нужны ли пользователю права администратора? | Оставить минимальный набор разрешений |
| Общий пароль | Кто ещё знает пароль и где он хранится? | Заменить пароль и перейти на персональные аккаунты |
| Интеграция | Кто владеет токеном и может его отозвать? | Зафиксировать владельца и порядок замены ключа |
| Подрядчик | Есть ли дата окончания работ? | Поставить срок отключения доступа |
Как распределить роли в CRM и каналах коммуникации?
Роль нужно назначать по рабочей задаче, а не по должности. Менеджеру продаж обычно требуется работа со своими лидами и сделками. Руководителю нужна отчётность и контроль воронки. Администратору приходится менять поля, права, интеграции и настройки автоматизации. Эти уровни нельзя смешивать без причины.
Удобно разделить права на четыре группы:
- Просмотр — пользователь видит карточки, отчёты или историю общения, но не меняет настройки.
- Работа с клиентами — сотрудник создаёт контакты, обрабатывает заявки и меняет стадии сделки.
- Редактирование процессов — специалист настраивает воронки, шаблоны, автоматические действия и интеграции.
- Администрирование — владелец управляет пользователями, оплатой, безопасностью и восстановлением доступа.
Один человек может совмещать несколько функций, особенно в микробизнесе. Но даже тогда лучше сохранить личную учётную запись и выдать ей нужные права. Общий логин мешает понять, кто изменил карточку клиента или отключил автоматическое сообщение.
Для каналов общения действует тот же принцип. Сотруднику, который отвечает на сообщения, не нужен доступ к настройкам подключения канала. Подрядчику, который настраивает CRM, не обязательно разрешать просмотр всей переписки. Если обращения из разных каналов собираются в одном интерфейсе, заранее задайте правила маршрутизации и видимости диалогов. С практической стороны это связано с задачей настроить маршрутизацию чатов WhatsApp и Telegram в CRM.
Как проверить пароли и двухфакторную защиту?
Ревизия доступа не заканчивается заменой одного общего пароля. Для каждого сервиса проверьте, есть ли персональные аккаунты, включена ли многофакторная аутентификация и кто получает коды восстановления. Резервные коды нельзя оставлять в открытом файле или пересылать в общий чат.
Пароли от ключевых систем храните в менеджере паролей с отдельными правами для владельца и сотрудников. Не отправляйте их в переписке, где сообщение легко переслать. Если компания использует общий ящик, проверьте не только пароль, но и активные сессии, правила переадресации и подключённые приложения.
При уходе сотрудника сначала заблокируйте его учётную запись, затем отзовите сессии, API-ключи и доступ к связанным сервисам. После этого смените общие пароли, если они всё же использовались. Подробный порядок настройки многофакторной защиты и ролей можно сверить в материале как настроить MFA и доступы в облаке для малого бизнеса.
Как оформить порядок выдачи доступов?
После проверки закрепите простой внутренний регламент на одной странице. В нём достаточно описать, кто выдаёт доступ, какие сведения нужны для заявки, когда проверяют права и кто отключает учётную запись. Для каждого подрядчика добавьте дату начала и дату окончания работ.
Полезный порядок выглядит так:
- Руководитель или владелец сервиса подтверждает необходимость доступа.
- Ответственный создаёт персональную учётную запись и назначает минимальную роль.
- Сотрудник включает многофакторную защиту и подтверждает вход.
- Ответственный заносит сервис, роль и срок доступа в реестр.
- После завершения проекта права закрывают, а ключи интеграции при необходимости отзывают.
Проверку можно проводить по расписанию, например после изменения состава команды, смены подрядчика или подключения нового канала. Внеплановая ревизия нужна после подозрительного входа, потери устройства или ошибки в интеграции. Если CRM связана с несколькими каналами, удобно отдельно проверить, какие заявки видит каждый сотрудник и кто может отправлять сообщения от имени компании.
Какие ошибки встречаются чаще всего?
- Один логин используют несколько менеджеров, поэтому в журнале действий нельзя определить исполнителя.
- Всем сотрудникам выдают права администратора, хотя для работы с заявками достаточно обычной роли.
- Бывшему подрядчику закрывают доступ в CRM, но забывают про почту, рекламный кабинет или интеграционный токен.
- Пароли передают через общий чат, а резервные коды хранят в таблице без ограничений.
- Доступ выдают без срока окончания и не заносят его в реестр.
- После настройки нового канала никто не проверяет, какие сотрудники видят переписку и могут запускать массовые отправки.
Для каналов коммуникации полезно дополнительно разделять право отвечать клиенту и право менять настройки отправки. Это снижает вероятность случайного запуска не той кампании и упрощает разбор спорной ситуации. Если заявки уже теряются между сайтом, чатами и CRM, сначала проверьте не только саму интеграцию, но и права пользователей: как не терять заявки между сайтом, чатами и CRM.
3 шага, которые можно сделать на этой неделе:
- Составьте список CRM, почты, телефонии, каналов общения, рекламы и интеграций.
- Сверьте каждого пользователя с его задачей, уберите лишние права и отключите старые аккаунты.
- Создайте реестр доступов с владельцем, ролью, датой выдачи и сроком следующей проверки.
Если сервисов стало больше, чем может контролировать один сотрудник, ревизию удобно оформить как отдельный проект: сначала описать схему коммуникаций, затем настроить роли и только после этого менять интеграции. Такой порядок помогает связать маркетинг, клиентские коммуникации и цифровую автоматизацию без ручного поиска владельца каждого пароля.
