60 дней фильмов и сериалов
по промокоду:
VC60
Забрать
60 дней подписки Яндекс Плюс бесплатно для новых пользователей, ранее не оформлявших подписку Яндекс Плюс либо подписки, её включающие, при условии привязки банковской карты. Далее — автопродление: 199 ₽/месяц. Действует на территории РФ. Активировать до 31.10.2021 г. https://hd.kinopoisk.ru/gift. Условия: clck.ru/FMQND.

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

В жизни любого диджитал-продакшена есть множество мелких сделок за которыми следует регулярно следить, продлять, делать документы. В нашем агентстве “5 УГЛОВ” эти сделки мы называем инфраструктурными и к ним относятся:

  1. Оплата и продление доменов
  2. Оплата хостинга
  3. Продление различных лицензий
  4. Аренда публичных WiFi-точек доступа
  5. Техническое обслуживание серверов и сайтов
  6. Продление SSL-сертификатов

Основные проблемы и сложности при ведении таких сделок:

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

Долгое время у нас была отдельная или совмещающая роль по ведению таких инфраструктурных сделок на ком-то из менеджеров. У него была простая гугл-табличка, где не хитрыми манипуляциями проставлялась вся необходимая информация.

Учет проектов на базе Google-таблиц

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

  • Нет никакой автоматики, которая бы напомнила клиенту о необходимости продлить услугу
  • Счета и закрывающие документы приходилось делать и отправлять вручную
  • Приходилось вручную отключать услугу за неуплату и включать, после оплаты
  • Человеческий фактор из-за которого постоянно что-то факапилось

Конечно, можно было использовать какую-нибудь хостинговую панель с модулем биллинга для этих целей, но, во-первых, не хотелось использовать еще один софт в нашем “зоопарке”, а, во-вторых, хостинговая панель не закрывала все наши потребности, но и добавляла дополнительные проблемы как то учет дебиторки, интеграции в бухгалтерию и т.п. Все-таки мы не хостинговая компания и процессы у нас настроены на другое.

Мы специализируемся на продуктах компании 1С-Битрикс и уже много лет используем коробочный корпоративный портал Битрикс24. Для нас, самым простым было бы реализовать логику управления инфраструктурными сделками на базе Битрикс24. Сказано - сделано!

Дисклеймер: Многие идеи можно было реализовать в Битрикс24 по-разному. Если вы захотите поспорить или узнать подробности конкретного решения, то пишите в личку или в комментарии.

Ниже я опишу наш опыт и подход использования Битрикс24 для автоматизации инфраструктурных сделок.

Описание требований и вводных данных

  • У нас 2 юридических лица с разными налоговыми режимами. У инфраструктурных сделок должна быть привязка к юрлицу и налоговому режиму.
  • Счета мы выставляем в CRM Битрикс24
  • У нас аутсорсная бухгалтерия, которая может готовить закрывающие документы по сформированному заданию.
  • Сотрудники - администраторы, которые занимаются отключением или продлением услуг, работают в Битрикс24
  • Необходимо чтобы за основным процессом следила автоматика, а человек подключался только для важных и ответственных задач.

Описание решения

Для начала необходимо в CRM создать отдельное направление сделок. Это позволит работать с ними автономно от других сделок и направлений компании.

В этом направлении мы создали следующие стадии сделок:

  1. Необходимо продление
  2. Создание акта
  3. Ожидание оплаты
  4. Продление (штатное)
  5. Продление (после отключения)
  6. Услуга продлена
  7. Отключение
  8. Услуга оказывается
  9. Контракт закрыт
  10. Услуга отключена

Такой набор стадий появился исторически, после проб и ошибок. Ниже опишу каждую стадию и что на ней происходит.

Необходимо продление

Техническая стадия для только что созданной сделки. На этой стадии ничего не происходит и ее удобно использовать при создании новой сделки.

Создание акта

В эту стадию сделка переводится автоматически всякий раз, как только создается и отправляется клиенту новый автоматический счет (т.е. когда предыдущая услуга полностью оказана). В этой стадии, если связанный со сделкой счет не закрыт актом (не проставлен чекбокс в соответствующем поле в счете), то отправляется заявка в бухгалтерию на создание и отправку акта клиенту. И далее сделка автоматически переводится в стадию Ожидание оплаты. Если у вас 1С или штатный бухгалтер, то это тоже можно реализовать.

Пример признака закрыт ли счет актом.

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

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

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

В эту стадию сделка переходит после автоматического создания и отправки счета клиенту. Далее срабатывает таймер и через 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.
  • Правила и условия в Роботах очень примитивные. Хотелось бы больше гибкости в настройках.

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

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

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

