Битрикс24 для B2B-продаж: модель, согласования и повторные сделки

Битрикс24 для B2B-продаж — это не одна воронка «на все случаи», а рабочая модель, где центром учёта становится компания, а сделка отражает конкретную закупку с согласованиями, счётом, поставкой и повторным обращением. Чтобы система помогала, заранее описывают сущности, роли, стадии и правила передачи заказа, а затем проверяют модель на тестовых данных до переноса реальной базы.

Что решает Битрикс24 для B2B-продаж и где границы решения

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

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

Отдельно стоит развести, что попадает в систему, а что остаётся во внешних контурах. В Битрикс24 удобно вести переговоры, задачи, историю закупок и статусы. Бухгалтерский учёт, складские остатки и производственные планы обычно живут в профильных системах, а в CRM отражаются только те их состояния, которые нужны продажам и снабжению. Если пытаться заменить CRM учётной системой, получится дублирование данных и расхождения, которые придётся разбирать вручную.

В Маркетплейсе Битрикс24 есть отраслевые приложения для B2B и оптовых компаний: готовые CRM с настроенными направлениями сделок, стадиями, пользовательскими полями, роботами и триггерами. Их можно поставить по подписке и адаптировать под себя. Но готовое решение — это заготовка, а не гарантия соответствия вашим согласованиям, номенклатуре и схеме поставки. Состав приложений и условия подписки стоит сверять на дату внедрения.

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

Модель B2B-продаж: какие сущности и связи заводить

Модель — это набор сущностей и правил, по которым они связаны. В B2B минимальный набор выглядит так: Компания, Контакт, Сделка, Лид, Счёт, Предложение, Дело. Каждая сущность отвечает на свой вопрос, и смешивать их нельзя. Ниже — как развести эти сущности так, чтобы система выдержала реальную нагрузку.

Разделяйте сделку и компанию

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

Лид или сразу сделка

Лид — это ещё не проверенное обращение: заявка с сайта, контакт с выставки, холодный звонок. Сделка — уже подтверждённый интерес с понятным предметом закупки. В B2B с длинным циклом полезно держать лиды отдельно и конвертировать их в компанию, контакт и сделку только тогда, когда появился реальный запрос. Если все обращения сразу становятся сделками, воронка забивается «мусорными» записями, и руководитель не видит, где на самом деле идёт работа. Критерий перехода простой: есть предмет закупки, есть контактное лицо и есть следующий шаг.

Направления сделок

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

Что хранить в карточке компании

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

Правила связей

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

Компания как центр учёта: контакты, роли и параллельные потребности

Роли контактов

В B2B решение принимают несколько человек, и у каждого своя зона. Полезно размечать контакты по ролям: ЛПР, снабжение, бухгалтерия, технический специалист, руководитель. Тогда менеджер понимает, к кому идти с коммерческим предложением, а к кому — с закрывающими документами. Без такой разметки письмо уходит «в никуда», а сделка стоит. Роль — это не украшение карточки, а фильтр: по нему менеджер быстро находит нужного человека в компании с десятком контактов.

Параллельные потребности

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

Связь с телефонией

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

Что проверить на этом шаге

• У каждой компании есть ответственный и хотя бы один контакт.
• Контакты размечены по ролям, а не свалены в один список.
• Параллельные закупки разведены по сделкам.
• Каналы связи (телефония, почта) привязаны к карточкам.
• Лиды отделены от сделок и не забивают воронку.

Согласования, счета и договоры: где ставить контрольные точки

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

Контрольные точки

• КП отправлено и подтверждено получение.
• Условия согласованы, зафиксирована отсрочка платежа.
• Договор передан на проверку профильному специалисту.
• Счёт выставлен и оплачен либо частично оплачен.
• Отгрузка согласована с клиентом.

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

Договор как отдельный поток

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

Роботы и триггеры

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

Как понять, что контрольные точки работают

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

Повторные сделки и «забытые» компании

В B2B значительная часть выручки приходит от повторных закупок. Поэтому важно, чтобы система сама напоминала о клиентах, с которыми давно не было активности. Иначе менеджер уходит в новые лиды, а тёплая база остывает.

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

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

Как не терять клиента между закупками

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

Где здесь развилка

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

Передача заказа в снабжение и контроль сроков поставки

В оптовых и производственных компаниях продажа не заканчивается на согласовании. Заказ уходит в снабжение или на производство, затем на отгрузку. Если этот переход держится на переписке и звонках, заказы теряются.

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

