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