Антон Дегтярёвнастройка полей crm в битрикс24: гайд для ропа
РОП открывает карточку сделки — и там 38 полей, 12 из них обязательные, а половину никто не заполняет уже полгода. Так выглядит типичный портал через год после внедрения. Разбираю, как настроить поля с нуля так, чтобы менеджеры их заполняли, а не обходили.
зачем вообще думать о полях, а не сразу их добавлять
Частая ситуация на моих проектах: РОП просит «добавить поле для источника клиента», через неделю — «поле для причины отказа», через месяц таких полей 15, и никто не помнит, зачем добавили половину. Проблема не в самих полях, а в том, что их добавляют по одному, реактивно, без плана.
Правильный порядок обратный: сначала список вопросов, на которые должна отвечать CRM-аналитика (откуда лиды, почему отваливаются, какой средний чек по сегменту), а уже под эти вопросы — поля. Если поле не отвечает ни на один управленческий вопрос — оно не нужно, каким бы полезным ни казалось на словах.
стандартные поля vs пользовательские
В сделке и лиде Битрикс24 уже есть штатный набор: источник, ответственный, сумма, дата закрытия, компания, контакт. Многие компании дублируют их пользовательскими полями — заводят своё «Источник 2.0», потому что не разобрались, как редактировать список значений в штатном справочнике источников.
Правило простое: сначала проверяю, нельзя ли расширить существующее поле (добавить значение в справочник), и только если это правда не подходит по логике — создаю новое пользовательское. На аудите вижу задвоенные поля примерно в 6 из 10 проектов, которые приходят «на доработку» после самостоятельной настройки.
как выбрать тип поля правильно
Тип поля — это не техническая деталь, а способ дисциплинировать ввод данных. Три частые ошибки:
Текстовая строка вместо списка. «Регион клиента» текстом даёт на выходе «Мск», «Москва», «г. Москва» — три разных значения для отчёта. Список с фиксированными вариантами такую путаницу исключает.
Список вместо чекбоксов, когда вариантов может быть несколько. Если клиент может интересоваться сразу двумя услугами, а поле — «список» с одним значением, менеджер выбирает первое попавшееся и теряет вторую услугу для отчёта.
Число вместо привязки к CRM-объекту. Если поле — «сумма прошлой сделки», логичнее привязать его к самой сделке (поле типа «привязка к CRM»), а не просить менеджера вписывать сумму руками — она устареет при следующем изменении.
сколько полей делать обязательными
Обязательное поле блокирует переход по воронке, пока не заполнено — это сильный инструмент, и им легко перегнуть. На моих внедрениях больше 5 обязательных полей на этапе — это уже риск: менеджер либо тратит время на карточку вместо звонка, либо начинает вписывать что попало, лишь бы сделка продвинулась.
Формула, которая работает: обязательным делаю только то поле, без которого физически нельзя закрыть сделку корректно — сумма, ответственный, товар/услуга. Всё информационное (комментарии, доп. контакты, теги интереса) — необязательное, но подсвечено в карточке, чтобы менеджер видел пробел и заполнял по возможности.
Отдельно проверяю обязательные поля не только на входе в этап, но и на переходе между этапами воронки — иногда логичнее требовать поле не при создании сделки, а именно перед конкретным шагом (например, «причина отказа» обязательна только при переводе в статус «не реализовано», а не с первого дня сделки).
где заводить поля — в лиде, в сделке или в обоих
Частый вопрос от РОПов: дублировать ли поля между лидом и сделкой. Если у вас включена конвертация лид → сделка, поля с одинаковым кодом переносятся автоматически, и дублировать вручную не нужно — это лишняя работа при создании и лишний риск разъехаться при редактировании.
Что имеет смысл разделять: в лиде — поля про первичный интерес и источник (пока квалификация не завершена, детали могут быть примерными), в сделке — поля про фактические условия (финальная сумма, состав заказа, сроки). Смешивать эти уровни в одном поле — источник постоянной путаницы у новых сотрудников.
чек-лист перед тем как нажать «создать поле»
Перед добавлением любого нового поля прохожусь по пяти пунктам: 1) какой отчёт или фильтр им будет пользоваться, 2) кто именно его заполняет — менеджер вручную или оно приходит из интеграции, 3) какой тип данных не даст ввести мусор, 4) обязательное оно или нет и на каком этапе, 5) видно ли оно в списке сделок или спрятано в детальной карточке.
Если на вопрос 1 нет внятного ответа — поле не создаю, а фиксирую в бэклоге «может пригодиться» и возвращаюсь к нему через месяц. В 8 из 10 случаев за месяц выясняется, что поле не нужно.
как убрать поля, которые уже расплодились
Если поля уже накопились, я делаю ревизию: выгружаю список сделок за 2-3 месяца и смотрю % заполненности по каждому пользовательскому полю. Всё, что заполнено меньше чем в 20% сделок — кандидат на удаление или перевод в необязательные с пометкой «не используется, будет удалено».
Удалять сразу не советую — сначала скрываю поле из формы (но не из базы), смотрю месяц, не возникнет ли жалоб, и только потом убираю окончательно. Это тот случай, где резкость вредит: если поле кому-то нужно для внутреннего отчёта, о котором вы не знали, лучше узнать это до удаления, а не после.
где поле должно быть видно — карточка, список, канбан
Место, где поле показывается, влияет на то, будет ли оно вообще заполняться. Поле, спрятанное на третьей вкладке детальной карточки, менеджер увидит только если специально туда зайдёт — на практике это происходит редко. Если поле важно для ежедневной работы (например, «дата следующего контакта»), его стоит выносить в список сделок или в карточку канбана, чтобы оно было на виду без лишних кликов.
Обратная ошибка — выносить в список все поля подряд, чтобы «было видно». Список с 15 колонками неудобно читать, менеджер начинает горизонтально скроллить и перестаёт им пользоваться вообще. На моих проектах в список сделок выношу не больше 5-6 полей — те, по которым реально принимаются решения на ходу: сумма, ответственный, статус оплаты, дата следующего действия.
Отдельно стоит продумать поля для карточки канбана — она компактнее списка, но её видят все сотрудники отдела постоянно, пока смотрят на доску. Хорошее место для короткого статусного поля («ожидает предоплаты», «согласовывает с юристом») — оно даёт понимание по сделке без открытия карточки.
как поля видит интеграция и REST API
Если у вас есть или планируется интеграция с сайтом, 1С или другой системой, у каждого пользовательского поля есть технический код (например, `UF_CRM_1234567890`), который используется при обмене данными через REST API. Этот код формируется автоматически при создании поля и не меняется, даже если переименовать заголовок поля в интерфейсе — это удобно, но и создаёт риск: через год никто не помнит, какой код соответствует какому полю по смыслу.
Практический совет — на этапе создания важных для интеграций полей сразу фиксировать в отдельном документе или таблице: название поля, его код, что именно в него пишет интеграция и откуда. Без этого документа при следующей доработке интеграции разработчику приходится заново разбирать структуру полей вручную, методом проб и ошибок — а это лишнее время и лишний риск ошибиться полем.
что почитать дальше
Настройка полей — только часть базовой конфигурации портала. Если у вас впереди полноценное внедрение с нуля, посмотрите, как я провожу аудит бизнес-процессов перед внедрением — поля логичнее проектировать после него, а не до. Если поля уже настроены, но воронка буксует, разбор в статье как настроить воронку продаж в Битрикс24 поможет понять, не в этапах ли дело. А если данные из полей нужно превратить в управленческие отчёты — начните со статьи аналитика продаж и отчёты в Битрикс24.