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