Как скрыть номера клиентов от сотрудников в Битрикс24 и защитить клиентскую базу

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

За годы работы с Битрикс24 мы много раз получали один и тот же запрос от собственников и руководителей компаний: можно ли сделать так, чтобы сотрудник работал с клиентом, звонил ему, вел сделку, но не видел реальный номер телефона?

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

Мы реализовывали проекты, где контактные данные действительно скрывались от отдельных сотрудников, а звонки продолжали работать. Но после нескольких таких внедрений пришли к более важному выводу: скрыть номер телефона и защитить клиентскую базу - не одна и та же задача.

Поэтому начинать лучше не с разработки, а с вопроса: от какого сценария утечки нужно защититься?

Короткий ответ

В Битрикс24 можно ограничить сотрудникам доступ к элементам CRM, настроить права на экспорт и телефонию и определить, с какими клиентами работает конкретная роль. (helpdesk.bitrix24.ru)

Но с самим телефоном есть особенность. Телефон относится к системным полям CRM. Системное поле можно скрыть из карточки, однако ограничение видимости поля для конкретных сотрудников Битрикс24 описывает для пользовательских полей.

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

Один запрос - три разные задачи

Фраза «скройте номера клиентов» может означать совершенно разные процессы.

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

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

В третьем случае внешний колл-центр должен сделать один звонок, задать несколько вопросов и вернуть результат.

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

Что стоит проверить в Битрикс24 до разработки

Начать стоит с прав CRM. Менеджеру необязательно видеть всю клиентскую базу. Права можно разделять по ролям и ограничивать доступ сотрудника к элементам CRM. (helpdesk.bitrix24.ru)

Следом стоит проверить экспорт. Битрикс24 позволяет отдельно управлять правом на экспорт, а для контактов также используется признак участия в экспорте. (helpdesk.bitrix24.ru). Если сотруднику выгрузка базы не нужна для работы, это право имеет смысл закрыть.

Отдельный слой - телефония. В ней есть собственная ролевая модель: можно управлять возможностью звонить, видеть статистику, слушать записи и работать с настройками телефонии. (helpdesk.bitrix24.ru)

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

Скрыть телефон в карточке и закрыть доступ к номеру - разные вещи

Предположим, мы убрали поле Телефон из карточки. На экране его больше нет. Но для задачи защиты данных этого недостаточно. Нужно понять, получил ли пользователь значение номера через другой интерфейс или технический механизм. Битрикс24 прямо относит Телефон к системным полям CRM. Системные поля существуют в продукте изначально и не удаляются как пользовательские. (helpdesk.bitrix24.ru)

Поэтому есть два разных уровня задачи:
первый - не показывать телефон в конкретном интерфейсе;
второй - не передавать конкретному пользователю само значение контактных данных.

Для защиты клиентской базы второй уровень значительно важнее.

Почему телефон нельзя рассматривать как обычный текст

Телефон в CRM используется не только как значение в карточке. Битрикс24 связывает звонки с CRM: звонки известных клиентов сохраняются в их карточках, а из карточки можно инициировать звонок. В мобильной CRM также предусмотрена возможность связаться с контактом непосредственно из карточки. (helpdesk.bitrix24.ru)

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

Сценарий 1. Менеджер постоянно работает с клиентом

Это наиболее сложный вариант.
Менеджер должен вести сделку, общаться с клиентом, принимать и совершать звонки и пользоваться привычным интерфейсом CRM. При этом собственник хочет скрыть от него контактные данные.

В старых проектах мы реализовывали подобные сценарии на коробочном Битрикс24. Причем задача была не в том, чтобы просто визуально убрать цифры. В демонстрации одного из наших решений сотрудник мог инициировать звонок, но номер не отображался в доступных ему элементах интерфейса. Это работавшая на тот момент кастомная архитектура конкретного проекта. Но ее нельзя автоматически переносить на актуальный Битрикс24 как готовую инструкцию. Сегодня такую задачу нужно заново проектировать под используемую версию продукта, интерфейсы, телефонию и требования клиента.

Сценарий 2. Сотруднику нужно позвонить, но номер ему действительно не нужен

Для отдельных ролей задача выглядит намного естественнее. Например, выездному специалисту нужны адрес, время, комментарии, задача и возможность связаться с клиентом. Сам номер телефона ему при этом может быть не нужен.

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

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

Сценарий 3. Внешнему колл-центру не обязательно давать доступ к CRM

Еще один случай - внешний оператор или подрядчик. Допустим, ему нужно позвонить клиенту, провести короткую квалификацию, заполнить несколько полей и сохранить результат. Для этого ему необязательно работать непосредственно с полной карточкой клиента в Битрикс24.

