В этом уроке рассмотрим автоматизацию по смарт-процессу с регистрациями волонтеров.
Рабочий процесс выглядит так:
- волонтеры регистрируются на мероприятия;
- Лидер связывается с волонтером для подтверждения участия и переводит регистрацию на стадию «Подтвердил участие»;
- Лидер перемещает регистрации волонтеров по факту пришедших на мероприятие на стадию «Участвовал»;
- волонтеры, пришедшие на мероприятие, получают ссылки на форму отчета;
- завершается работа по регистрации после подтверждения отчета от волонтёра.
Автоматизируем рабочий процесс, конкретные требования рассмотрим в деталях на каждой стадии смарт-процесса.
Автоматизация по регистрациям
25 мин
1) НОВАЯ РЕГИСТРАЦИЯ
Обработка новой регистрации – довольно объемный этап!
Реализуем требования:
- Название установить по шаблону «Регистрация: [Фамилия] – [Название мероприятия]».
- Регистрации должны корректно создаваться как через CRM-форму, так и в интерфейсе Битрикс24.
- Проверить данные: волонтер указан, дата мероприятия не в прошлом, это не повторная регистрация. Если данные некорректны, то уведомить ответственного, что конкретно не так, и перенести регистрацию на соответствующую стадию.
- Неразобранные регистрации переводятся в финальную стадию на следующий день после проведения мероприятия.
В этом шаблоне БП также раскроем технические моменты, которые бизнес-заказчик знать не может, а специалист должен учитывать.
Решим технические задачи:
- синхронизировать значения двух полей регистрации с ID мероприятия;
- создать технические поля для использования в фильтрах в настройках действий;
- учитывать в автоматизации, что дата проведения мероприятия может измениться.
Весь шаблон на стадии будет такой:
Разберём его ниже по частям.
Два способа создания регистрации
Когда заполняется CRM-форма регистрации, то в элементе смарт-процесса, в специальном строковом поле, сохраняется ID мероприятия (для этого ранее настроили скрытое поле в форме и добавили ID мероприятия в ссылку регистрации).
Этого недостаточно для удобства пользователей Битрикс24 и не даст использовать возможности Битрикс24 по связанным смарт-процессам.
Если же создавать регистрацию в Битрикс24, то сотруднику, конечно, удобнее указать мероприятие в специальном поле, реализующим связь смарт-процессов, чем искать ID и заполнять его как строчку.
Поэтому, если мероприятие создано через форму, продублируем значение мероприятия в стандартное поле-связь между смарт-процессами. И, наоборот, если регистрацию создали в Битрикс24, то сотрудник заполнял поле-привязку, значит продублируем ID мероприятия в техническое поле.
Обработка двух вариантов создания регистрации решается вот такой схемой БП:
В зависимости от того, какое поле заполнено - ID или мероприятия - запустится соответствующая ветка, в которой заполняем другое поле.
Техническое поле "ID контакта"
Обратите внимание на настройку действий выше - значение контакта дублируется в техническое поле "ID контакта".
Такое решение требуется из-за особенности в настройках действий. В некоторые фильтры не получится передать контакт из стандартного поля, поэтому сохраним его ID в техническое поле.
Подготовка данных
Рассмотрим шаблон чуть больше, в рамках этой схемы решим еще несколько задач по подготовке данных для дальнейшей работы БП.
Название элемента
Устанавливаем название элемента смарт-процесса по шаблону:
Данные мероприятия
С помощью действия "Получить информацию о привязанном элементе" получим данные мероприятия, на которое пришла регистрация: дату проведения, ссылки на формы и т.д. Они нам потребуются дальше для проверки корректности регистрации.
Обращаться к полученным значениям будем через форму вставки значения, выбирая раздел "Дополнительные результаты".
Полезно
Обратите внимание на поле «Дата проведения мероприятия». Это часто используемое значение, от него вычисляются сроки выполнения задач, ожидания для автоматики и т.д.
Заманчиво сохранить это поле в регистрации и не получить его каждый раз из мероприятия – непонятное предложение. Но дата проведения может измениться, а в регистрации останется старое значение.
Поэтому либо в каждом шаблоне БП нужно получать дату из мероприятия (в нашем примере будет использован этот способ), либо при изменении мероприятия обновлять дату во всех связанных регистрациях.
Данные для проверки на дубль
Наверняка кто-то из волонтеров по ошибке отправит форму регистрации повторно. Автоматика должна помочь определить дубли, чтобы ответственный не разбирался самостоятельно с этим.
Для решения используем действие "Получить информацию об элементе смарт-процесса" с такой настройкой:
Две особенности настройки действия для поиска дубликата:
- Укажем в фильтре, что ID регистрации не должно быть равно ID текущего элемента, иначе мы найдем текущий элемент.
- В настройке этого фильтра используем технические поля с "ID мероприятия" и "ID контакта". Именно для этого случая мы и создали техническое поле с "ID контакта", а поле для "ID мероприятия" уже было создано для другой задачи.
Проверка корректности данных
Далее выполняем проверку на наличие некорректных данных в регистрации: если все хорошо, значит выполнится левая ветка.
В условии пропишем все, что можем оценить:
- мероприятие заполнено;
- дата мероприятия не в прошлом;
- контакт заполнен;
- дубль не найден.
В левой ветке далее идут пауза и смена стадии, которые реализуют сценарий: если мероприятие прошло, а элемент так и остался на этой стадии (Лидер по какой-то причине не перевел его в подтвержденные или другую стадию), то на следующий день переместим его в завершённые.
У паузы такие настройки: =dateadd({=A60233_39476_66041_92840:UF_CRM_5_1693210298840},"1d")
A60233_39476_66041_92840:UF_CRM_5_1693210298840 это значения даты проведения мероприятия, такой код подставляет редактор БП, когда вы выбираете в интерфейсе нужное поле:
Обработка ошибок
Если же с данными не все в порядке, уведомим ответственного и переведем элемент в стадию разбора ошибок.
Эта ветка могла бы быть простой из двух-трех действий с уведомлением и сменой стадий, но тогда ответственный не будет знать, в чем именно дело.
Поэтому тут несколько условий, чтобы облегчить работу Лидеру и уведомить его, что именно не так.
На этом этап подготовки завершен.
2) ПОДТВЕРЖДЕНИЕ УЧАСТИЯ
Требования:
- При подтверждении участия увеличивать счетчик регистраций по мероприятию. Предусмотреть защиту от повторного учета регистрации, если элемент снова будет перенесен на эту стадию.
- Если волонтер не пришел на мероприятие (регистрация осталась на стадии «Подтвердил участие»), то после даты проведения мероприятия – перевести регистрацию в завершенные.
Для решения понадобится небольшой шаблон БП:
Все подходы вам уже знакомы.
В начале получаем данные связанного мероприятия.
Далее идет условие, которое проверяет, учитывали ли мы ранее эту регистрацию. Если не сделать проверку, то будет некорректный подсчет регистраций по мероприятию при случайном повторном перемещении элемента на эту стадию.
Проверку будем выполнять через техническое поле, тут все «по классике» - заведем техническое поле-флажок «Подтвердил участие» и будем его проверять.
Если мы тут первый раз, то запустится левая ветка. В ней установим флаг «Подтвердил участие» и увеличим счетчик регистраций в мероприятии.
Для увеличения счетчика используем действие "Изменить элемент смарт-процесса", текущее значение поля «Набранное количество регистраций» возьмем из результатов действия «Получить информацию о привязанном элементе» и добавим к нему единицу.
А для того чтобы указать системе, в каком именно мероприятии мы хотим увеличить счетчик, в фильтре указываем ID.
После веток условия идет уже известный вам прием из двух действий: пауза (со сроком +1 день к дате проведения мероприятия) и смена стадии.
Так мы закроем регистрации непришедших волонтеров. По пришедшим Лидер сменит стадию, тогда БП завершится до окончания паузы и действие смены стадии уже не отработает.
3) УЧАСТВОВАЛ
Требования к автоматизации:
- Отсылать волонтеру письмо со ссылкой на форму отчета и сроком его предоставления через 4 дня, при повторном перемещении элемента на стадию письмо не отсылаем.
- Если волонтер не предоставил отчет в указанный срок, необходимо перевести регистрацию в завершенные.
Схема шаблона БП очень похожа на предыдущую: получение данных мероприятия, проверка, что ранее письмо не отправляли, отправка письма, ожидание и смена стадии.
Отметим здесь действие по отправке письма. Нужно указать сроки предоставления отчета и ссылку на форму отчета, которую мы ранее составили и сохранили в мероприятии.
Вычисляем срок предоставления отчета, для наглядности используем переменную «Срок подачи отчета», добавим к дате проведения мероприятия 4 дня: =dateadd({=A57832_54647_8612_32471:UF_CRM_5_1693210298840},"4d")
Затем в действии, отправляющем письмо, укажем эту переменную, ссылку на форму и другие данные мероприятия:
Волонтер получит вот такое письмо:
4) ОТЧЕТ ПОЛУЧЕН
Требования:
Облегчить ручную работу на этапе контроля отчетов. Если отчет так и не был предоставлен, завершаем работу по регистрации.
Схема очень простая - получаем дату мероприятия, ждем и меняем стадию:
На этом по регистрациям все! Большая часть кейса автоматизирована :)
Далее - отчеты.