Кейс 05

Ключ: карточка сделки в CRM для застройщика

Тестовое задание Web CRM / B2B UX Research

Спроектировала этап «Сбор данных» в карточке сделки CRM-системы для застройщика: как менеджер по продажам собирает информацию о клиенте, объекте и оплате, прежде чем перейти к заключению договора.

01Задача

Получила тестовое задание на позицию продуктового дизайнера в CRM для застройщиков. Легенда: я менеджер по продажам квартир, мой рабочий инструмент: CRM, в которой я веду сделку с клиентом от первого контакта до передачи ключей.

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

В сделке менеджер должен уметь: посмотреть и изменить данные покупателя: ФИО, телефон, паспорт, проверить помещение, которое покупает клиент, и убедиться, что оно ещё не продано, выбрать способ оплаты и увидеть график платежей, добавить дополнительные услуги к сделке, записать клиента на просмотр объекта. Остальные возможности оставила на моё усмотрение.

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

02Ресерч

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

CRM 1: карточка сделки

Хорошая лента событий, но визуально перегружена и плохо структурирована

CRM 2: канбан воронки

Удобно для обзора всех сделок разом, неудобно для глубокой работы с одной заявкой

CRM 3: лента и чат

Сделка подана как переписка с клиентом: хорошо для коммуникации, плохо для структурированных данных

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

03Гипотезы

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

Разделение на экраны

Если разбить заполнение данных на отдельные шаги вместо одной длинной формы, вырастет Completion Rate и снизится когнитивная нагрузка на менеджера.

Прогресс-индикатор

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

Предзаполнение по повторным клиентам

Если подтягивать данные о клиенте, который уже есть в базе, время заполнения (Time on Task) сократится примерно на 15%.

Обязательные поля

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

04Шаг 1: Контактные и паспортные данные

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

Контактные данные: обязательные поля помечены и подсвечиваются при ошибке

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

Паспортные данные: скан загружается отдельно, есть возможность добавить второго собственника

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

05Шаг 2: Источник заявки и объект сделки

05 Шаг 2: Источник заявки и объект сделки

Канал привлечения: источник заявки, ответственный агент, сумма сделки и комментарий по клиенту

Добавила блок «Источник клиента», которого не было в прямом требовании задания. Это данные, которые обычно теряются в CRM: если менеджер фиксирует, с какого ресурса пришла заявка, компания может считать эффективность каналов прямо по сделкам, а не через отдельную аналитику, до которой у отдела маркетинга не всегда доходят руки.

Информация о помещении: параметры квартиры, интеграция с Росреестром, статус сделки по объекту

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

06Шаг 3: Оплата и допуслуги

06 Шаг 3: Оплата и допуслуги

<div

Оплата: способ оплаты, дополнительные услуги и итоговая сумма сделки с учётом скидок

07Метрики

Задание отдельно спрашивало, какие метрики стоит отслеживать в кабинете менеджера. Отвечаю: за основную взяла бы Completion Rate, процент сделок, которые доходят до конца этапа «Сбор данных» без обрыва. Это самая прямая проверка того, что редизайн вообще решил свою задачу: если после разделения на шаги и прогресс-бара completion rate не вырос, значит, гипотезы не подтвердились, и разбираться дальше с формой нет смысла.

Остальные метрики вспомогательные, они объясняют, почему completion rate ведёт себя так, а не иначе.

Time to First Action

Как быстро менеджер начинает заполнять данные после открытия сделки. Долгая раскачка обычно значит, что интерфейс неочевиден.

Error Rate

Как часто менеджер получает ошибку валидации. Высокий error rate показывает, что подсказки и форматы полей не помогают.

Time on Task

Сколько времени уходит на весь этап целиком. По этой метрике измеряется эффект от предзаполнения повторных клиентов.

Churn на этапе

Процент сделок, которые зависают на «Сбор данных» дольше нормы и не двигаются дальше по воронке.

08Итоги и выводы

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

Форма, а не анкета

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

Данные не теряются

Источник заявки и повторное обращение фиксируются прямо в сделке, а не в отдельном отчёте, который никто не открывает.

Completion Rate как компас

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