Заявки приходили в шесть разных мест
Два аккаунта на площадке объявлений, сайт, телефон, мессенджеры, сообщество в соцсети. Чтобы понять, сколько обращений было за неделю, приходилось заходить в каждый источник по очереди.
Компания до десяти человек в Москве делает дизайн-проекты, ремонт под ключ, комплектацию и авторский надзор. Пришли не с проблемой, а с задачей: собрать заявки из шести источников в одно место и сделать работу каждого сотрудника видимой.
Ни одной цифры про рост выручки здесь не будет, и это осознанно: компания внедряла систему не для роста. Подробно объясняем в конце.
Редкий случай, когда компания обращается не в кризис. Бизнес шёл нормально, заявки обрабатывались, клиенты были довольны. Просто собственник понимал, что дальше так работать неудобно.
Два аккаунта на площадке объявлений, сайт, телефон, мессенджеры, сообщество в соцсети. Чтобы понять, сколько обращений было за неделю, приходилось заходить в каждый источник по очереди.
Дизайн-проект, ремонт, комплектация и авторский надзор — разные работы с разными сроками и деньгами. Но в учёте они не различались, и понять экономику каждой было нельзя.
Кто чем занят, какой клиент на каком этапе, что запланировано на завтра — всё это выяснялось разговорами. При десяти сотрудниках это ещё возможно, но отнимает время каждый день.
Доходы и расходы по объектам велись вне системы. Связать конкретный заказ с тем, сколько он принёс и во что обошёлся, можно было только вручную.
Договорённости с клиентом, детали объекта, история переписки — у того, кто вёл заказ. Коллеги узнавали подробности, спросив у него лично.
Главная задача, как её сформулировал собственник: чтобы вся компания находилась в одном месте и видела одну и ту же картину.
Первое, что сделали, — свели все каналы в систему. Обращение попадает в CRM автоматически, получает ответственного и не зависит от того, кто и когда заглянул в конкретный аккаунт.
Отдельная тонкость — два аккаунта на одной площадке объявлений. Заявки из обоих приходят в общую воронку, но источник сохраняется: видно, какой аккаунт работает лучше и стоит ли держать оба.
Услуги продаются по отдельности: клиент может заказать только дизайн-проект, а ремонт делать с другим подрядчиком. Может прийти с готовым проектом сразу на ремонт. Поэтому каждая услуга получила свой контур со своими стадиями.
Замеры, концепция, согласование, рабочая документация. Цикл длинный, с несколькими кругами правок — и каждый круг важно видеть, чтобы понимать, где проект застрял.
Основная услуга с самым долгим циклом и самыми большими суммами. Смета, договор, этапы работ, приёмка. Здесь же ведутся расходы по объекту.
Подбор и закупка материалов, мебели, техники. Своя логика: много позиций, сроки поставок, зависимость от поставщиков.
Сопровождение чужого ремонта по своему проекту. Короткие регулярные выезды вместо непрерывной работы — совсем другой ритм, чем у остальных услуг.
Отдельно собрали смарт-процессы по доходам и расходам. Деньги привязаны к конкретным заказам, поэтому видно не только выручку, но и то, что осталось после затрат по каждому объекту.
Для этой отрасли у нас уже существовало готовое решение — оно опубликовано в Маркетплейс Битрикс24. Поэтому на встрече мы показали не схему на словах, а работающий прототип: вот как будет выглядеть система.
Дальше обсудили, что подключать из каналов, скорректировали предложение под особенности студии и заключили договор. Разговор занял заметно меньше времени, чем обычно, — потому что обсуждать было что конкретное, а не абстрактные возможности.
Важная оговорка: готовое решение — это отправная точка, а не итог. Под студию мы его меняли: своя структура услуг, свои каналы, свои финансовые процессы. Внедрять шаблон без правок мы не беремся — даже одинаковая отрасль не означает одинаковых процессов.
Больше не нужно обходить шесть источников. Появилась цифра, которой раньше не было: сколько обращений приходит на самом деле и откуда.
Кто чем занят, какой клиент на каком этапе, что запланировано дальше. Ежедневные опросы «что у тебя происходит» стали не нужны.
Понятно, сколько дизайн-проектов в работе, сколько объектов на ремонте и как это соотносится. Раньше всё было общим списком дел.
Доходы и расходы привязаны к заказам. Видно не только выручку, но и что остаётся после затрат по каждому объекту.
Договорённости и детали объекта хранятся в карточке, а не в голове того, кто вёл заказ. Подхватить чужого клиента стало возможно.
Главная задача, ради которой всё затевалось. Вся компания видит одну картину и работает в одном месте.
Прошёл год. Штат не увеличился, обороты кратно не выросли. Если мерить проект привычными для рынка мерками, он выглядит неудачным — и мы всё равно считаем его удачным.
Рост компании зависит от собственника, а не от системы. Этот собственник расти не хочет — ему комфортно на текущем масштабе. Это абсолютно нормально.
Систему внедряли не ради роста. Задача формулировалась иначе: чтобы всё было в одном месте, чтобы работа каждого сотрудника была прозрачной, чтобы компания находилась в едином информационном поле. Всё это получилось — значит проект достиг своей цели.
И вот что мы хотим сказать отдельно: это и есть главная причина внедрения CRM в большинстве случаев. Не удвоение выручки, а порядок. Не взрывной рост, а возможность спокойно работать, не держа всё в голове и не выясняя каждое утро, что у кого происходит.
Обещание роста от внедрения — самое распространённое и самое лукавое на рынке. Система не создаёт спрос и не приводит клиентов. Она убирает потери, делает работу видимой и снимает с людей необходимость всё помнить. Превратится это в рост или в спокойствие — решает владелец бизнеса.
У нас есть ещё один такой кейс: международная логистика, компания работает в прежних объёмах тем же составом и не собирается меняться. Два проекта подряд с одинаковым финалом — это уже не исключение, а закономерность, о которой стоит говорить вслух.
Зависит не от размера, а от числа источников заявок и от того, ведут ли клиентов несколько сотрудников. Если обращения приходят из пяти-шести мест, а заказы ведут разные люди, порядок нужен уже сейчас. В этом проекте компания до десяти человек, и система оказалась оправданной — но она получилась простой, без лишнего.
Если каждая услуга может быть продана сама по себе — это отдельная воронка. Клиент может заказать только дизайн-проект, а ремонт делать с другим подрядчиком; может прийти с готовым проектом сразу на ремонт. Вести их в одном контуре означало бы не видеть ни одну: показатели смешиваются, а половина стадий не относится к конкретному заказу.
Да, и заявки из них можно направлять в общую воронку, сохраняя источник. Это удобно, когда аккаунты работают на разные направления или регионы: обработка единая, а статистика раздельная — видно, какой аккаунт приносит больше и стоит ли держать оба.
Через отдельные процессы доходов и расходов, привязанные к заказам. Тогда по каждому объекту видно не только сумму договора, но и затраты: материалы, работы подрядчиков, прочие расходы. В ремонте это особенно важно, потому что смета почти всегда меняется по ходу работ.
Для ряда отраслей у нас собраны готовые прототипы, часть опубликована в Маркетплейс Битрикс24. Мы показываем их на первой встрече, чтобы разговор шёл о конкретном, а не о возможностях вообще. Но внедрять шаблон без изменений мы не беремся: это отправная точка, которую мы правим под вашу компанию.
В этом проекте обучение и сопровождение заняли два месяца. Само обучение — одна-две встречи, дальше регулярные разборы живой работы: где неудобно, что не получается, что стоит поправить. Одно занятие даёт знание, но не привычку, — поэтому часы на сопровождение мы закладываем в проект сразу.
Если обращения идут из нескольких источников, а услуг у вас больше одной — посмотрим процесс и покажем, как собрать это в одну систему. Рост обещать не будем: скажем честно, что изменится. Встреча на 40 минут, без обязательств продолжать.