Стадия, в которую переводится сделка, после стадии Услуга продлена. Тут оказался еще один нюанс - такие услуги как, например, хостинг правильно закрывать актом после того как услуга оказана, т.е. в последний день. Именно для этого мы сделали в начале стадию Создание акта, которая запускается после создание нового счета (а значит предыдущий период был полностью закрыт). Но есть услуги, которые следует закрывать сразу, например, продление домена, SSL-сертификата, поставку лицензий. Вот для таких сделок мы сделали специальную проверку названия сделки и, если там встречаются ключевые слова "Домен", "SSL", "Лицензия", то запускается точно такой же бизнес-процесс по созданию закрывающих документов, как на стадии Создание акта.
А что в итоге сэкономило 480к?
Судя по всему вы не дочитали статью. Цитирую из выводов:
Больше не нужна отдельная роль по контролю за инфраструктурными сделками. Даже если взять минимальную оплату такого человека в 40 000 рублей в месяц, то по году это экономия в 480 000 рублей! А сэкономил - считай заработал! :)
У меня, кроме роботов, к Битрикс прикручено несколько простейших скриптов на питоне, которые запускаются каждый час и, используя REST API Битрикса, выполняют следующие задачи:
1. Постановка задач на сделки, на которых они отсутствуют (у нас работа поставлена так, что менеджер в течение рабочего дня идёт по списку задач, выполняя старую и создавая новую, поэтому сделка без задачи - потерянная сделка)
2. Возврат сделок со стадии "Отложенные" при наступлении даты возврата сделки (отправка в отложенные - наш способ не захламлять воронку сделками, где клиенту нужно дозреть)
3. Назначение ответственный за контакт по сделке ответственного по самой сделке (иначе при переносе сделки с одного ответственного на другого новый ответственный не будет иметь доступа к данным контакта по сделке)
4. Выгрузка данных по сделкам в файлы, которые потом засасываются в Tableau для построения дэшбордов по воронка.
Использование связки Битрикс + Python сильно развязало руки.
Алексей, есть вопросы по вашему комменту:
1. А какую задачу ставит скрипт? В штатном Битриксе есть счетчик, который загорается, если по сделке нет следующего дела.
2. А почему не сделали штатной задачей "пингануть" заказчика через ХХХ дней или Ожидание ХХХ дней? ИМХО методологически не верно менять статус у таких сделок т.к. после 1 пинга может оказаться, что она еще отложена и ее трогать не стоит.
3. По-моему, есть модуль в маркетплейсе, который делает эту операцию.
Однако, получается для реализации этой схемы нужны еще сторонние средства и компетенции в Python.
В той системе с которой я работаю (не знаю можно ли её по правилам vc ) это все реализуетcя штатными средствами использованием специального статуса Отложенная, с указанием даты когда "сделка/задача" должна вернуться в текущий статус, для продолжения работы с ней.
Это все прекрасно. А как работает система если приходит частичная оплата или оплата сразу не поскольким счетам или обезличенная оплата (без четкого назначения платежа)?
Василий, отвечу по пунктам:
1) Если приходит частичная оплата, то сценарий не идет дальше, пока счет полностью не будет оплачен. Т.е. если домен, условно, стоит 1000 рублей, то если оплатят 500 руб, то ничего не произойдет (кроме статуса счета, что он оплачен частично). Как только поступит полная оплата по счету, то сработает триггер и сделка переведется в "Продление". А если полной оплаты не поступит, то услуга будет отключена.
2) Обезличенная оплата или оплата сразу по нескольким счетам это всегда геморрой. :( Ну скорее это всегда геморрой для бухгалтера, который разносит платежи и ему приходится угадывать за что была оплата. И это проблема платежной дисциплины со стороны клиента ибо во всех счетах написано красным по белому - указывайте номер счета, который оплачиваете. Как правило, это быстро лечится, когда отключишь 1 раз такого клиента с формулировкой "Автоматика не распознала ваш платеж и отключила. Ваш же просили в каждом платеже указывать реквизиты счета." Для адекватных заказчиков этого достаточно. :)
А для описанной системы все равно - триггеры на оплату срабатывают только когда у связанного со сделкой счетом меняется статус на ОПЛАЧЕН.