Что настраивается в Битрикс24 по карте вашего бизнеса

Свежий Битрикс24 - это пустая коробка с воронкой «новая - в работе - успех». Ниже разбор того, что в нем настраивается под конкретную фирму: воронки, поля, автоматические дела, права доступа. И три места, где автоматика ломается молча: ошибки нет, все выглядит настроенным, а робот не работает.

Воронки и стадии под цепочку заказа, а не «новая - в работе - успех»

Портал из коробки дает одну воронку сделок со стадиями общего вида. По ней нельзя ответить на вопрос, который директор задает каждый день: где сейчас заказ. «В работе» - это и замер, и цех, и ожидание оплаты, и клиент, который пропал.

Воронка начинает работать, когда ее стадии совпадают с реальными руками, через которые проходит заказ. У производства на заказ это обычно так: заявка, замер, расчет, договор и предоплата, производство, монтаж, окончательный расчет. Семь стадий вместо трех, и каждая - место, где заказ реально встает.

Воронок почти всегда нужно больше одной. Типичный набор: основные заказы, рекламации, отложенные заявки в духе «клиент вернется весной». Отложенные - самая недооцененная воронка: именно там лежат деньги, про которые вспоминают через год и случайно.

Поля: под то, что вы правда записываете

Стандартная карточка сделки знает сумму, ответственного и срок. Она не знает адрес объекта, дату замера, кто конструктор, номер договора, сколько внесено предоплаты. А это ровно те данные, ради которых менеджер держит параллельную тетрадь или файл на рабочем столе.

Поля добавляются программно (метод crm.deal.userfield.add и его аналоги для лидов, компаний и смарт-процессов). Сложность не в том, чтобы добавить, а в том, чтобы решить, какие поля обязательны. Двадцать обязательных полей - надежный способ добиться, чтобы менеджер заполнял их точками и прочерками.

Отдельно настраивается вид карточки: какие поля в каком блоке и в каком порядке. Смысл простой - чтобы до даты замера не надо было листать три экрана.

Смарт-процессы: для того, что не является сделкой

Замер, объект, рекламация, отгрузка, договор подряда - это не сделка, но у этого есть свой путь и свои стадии. В Битриксе такие сущности называются смарт-процессами, у них своя воронка и своя автоматика, и они привязываются к сделке.

Практический признак, что вам нужен смарт-процесс: вы пытаетесь запихнуть в карточку сделки поля «замер 1», «замер 2», «замер 3». Значит замеров у одного заказа бывает несколько, и это отдельная сущность, а не еще три поля.

Дело на каждой рабочей стадии: главное правило портала

Есть одно правило, без которого мы портал не сдаем.

На практике это значит: как только заказ переезжает на стадию, на нем автоматически появляется дело, осмысленное именно для этой стадии, с ответственным и сроком. На замере - назначить замер. На счете - проверить оплату. На производстве - подтвердить дату готовности. Не общее «связаться с клиентом», а то действие, которого требует именно этот шаг.

Правило появилось из разбора типичного отказа, и он выглядит одинаково почти везде. Крупный заказ висит три недели без единого действия. Менеджер на больничном, конструктор в отпуске, клиент пишет в личный вотсап человеку, которого нет на работе. Директор узнает последним и случайно, когда клиент уже ушел к другим.

Формально в CRM все было в порядке: сделка заведена, сумма проставлена, стадия указана. Не хватало одной вещи - у сделки не было следующего шага. И виноватого тоже нет: система не требовала, чтобы шаг был.

Почему именно дело, а не уведомление. Уведомление читают и забывают, оно нигде не висит и ни за кем не числится. У дела есть ответственный, срок и состояние «не сделано». Оно попадает в список дел человека и в отчет руководителя. Просроченное дело - это число, которое можно посмотреть, а не ощущение, что «что-то у нас буксует».

Скажем честно и про побочный эффект: правило делает видимым, у кого дела копятся. Часть сотрудников это встречает без восторга. Мы поэтому не начинаем внедрение с самых несговорчивых - но и правило не отменяем, потому что без него портал превращается в красивый список заказов, о которых никто не думает.

Почему робот, который ставит дело, обязан защищаться от дублей

Наивная реализация выглядит очевидной: бизнес-процесс с автозапуском при изменении сделки, внутри ветвление по стадиям, в каждой ветке свое дело. Он работает ровно один раз, а дальше начинает вредить.

Процесс с автозапуском на изменение стартует при каждом изменении сделки. Менеджер поправил телефон - запуск. Дописал комментарий в поле - запуск. Робот честно проверяет: стадия «монтаж»? да. И ставит дело. Снова. И еще раз.

За неделю активной работы это выливается в сотню одинаковых задач на человека. Дальше происходит предсказуемое: список дел перестают открывать вообще, потому что в нем мусор. Портал выключают на второй или третьей неделе, и почти никто не связывает это с роботом - обычно говорят «неудобная система».

Лечится отметкой. Заводится служебное поле, в которое процесс записывает код стадии, для которой дело уже поставлено. Условие ветки становится двойным: стадия равна «монтаж» И отметка не равна «монтаж». Поставил дело - записал отметку. Следующий запуск на той же стадии условие не проходит и молчит. Заказ вернули на предыдущую стадию и снова двинули вперед - отметка не совпадает, дело ставится заново, как и должно.

Две детали, которые видно только после того, как на них наступишь:

