Когда сделке действительно нужно своё поле
Битрикс24 из коробки даёт сделке приличный набор системных полей: сумма и валюта, ответственный, стадия, источник, даты начала и завершения, вероятность, тип сделки. Эти поля нельзя удалить и нельзя переименовать: они одинаковы на любом портале и составляют фиксированный каркас CRM.
Каркас перестаёт покрывать реальность довольно быстро. Производственная компания хочет видеть срок изготовления, оптовик — склад отгрузки, учебный центр — формат обучения, сервисная компания — номер объекта. Пока таких данных нет в отдельном поле, они оседают в комментариях: менеджер пишет «отгрузка со склада на Райымбека, срок 12 дней», и формально информация в системе есть. Только найти её можно исключительно глазами, отфильтровать нельзя, в отчёт она не попадёт никогда.
Простой критерий такой. Значение повторяется от сделки к сделке, по нему нужно отбирать или считать, и ни одно системное поле под него не подходит: пора добавить поле в сделку Битрикс24. Если же значение уникально для каждой сделки и в отборе никогда не участвует, его место в комментарии или в таймлайне, а не в отдельной строке карточки.
Второй критерий чуть менее очевидный. Кастомное поле CRM стоит заводить тогда, когда вы готовы объяснить менеджерам, кто и в какой момент его заполняет. У поля без владельца и без понятного момента заполнения судьба одна: через месяц оно пустует в большинстве сделок, а карточка при этом стала длиннее и неудобнее. Такое поле лучше не создавать вовсе.
Кто имеет право создавать поля
Создать пользовательское поле может администратор Битрикс24 либо сотрудник, которому в правах доступа CRM выдано разрешение на изменение настроек CRM. Обычный менеджер, даже если он видит все сделки и работает с ними каждый день, кнопку создания поля просто не увидит.
Это разумное ограничение, и обходить его не стоит. Поля живут на уровне всего портала: одно неудачное поле, созданное в спешке, увидят все сотрудники во всех сделках. На практике мы советуем клиентам держать право на изменение настроек CRM у двух-трёх человек максимум, обычно это администратор и руководитель отдела продаж.
Способ первый: создать поле прямо в карточке сделки
Это самый короткий путь, и в большинстве случаев его достаточно. Он удобен, когда поле нужно здесь и сейчас: вы открыли сделку, поняли, что вносить данные некуда, и создали строку не выходя из карточки.
Порядок действий такой:
- Откройте любую сделку. Карточка открывается кликом по названию в списке или в канбане.
- В левой части карточки, там, где перечислены поля, найдите пункт создания поля. Он расположен внизу подходящего раздела.
- Выберите тип поля из предложенного списка. Это самый ответственный шаг: тип потом не меняется.
- Впишите название поля. Название видят все сотрудники, поэтому пишите так, как менеджер спросил бы у клиента: «Срок поставки, дней», а не «SROK_POST».
- Включите нужные параметры: обязательность, множественность, значение по умолчанию. Сохраните.
Поле появляется в карточке немедленно и сразу доступно во всех остальных сделках. Заполнять его в старых сделках задним числом никто не заставляет: там, где значение не внесли, поле просто останется пустым.
У этого способа есть предел. Часть настроек, например работа с большими списками значений или привязка к справочникам CRM, удобнее и полнее делается через раздел настроек. Если поле сложное, начинайте сразу со второго способа.
Способ второй: раздел пользовательских полей в настройках CRM
Полный набор возможностей живёт по адресу CRM → Ещё → Настройки → Настройки CRM → Настройки форм и отчётов → Пользовательские поля. Путь длинный, но пройти его придётся один раз: дальше страница добавляется в закладки браузера.
На этой странице поля сгруппированы по типам элементов CRM: отдельно лиды, отдельно сделки, отдельно контакты, компании, счета, предложения, смарт-процессы. Выбираете сделку, нажимаете добавление поля и получаете форму со всеми настройками сразу.
Здесь же удобно наводить порядок в том, что уже создано. Через полгода работы портала список полей сделки обычно выглядит неопрятно: три поля с похожими названиями, два пустых, одно созданное «на пробу». Раздел настроек остаётся единственным местом, где эту картину видно целиком, а не по одному полю за раз.
Ещё одна причина заходить именно сюда: поля разных типов элементов не связаны между собой. Поле «Срок поставки», созданное для сделки, в лиде не появится. Если данные собираются в лиде и должны переехать в сделку при конвертации, поле нужно завести в обоих местах и уже потом настраивать соответствие. Люди регулярно наступают на эти грабли, а затем удивляются, почему при конвертации лида половина информации пропала.
Какой тип поля выбрать
Типов полей больше пятнадцати, и выбирать между ними приходится ровно один раз. Основные рабочие варианты выглядят так.
Строка — универсальный текст. Подходит для номера договора, адреса объекта, названия проекта. В строку можно внести что угодно, включая цифры и даты, и именно поэтому её часто выбирают там, где нужен другой тип. Строка не суммируется, не сортируется как число и не участвует в вычислениях.
Целое число и число — для количества, сроков в днях, площади, веса. Как только значение нужно сравнивать или суммировать, тип должен быть числовым.
Деньги — сумма с указанием валюты. Незаменимо для компаний, которые работают в тенге и долларах одновременно: поле хранит и цифру, и валюту, вместо того чтобы держать курс в голове менеджера.
Дата/время — срок отгрузки, дата подписания, плановая установка. Дата, записанная в строку, выглядит точно так же, но по ней невозможно построить нормальный отбор «всё, что раньше пятницы».
Список — фиксированный набор значений на выбор. Именно он спасает будущую аналитику. Пока менеджеры вписывают склад руками, вы получите «Алматы», «алматы», «Алматинский» и «АЛА» в одной выборке. Со списком вариантов ровно столько, сколько вы задали.
Да/Нет — простая галочка: нужна доставка, подписан NDA, клиент пришёл из тендера.
Файл — вложение прямо в поле карточки: договор, техническое задание, спецификация. Отличается от файлов в таймлайне тем, что лежит в предсказуемом месте и не тонет в переписке.
Привязка к пользователю — выбор сотрудника портала. Удобно, когда у сделки кроме ответственного есть второй человек: инженер, монтажник, куратор проекта.
Привязка к элементам CRM — ссылка на другой объект системы: контакт, компанию, счёт, предложение. Так связывают сделку с сопутствующими элементами, не дублируя их данные.
Привязка к справочникам CRM — значение берётся из справочника: тип контакта, сфера деятельности компании. Работает как список, только источник значений общий для портала.
Есть ещё ссылка, адрес, бронирование ресурсов и привязка к элементам инфоблоков. Они нужны реже и обычно в связке с конкретным сценарием.
Что стоит настроить у поля кроме названия
Обычно поле создают и на этом останавливаются, а дальше удивляются, что пользы от него мало. Настроек у поля несколько, и каждая экономит время потом.
Множественность включают, когда в поле может быть несколько значений одновременно. Классический случай: набор дополнительных услуг в сделке, где их бывает две, а бывает пять.
Значение по умолчанию подставляется автоматически. Это удобно, когда у подавляющего большинства сделок значение одинаковое: менеджер меняет его только в исключениях, а не вводит каждый раз одно и то же.
Подсказка к полю — короткое пояснение, которое видит сотрудник. Одна фраза вроде «дата, к которой клиент ждёт оборудование на объекте» снимает и вопросы, и разночтения в данных.
Показ в списке и фильтре часто забывают включить. Если поле не выведено в фильтр, отобрать по нему сделки не получится, а ради этого поле обычно и заводили.
Ограничение видимости по сотрудникам позволяет показывать поле не всем. Так поступают с внутренними пометками, себестоимостью, комментариями руководителя.
Тип и множественность выбираются один раз
После сохранения поля изменить его тип и множественность уже нельзя. Остальные настройки (название, обязательность, подсказку, порядок) правьте сколько угодно, а вот превратить строку в список или одиночное поле в множественное задним числом не получится.
Значит, единственный способ исправить ошибку — создать новое поле правильного типа и перенести туда данные. В маленьком портале на полсотни сделок это скучная, но выполнимая работа. В портале на десять тысяч сделок это уже задача с выгрузкой, обработкой и обратной загрузкой.
Отсюда практический совет, который экономит клиентам недели. Прежде чем нажимать «Сохранить», ответьте себе на три вопроса. Буду ли я по этому полю фильтровать или считать? Может ли в поле оказаться несколько значений одновременно? Есть ли у значений конечный список? Первый вопрос отделяет строку от числа и даты, второй решает вопрос множественности, третий подсказывает, нужен ли список вместо свободного текста.
Обязательные поля и обязательность на стадии
Поле можно сделать обязательным: тогда сделку не сохранить, пока оно пустое. В карточке такие поля отмечены красной звёздочкой, так что менеджеру не приходится гадать.
Настраивается это прямо в карточке: наведите курсор на поле, нажмите шестерёнку настроек, выберите пункт настройки поля и поставьте галочку «Обязательное».
Гораздо интереснее вторая опция — обязательное на стадии. Она доступна для элементов со стадиями: лидов, сделок, счетов, предложений, смарт-процессов. Смысл в том, что поле требуется заполнить не сразу, а на конкретном этапе воронки. Сотрудник не сможет перевести сделку дальше, пока не внесёт значение.
На этой опции строится вся дисциплина данных в отделе продаж. Требовать номер договора в момент создания сделки бессмысленно: договора ещё нет, и менеджер впишет прочерк, лишь бы система пропустила. А на стадии «Договор подписан» требование законно, и обойти его нечем.
Тот же приём закрывает вечную боль руководителей: незаполненную причину отказа. Сделайте поле «Причина отказа» обязательным на стадии проигрыша, и через месяц у вас появится первая честная статистика провалов вместо пустых значений в карточках.
Важная деталь для компаний с несколькими воронками: в сделках и смарт-процессах обязательные поля настраиваются отдельно для каждой воронки. Настроили обязательность в «Продажах» — в «Сервисе» она не появится. С одной стороны, это лишняя работа при настройке. С другой, именно так и должно быть: у сервиса и продаж требования к данным разные.
Разделы карточки и три режима отображения
Новое поле встанет туда, куда его поставила система. Дальше карточку стоит привести в порядок, иначе через десяток полей менеджер начнёт терять нужное среди ненужного.
Поля в карточке группируются по разделам. Разделы можно создавать, переименовывать, менять местами и удалять, то есть собрать структуру под свой процесс: отдельно блок про клиента, отдельно про условия поставки, отдельно про документы. Внутри раздела поля тоже переставляются. Ненужные поля можно скрыть, не удаляя: данные останутся, просто перестанут занимать место на экране. Вкладки карточки при желании скрываются и переупорядочиваются тем же способом.
У карточки три режима отображения, и путаница между ними — частая причина обращений в поддержку. Общий вид настраивает администратор, и он действует на всех сотрудников. Персональный вид — это личная настройка конкретного сотрудника поверх общей. Вид по ролям позволяет собрать отдельную раскладку карточки для определённой группы: например, показать монтажникам блок с адресом и оборудованием, а финансовые поля от них убрать.
Типичная ситуация: администратор навёл порядок в карточке, а менеджер говорит, что у него всё по-старому. Почти всегда причина в том, что у менеджера сохранена персональная настройка, которая перекрывает общую.
Ограничения, о которых узнают поздно
Лимит на количество пользовательских полей — 1016 на каждый тип элемента CRM: столько для лида, столько же отдельно для сделки, для счёта и так далее. В обычной компании до этой цифры дело не доходит никогда. Упираются в неё те, кто годами создавал поля под каждый разовый запрос и ни разу не чистил список.
Гораздо ближе другое ограничение, человеческое. Карточка на сорок полей мешает работать. Менеджер пролистывает её, не читая, и заполняет ровно то, что подсвечено красной звёздочкой. Когда список полей растёт быстрее бизнеса, дело обычно не в возможностях Битрикс24, а в том, что поля заводят без разбора.
И главное предупреждение. Удаление пользовательского поля стирает все данные, которые в нём хранились, по всем элементам и безвозвратно. Поле при этом не скрывается, а именно удаляется вместе со значениями. Поэтому правило простое: сначала скрыть поле из карточки и понаблюдать месяц, и только потом, если по нему никто не хватился, удалять. Пустое поле ничего не стоит, а вот три года накопленных значений восстановить будет нечем.
Как это выглядит на реальном процессе
Пример ниже собирательный, но каждый его элемент мы встречали у клиентов не по одному разу.
Компания продаёт и монтирует оборудование. Сделка проходит стадии: заявка, расчёт, договор, предоплата, монтаж, закрытие. Руководитель жалуется на две вещи. Невозможно спланировать загрузку монтажников, и непонятно, почему уходят клиенты на стадии расчёта.
Что здесь нужно добавить в карточку сделки:
- Планируемая дата монтажа — тип «дата», обязательное на стадии «Предоплата». Раньше этой стадии дата неизвестна, позже уже поздно планировать.
- Монтажник — тип «привязка к пользователю», обязательное на той же стадии. Ответственный по сделке остаётся менеджером, а исполнитель работ становится отдельной, отбираемой величиной.
- Объект — тип «адрес», не обязательное. Заполняется по мере уточнения.
- Причина отказа — тип «список» с пятью значениями: дорого, выбрали конкурента, отложили, не наш профиль, нет ответа. Обязательное на стадии проигрыша.
- Спецификация — тип «файл». Чтобы утверждённая версия лежала в одном месте, а не в переписке.
Через месяц такой настройки руководитель получает две вещи, которых у него не было. Первая — календарь монтажей, потому что дата и исполнитель теперь машиночитаемые данные, а не текст в комментарии. Вторая — распределение причин отказа, из которого сразу видно, борется компания с ценой или с медленной реакцией.
Обратите внимание, что ни одно поле в списке не создано «на всякий случай». У каждого есть момент заполнения, ответственный и вопрос, на который оно отвечает. Пока это условие выполняется, карточка остаётся рабочим инструментом, а не складом данных.
Что делать, если поле не появилось
Несколько ситуаций, которые чаще всего приводят к обращению в поддержку.
Поле создали, а в карточке его нет. Проверьте, в каком типе элемента вы его создавали: распространённая ошибка в том, что поле завели в лиде, а ищут в сделке. Второй вариант — поле скрыто в настройках карточки, и его нужно вернуть в раздел.
Поле видно вам, но не видно менеджеру. Смотрите настройки видимости поля по сотрудникам и персональный вид карточки у самого менеджера.
Обязательность не срабатывает. Убедитесь, что настраивали её в той же воронке, в которой работает сотрудник.
Кнопки создания поля нет вообще. Не хватает прав на изменение настроек CRM, вопрос к администратору портала.
Если разобраться самостоятельно не получается или портал уже оброс полями настолько, что страшно что-то трогать, наша техподдержка Битрикс24 на связи 24/7: посмотрим структуру карточки, приведём поля в порядок и настроим обязательность по стадиям так, чтобы менеджеры не саботировали заполнение.
Частые вопросы
Можно ли изменить тип уже созданного поля?
Нет. Тип и множественность фиксируются в момент сохранения поля. Изменить можно название, обязательность, подсказку, видимость и порядок в карточке. Чтобы сменить тип, придётся создать новое поле и перенести в него данные.
Что произойдёт со старыми сделками после добавления поля?
Ничего не сломается. Поле появится во всех сделках, включая закрытые, но останется пустым там, где его никто не заполнял. Заполнять историю задним числом не обязательно.
Появится ли поле сделки автоматически в лиде?
Нет. Пользовательские поля создаются отдельно для каждого типа элемента CRM. Если данные собираются в лиде и должны переехать в сделку, поле нужно завести в обоих местах.
Можно ли скрыть поле от части сотрудников?
Да, у поля есть настройка видимости по сотрудникам, а кроме того, карточку можно собрать отдельно для конкретной роли. Так финансовые данные не показывают монтажникам, а служебные поля не мешают менеджерам.
Что будет, если удалить поле?
Все значения, которые в нём хранились, удалятся вместе с ним по всем элементам и без возможности восстановления. Безопасный путь — сначала скрыть поле в настройках карточки, подождать и удалять только после того, как убедились, что оно точно не нужно.