Проектирование карточек сделок в CRM Битрикс24

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Предлагаемые услуги
Показано 1 из 1 услугВсе 1626 услуг
Проектирование карточек сделок в CRM Битрикс24
Средняя
~2-3 рабочих дня
Часто задаваемые вопросы
Наши компетенции:
Этапы разработки
Последние работы
  • image_website-b2b-advance_0.png
    Разработка сайта компании B2B ADVANCE
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Разработка веб-сайта для компании ФИКСПЕР
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    747
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    976

Проектирование карточек сделок в CRM Битрикс24

Проектирование карточек сделок в CRM Битрикс24

Карточка сделки — центральный объект работы менеджера по продажам. Именно здесь проводится большая часть рабочего времени: просмотр истории, фиксация договорённостей, управление суммой, запуск счёта. Если карточка спроектирована неудачно, менеджеры начинают вести параллельный учёт в Excel — «там удобнее». Это не проблема менеджеров, это проблема проектирования.

Структура карточки сделки в Битрикс24

Карточка сделки (crm_deal, таблица b_crm_deal) имеет несколько зон:

Хедер — название сделки, сумма, стадия, ответственный, дата закрытия. Это поля, видимые всегда, без прокрутки — самые важные.

Основной блок полей — настраивается через «Настройка карточки». Может быть разбит на вкладки или секции. Состав зависит от воронки: у сделок разных направлений (crm_category) может быть разная конфигурация карточки.

Блок «Товары» — каталог продуктов/услуг, привязанных к сделке. Данные хранятся в b_crm_deal_product_row. Если каталог не используется — блок можно скрыть.

Лента дел — звонки, письма, встречи, задачи, комментарии. Хронологическая история взаимодействий.

Связи — контакты и компании, привязанные к сделке. Настраивается через crm.deal.contact.add / crm.deal.contact.items.set.

Проектирование под процесс продажи

Главный принцип: карточка сделки должна отражать именно ту стадию, на которой находится сделка. В Битрикс24 это реализуется через настройку отображения полей в зависимости от стадии — функционал «обязательных полей» по стадии (crm.stageField).

Типичная ошибка: все 30 полей отображаются на всех стадиях. Менеджер на стадии «Первый контакт» видит поля «Договор подписан», «Реквизиты для счёта», «Номер заказа на поставку» — и не понимает, что с ними делать. Хорошая карточка показывает нужное в нужный момент.

Что проектируем:

  1. Обязательные поля по стадии. На стадии «КП отправлено» — обязательно заполнить «Срок действия КП» и «Контактное лицо для КП». На стадии «Счёт выставлен» — реквизиты и сумму. Это делается через настройку обязательных полей в карточке на конкретной стадии.

  2. Группировка полей по смыслу. Секции карточки: «О сделке», «О клиенте», «Финансы», «Документы». Менеджер знает, в какой секции искать нужное поле.

  3. Кастомные поля правильного типа. Битрикс24 поддерживает типы: строка, число, список, дата, boolean, привязка к элементу CRM, файл, деньги, адрес. Выбор неправильного типа — например, «строка» вместо «список» для типа клиента — убивает аналитику.

  4. Калькулируемые поля. В Битрикс24 нет встроенного механизма вычисляемых полей «из коробки», но через роботы-автоматизации можно обновлять поля при изменении других. Например, автоматически рассчитывать маржу при изменении суммы закупки.

Кейс: карточка сделки для строительной компании

Клиент — подрядчик в гражданском строительстве. Сделки: строительство объектов под ключ, средний чек — 5–50 млн рублей, цикл — 3–18 месяцев.

Исходная карточка: стандартная, дополнена 18 пользовательскими полями в хаотичном порядке — «Площадь объекта», «Тип фундамента», «Этажность», «ИНН заказчика», «Кадастровый номер участка», «Статус разрешения на строительство» и т.д. Всё в одном блоке, без группировки.

Переработанная структура карточки:

Секция «Объект»: адрес объекта (тип «Адрес»), площадь (число), этажность (число), тип строительства (список: новое строительство / реконструкция / капремонт).

Секция «Заказчик»: ИНН (строка с маской), статус заказчика (список: физлицо / юрлицо / госзаказ), наличие проектной документации (boolean).

Секция «Юридические документы» (появляется только начиная со стадии «Договор»): номер договора, дата договора, кадастровый номер, статус разрешения на строительство (список).

Секция «Финансы»: бюджет заказчика, наша цена предложения, итоговая сумма договора, форма оплаты (список), график платежей (файл).

Поля секции «Юридические документы» обязательны на стадии «Договор подписан» — нельзя перейти на следующую стадию без заполнения.

Дополнительно настроили: при переходе на стадию «Объект сдан» — автоматическое создание задачи «Запросить отзыв у заказчика» с дедлайном +7 дней.

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

Подводные камни

Слишком много вкладок. Если карточка разбита на 6+ вкладок, менеджеры перестают заходить дальше первой. Оптимально — 3–4 секции или вкладки.

Дублирование полей из контакта в сделку. ИНН, адрес, телефон — это данные компании/контакта, не сделки. Размещение их в карточке сделки приводит к расхождению данных при обновлении.

Поле «Комментарий» вместо классификатора. «Почему сделка провалилась?» — текстовое поле даёт ответ, который нельзя агрегировать. Нужен список причин отказа.

Сроки

Проектирование и реализация карточки сделки — 3–6 дней для одной воронки. Если несколько воронок с разными конфигурациями карточек — 8–15 дней.