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

Проектирование карточек сделок в Битрикс24: где рвётся воронка

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

Самая дорогая потеря заявок в воронке — та, где заявка формально не потеряна. Сделка остаётся в базе, но источник обращения не заполнен, поэтому её не видно ни в срезе по каналам, ни в прогнозе. Аналогично с дублями: клиент возвращается, менеджер создаёт вторую сделку или нового контакта — и история обращений разъезжается по двум записям, каждая из которых выглядит неполной.

Ручной перенос данных между этапами — вторая точка разрыва. Исполнитель копирует номер договора, вложения из переписки и решения по задаче дальше по воронке, потому что карточка не переносит их сама. Каждое копирование — это задержка отклика и новый шанс что-то не донести: часть истории оседает в комментариях и чатах, до которых следующий участник уже не дойдёт.

Всё это чинится не мотивацией и не регламентом, а проектированием карточек сделок: обязательные поля сделки с правилами заполнения и проверкой на переходе, автоматический перенос данных между этапами, отлов дублей до создания записи и сквозная история обращений в одной карточке. Разбираем, как это устроено.

Что меняется после переработки логики продаж

Эффект от переработки карточек видно по метрикам, которые снимаются на одной и той же выборке сделок до изменений и спустя месяц работы в новой логике. Ниже — то, что мы проверяем вместе с заказчиком на живой воронке в Битрикс24.

• Сокращение времени обработки заявки. Карточка заполняется за 2–3 минуты вместо десяти: часть полей приходит из формы, остальное выбирается из справочника. Менеджер занимается клиентом, а не переключением между окнами и поиском данных.
• Доля пропущенных обязательных полей. Валидация на переходе между стадиями не пропускает сделку без ключевых данных — пропуски падают с половины карточек до единичных случаев, и отчётность перестаёт строиться на догадках.
• Прозрачность этапов воронки. У каждой стадии одно определение и один набор обязательных полей, поэтому руководитель видит реальную картину: где сделки стоят, где зависают и на каком шаге теряются.
• Устранённые классы ошибок. Двойные карточки по одному клиенту, разорванная связь сделки с контактом и компанией, расхождения с учётной системой при переносах. Эти ошибки не «стали реже» — их больше негде совершить.
• Единые правила квалификации. Критерии перевода зафиксированы в полях и проверках, а не в устных договорённостях, поэтому два менеджера на одинаковых вводных принимают одинаковое решение.
• Скорость восстановления после сбоя. История изменений по полям и стадиям позволяет вернуть карточку к прежнему состоянию точечно, без разбора выгрузок и ручного восстановления связей.

Показатели снимаем до и после на одинаковых периодах, иначе сравнение ничего не доказывает.

Сравнение подходов к настройке карточки

Выбор подхода определяется тем, сколько логики живёт внутри карточки и как часто её придётся менять. Штатные средства Битрикс24 закрывают типовые сценарии, но упираются в потолок, когда правила начинают зависеть друг от друга.

Практический критерий простой: если правило выражается штатным условием и не требует внешних данных — оставляем его в карточке. Всё, что зависит от расчёта, смежных систем или истории изменений, выносим наружу и возвращаем результатом.

Такой разрез снимает главный риск проектирования — логика, размазанная по настройкам, ломается при первом же изменении процесса.

Этапы внедрения: от аудита до передачи регламентов

Карточка сделки — это не форма, а модель данных: поля, связи с контактом, компанией и счётом, стадии, права ролей и роботы, которые на всё это реагируют. Если начать с перерисовки интерфейса, через месяц выясняется, что часть полей дублируется, история обращений не подтягивается, а автоматизация срабатывает не на той стадии. Поэтому порядок работ фиксирован: сначала разбор данных и схемы, затем настройка, затем проверка на реальных сценариях продаж.

1. Аудит CRM перед доработкой. Выгружаем текущие сущности, поля, стадии, права и роботов, отмечаем дубли и неиспользуемые поля, смотрим, где менеджеры обходят систему вручную.
2. Схема полей и связей. Карта: какие поля обязательны, какие считаются автоматически, как сделка связана с контактом, компанией, счётом, задачей и обращением из канала связи.
3. Настройка стадий, правил и ролей. Собираем воронки, триггеры и ограничения прав по отделам, чтобы карточка показывала менеджеру ровно то, что нужно на текущем шаге.
4. Проверка сценариев продаж. Прогоняем типовые и пограничные пути — возврат на предыдущую стадию, повторное обращение, сделку без компании — на тестовом контуре с копией данных.
5. Перенос истории обращений. Загружаем накопленные сделки и переписку с сохранением дат, авторства и связей, сверяем число записей до и после.
6. Обкатка на одном отделе. Включаем новую схему для ограниченной группы, смотрим скорость заполнения и долю карточек без обязательных полей.
7. Передача регламентов. Отдаём схему данных, описание ролей, инструкции и правила сопровождения — чтобы правки дальше вносились без нас.

Схемы данных, политики доступа и регламенты работы

Проектирование карточек сделок завершается не настройкой полей, а комплектом артефактов. По ним команда сопровождения развивает систему, а отдел продаж работает без устных договорённостей о том, кто что заполняет.