Контроль сроков

Когда подходит крайний срок поставки, система напоминает ответственному и руководителю. Это снижает риск пропустить срок и потерять репутацию. Напоминание должно приходить заранее, а не в день отгрузки, иначе оно бесполезно. Разумно задать два порога: предупреждение за несколько дней и сигнал в день срока. Точные интервалы зависят от вашего цикла поставки и определяются на тестовых данных.

Права доступа между отделами

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

Что должно быть в уведомлении о передаче заказа

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

Права доступа и разделение ролей

Роли в B2B-модели обычно такие: руководитель, менеджер по продажам, снабженец, логист, бухгалтер, юрист. Каждой роли — свой набор видимых полей и доступных действий.

• Руководитель видит все сделки, отчёты и зависшие этапы.
• Менеджер — свои компании и сделки.
• Снабженец — заказы в работе, без деталей продажи.
• Бухгалтер — счета и документы.
• Логист — данные по доставке.

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

Как проверять права без риска

Заведите тестового пользователя на каждую роль и пройдите с ним типовой сценарий: создание сделки, передача в снабжение, просмотр счёта, закрытие. Если роль видит лишнее или, наоборот, не может выполнить шаг, правило правят до запуска. Такой прогон занимает меньше времени, чем разбор последствий неверных доступов на рабочей базе.

Как выбрать вариант настройки: сравнение по критериям

Выбор между готовым приложением, настройкой на штатных инструментах и доработкой — это не вопрос вкуса, а вопрос соответствия процессу. Таблица ниже помогает принять решение по конкретным критериям.

Учебный пример: модель B2B-продаж на тестовых данных

Учебный пример. Данные условные, это не реальный кейс и не статистика.

Входные условия. Условная компания «Северная арматура» торгует промышленной арматурой оптом. Четыре менеджера по продажам, два снабженца, один логист, бухгалтер. Средний цикл сделки — от нескольких недель до нескольких месяцев. Для постоянных клиентов действует отсрочка платежа. Клиенты — заводы и подрядчики, закупки регулярные. Часть клиентов работает по тендерам, часть — по прямым договорам.

Задача. Навести порядок в учёте: видеть все сделки по компании, не терять согласования, контролировать поставку и возвращаться к клиентам с повторными закупками.

Действия.

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

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

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

Развилка в примере. Если у компании появляется тендерное направление, его оформляют отдельной воронкой, а не добавляют стадии в существующую. Иначе обычные сделки начнут путаться с тендерными, и отчёты потеряют смысл.

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

Как проверить результат и принять работу

• Модель сущностей описана: компания, контакт, сделка, счёт, дело.
• Направления сделок и стадии соответствуют реальному процессу.
• Поля карточек заполняются и не дублируются.
• Роботы и триггеры срабатывают на тестовых сделках.
• Права доступа проверены по каждой роли на тестовых пользователях.
• Передача заказа в снабжение и обратно работает.
• Напоминания о сроках поставки приходят ответственному и руководителю.
• Повторные сделки планируются, дата следующей закупки фиксируется.
• Отчёты показывают данные по компаниям и сотрудникам.
• Сценарий увольнения сотрудника проверен: компании переходят новому ответственному.
• Есть план возврата: копия базы и порядок отката изменений.

Типичные ошибки и ограничения

• Одна сделка на всю историю компании. Смешивает закупки и ломает повторные продажи.
• Стадии ради стадий. Если стадия не меняет действие менеджера, она бесполезна.
• Роботы без проверки. Шумные уведомления быстро отключают, и автоматизация умирает.
• Слишком дробные права. Замедляют работу и создают лишние обращения в поддержку.
• Перенос реальной базы без теста. Сначала копия, тестовый контур, план возврата.
• Ожидание, что система сама поднимет продажи. CRM фиксирует процесс, а не создаёт спрос.
• Смешивание тендерных и обычных сделок в одной воронке. Ломает отчётность и планирование.
• Лиды, которые сразу становятся сделками. Забивают воронку и скрывают реальную работу.

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

Какие исходные данные подготовить для оценки

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

Чем полнее этот список, тем точнее можно оценить объём работ и меньше правок потребуется после старта. Если часть данных отсутствует, это не повод откладывать: недостающие пункты описывают на тестовом контуре и уточняют по ходу.