В карточке клиента тридцать обязательных полей. Чтобы сохранить первый запрос, менеджер должен указать бюджет, срок закупки, юридические реквизиты и сегмент. Часть ответов ещё неизвестна, поэтому появляются нули, случайные даты и значение «прочее». Отчёт выглядит заполненным, но использовать его для решения нельзя.
Полезная карточка B2B-клиента содержит сведения, которые помогают узнать покупателя, найти нужного человека и продолжить работу. Остальные данные должны появляться там и тогда, где у них есть понятное назначение. Настройка начинается со словаря полей: что означает каждое значение, кто его подтверждает и на каком этапе оно необходимо.
Сначала разделите компанию, человека и продажу
Компания может иметь несколько контактов и одновременно покупать разные продукты. Если бюджет, срок поставки и этап переговоров хранить одним набором в карточке компании, новый заказ перезапишет условия предыдущего.
Разнесите сведения по смыслу. У компании находятся идентификация и устойчивые особенности отношений. У контакта — роль человека и рабочие способы связи. У сделки или обращения — конкретная потребность, условия и следующее действие. История общения связывает эти записи.
Такое разделение встречается, например, в документации Microsoft по квалификации обращения. Это не требование копировать чужую CRM: названия разделов могут отличаться, но смысл сведений не должен смешиваться.
Если у компании два действующих заказа, вопрос «когда клиенту нужна поставка?» относится к каждому заказу отдельно. В карточке компании допустим обзор связанных заказов, но единственное поле «срок поставки» создаст неоднозначность.
Отберите поля через решения сотрудников
Выпишите десять последних действий менеджеров: передали запрос инженеру, уточнили плательщика, подготовили предложение, назначили встречу. Для каждого укажите, какие сведения позволили выполнить действие и что пришлось искать дополнительно.
Затем проверьте существующие поля. У каждого должны быть пользователь и решение. Например, отрасль нужна для назначения специалиста; основной ответственный — для продолжения коммуникации; реквизиты плательщика — для конкретного оформления заказа.
Если поле добавили «для аналитики», уточните, какой отчёт изменит решение руководителя. Ежемесячный ручной ввод показателя, который никто не смотрит, создаёт затраты и снижает внимание к действительно важным данным.
Не ограничивайте карточку произвольным числом полей. Для сложного продукта исходных сведений больше. Критерий достаточности — возможность выполнить согласованные сценарии без обязательного выдумывания ответов.
Минимальный словарь для компании
Ниже — стартовый вариант. Его следует адаптировать к вашей модели отношений и структуре системы.
- Идентификатор записи. Нужен для устойчивой связи с контактами, заказами и другими системами. Присваивается при создании; обычный пользователь не меняет его ради исправления названия.
- Рабочее название. Помогает найти компанию. Его вводит принявший обращение сотрудник; при первом контакте допустимо название, которым представился клиент, с пометкой о необходимости уточнения.
- Подтверждённые реквизиты. Позволяют различать юридические лица и оформлять документы. Источник — проверенный документ или согласованная процедура; срок заполнения связан с оформлением конкретного обязательства.
- Ответственный за отношения. Показывает, кто координирует работу. Назначается по регламенту, а не автоматически считается автором самой старой заметки.
- Рабочий сегмент. Используется, только если влияет на обслуживание, маршрутизацию или предложение. Нужен согласованный список значений и правило отнесения.
- Статус отношений. Например, потенциальный, действующий, неактивный. Для каждого значения нужны критерии; состояние отдельной сделки сюда не переносится.
- Источник подтверждения и дата проверки. Позволяют понять, почему значение считается достоверным. Эти сведения особенно полезны для реквизитов и контактных данных.
Если две карточки похожи, сначала проверьте их идентичность по правилам работы с дублями. Исправление названия и объединение компаний — разные операции.
Какие сведения относятся к контакту
Имя и роль нужны, чтобы понимать, с кем общается команда. Один человек может собирать предложения, другой проверять техническую часть, третий согласовывать покупку. Не записывайте их в одно поле «контактное лицо» через запятую, если процесс требует отдельной коммуникации.
Минимальная запись контакта включает имя, связь с компанией, рабочую роль, подходящий канал связи и статус актуальности. Для каждой роли полезно зафиксировать конкретное участие: «передаёт технические требования», «согласует состав заказа». Формулировка «ЛПР» без подтверждения часто скрывает предположение менеджера.
Храните только сведения, нужные для работы. Если человек перестал заниматься закупками, зафиксируйте изменение роли и нового собеседника. Не меняйте имя старого контакта на нового сотрудника: история разговоров относится к прежнему человеку.
Способ ведения нескольких мест работы, общих адресов и контактов подразделений зависит от возможностей CRM. Эти ситуации лучше проверить на примерах до массового переноса базы.
Назначьте обязательность по этапу
Для регистрации запроса достаточно возможности вернуться к обращению, его сути и ответственного. Для подготовки технического предложения потребуются дополнительные исходные данные. Для оформления заказа — согласованные условия и подтверждённые реквизиты.
Обязательность — правило процесса, а не характеристика поля навсегда. Составьте три уровня: нужно при регистрации, нужно перед определённым переходом, заполняется при наличии подтверждённых сведений.
В описании бизнес-правил Dataverse показаны проверки значений и условные действия с полями. В своей CRM проверяйте конкретную реализацию: правило формы не обязательно одинаково работает при импорте или другом способе ввода. Если автоматической проверки нет, её можно включить в регламент перехода.
У неизвестного значения должен быть понятный смысл. «Бюджет не обсуждался» отличается от «клиент отказался раскрыть бюджет». Ноль означает числовое значение, а не удобную замену отсутствующего ответа.
Заполненный пример без лишних сведений
Учебная компания «Северный участок» запросила комплекты для двух площадок. Менеджер Анна получила первое обращение от закупщика Ольги. Пока подтверждён только состав первой потребности.
- Компания: К-318, рабочее название «Северный участок»; юридическое лицо уточняется до оформления заказа.
- Ответственный за отношения: Анна; сегмент — заказные комплектующие, поскольку он влияет на подбор специалиста.
- Контакт: Ольга, закупки; рабочий канал указан в карточке; технические вопросы согласует инженер заказчика.
- Запрос З-812: 30 комплектов для площадки № 1; требуется уточнить состав.
- Следующее действие: Анна получает перечень позиций к четвергу, 14:00.
- Запрос по площадке № 2: отдельная связанная запись; количество и срок ещё не подтверждены.
- Реквизиты: задача на уточнение назначена Анне; фиктивные значения не вводятся.
Из этого примера видно, почему нельзя хранить количество и срок единственными полями компании. Они относятся к разным потребностям. При этом коллега уже может понять, кто ведёт работу и что должно произойти дальше.
Определите владельцев и источники изменений
Менеджер может отвечать за контакт и потребность, а сотрудник, оформляющий заказ, — за проверку реквизитов. Руководитель процесса утверждает значения сегментов. Администратор помогает реализовать правила, но не должен самостоятельно решать, какое юридическое лицо является покупателем.
Если поле обновляют две системы, назначьте источник истины и правила разрешения расхождений. Последнее поступившее значение не всегда самое правильное: импорт старого файла может оказаться новее подтверждённого разговора.
Для важных изменений сохраняйте основание. Не обязательно вручную комментировать каждый пробел в названии; однако замена ответственного, ключевого контакта или реквизитов должна быть объяснима. Сложные случаи обмена разобраны в статье о согласовании данных между системами.
Шаблон паспорта поля
Перед добавлением нового поля заполните короткую запись:
- Название и сущность: «Дата требуемой поставки», конкретная сделка.
- Назначение: проверка выполнимости обещания.
- Тип: дата; отдельно — признак согласования.
- Источник: подтверждённая потребность клиента.
- Владелец заполнения: менеджер сделки.
- Момент обязательности: до подтверждения условий заказа.
- Неизвестное значение: не согласовано; назначено уточнение.
- Правило изменения: новое согласование с сохранением основания.
- Использование: планирование и проверка обязательств.
Проверьте словарь на нескольких реальных обращениях. Попросите сотрудника объяснить значение полей и найти следующее действие. Если ответы различаются, проблема ещё в определениях, а не в дисциплине заполнения.
В ЧатПлюс заявлены CRM, воронки, задачи и единые входящие. Обсудите с ExtentLab пример вашей карточки: по нему можно проверить, какие данные нужны процессу и когда их следует запрашивать.