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