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