С данной компанией мы работаем в рамках программы “Сопровождение” с 2022 года.
Нам предстояло решить следующие вопросы:
-
Ручной учет людей, которые посетили обучающий семинар. Невозможность сегментировать клиентов для дальнейшей работы с ними. Компания работает на платформе Timepad, где размещает информацию о предстоящем событии и принимает заявки на его посещение. С платформы формируется отдельная база клиентских заявок, которая никак не связана с клиентской базой в Битрикс24. Менеджеры вручную собирали списки участников обучения. Задача выделить клиентов, которые уже посещали обучения и тех, кто проходит его впервые, занимала очень много времени.
-
Менеджеры вручную рассылали уведомления клиентам о проведении серии обучающих семинаров. Центр проводит обучающие семинары для родителей, волонтеров и всех желающих. Некоторые семинары состоят из нескольких уроков, поэтому при проведении второго, третьего и последующих. занятий, необходимо вручную рассылать уведомления клиентам.
3. Интегрировать онлайн Лейку и Битрикс24.
Как мы решили поставленные задачи
Шаг 1. Интегрировали Timepad и Битрикс24 через реализацию собственного приложения. Процесс работы выстроили следующим образом:
- Как только наступала дата и время завершения мероприятия, которые были прописаны в событии на стороне Timapad, платформа автоматически передавала по API информацию о мероприятии и всех ее участниках в Битрикс24.
- На стороне Битрикс24 выполнялась проверка участников по совпадению email, фамилия, имя.
-
Если было полное совпадение данных - контакт в CRM не создавался, в противном случае появлялся новый.
-
На стороне Битрикс24 в отдельном универсальном списке "Мероприятия из Таймпада" создавался раздел, именуемый по названию мероприятия, внутри которого хранилась связь участника из CRM (т.е. с карточкой контакта) с обучающей программой.
Как выглядит универсальный список “Мероприятия из Таймпада”
Вкладка на каждое мероприятие
В процессе работы выявили “баг” в работе Timepad.Оказалось, что Timepad не всегда по завершению мероприятия передает необходимую информацию в Битрикс24. В связи с чем мы разработали дополнительное приложение, которое позволяло в несколько действий принудительно из Б24 запустить процесс передачи данных по конкретному мероприятию в Битрикс24 из Timepad.
Как выглядит процесс принудительной загрузки информации из Timepad
Шаг 2. Настроили процесс автоматической рассылки сообщений участникам семинара.
В карточке товара в CRM (в данной сущности хранились курсы/семинары, на которые записываются клиенты) мы предусмотрели поле под ввод данных о проведении занятий. В данном поле указывалась дата и время начала второго и последующих занятий.
В отдельной воронке продаж когда сделка переходит на определенную стадию, система начинает проверять значения из поля товара (товар в свою очередь связан со сделкой) и за два часа до наступления установленных дат автоматически отправляет на почту клиенту уведомление о проведении занятия.
Поле проверки значений
Как выглядит бизнес-процесс в Битрикс24
Шаг 3. Настроили в Битрикс 24 систему приема платежей от меценатов. Процесс настроили следующим образом:
-
После нажатия, активной кнопки “Помочь” на сайте, данные поступают на портал клиента, в CRM автоматически в нужной воронке формируется сделка.
Как выглядит окно платежа на сайте клиента
В карточке сделки сотрудники видят всю заполненную на сайте информацию:
- сумму пожертвования;
- дату и время, когда оно было совершено;
- информацию о направлении, в которое было направлено пожертвование;
- статус пожертвования: повторный или первичный.
Окно отображения данных мецената
-
Внутри сделки статус платежа контролируется роботами, и в зависимости от него производятся дальнейшие манипуляции по сделке, в частности отправка писем-отбойников о результатах пожертвования.
НО не все оказалось так просто! Когда интеграция была выполнена, и в Битрикс24 стали поступать все факты благотворительных платежей, выяснилось, что на один и тот же платёж, Лейка присылает два статуса: первый - попытка платежа, второй - оплачено.
В Битрикс24 при этом создаются две сделки, практически полные дубликаты (за исключением статуса платежа), а также дубликаты данных-меценатов, так как информация об обоих платежах приходит практически одновременно.
Как мы решили проблему?
Чтобы избежать наличия в системе дубликатов, использовали относительно новый REST-метод для объединения дубликатов (crm.entity.mergeBatch) и при получении успешного платежа добавили дополнительную проверку на наличие такого же платежа, но в ошибочном статусе.По результатам такой проверки лишний платёж мы удаляем, а значит база платежей в Битрикс24 находится всегда в актуальном состоянии.
Проверка сделок
Что получил клиент после работы проведенной “Солью”:
- Клиенты заблаговременно и исправно получают почтовые уведомления о предстоящих занятиях, что значительно повышает лояльность клиентов.
- Экономия времени менеджера, нет необходимости вручную проверять каждую сделку.
- Вся клиентская база находится в одной системе.
- Легко проводить анализ и сегментирование клиентской базы для принятия управленческих решений.
- Возможность увидеть всю “историю работы с клиентом” и понять какие мероприятия он уже посещал.
- Снижение риска ошибки вследствие “человеческого фактора”.
- В результате интеграции Лейки и Битрикс24 сотрудники получили возможность сегментировать направления платежей, клиентов и получать данные о неуспешных взносах.
- Появилась возможность сегментировать клиентскую базу в Битрикс24 и делать целевые рассылки на будущие мероприятия в зависимости от того, на какие мероприятия ранее записывались клиенты.
Приглашаем ваc на экскурсию по идеально настроенной CRM-системе Битрикс24.
Вы увидите, как работают все самые необходимые ее функции для отдела продаж, и не только! Разберётесь, как можно настроить и автоматизировать другие бизнес-процессы на своем портале.