В одном из наших старых сценариев Битрикс24 оставался основной системой с клиентскими данными и задачами, а оператор работал через специализированную платформу обзвона. Он получал только необходимую информацию, после чего результат возвращался обратно в Битрикс24.

Здесь сама архитектура меняется: вместо того чтобы дать подрядчику CRM и затем скрывать из нее данные, можно вообще не передавать ему то, что не требуется для работы.. Для ограниченных операционных ролей такой подход часто оказывается рациональнее глубокой модификации CRM.

Если задача связана с массовым исходящим обзвоном, отдельно мы разбирали как организовать холодные звонки в Битрикс24.

Почему глубокое скрытие номера становится сложной доработкой

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

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

Обновления тоже становятся частью проекта

Первоначальная разработка - только одна часть стоимости. После обновления платформы может измениться карточка CRM, мобильный интерфейс, телефония или другой связанный механизм. Тогда необходимо проверить, сохранилось ли ограничение и не появился ли номер в новой точке интерфейса.

В наших старых коробочных проектах обновления сначала проверялись на отдельном тестовом контуре и только после проверки переносились на рабочий портал. Похожий принцип безопасного обновления и проверки на отдельной площадке мы разбирали в материале про обновление сервера коробочного Битрикс24. Это важный экономический фактор: появляется не только стоимость создания решения, но и стоимость его дальнейшего сопровождения.

Исторический пример стоимости

В одном из наших старых проектов первоначальная разработка стоила около 250 000 рублей в ценах того времени. Дальнейшее сопровождение при активных изменениях платформы потенциально могло доходить примерно до 100 000 рублей в месяц. Это не текущая цена Лаборатории автоматизации «LOG [IN] OFF» и не оценка любого подобного проекта сегодня. Цифры относятся к конкретному историческому случаю.

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

Почему даже такое решение не дает абсолютной защиты

Предположим, техническая часть работает идеально в рамках спроектированного сценария. Сотрудник не видит телефон в карточке, не получает его при звонке, не может экспортировать базу и работает только со своими клиентами.

Но он продолжает разговаривать с клиентом. Если человек целенаправленно хочет получить контакт, он может спросить номер у самого клиента или зафиксировать его другим способом. Этот риск отмечался и в одном из наших проектов.

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

Как мы сейчас рекомендуем подходить к защите клиентской базы

Логика для нас начинается с принципа минимально необходимого доступа.

Сначала определяется, какие клиенты и данные действительно нужны конкретной роли.
Затем проверяются права CRM, экспорт и коммуникационные инструменты.
После этого рассматривается сам бизнес-процесс: можно ли выездному сотруднику передавать только задачу, оператору - только сценарий звонка, подрядчику - отдельный ограниченный интерфейс.

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

Это позволяет не превращать технически сложную кастомизацию в решение по умолчанию.

Техническая защита не заменяет организационную

Если клиентская база является критическим активом, правила работы с ней должны существовать не только в CRM. Компания определяет, кто получает доступ к конфиденциальной информации, для какой работы он предоставляется и какие действия допустимы.

Для отдельных компаний сюда может входить режим коммерческой тайны и другие юридические меры. Конкретные документы, основания ответственности и кадровые процедуры должен проектировать профильный юрист. Битрикс24 в такой системе является одним из уровней защиты, а не всей системой целиком.

Когда глубокое скрытие контактов может быть оправдано

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

Глубокая доработка также может иметь экономический смысл, если потенциальный ущерб от раскрытия данных существенно выше стоимости создания и сопровождения решения. Но решение лучше принимать после описания модели: роль -> действие -> необходимые данные -> допустимый доступ.

Когда мы бы не начинали с разработки

Если запрос звучит как «мы боимся, что менеджеры заберут базу, поэтому спрячьте у них все телефоны», сначала стоит проверить саму организацию доступа.
Почему сотрудник видит всю базу?
Нужен ли ему экспорт?
Должен ли он видеть клиентов других менеджеров?
Какие данные передаются подрядчикам?
Можно ли разделить процесс так, чтобы конкретная роль вообще не получала лишнюю информацию?

После такого разбора объем разработки часто сокращается. Иногда она становится не нужна вовсе.

Наши видео с реализованными сценариями

В этих видео показаны исторические реализации похожих задач:

Их полезно смотреть как демонстрацию конкретных рабочих сценариев и инженерного подхода. Но это не инструкция для буквального повторения на любой актуальной версии Битрикс24.

Вывод

Скрытие телефона - техническая мера.
Защита клиентской базы - система мер.

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

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

Поэтому первый вопрос должен быть
не: «Как спрятать номер?»
А: «От какого сценария утечки мы защищаемся и какие данные нужны каждой роли для работы?»

После этого можно проверить штатные права Битрикс24, экспорт, телефонию, архитектуру процесса и только затем принимать решение о кастомной разработке.