Как организовать холодные звонки в Битрикс24, если цель - 100 звонков в день

Если цель - около 100 попыток звонка в день на одного сотрудника, начинать стоит не с максимальной автоматизации. Сначала нужно собрать минимальный рабочий контур, запустить реальные звонки, измерить, где теряется время, и только после этого развивать процесс.

Реальная задача:
нужно организовать холодные звонки в Битрикс24, а предварительная цель - около 100 попыток звонка в день на одного сотрудника.

На этом этапе легко начать обсуждать роботов, стадии, обязательные поля, ограничения, AI, отчеты и приложения.

Мы бы начинали иначе.
Сначала нужно понять, как сотрудник должен провести обычный рабочий день, что действительно мешает ему звонить и какой минимальный контур необходимо запустить, чтобы уже через несколько дней получить реальные данные.

Только после этого имеет смысл решать, какие действия автоматизировать дальше.

С какой задачей к нам пришли

В одном из проектов заказчик уже достаточно подробно представлял будущий процесс.

В нем были:

• отдельная воронка холодного обзвона;
• стадии работы;
• исходящие звонки;
• повторные звонки;
• электронная почта;
• статусы результата;
• комментарии;
• актуализация контактов;
• ограничения для оператора;
• автоматические переходы;
• контроль выполненной работы;
• расчет вознаграждения;
• анализ разговоров с помощью AI.

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

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

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

Какие вопросы нужно задать до настройки Битрикс24

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

В рассматриваемой задаче один из главных ориентиров звучал так:
около 100 попыток звонка в день на одного сотрудника.

Это сразу меняет способ проектирования.

100 звонков в день - цель, а не универсальная норма

Если рабочее окно составляет с 10:00 до 17:00 и внутри есть часовой перерыв, остается примерно шесть часов активной работы.
100 попыток за шесть часов - это примерно:

• 17 попыток в час;
• одна новая попытка каждые 3 минуты 36 секунд.

Это простая арифметика, а не норматив.

Один звонок может закончиться почти сразу: номер недоступен или никто не ответил.
Другой может занять 10-15 минут: оператор вышел на нужного человека, обсудил вопрос, уточнил данные, отправил письмо и договорился о следующем контакте.

Поэтому до запуска нельзя достоверно утверждать, что именно 100 попыток является правильным KPI.
Сначала эту гипотезу нужно проверить реальной работой.

Что показывает рынок труда

Для дополнительной проверки мы отдельно посмотрели, как подобные задачи описываются работодателями на HH.ru.

В контрольной выборке свежих вакансий на 14 сентября 2026 года встречались, например:

Это не означает, что существует единая правильная норма.
Наоборот, разброс показывает, насколько сильно цифра зависит от самого процесса.

100 ручных B2B-звонков с поиском ЛПР, заполнением CRM и письмами и 150-200 коротких исходящих звонков без полноценной продажи - принципиально разные виды работы.
Поэтому для нас число звонков является не обещанием, а точкой проверки архитектуры процесса.

Если бы мы внедряли такой процесс у себя

Мы бы начали не с вопроса:

Какие еще роботы можно настроить?

А с вопроса:

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

Получается такая последовательность.

Это позволяет двигаться от общего к частному.

Каким должен быть рабочий день оператора

В нашем варианте логика получилась достаточно простой.

Сначала запланированные звонки

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

1. Открыть список запланированных дел.
2. Перейти в связанную сделку.
3. Посмотреть предыдущую историю.
4. Совершить звонок.
5. Зафиксировать результат.
6. Запланировать следующий контакт или завершить текущий цикл.

Для повторных контактов в CRM логичнее использовать именно дела, а не отдельные задачи. Разницу между этими сущностями мы отдельно разбирали в статье «Задачи или дела в Битрикс24».

Затем новые сделки

После запланированных перезвонов оператор переходит к очереди новых сделок.
Базовая последовательность:
сделка -> звонок -> результат -> уточнение данных -> письмо при необходимости -> следующий звонок или завершение.

Именно этот короткий маршрут должен стать первым объектом внедрения.

Что Битрикс24 уже дает для такого сценария

На момент подготовки материала в Битрикс24 есть штатный сценарий обзвона клиентов из CRM: можно выбрать контакты, компании, лиды или сделки, последовательно звонить, фиксировать результат и планировать дальнейшую работу.

Телефония Битрикс24 поддерживает входящие и исходящие звонки, запись разговоров и сохранение звонков в CRM при соответствующей настройке.

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

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

Нужно определить:

• какие элементы CRM использует оператор;
• какие результаты звонка фиксируются;
• когда отправляется письмо;
• как создается следующий звонок;
• что происходит со сделкой после результата;
• какие данные сотрудник должен заполнить;
• какие действия стоит автоматизировать;
• где необходим контроль.

То есть Битрикс24 дает инструменты, а задача внедрения - собрать из них рабочий контур.

Этап 1. За первую неделю запустить реальные звонки

Первая неделя должна закончиться не словами «мы настроили CRM».
Она должна закончиться тем, что оператор может начать реальную работу.

В конкретном проекте первый этап мы декомпозировали следующим образом.

Что считаем результатом первой недели

Оператор должен уметь пройти всю последовательность:
открыть сделку -> позвонить -> зафиксировать результат -> отправить письмо -> назначить перезвон или завершить обработку.

Если это работает, у компании уже есть полезный результат.
Даже если дальнейшие этапы проекта будут отложены, базовый рабочий процесс остается.
В конкретной фактуре такой первый этап был оценен в 77 000 ₽.

