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