{ "author_name": "Павел Ларкин", "author_type": "self", "tags": [], "comments": 15, "likes": 4, "favorites": 39, "is_advertisement": false, "subsite_label": "life", "id": 150781, "is_wide": true, "is_ugc": true, "date": "Mon, 17 Aug 2020 16:40:08 +0300", "is_special": false }
0
15 комментариев
Популярные
По порядку
Написать комментарий...
0

А что в итоге сэкономило 480к?

Ответить
1

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

Ответить
0

Погодите, но сначала надо посчитать ваше время и "деньги" которые вы потратили на реализацию такой логики. Также для работы по такой логике все равно какие-то затраты ресурсов требуются. То есть вот прямо так сходу 480 т.р в первый год не заработали ;).

Ответить
0

Илья, пройдя этот путь перенести все это ну другой портал можно за несколько часов. Т.е. на повторение пройденного пути требуется гораздо меньше времени. :)

Но вы, конечно же, правы. 

Ответить
0

У меня, кроме роботов, к Битрикс прикручено несколько простейших скриптов на питоне, которые запускаются каждый час и, используя REST API Битрикса, выполняют следующие задачи:

1. Постановка задач на сделки, на которых они отсутствуют (у нас работа поставлена так, что менеджер в течение рабочего дня идёт по списку задач, выполняя старую и создавая новую, поэтому сделка без задачи - потерянная сделка)

2. Возврат сделок со стадии "Отложенные" при наступлении даты возврата сделки (отправка в отложенные - наш способ не захламлять воронку сделками, где клиенту нужно дозреть)

3. Назначение ответственный за контакт по сделке ответственного по самой сделке (иначе при переносе сделки с одного ответственного на другого новый ответственный не будет иметь доступа к данным контакта по сделке)

4. Выгрузка данных по сделкам в файлы, которые потом засасываются в Tableau для построения дэшбордов по воронка.

Использование связки Битрикс + Python сильно развязало руки.

Ответить
0

Алексей, есть вопросы по вашему комменту:
1. А какую задачу ставит скрипт? В штатном Битриксе есть счетчик, который загорается, если по сделке нет следующего дела. 
2. А почему не сделали штатной задачей "пингануть" заказчика через ХХХ дней или Ожидание ХХХ дней? ИМХО методологически не верно менять статус у таких сделок т.к. после 1 пинга может оказаться, что она еще отложена и ее трогать не стоит.
3. По-моему, есть модуль в маркетплейсе, который делает эту операцию. 

Ответить
1

1. Задачу "Вернуться к сделке". Счетчик есть, но он неудобен - у продавцов основной экран "Мои дела", где этого счетчика нет.

2. Сделка возвращается ровно в ту дату, до которой она была отложена (указывается пользователем). Если после контакта с клиентом оказывается, что нужно подождать еще, то откладываем опять с новой датой возврата.

Альтернативным решением было бы действительно поставить задачу на ожидание, и не трогать этап сделки. Однако гораздо удобнее понимать, насколько загружен продавец, когда сделки в ожидании у него вычищены из воронки и складируются на этапе "Отложенные" (который находится группе этапов "Проигранные").

3. Уже поздно :)

Ответить
0

Однако, получается для реализации этой схемы нужны еще сторонние средства и компетенции в Python.
В той системе с которой я работаю (не знаю можно ли её по правилам vc ) это все реализуетcя штатными средствами использованием специального статуса Отложенная, с указанием даты когда "сделка/задача" должна вернуться в текущий статус, для продолжения работы с ней. 

Ответить
0

Да, у меня в Битрикс24 тоже было настроено штатными средствами - пользовательскими полями и роботами - пока я не понял, что роботы выполняются один раз на сделку и цикл отправки в отложенные и возврата можно сделать только один раз. :(

Ответить

Яркий ихтиандр

0

Это все прекрасно. А как работает система если приходит частичная оплата или оплата сразу не поскольким счетам или обезличенная оплата (без четкого назначения платежа)?

Ответить
0

Василий, отвечу по пунктам:
1) Если приходит частичная оплата, то сценарий не идет дальше, пока счет полностью не будет оплачен. Т.е. если домен, условно, стоит 1000 рублей, то если оплатят 500 руб, то ничего не произойдет (кроме статуса счета, что он оплачен частично). Как только поступит полная оплата по счету, то сработает триггер и сделка переведется в "Продление". А если полной оплаты не поступит, то услуга будет отключена.
2) Обезличенная оплата или оплата сразу по нескольким счетам это всегда геморрой. :( Ну скорее это всегда геморрой для бухгалтера, который разносит платежи и ему приходится угадывать за что была оплата. И это проблема платежной дисциплины со стороны клиента ибо во всех счетах написано красным по белому - указывайте номер счета, который оплачиваете. Как правило, это быстро лечится, когда отключишь 1 раз такого клиента с формулировкой "Автоматика не распознала ваш платеж и отключила. Ваш же просили в каждом платеже указывать реквизиты счета." Для адекватных заказчиков этого достаточно. :)