Почему мы не ставим сложные ограничения в первую очередь

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

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

Принцип здесь простой:
сначала наблюдаем ошибку или потерю времени, потом автоматизируем ее устранение.

Этап 2. Вторая неделя - эксплуатация вместо догадок

После запуска начинают появляться факты.

Например:

• оператор слишком долго добавляет новый контакт;
• неудобно искать следующий звонок;
• письмо отправляется нормально и дополнительная автоматизация не нужна;
• после разговора приходится выполнять несколько повторяющихся действий;
• стандартный AI-анализ оказался полезным;
• или, наоборот, практически ничего не дает конкретному процессу.

Поэтому задача второй недели - не бесконечно дорабатывать все новые идеи.
Задача - стабилизировать запущенный процесс и собрать нормальный backlog следующих изменений.

В конкретном проекте такая неделя сопровождения оценивалась в 47 000 ₽.

Где проходит граница между исправлением и новой задачей

Это важно зафиксировать заранее.

Без этой границы «неделя стабилизации» быстро превращается в открытую разработку без понятного результата.

Что нужно измерять после запуска

Вернемся к первоначальной цели в 100 попыток.
Допустим, сотрудник фактически совершает 35 звонков.

Первый вопрос не должен звучать:

Почему он не сделал 100?

Правильный вопрос:

Куда ушло рабочее время?

Мы бы смотрели минимум на следующие показатели.

Два совершенно разных результата

Представим два сценария.

Сценарий А.
Оператор сделал 35 попыток, но большая часть разговоров длилась по 10-15 минут и завершалась полезным контактом.
Тогда, возможно, 100 звонков просто не являются правильной нормой для этого процесса.

Сценарий Б.
Оператор сделал 35 попыток, разговоры были короткими, но после каждого звонка тратил несколько минут на ручное заполнение CRM.
Тогда проблема уже техническая.

Можно искать, какие действия сократить:

• автоматическое заполнение;
• более простую карточку;
• автоматическую отправку письма;
• создание следующего дела;
• фиксацию типовых событий;
• изменение стадии;
• другие повторяющиеся операции.

Так автоматизация начинает работать на реальное ограничение.

Этап 3. Ограничения и дополнительная автоматизация

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

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

В рассматриваемом проекте такой этап предварительно оценивался от 47 000 ₽.
Слово «от» здесь принципиально.
Точный объем определяется после первых двух недель, когда уже есть фактический список задач.

Этап 4. Вознаграждение и управленческий контроль

Следующий отдельный слой - расчет результата работы сотрудника.
До реальной эксплуатации можно придумать довольно сложную формулу:

• один процент за дозвон;
• другой за найденного ЛПР;
• отдельная часть за письмо;
• доплата после актуализации данных;
• разные коэффициенты по итоговому результату.

Но такую модель опасно автоматизировать до того, как зафиксирован сам процесс.
Сначала нужно определить:

• за какой конечный результат мы действительно платим;
• какие промежуточные действия имеют самостоятельную ценность;
• какие данные можно надежно получить из CRM;
• что требуется для акта или внутреннего отчета.

После этого уже строится расчет.
Предварительная стоимость такого отдельного этапа в рассматриваемой фактуре также начиналась от 47 000 ₽.

Почему мы не фиксируем жестко весь проект заранее

Можно заранее написать большое техническое задание и оценить пять недель разработки.
Но такая точность будет частично искусственной.

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

Поэтому более безопасная модель выглядит так:

Так заказчик не покупает заранее весь возможный объем автоматизации.
Каждый следующий блок должен иметь понятную причину.

Два варианта нашего участия

Есть еще одна граница, которую стоит определить до начала проекта.

Только техническая реализация

Мы получаем согласованную задачу:

• настраиваем;
• тестируем;
• передаем инструкции;
• исправляем ошибки в согласованных границах.

Дальше вопросы оператора собирает ответственный сотрудник заказчика.
Он сам анализирует обратную связь и формулирует нам следующие технические задачи.

Ведение процесса с нашей стороны

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

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

В конкретном предложении стоимость такого участия была рассчитана как 37 000 ₽ за активную неделю ведения проекта дополнительно к техническим работам.
Это отдельная услуга, а не обязательная часть настройки.

Как выглядела итоговая декомпозиция

Если свести весь подход в одну таблицу:

Главное здесь не цена каждого блока.
Главное - момент, когда принимается решение о его необходимости.

Сколько в итоге стоит запуск

В рассматриваемом проекте первые две недели были оценены в:

• первая неделя - 77 000 ₽;
• вторая неделя - 47 000 ₽.
  Итого - 124 000 ₽ за первоначальный запуск и стабилизацию.

После этого заказчик уже получает:

• работающий процесс;
• сотрудника, который начал фактический обзвон;
• данные первых дней эксплуатации;
• список реальных проблем;
• приоритетный backlog;
• оценку следующих работ.

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

* О стоимости. Все цены в статье приведены на примере конкретного коммерческого предложения, подготовленного 14 сентября 2026 года. Они отражают фактуру именно этого проекта и не являются универсальным публичным прайсом CRM4. Для другого портала стоимость зависит от текущих настроек Битрикс24, телефонии, почты, воронок, прав, количества пользователей, сторонних приложений и объема необходимой автоматизации.

Главный вывод

Если бизнес ставит цель в 100 холодных звонков в день, вопрос не сводится к настройке телефонии.

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

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

Мы бы двигались именно в такой последовательности:
цель -> вопросы -> рабочий сценарий -> минимальный запуск -> реальные данные -> узкое место -> следующая автоматизация.

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