Заявка пришла с сайта, менеджер связался с клиентом, выставил счёт. Через две недели никто не может сказать, оплатил клиент или просто пропал. Такая картина типична для компаний, которые ведут сделки в Битрикс24, но не выстроили саму воронку: стадии существуют формально, роботы не настроены, а разрыв между «заявка получена» и «деньги на счету» никак не отслеживается. В результате часть заявок теряется на стыке отдела продаж и бухгалтерии, руководитель не видит, на каком этапе застревают деньги, а маркетинг не может посчитать, какой канал приводит платящих клиентов, а какой — только любопытных.
Сквозная воронка решает именно эту задачу: она делает путь клиента от первого контакта до поступления оплаты одним непрерывным процессом внутри CRM, где каждый шаг фиксируется автоматически, а не держится в голове менеджера. Проблема в том, что «настроить CRM» и «выстроить сквозную воронку» — разные по глубине задачи. Завести карточки лидов и сделок можно за час, а вот сделать так, чтобы каждый переход между этапами происходил без ручного участия менеджера и без потери данных — это уже вопрос архитектуры процесса, а не просто заполнения полей в интерфейсе. Разберём, как выстроить такую воронку в облачном Битрикс24: от структуры стадий до автоматизации перехода между ними, приёма оплаты и подключения аналитики.
Из чего состоит воронка в Битрикс24: лид, сделка, счёт, оплата
В CRM Битрикс24 путь клиента обычно проходит через несколько связанных сущностей. Заявка с сайта, звонок или сообщение в мессенджер создают лид — первичное обращение, ещё не подтверждённое как реальный интерес к покупке. После квалификации лид конвертируется в сделку, которая уже привязана к конкретному товару или услуге, сумме и ответственному менеджеру. Внутри сделки формируется счёт — отдельный элемент CRM с данными клиента, составом товаров или услуг, суммой и реквизитами для оплаты. Финальная точка — фактическая оплата, статус которой автоматически отражается в таймлайне сделки или заказа.
Дело в том, что многие компании используют только часть этой цепочки: заводят сделки, но выставляют счета вручную в другой программе, либо принимают оплату наличными без фиксации в CRM. Тогда воронка формально есть, а сквозной она не становится: часть данных выпадает, и посчитать реальную конверсию от заявки до денег невозможно. Первый шаг к сквозной воронке — договориться, что все четыре звена (лид, сделка, счёт, оплата) ведутся в одной системе, без исключений «для срочных клиентов» или «пока по старинке».
Настройка стадий сделки под свой цикл продаж
Стадии сделки по умолчанию в Битрикс24 — это универсальный шаблон, который редко подходит бизнесу без доработки. Прежде чем что-то автоматизировать, стоит честно описать, через какие этапы реально проходит сделка именно у вас — не так, как хотелось бы в теории, а так, как происходит на практике. Для розничного B2B это может быть: «Новая заявка» → «Квалификация» → «Коммерческое предложение отправлено» → «Согласование условий» → «Счёт выставлен» → «Ожидание оплаты» → «Оплачено» → «Сделка закрыта». Для проектных продаж с длинным циклом список будет другим и, скорее всего, длиннее.
Важное правило: количество стадий не должно превращаться в формальность. Если менеджер физически не может объяснить, чем отличается стадия «В работе» от «В процессе», это сигнал, что стадии дублируют друг друга и их нужно объединить. С другой стороны, если между «Заявка получена» и «Счёт выставлен» проходит неделя и множество невидимых шагов — переговоры, согласование спецификации, тестовый образец — эти шаги стоит вынести в отдельные стадии, иначе аналитика по воронке будет врать: формально сделка «висит» на одном этапе месяцами, а руководитель не понимает, что там происходит на самом деле.
Отдельного внимания заслуживают стадии, связанные именно с оплатой. Смысл в том, чтобы разделить «счёт выставлен» и «счёт оплачен» на разные стадии сделки — это единственный способ увидеть в отчётах, сколько сделок «зависает» именно на этапе ожидания денег, а не теряется где-то раньше в переговорах.
Полезная практика — заранее прописать для каждой стадии не только название, но и критерий перехода: конкретное действие или событие, после которого сделка обязана переместиться дальше. Например, переход на «Коммерческое предложение отправлено» происходит только после того, как менеджер прикрепил файл КП к карточке сделки, а не просто написал клиенту в переписке. Без таких критериев стадии превращаются в субъективную оценку каждого менеджера. Один переносит сделку на следующий этап после первого звонка, другой ждёт письменного согласия, и в итоге отчёты по воронке сравнивают несопоставимые вещи. Именно эти критерии перехода потом становятся основой для настройки роботов и триггеров: система не может сама решить, отправлено КП или нет, но может отследить факт прикрепления файла, изменение суммы сделки или смену статуса счёта, и на основании этого события подвинуть карточку дальше.
Роботы и триггеры: как автоматизировать переход между стадиями
Ручной перенос сделок между стадиями — то, что чаще всего разваливает воронку: менеджер забыл передвинуть карточку, и аналитика показывает искажённую картину. В Битрикс24 за автоматизацию этой логики отвечают роботы и триггеры, и разница между ними принципиальна.
Роботы запускаются, когда сделка (или лид, счёт) попадает на определённую стадию, и выполняют заданное действие: ставят задачу менеджеру, отправляют клиенту письмо или документ, уведомляют руководителя отдела. Например, при переходе сделки на стадию «Счёт выставлен» робот может автоматически сформировать и отправить клиенту счёт с реквизитами и ссылкой на оплату.
Триггеры, наоборот, реагируют на действия клиента или изменения в системе и уже сами перемещают элемент на другую стадию. Классический пример именно для нашей задачи: клиент переходит по ссылке из письма со счётом, либо оплачивает счёт, и триггер автоматически переводит сделку со стадии «Ожидание оплаты» на «Оплачено», без участия менеджера. Это устраняет главный источник ошибок в воронке от заявки до оплаты: человеческий фактор на стыке «выставили счёт» и «увидели, что деньги пришли».
Настройка связки «робот + триггер» на переходе к оплате обычно выглядит так: при попадании сделки на стадию согласования условий робот формирует счёт и уведомляет менеджера, что документ отправлен клиенту; отдельный триггер отслеживает статус оплаты счёта и, как только он меняется на «Оплачен», автоматически переводит сделку дальше по воронке и снимает задачу с менеджера. В результате продавец не тратит время на ручной контроль оплат, а руководитель в любой момент видит по отчёту, сколько сделок реально закрыто деньгами, а не просто «отправлено на согласование».
Имеет смысл настроить и обратную сторону процесса — работу с просроченной оплатой. Если счёт выставлен, а клиент не оплачивает его в течение оговорённого срока, робот может через несколько дней автоматически поставить менеджеру задачу «связаться с клиентом по счёту» или отправить клиенту мягкое напоминание. Без этого механизма счета «зависают» в статусе ожидания неделями, а менеджер вспоминает о них только тогда, когда клиент сам напишет, либо не напишет вовсе, и сделка тихо умирает без явного отказа. Именно такие незаметные утечки на стадии ожидания оплаты чаще всего съедают выручку в компаниях, где воронка настроена лишь наполовину: до счёта всё работает автоматически, а после него менеджер снова остаётся один на один с ручным контролем.
Приём оплаты внутри CRM: счета, ссылки и статус в таймлайне
Счёт в Битрикс24 — не просто документ для печати, а полноценный элемент CRM со своим жизненным циклом. В нём фиксируются данные клиента, состав товаров или услуг, сумма, реквизиты и срок оплаты. Клиенту можно отправить прямую ссылку на оплату счёта, где предусмотрен приём платежей картой через подключённый эквайринг, без необходимости уводить клиента на сторонний сайт или в другую систему. Как только оплата проходит, статус счёта меняется автоматически, а обновление сразу отражается в таймлайне связанной сделки или заказа. Руководителю и менеджеру не нужно сверяться с банковской выпиской вручную, чтобы понять, поступили деньги или нет.
Эта механика и делает счёт связующим звеном сквозной воронки: он одновременно является финальным документом по сделке и точкой, где фиксируется факт оплаты. Для счетов, как и для сделок, тоже доступны роботы и триггеры: можно настроить автоматическое напоминание клиенту, если счёт не оплачен в течение нескольких дней, или уведомление ответственному менеджеру о просроченной оплате.
Компаниям, которые только выстраивают такую цепочку с нуля, стоит закладывать время не только на настройку самих стадий и роботов, но и на подключение эквайринга, тестирование ссылок на оплату и обучение менеджеров работать со счетами внутри CRM, а не в отдельной бухгалтерской программе. Если ресурсов внутри команды на это не хватает, разумнее заказать настройку и внедрение Битрикс24 у партнёра, который уже выстраивал подобные воронки для других компаний и знает типичные грабли на этом пути.
Как связать источник заявки с фактической оплатой через сквозную аналитику
Настроенная воронка отвечает на вопрос «прошла ли сделка путь от заявки до оплаты», но не отвечает на вопрос «какой канал маркетинга принёс эти деньги». Для этого в Битрикс24 CRM есть встроенный инструмент сквозной аналитики — он работает без сторонних сервисов и дополнительных интеграций и позволяет отследить путь клиента от первого контакта с рекламой до конкретной сделки и оплаты.
Рекламные каналы — Facebook, ВКонтакте, Яндекс.Директ, Google Ads, Instagram — подключаются в интерфейсе в несколько шагов. Помимо привычных UTM-меток инструмент поддерживает выделенные номера телефонов и email-адреса, закреплённые за конкретным источником: это полезно, когда клиент из рекламы звонит напрямую, а не заполняет форму на сайте, и стандартная UTM-метка до CRM просто не доходит.
Когда рекламные каналы подключены, а воронка выстроена так, что каждая сделка доходит до стадии «Оплачено» через триггер, а не «на глаз» от менеджера, в отчётах сквозной аналитики становится видна реальная стоимость лида и сделки по каждому источнику, а не только количество кликов или заявок. Это меняет разговор с маркетингом: вместо «сколько заявок дал Instagram» руководитель может спросить «сколько денег в итоге принёс Instagram», и получить точный ответ, а не оценку на глаз.
На практике связка «воронка + сквозная аналитика» особенно хорошо показывает себя в компаниях с несколькими каналами продвижения одновременно. Например, у розничного поставщика оборудования из Алматы, который вёл рекламу в Яндекс.Директ и Instagram параллельно, до настройки сквозной воронки оба канала выглядели примерно одинаково эффективными по числу заявок. После того как стадии сделки развели «счёт выставлен» и «оплачено» на разные шаги, а триггеры начали фиксировать реальные оплаты, выяснилось, что заявки из Яндекс.Директ закрывались оплатой почти вдвое чаще: клиенты из поиска чаще уже сравнили цены и были готовы платить, тогда как из Instagram шло больше «нецелевого» интереса. Бюджет перераспределили в пользу более конверсионного канала. Это стало возможным только потому, что воронка в CRM показывала не заявки, а именно оплаты.
Отчёты по воронке: что видит руководитель
Выстроенная воронка бесполезна, если её показатели никто регулярно не смотрит. В разделе CRM-аналитики Битрикс24 есть отдельный блок отчётов по воронке продаж — классический и конверсионный. Классический отчёт показывает, сколько сделок дошло до каждой стадии и какие этапы менеджеры фактически пропускают. Например, если половина сделок перескакивает сразу с «Заявка получена» на «Счёт выставлен», это повод разобраться, реально ли менеджеры ведут переговоры или просто формально продвигают карточку. Конверсионный отчёт, в свою очередь, показывает, на каких именно стадиях сделки чаще всего срываются, то есть где теряется больше всего потенциальной выручки.
При наведении на каждый этап в этих отчётах доступна детализация: процент перехода на следующую стадию, сумма сделок и среднее время, которое сделки проводят на этом шаге. Это особенно важно для контроля именно денежной части воронки: по среднему времени на стадии «Ожидание оплаты» видно, насколько быстро клиенты платят после выставления счёта, и можно сравнить этот показатель по разным менеджерам, товарным категориям или источникам заявок. Отчёты поддерживают фильтрацию по любым полям, включая пользовательские. Можно, например, отдельно посмотреть конверсию в оплату только по сделкам из определённого рекламного канала или только по конкретному менеджеру.
На практике имеет смысл закрепить короткий ритуал: раз в неделю руководитель отдела продаж смотрит конверсионный отчёт и обсуждает с командой не общий план продаж, а конкретную стадию, где теряется больше всего сделок в моменте. Это гораздо продуктивнее, чем разбирать воронку целиком раз в квартал. Узкое место обычно можно устранить точечно, если увидеть его вовремя, а не когда квартальные цифры уже подведены.
Типичные ошибки при настройке сквозной воронки
Даже когда в компании есть желание выстроить воронку правильно, на практике встречается несколько повторяющихся ошибок.
Первая — попытка скопировать чужую структуру стадий без адаптации под собственный цикл продаж. Готовые шаблоны из интернета редко учитывают специфику конкретного бизнеса, и в итоге часть стадий остаётся пустой, а часть реальных этапов не помещается в схему.
Вторая — настройка роботов без триггеров или наоборот. Робот, который отправляет счёт, но не связан с триггером, отслеживающим оплату, оставляет тот же ручной разрыв, который и должна была устранить автоматизация: менеджеру всё равно приходится вручную проверять, пришли деньги или нет.
Третья — ведение части сделок вне CRM «для скорости», особенно у ключевых клиентов, с которыми работают напрямую в мессенджере или по телефону. Даже единичные исключения ломают статистику: сквозная аналитика и отчёты по воронке начинают показывать искажённую конверсию, потому что часть реальных оплат в системе просто не зафиксирована.
Четвёртая ошибка — отсутствие регулярной проверки самой воронки после запуска. Бизнес меняется, появляются новые товары, каналы продаж или условия оплаты, а стадии сделки остаются прежними полгода-год. Раз в квартал стоит сверять, соответствуют ли стадии в CRM тому, как реально идут продажи сейчас, и донастраивать роботов и триггеров под изменившийся процесс. Иначе воронка постепенно перестаёт отражать реальность и превращается в формальность, от которой пытались уйти изначально.
Частые вопросы
Сколько времени занимает настройка сквозной воронки в Битрикс24 с нуля?
Для типовой воронки с 6-8 стадиями, роботами на ключевых переходах и подключением эквайринга обычно достаточно нескольких дней активной настройки, если процесс продаж уже описан. Если структуру этапов продаж ещё предстоит формализовать, времени уйдёт больше. Основная часть работы уходит именно на согласование логики этапов внутри команды, а не на техническую настройку CRM.
Нужна ли отдельная интеграция для приёма оплаты по ссылке из счёта?
Приём оплаты картой доступен через подключённый эквайринг внутри CRM, без вывода клиента на сторонний сайт. Конкретный набор доступных платёжных методов зависит от того, какая платёжная система подключена к аккаунту, поэтому этот момент стоит уточнять и тестировать до запуска воронки в боевом режиме.
Можно ли настроить воронку так, чтобы разные менеджеры видели только свои сделки?
Да, права доступа в CRM настраиваются по ролям и отделам, и это стандартная часть настройки воронки, а не отдельная задача. Обычно это делают параллельно с настройкой стадий, чтобы сразу разграничить видимость сделок между отделами продаж.
Что делать, если часть сделок всё равно ведётся вне CRM?
Единственный устойчивый вариант — постепенно переводить все источники заявок в CRM, включая звонки и мессенджеры, а не оставлять исключения «для важных клиентов». Пока хотя бы часть сделок остаётся вне системы, отчёты по сквозной воронке и аналитике будут показывать искажённую картину независимо от того, насколько точно настроены роботы и триггеры.
Стоит ли настраивать воронку самостоятельно или обращаться к партнёру?
Небольшую воронку с несколькими стадиями можно настроить своими силами, если в команде есть человек, готовый разобраться в логике роботов и триггеров. Для более сложных процессов — с несколькими воронками под разные продукты, интеграцией эквайринга и сквозной аналитикой по нескольким рекламным каналам — обычно быстрее и надёжнее привлечь партнёра с опытом подобных внедрений, чтобы не переделывать структуру стадий несколько раз методом проб и ошибок.