Антон Дегтярёвбитрикс24 для интернет-провайдера: заявки и техподдержка
У интернет-провайдера в CRM всегда две разные жизни: продажа новых подключений и техподдержка уже подключённых абонентов. На аудитах чаще всего вижу, что обе эти жизни пытаются впихнуть в одну воронку — и она разваливается на третьем месяце. Показываю, как развести это в Битрикс24 так, чтобы заявки на подключение не терялись, а обращения в техподдержку не зависали без ответа.
почему одна воронка здесь не работает
Заявка на подключение и обращение в техподдержку — разные процессы с разной скоростью и разным финалом. Подключение длится дни или недели и заканчивается сделкой, а обращение в поддержку должно закрываться за часы и заканчивается не деньгами, а решённой проблемой абонента.
На моих внедрениях у провайдеров всегда две отдельные воронки в CRM: «Подключения» — обычная сделка с этапами от заявки до монтажа, и «Обращения» — отдельная сущность для тикетов техподдержки со своими статусами и SLA. Смешивать их в одну — значит либо терять новые заявки среди тикетов «не работает интернет», либо наоборот.
Разделение важно ещё и для отчётности: отдел продаж смотрит на конверсию по воронке подключений, а руководитель поддержки — на скорость реакции по обращениям. Если оба процесса свалены в одну воронку, ни один из этих отчётов не получается собрать без ручной сортировки задним числом.
воронка подключений — от заявки до монтажа
Типовые этапы: заявка с сайта или по телефону → проверка технической возможности по адресу → согласование тарифа → выезд монтажника → активация услуги. Каждый этап — это конкретное действие конкретного человека, а не абстрактный статус «в работе».
Проверку технической возможности стоит вынести отдельным полем сделки с автоматическим уведомлением ответственному — в 8 из 10 случаев именно на этом этапе заявки зависают, потому что «не знаем, тянет ли туда линия» превращается в задачу, о которой все забыли.
Если ответ по технической возможности не пришёл за сутки — по регламенту заявка должна эскалироваться руководителю, а не висеть в статусе «на проверке» неделями. На аудитах именно этот этап оказывается самым долгим во всей воронке, хотя формально должен быть самым быстрым.
техподдержка — очередь обращений и sla
Обращения в поддержку удобно вести через открытые линии Битрикс24: звонок, чат на сайте, WhatsApp — всё падает в одну очередь с распределением по свободным операторам, а не теряется между разными каналами. У каждого обращения — таймер до первого ответа и таймер до решения, оба видны руководителю в реальном времени.
Реалистичный ориентир по SLA для провайдера: первый ответ до 5 минут при звонке, до 15 минут в чате, полное решение аварии — по регламенту, зафиксированному в договоре с абонентом, а не «когда получится». Именно нарушение этих таймеров — то, из-за чего абоненты уходят к конкурентам, а не сама авария.
Отдельно стоит настроить автоматическую эскалацию: если обращение не взято оператором в работу за 3-5 минут, задача должна уйти руководителю смены, а не оставаться в общей очереди до тех пор, пока кто-то её не заметит вручную.
диспетчеризация техников на выезд
Когда проблему нельзя решить удалённо, нужен выезд — и тут CRM либо помогает диспетчеру, либо превращается в ещё один список, который никто не смотрит. Рабочая схема: обращение автоматически создаёт задачу технику с адресом и описанием проблемы, ответственный назначается по правилу (ближайший свободный, а не вручную каждый раз).
Про то, как настроить автоматическое назначение ответственного вместо ручного распределения, — в статье про автоназначение ответственного в Битрикс24. Похожий принцип диспетчеризации выездных сотрудников я разбирал и для другой отрасли — в статье про Битрикс24 для логистики и доставки, там логика назначения исполнителя почти идентична.
Технику важно видеть маршрут на день целиком, а не по одной задаче за раз — иначе он физически не может спланировать порядок выездов и ездит через весь город туда-обратно вместо логичного маршрута по районам. Список задач с адресами на день, отсортированный по геопозиции, экономит час-полтора рабочего времени одного техника в день на больших городах.
телефония и мессенджеры в одном окне
У провайдера звонков много и они разного типа: продажа, авария, вопрос по оплате. Без интеграции телефонии с CRM оператор тратит первые 30 секунд разговора на то, чтобы понять, кто звонит и что у него уже было — с интеграцией карточка абонента открывается автоматически по номеру, с историей всех прошлых обращений.
Какую телефонию выбрать под конкретные задачи и чем варианты отличаются друг от друга, разбирал в статье про телефонию UIS для Битрикс24.
Отдельно стоит продумать, куда падает обращение из Telegram или WhatsApp в нерабочее время — если аварийная линия работает круглосуточно, а чат в мессенджере отвечает только днём, абонент должен явно видеть это в автоответе, а не молча ждать ответа до утра.
база абонентов и напоминания об оплате
Абонентская база в CRM — это не просто список контактов, а связка «абонент → тариф → дата следующей оплаты → статус услуги». На основе этой связки настраиваются автоматические напоминания за 3 дня до окончания оплаченного периода и уведомление при просрочке — без этого отдел продаж узнаёт об отключении абонента только после звонка с жалобой.
Автоматизация таких напоминаний — типовой сценарий для роботов и триггеров в Битрикс24, примеры похожих настроек я собирал в статье про роботов и триггеры.
Отдельная польза от такой связки — сегментация абонентов по тарифу и сроку подключения. Если видно, что абонент на минимальном тарифе не продлевает услугу больше двух раз подряд с задержкой, это заранее сигнал для отдела продаж предложить более подходящий тариф, а не ждать, пока он просто отключится молча.
отчёты, которые реально нужны руководителю
Из практики — три отчёта, которые руководителю провайдера важны каждую неделю, а не раз в квартал: среднее время первого ответа на обращение, доля обращений, решённых в срок по SLA, и конверсия заявок на подключение в оплаченные подключения по этапам воронки. Остальные отчёты обычно смотрят по требованию, а не регулярно.
Если конверсия по этапу «выезд монтажника» стабильно проседает — это почти всегда сигнал не про продажи, а про нехватку монтажников или плохое планирование маршрутов, а не про качество заявок.
Такие отчёты полезно смотреть не только цифрой за неделю, а в динамике за 2-3 месяца — разовый всплеск обращений после аварии на магистрали не говорит о системной проблеме, а вот устойчивый рост среднего времени решения из месяца в месяц — уже повод разбираться, что именно сломалось в процессе.
типичные ошибки при внедрении у провайдера
Ведут заявки на подключение и обращения в поддержку в одной воронке — теряют и то, и другое. Не разводят SLA по типу обращения — авария у абонента без интернета и вопрос про смену тарифа получают одинаковый приоритет, хотя это разные по срочности вещи.
Настраивают диспетчеризацию техников вручную через звонки и мессенджеры вместо автоматической постановки задач — при росте базы абонентов диспетчер физически не успевает распределять выезды, и время реакции на аварии растёт вместе с базой, а не остаётся стабильным.
И последнее — запускают сразу всё и сразу на всю базу абонентов. На моих внедрениях устойчивее работает поэтапный запуск: сначала воронка подключений на одном канале заявок, затем открытые линии поддержки, и только потом полная автоматизация диспетчеризации — так проще увидеть, что реально не работает, пока это не масштабировалось на всю компанию.