А для описанной системы все равно - триггеры на оплату срабатывают только когда у связанного со сделкой счетом меняется статус на ОПЛАЧЕН.

Ответить

Яркий ихтиандр

Павел
0

Спасибо. Все платежи привязываются бухгалтером или распознаются и разносятся по сделкам роботом?

Ответить
1

У нас все кассы проверяются бухгалтером и в ручную проставляются оплаты у счетов в CRM. Но для некоторых банков есть модули для Битрикс24, которые обещают автоматическое получение выписки по счету и распознавание счетов. Естественно, если в назначении платежа явно указан счет и сумму.

Ответить
0

Хороший пример. Есть несколько комментариев к процессу и к особенностям реализации в Б24 (с настройкой Б24 не знаком) .
1. В тексте часто упоминается связь с ключевыми словами в названии задачи, а в сделку нельзя добавить "справочник" и специальное поле характеризующее услуги и по значению этого поля уже запускать "роботов"?
2. Мне логичнее акт составлять не в новой задаче продление услуги, а в той задаче по которой услуга была оплачена, то есть задача стартует с выставления нового счета и заканчивается выставлением акта (после этого закрывается). При этом по одной клиенту, по одной услуге одновременно есть две "активных задачи" одна за прошлый период по которой нужно выставить документы и вторая уже на следующий период по которой только ждем оплаты. Это бы более точно соответствовало жизненному циклу взаимодействия с Клиентом.    

Ответить
0

1. Можно, но проще придумать костыль из правил наименования сделок. Например, есть услуга: "Хостинг домена ya.ru" Если договориться всегда писать услуги=названия сделки в таком формате, то потом очень просто любые штатные фильтры делать по ключевому слову из названия сделки, а так же вставлять прям название сделки в любые автоматические письма. Например, "Уважаемый клиент, Хостинг домена ya.ru отключен!" Причем для этой логики не важно что вы занесете в справочник т.к. она универсальна.

2. Задачу можно решить разными способами, как техническими, так и на уровне логики процесса. Мы выбрали для себя метод, описанный в статье. :)

Ответить

Комментарий удален

Читать все 15 комментариев
Первое место в App Store уже не признак качества: теперь приложения «поднимают» блогеры из рекламных сервисов Статьи редакции

Вот как это работает на примере приложения с индивидуальными шрифтами.

Запивать еду чаем или кофе не вредно — кофеин не мешает усвоению витаминов и минералов Статьи редакции

Материал издания Reminder.

Что может быть важнее прибыли. ESG-словарь для инвестора

В 2020–2021 гг. резко возросла популярность темы ответственного инвестирования, или ESG. Идея о том, что инвестиции должны не только приносить прибыль, но и поддерживать экологию и социальную справедливость, привела к тому, что ESG-фонды стали играть значимую роль на мировых рынках капитала.

Конференция GoGlobal! соберет ведущих маркетологов

29 сентября 2021 года впервые состоится GoGlobal! — однодневная онлайн-конференция для маркетологов, заинтересованных в ускорении глобального присутствия своих кампаний.

«Вам звонок из Циан»: зачем компания скупает номера телефонов и как call-tracking помогает клиентам сервиса

Подменные номера телефонов защищают от нежелательных звонков и упрощают аналитику продаж

Как работать удалённо по московскому времени, если живёшь в Сибири

Команда ИТ-компании Southbridge — о преодолении трудностей часовых поясов: графике работы, планировании и отдыхе.

«Яндекс» оставляет только положительные отзывы о своих сервисах

После ситуации с не доставленным заказом из Яндекс Лавки, я оставил отзыв на сервисе Карт. Его приняли и разместили, но доступен он только для аккаунта, с которого я его оставлял)))

Дайджест новостей Сбера: AR-экскурсия, распознавание животных и премия для учёных

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

Я задолбался пропускать интересные статьи на vc.ru и создал Capitan

Это самый удобный рабочий стол для браузера

Инвестиции разрушили дух общины: гостевая сеть Couchsurfing хотела быть бесплатной Airbnb, но стала корпорацией Статьи редакции

Идейный лидер привлёк инвестиции и передал управление менеджерам, которые растратили их впустую и погубили философию безвозмездного культурного обмена. Как это отразилось на сотрудниках и пользователях сервиса — в пересказе материала Input.

Команда Couchsurfing в Мексике в 2010 году Эндрю Отто
null