• Схема сущностей CRM: сделки, компании, контакты, товарные позиции и дополнительные сущности — типы полей, связи и правила переноса значений между стадиями.
• Матрица прав по ролям: кто читает, кто правит, кто видит только свои записи — вплоть до отдельного поля; проверяется тестовыми учётками до запуска.
• Регламент заполнения полей: обязательные поля для каждой стадии, условия перехода дальше и порядок действий, когда данных не хватает.
• Правила автоматизации: роботы, триггеры и бизнес-процессы с условиями срабатывания, постановкой задач, сменой ответственного и обработкой ошибок.
• Инструкция для отдела продаж: пошаговый сценарий работы с карточкой — что заполнять при звонке, перед предложением и при закрытии сделки.
• Порядок внесения правок: как заводится запрос на новое поле или стадию, кто согласует, как изменение тестируется и откатывается.
• Карта миграции: сопоставление полей из прежней системы с новой схемой и журнал расхождений для ручного разбора.

Комплект передаётся и как документация, и как рабочие настройки — его достаточно, чтобы новый администратор ввёл систему в строй без автора схемы.

Кейс: единая модель данных для трёх направлений продаж

У заказчика три направления продаж работали в одной воронке Битрикс24, и карточку сделки каждый отдел достраивал под себя. Обязательные поля не совпадали, часть реквизитов менеджеры дублировали в комментариях, повторный клиент заводился второй карточкой — типичный кейс внедрения CRM, где проблема не в настройках, а в отсутствии общей модели данных.

Что было до

Заявки терялись на стыке между отделами: сделка уходила на следующий этап, но ответственный не менялся — доля потерь доходила до пятой части новых обращений. Дубли составляли около трети сделок, история по клиенту не собиралась. Средний срок прохождения этапа измерялся днями и у каждого отдела считался по своим статусам, сравнить направления было нельзя. Поддержка получала десятки вопросов в неделю только о том, как правильно заполнить карточку.

Что изменили

Спроектировали единую модель: общий справочник полей с обязательностью, привязанной к стадии, правило смены ответственного при переходе между направлениями и проверку контакта по номеру и почте перед созданием новой сделки. Направления развели по отдельным воронкам с общей аналитикой.

После запуска доля потерянных заявок упала с 18% до 2%, дубли — с 30% до 3%, средний срок прохождения этапа сократился вдвое, а число обращений в поддержку по заполнению — втрое. Отчётность по трём направлениям впервые собиралась из одного источника.

Что делать, если система уже развёрнута и полей слишком много

Переполненная структура полей почти никогда не требует остановки отдела продаж. Обязательность, порядок и видимость полей, подсказки, новые значения справочников меняются прямо в рабочем контуре — за минуты, без выгрузок и пауз в переговорах. Опасны только операции над тем, на что уже ссылается история сделок: удаление поля, переименование или удаление стадии, смена воронки.

Причина простая: карточка — не изолированная форма, а узел связей. На значения полей опираются отчёты, автоматизации, права ролей и обмен с учётной системой. Поэтому устаревшее поле нельзя выключить одним действием — сначала нужно увидеть, кто и что из него читает. Инвентаризация по факту использования занимает пару дней и снимает основную часть рисков.

Дальше работает поэтапная переработка CRM, где каждый шаг обратим:

Между шагами держим паузу — неделю наблюдений за обращениями к полю и ошибками обмена. Такой порядок позволяет закрывать сделки на каждом этапе: недоступным становится только то, что уже выведено из использования и не попадёт в отчётность.

Технические сомнения: ограничения, миграции, интеграции

Карточка сделки — не отдельная форма, а надстройка над штатным объектом CRM: поля, стадии, права и правила автоматизации живут в той же сущности, что и стандартные. Поэтому возражения у инженеров повторяются — разберём четыре самых частых.

Что будет с обменом, если учётную систему заменят?

Обмен строится на постоянных идентификаторах: сделка, контрагент и позиции связываются по внешнему ключу, а не по названию. При смене учётной системы сопоставление идёт по этим ключам — дубли и записи без пары не появляются, а перенос обмена сводится к настройке нового источника.

Сохранится ли история сделок?

Закрытые сделки остаются со своими стадиями, ответственными и перепиской, новые поля заполняются по мере движения. Изменения значений пишутся в журнал — видно, кто и когда их внёс, что закрывает вопросы аудита при смене команды.

Что входит в сопровождение после передачи?

Регламент изменений, схема полей и роли доступа. Правки в стадиях и правилах автоматизации идут через согласованный порядок и тестовый контур — карточка не «расползается» через полгода после запуска.

Обсудим задачу — вернёмся с оценкой и планом

Чтобы спроектировать карточки сделок под ваш процесс, а не под средний шаблон, нужен короткий разбор текущего состояния. Достаточно прислать то, что уже есть, — недостающее уточним на созвоне.

• Состав ролей и направлений: кто работает в CRM — продажи, сервис, снабжение, руководство — и какие зоны ответственности за кем закреплены.
• Текущая структура полей: обязательные и необязательные поля, дубли, формат ведения справочников и контрагентов.
• Этапы сделки: стадии воронки, что считается результатом этапа и где нужны обязательные проверки перед переходом дальше.
• Существующие интеграции: 1С, телефония, почта, сайт, внешние сервисы — что синхронизируется и по какому признаку сопоставляются записи.
• Требования к отчётности: какие срезы нужны руководству, с какой периодичностью и в каких разрезах — направление, сотрудник, период.
• Разграничение доступа: кому видны какие поля и разделы, нужен ли журнал действий по карточке.

Дальше обсуждаем задачу автоматизации, сверяем список и возвращаемся с оценкой и планом работ: схема полей, порядок переноса данных, этапы внедрения и точки контроля. Объём и последовательность вы видите до старта — правки на этом этапе обходятся дешевле, чем переделка воронки после запуска.