Чек-лист безопасности клиентской базы: 12 пунктов
Клиентская база в безопасности тогда, когда каждое из двенадцати утверждений ниже проверяется действием и оказывается верным. Не «в компании принято», не «сотрудники знают», а проверяется: кто-то выполняет конкретное действие и видит конкретный результат. Всё остальное — намерение.
Этот текст устроен как справочник, к которому возвращаются: двенадцать пунктов, у каждого своя проверка, свой признак выполнения и своя частота пересмотра. Если нужна не постоянная проверка, а одна разовая диагностика с оценкой масштаба — есть аудит из десяти вопросов и получасовая процедура, которая показывает состояние базы за один присест. Чек-лист ниже — про то, что проверяют потом, каждый квартал.
Как пользоваться списком
Каждый пункт сформулирован как утверждение, которое либо верно, либо нет. Проверять их надо в порядке, в котором они идут: первые три отвечают на вопрос, где вообще живёт переписка, и без ответа на него остальные девять проверяются на неполном списке каналов.
Ответ «частично» не засчитывается. На практике он почти всегда означает «выполнено там, где и так никогда не было проблем». Записывайте невыполненный пункт как невыполненный, с пометкой, какая часть закрыта — эта пометка полезнее галочки.
Блок 1. Где живёт переписка
1. Существует письменный список всех точек входа, через которые клиент связывается с компанией. Не только очевидные каналы, но и те, о которых обычно забывают: форма на сайте, чат на маркетплейсе, комментарии под постами, рабочая почта, личные номера сотрудников. Проверка: попросите двух разных сотрудников назвать все способы, которыми им пишут клиенты, и сравните с вашим списком. Расхождение — и есть цена этого пункта. Личные номера в списке не нарушение, а исходное состояние.
2. По каждой точке входа известно, на кого она оформлена и кто может восстановить к ней доступ. Проверка на бумаге не работает — нужен ответ на вопрос «кто получит письмо о восстановлении пароля». Пункт выполнен, когда напротив каждой строки списка стоит имя и способ восстановления, а не «вроде на компанию».
3. Клиентская переписка компании доступна из одного места, а не собирается по кусочкам. Проверка: выберите клиента, который писал в два разных канала, и попробуйте увидеть оба разговора не переключаясь между устройствами и не спрашивая никого. Пункт про удобство только на первый взгляд: рассыпанная по каналам переписка не проверяется дальше нигде, потому что проверяющий не знает, всё ли он увидел.
Блок 2. Доступ
4. Переписку с любым клиентом можно открыть, не обращаясь к менеджеру, который её ведёт. Самая быстрая проверка во всём списке — минута. Открылось — доступ есть. Пришлось написать сотруднику «скинь скрины» — доступа нет, есть его добровольное согласие, которое действует ровно до дня, когда отношения испортятся.
5. Доступ выдаётся ролью, а не персональной договорённостью. Признак выполнения: при замене сотрудника на той же должности никто не переписывает список разрешений — новый человек получает роль. Признак невыполнения: в компании помнят, «кому что открыли», и этот факт хранится только в чьей-то голове или в переписке с администратором.
6. Доступ отзывается за один рабочий день и отзыв не ждёт истечения срока пароля. Проверка: отключите тестовую или уже не используемую учётную запись и попробуйте открыть рабочее окно в браузере, где она была залогинена. Если сессия продолжает работать — механизма отзыва у вас нет, есть смена пароля, которая на открытую сессию не действует.
7. Доступы пересматриваются по календарю, а не по случаю. Пункт выполнен, когда есть дата следующего пересмотра и ответственный за него человек. Смотрят при пересмотре в первую очередь на разрешения, выданные под разовую задачу и с тех пор никем не снятые, — они и составляют основную часть находок.
Блок 3. Следы и сохранность
8. Восстанавливается, кто и когда обращался к клиентским данным. Проверка: возьмите любое действие за прошлую неделю и попробуйте узнать, кто его совершил и с какого адреса. Смысл пункта не в предотвращении: следы не мешают выгрузить базу, зато переводят подозрение в разряд проверяемого — и заметно меняют поведение тех, кто про них знает.
9. История переписки переживает уход человека и смену его устройства. Проверка мысленная, но строгая: сотрудник сегодня перестал выходить на связь, а телефон утопил. Что из переписки с его клиентами останется у компании? То, что останется, хранится у компании. Остальное хранится у сотрудника, независимо от того, что написано в регламенте. Механика потерь разобрана отдельно: как не потерять историю общения.
10. Договорённости с клиентом зафиксированы вне личной памяти сотрудника. Этап, условия, обещанные сроки, снятые возражения. Проверка: выберите три активные сделки и попробуйте по записям понять, что клиенту обещано и когда. Если для ответа нужно спросить менеджера — пункт не выполнен, и потеря здесь дороже потери списка контактов: список восстанавливается по счетам, контекст не восстанавливается ничем.
Блок 4. Люди и правила
11. Есть письменный порядок действий на случай ухода сотрудника с доступом к базе. С фамилиями ответственных и сроками, а не «отзовём доступы». Проверка: покажите документ человеку, который в нём назван ответственным, и спросите, знал ли он об этом. Порядок действий на ту часть, которая происходит до последнего дня, разобран отдельно: что делать перед увольнением менеджера.
12. Правовая часть задана юристу, а не выведена из статей в интернете. Какие согласия нужны, что оформлено как коммерческая тайна, что можно требовать от бывшего сотрудника, какие обязанности у компании как оператора персональных данных. Пункт выполнен, когда на эти вопросы есть ответы от юриста, который смотрел ваши документы. Где здесь граница между операционной и правовой частью — разобрано в тексте о защите данных клиентов и 152-ФЗ; общие тексты в интернете, включая этот, консультацию не заменяют.
Компактный чек-лист
- список всех точек входа существует в письменном виде и совпадает с тем, что называют сотрудники
- по каждой точке входа известен владелец и способ восстановления доступа
- переписка компании доступна из одного места, без сборки по устройствам
- переписку с клиентом можно открыть без участия менеджера, который её ведёт
- доступ выдаётся ролью, а не персональной договорённостью
- отзыв доступа срабатывает в тот же день и завершает открытые сессии
- есть дата следующего пересмотра доступов и ответственный за него
- по любому действию с данными восстанавливается, кто и когда его совершил
- история переписки остаётся у компании при уходе человека и смене устройства
- договорённости по активным сделкам понятны из записей, а не из памяти менеджера
- письменный порядок действий при увольнении существует, и названные в нём люди о нём знают
- правовые вопросы заданы юристу, а не выведены из общих текстов
Что чек-лист не проверяет
Честная граница списка важнее его полноты.
Он не проверяет мотивы. Сотрудник уходит к конкуренту не потому, что ему выдали лишний доступ; двенадцать выполненных пунктов меняют объём последствий, а не вероятность события.
Он не защищает от памяти и блокнота. Ни одна настройка не мешает человеку выписать двадцать ключевых контактов или помнить их наизусть. Список защищает от другой ситуации: когда после ухода человека у компании не остаётся никакого следа отношений с клиентом — ни записанного контекста, ни доступа к каналу, в котором этот контекст обсуждался.
Он не оценивает качество работы с клиентом. Все двенадцать пунктов могут быть закрыты в компании, где менеджеры отвечают через сутки и теряют сделки. Это отдельная задача, и устроена она как процесс просмотра диалогов: контроль переписок.
И он не даёт правовой оценки — ни одному из двенадцати пунктов. Пункт 12 существует именно для того, чтобы не путать выполненную проверку с выполненной обязанностью.
Что из этого закрывается инструментом
Инструмент закрывает часть пунктов блоков 2 и 3, и не закрывает ни одного из блоков 1 и 4 — там решения принимает компания. Из проверяемых свойств LTVchat для этого списка существенны:
- пункты 3 и 4 — клиентские сообщения из подключённых мессенджеров попадают в общее рабочее окно, и история открывается вместе с карточкой клиента; сюда же относится сведение диалогов одного клиента из разных каналов в одну карточку с возможностью развести их обратно;
- пункт 5 — доступ выдаётся одной из четырёх ролей: менеджер, администратор, владелец, супер-администратор. Роль проверяет сервер при обработке запроса, а не интерфейс, поэтому скрытая кнопка — не единственное, что отделяет менеджера от административного действия;
- пункт 6 — учётная запись отключается, а сессия отзывается отдельным действием, причём история переписки при этом никуда не пропадает: доступ теряет человек, а не компания;
- пункт 8 — по каждому действию остаётся запись: событие, объект, роль исполнителя, IP-адрес, время, привязка к рабочему пространству;
- сквозное условие — данные принадлежат рабочему пространству компании, обращение к чужому пространству отклоняется, и эта проверка идёт отдельно от проверки роли.
Чего сервис не делает: не составляет за компанию список точек входа, не решает, кому выдать роль, не назначает дату пересмотра доступов и не пишет регламент увольнения. Ни один пункт блока 4 он тоже не закрывает. Сертификаций, аттестаций и аудитов третьих сторон у сервиса нет — подробности реализации на странице безопасности.
Считается это так: 300 ₽/канал в месяц + 50 ₽/сотрудник в месяц, причём владельцы подключённых каналов сотрудниками не считаются. Как это выглядит в работе — видно в демо без регистрации. Если пунктов невыполненных много и непонятно, за что браться первым, — план возврата контроля над продажами в мессенджерах задаёт порядок работ; как выстроить доступы с нуля — отдельный текст.
Частые вопросы
Двенадцать пунктов — это много. С какого начинать?
С первого, и не потому, что он первый по важности, а потому, что остальные одиннадцать без него не проверяются. Пока неизвестно, через какие точки клиенты попадают в компанию, любая проверка доступа проверяется на неполном списке дверей. Дальше порядок такой: пункты 1–3 — про то, где переписка живёт, 4–7 — про доступ, 8–10 — про следы и сохранность, 11–12 — про людей и правила.
Как часто проходить весь чек-лист целиком?
Как ориентир — раз в квартал целиком плюс частичный проход в день любого кадрового изменения. Пункты 4–7 (доступы) устаревают быстрее всех: они меняются с каждым приёмом, увольнением и повышением. Пункты 1–3 и 11–12 меняются редко, поэтому их достаточно перечитывать при пересмотре процессов, а не по календарю.
Что считать выполненным пунктом: «частично» тоже засчитывать?
Нет, и это принципиально. Пункт либо проверяется действием и даёт «да», либо не выполнен. «Частично» на практике означает «выполнено для тех каналов, где никогда не бывает проблем», а проблемы приходят через остальные. Полезнее записать пункт как невыполненный с пометкой, какая именно часть закрыта, чем поставить галочку и потерять это знание.
Чем этот чек-лист отличается от аудита из десяти вопросов?
Назначением. Аудит на странице аудита даёт числовую оценку риска по десяти вопросам и нужен один раз, чтобы понять масштаб. Этот чек-лист — постоянный справочник из двенадцати утверждений, к которому возвращаются по календарю; он не считает баллы, а показывает, какие конкретные пункты не закрыты сейчас. Первый отвечает «насколько всё плохо», второй — «что именно чинить».
Нужно ли проходить чек-лист, если в компании два человека?
Да, но с другими выводами. В компании из двух человек пункты про роли и разграничение доступа почти вырождаются, зато пункты 1–3 и 8–10 (точки входа, история, сохранность) становятся критичнее: терять здесь нечего, кроме всего сразу. Практический минимум для маленькой компании — точки входа оформлены на компанию, история доступна обоим, и есть письменный порядок на случай, если один из двоих уйдёт.
Кто в компании должен владеть этим чек-листом?
Тот, кто отвечает за результат отдела продаж и имеет право менять процессы — обычно владелец или руководитель отдела. Отдавать чек-лист в IT целиком не стоит: половина пунктов — не техника, а порядок действий при увольнении и оформление точек контакта. Пункты 8–10 действительно требуют участия того, кто администрирует системы, но решения по остальным принимаются не там.