Автоматизация в Битрикс24, сэкономившая 480 000 руб. в год

Бизнес-процесс "Создание акта".

Ожидание оплаты

В эту стадию сделка переходит после автоматического создания и отправки счета клиенту. Далее срабатывает таймер и через 7 дней клиенту дублируется письмо с повторным счетом. За 3 дня до отключения письмо дублируется последний раз. Если за 14 дней оплата так и не поступила, то стадия автоматически меняется на Отключение.

Логику реализовали через бизнес-процессы:

Бизнес-процесс "Ожидание оплаты".

Продление (штатное)

В эту стадию переводится сделка, если клиент оплачивает счет в период ожидания оплаты счета. Если сделка содержит фразу "Хостинг", "ТО", "WiFI", то сделка сразу меняется на стадию Услуга продлена т.к. это наши услуги и продлевать их нет смысла. Во всех остальных случаях ставится задача на системного администратора на продление услуги (домены, SSL, лицензии).

Продление (после отключения)

В эту стадию переводится сделка, если клиент оплачивает счета когда мы уже отключили услугу. На ней ставится задача на системного администратора по включении услуги.

Разделение стадии на 2 произошло исторически, когда стало понятно, что по процессам продление продлению рознь и что в каждом случае нужна своя логика. :)

Всю логику реализовали на штатных роботах.

Роботы стадий "Продление".

Услуга продлена

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

Отключение

В эту стадию сделка переводится, если клиент не оплатил выставленный счет после двух недель ожидания. Если название сделки содержит фразы "Домен", "SSL", "Лицензия", то стадия автоматически меняется на Услуга отключена, т.к. услуга блокируется за неуплату автоматически третьей стороной (не нами). Для всех остальных сделок ставится задача на админа по отключению услуги.

Услуга оказывается

Стадия, в которую переводится сделка, после стадии Услуга продлена. Тут оказался еще один нюанс - такие услуги как, например, хостинг правильно закрывать актом после того как услуга оказана, т.е. в последний день. Именно для этого мы сделали в начале стадию Создание акта, которая запускается после создание нового счета (а значит предыдущий период был полностью закрыт). Но есть услуги, которые следует закрывать сразу, например, продление домена, SSL-сертификата, поставку лицензий. Вот для таких сделок мы сделали специальную проверку названия сделки и, если там встречаются ключевые слова "Домен", "SSL", "Лицензия", то запускается точно такой же бизнес-процесс по созданию закрывающих документов, как на стадии Создание акта.

Ну и в качестве “вишенки на торте” на этой стадии мы изменяем сумму сделки на сумму всех оплаченных и закрытых актами счетов. Это позволяет сразу видеть сколько денег “занес” нам тот или иной клиент. Мелочь, а приятно. :)

Код, собирающий в переменную сумму всех оплаченных счетов.

Контракт закрыт

Это чисто техническая стадия, которую мы никогда не используем т.к. она является штатной финальной успешной стадией в сделках. Если перевести в нее сделку, то она исчезает из представления сделок в качестве Канбана т.к. CRM считает сделку завершенной и недостойной внимания. :)

Услуга отключена

В эту стадию переводится сделка после отключения услуги админом или автоматически, для сделок с названиями "SSL", "Домен", "Лицензия". Клиенту отлетает письмо о том, что услуга отключена и что для возобновления необходимо связаться с техподдержкой.

Автоматическое письмо об отключении услуги.

Все направление инфраструктурных сделок выглядит следующим образом:

Направление сделок "Инфраструктурные сделки".

Теперь пару слов о том, как заставить это все работать на регулярной основе.

1. На 1 услугу должна быть 1 сделка.
2. Каждая сделка должна иметь стандартизованное название состоящее из названия услуги и домена. Например, Хостинг www.mysite.ru. Это нужно для настройки правил в роботах по ключевым словам из названия сделки, а так же для использования переменных в шаблонах писем.
3. В самой сделке и в счете нужно создать пользовательское поле Номер и дата договора, которое будет подставляться в шаблон счета и отправляемых письмах, чтобы в документах всегда была ссылка на нужный договор.
4. Сама периодичность задается через создание регулярных счетов в конкретной сделке. При создании регулярного счета необходимо использовать заранее созданный почтовый шаблон, чтобы все выглядело максимально красиво.

Что в итоге получилось?

На самом деле получилось очень классно!

Вот основные преимущества от этого решения:

• Зайдя в нужное направление сразу видишь в какой стадии находятся те или иные сделки\услуги
• Зайдя в нужную сделку\услугу сразу видишь всю историю по этой сделке, включая уведомления клиенту, прочитал ли он это уведомление, задачи администратору или телефонные звонки от клиента.
• Больше не нужно следить или переживать отправлен ли счет клиенту, получил ли он уведомление, что завтра услуга будет отключена за неуплату, вовремя ли отключили услугу или спустя неделю, когда “дошли руки”. А раз отключения происходят неминуемо, то и платежная дисциплина сразу возросла до небес!
• Больше не нужна отдельная роль по контролю за инфраструктурными сделками. Даже если взять минимальную оплату такого человека в 40 000 рублей в месяц, то по году это экономия в 480 000 рублей! А сэкономил - считай заработал! :)

Таймлайн по сделке - видна вся история.

Но есть и проблемы у этого решения:

• Регулярные счета в Битрикс24 не умеют автоматически изменять период в теле услуги. Т.е. не удастся написать что-то типа: “Хостинг за август 2020”, т.к. это формулировка будет тупо копироваться из месяца в месяц.
• Автоматические е-мейл сообщение при создании регулярного счета почему-то не сохраняется в таймлайне сделки. Мелочь, а неприятный баг со стороны Битрикс24.
• Правила и условия в Роботах очень примитивные. Хотелось бы больше гибкости в настройках.

В статье описали не все подробности нашего решения, а только основной вектор реализации. Для компании, занимающийся разработкой на Битрикс, повторить это решение делов на несколько часов работы.

Если у вас остались вопросы по решению или есть предложение как его можно улучшить, то жду комментариев.

Также было бы интересно узнать как у вас в компании реализована работа с такими регулярными инфраструктурными сделками.