• Служебное поле надо прятать из карточки. Оно нужно роботу, а не менеджеру. Мы этот шаг однажды пропустили, и в карточке рядом с адресом объекта висела строка вида «Дело поставлено для стадии: C4:PREPAYMENT_INVOICE». Такое клиент замечает в первую же минуту и делает верный вывод о качестве работы.
• Поле-список сравнивается не по тексту. Если поле - выпадающий список, внутри процесса оно хранит номер варианта, а не его название. Условие «поле равно Нужен перерасчет» не срабатывает никогда, а условие «не равно» срабатывает всегда. Второе гораздо хуже: робот ложно срабатывает на каждой сделке подряд, и со стороны это выглядит как прекрасно работающий робот.

Родственная ловушка - пустое поле. Робот, который сравнивает дату монтажа с сегодняшней, при пустой дате ведет себя не так, как ожидает автор. Пустоту приходится проверять отдельной веткой, иначе тревога будет приходить по всем заказам, где дату просто еще не поставили.

Долгие паузы: почему больше одного отложенного процесса на сделке не живет

Это самое дорогое место, потому что ломается тихо и не там, где смотрят.

У Битрикса в облаке есть документированное ограничение: не больше двух бизнес-процессов одновременно на одном элементе CRM - сделке, лиде, контакте, компании, счете, смарт-процессе. Третий, по справке Битрикса, должен запуститься, когда освободится место. На нашем живом портале он не сработал вообще: дело не появилось, ошибки в логе не было, и главное правило портала сломалось молча. Поэтому мы не полагаемся на очередь. На роботов, привязанных к стадиям канбана, ограничение не распространяется, коробочной версии оно тоже не касается.

Пока процессы короткие, ограничение незаметно: они отрабатывают за секунды и уходят, освобождая место. Все меняется, когда внутри процесса стоит пауза. Процесс «напомнить про доплату через десять дней» занимает одно из двух мест на десять дней. Процесс «поднять тревогу, если заказ висит три дня» - второе. Места кончились.

С тех пор проектируем иначе:

• Долгоживущий процесс с паузой на сделке - максимум один. Это не рекомендация, а бюджет: два места всего, одно надо держать свободным под то, что ставит дела.
• Все, что можно сделать по событию, делается по событию - переход на стадию, изменение поля, входящее письмо. Такие процессы отрабатывают мгновенно и очередь не держат.
• Отложенные напоминания ставятся делом с датой в будущем, а не паузой внутри процесса. Дело спокойно ждет в календаре ответственного и ничего не блокирует.

Робот и бизнес-процесс - разные вещи, и разница важна

Здесь мы честно называем собственное ограничение. Настоящего робота на стадию канбана через программный интерфейс поставить нельзя: у Битрикса нет такого метода, а попытка загрузить шаблон с привязкой к стадии эту привязку молча теряет - шаблон создается, привязка исчезает. Поэтому наша автоматика ложится в раздел «Бизнес-процессы» и проверяет стадию условием внутри себя. По результату это то же самое дело в то же время; отличается пункт меню, в котором ее искать. Мы говорим об этом заранее, чтобы никто не удивлялся пустой вкладке роботов. И именно поэтому лимит двух процессов для нас не абстракция, а ежедневная арифметика.

Права доступа CRM - единственное место, где у Битрикса нет программного интерфейса

Права в CRM устроены ролями. Роль описывает, что человек может делать со сделками, лидами, контактами и компаниями: читать, добавлять, изменять, удалять, экспортировать, импортировать. И на каком объеме: только свои, свои и своего отдела, отдел вместе с подчиненными отделами, все.

Отдельными галочками включается то, о чем обычно вспоминают поздно: право видеть суммы на стадиях канбана, право менять настройки карточки, право управлять роботами, право двигать сделку по стадиям.

Почему это не мелочь. Без настроенных прав каждый сотрудник видит все сделки фирмы вместе с суммами и контактами клиентов. Монтажник видит наценку. Менеджер видит клиентов соседа. Уволившийся выгружает базу в файл одной кнопкой, потому что право на экспорт по умолчанию у него есть.

Практический вывод отсюда простой: права настраиваются тем же способом, каким их настраивает администратор - в интерфейсе, по экранам ролей. Это надо заложить в работу и не обещать, что права возникнут сами. Если вам говорят «мы настраиваем портал полностью автоматически», уточните отдельным вопросом, входят ли туда права доступа.

Что проверяется перед сдачей портала

Мало убедиться, что все заказанное на месте. Отдельная проверка - что на портале нет ничего лишнего.

Мы на этом однажды попались, и рассказываем, потому что урок дорогой. Собирая процессы, мы взяли за образец файл процесса с другого портала. Внутри такого файла хранится список полей документа, а там их было больше пятисот. При загрузке шаблона Битрикс аккуратно создал их все. В карточке компании, которая ни про какие сервисы коллтрекинга и подбора персонала не слышала, появились под две сотни чужих полей с названиями вроде «На проверке РОП» и «Время второй реакции по счету». Заметил это владелец, глядя на готовый портал, а не мы при сдаче.

Теперь перед сдачей мы считаем: сколько полей, воронок, стадий, смарт-процессов и шаблонов процессов на портале, и сверяем с тем, что заказывалось. Все сверх - мусор, который занесли мы, и его надо убрать до того, как клиент откроет карточку.

Вторая обязательная проверка - контрольная сделка. Заводим фиктивный заказ, прогоняем по всем стадиям, смотрим: дела ставятся, дубли не появляются, тревоги срабатывают там, где должны, и молчат там, где не должны. После проверки сделку удаляем. Только после этого говорим «работает».

Читать и ничего не решать - нормально. Если хотите сначала понять, с кем имеете дело, посмотрите на странице про подрядчиков раздел «Чего мы не делаем» и признание, что живых клиентов у нас пока нет. А чтобы время не пропало, ответьте себе на шесть вопросов о своей фирме со страницы про карту бизнеса. Оставлять нам ничего не надо: формы на сайте нет.