Геткурс как настроить процесс

Blank page it all starts here

Настройка процессов в Getcourse

Чтобы заказы и оплаты попадали в vakas-tools, необходимо создать нужные процессы в Getcourse. Важно их создавать после настройки передачи в amo в vakas-tools, если вы создали их раньше, то не запускать, пока все не настроите.

Процесс Новый заказ

1. Заходите в процессы.

2. Нажимаете кнопку [Создать процесс].

• Название, чтобы вы понимали;
• Тип объекта — заказы;
• Шаблон процесса — без шаблона;

3. Массовое создание задач — При создании объекта. Т.е. заказ будет выгружаться при создании. Если вы создадите процесс после того, как есть какие то новые заказы, то они не будут переданы.

Если вам нужно передать заказы, которые не оплачены и уже есть в системе, нужно создать одноразовый процесс, который выгрузит заказы в vakas-tools.

4. Добавляем правило вхождения объекта (условие): Продукт или Предложение, если вам необходимо разграничить. Проще всего это сделать через теги. Выбираете все продукты или предложения с нужными тегами. Плюс в том, что если у вас появляется новый продукт, то вы у него указываете тот же тег, он автоматически попадает в процесс и выгружается. Не надо создавать новый процесс.

Еще есть варианты условий, например: Заказ создан клиентом или по сумме ограничить, или выгружать только платные продукты. Если не нужны все заказы, можно ограничить датой.

5. Нажимаете кнопку [Сохранить]

6. Выбираете вкладку Процессы. Добавляете блок: Операция -> Задача: Вызвать url. В url вставляете ссылку с vakas-tools. Где ее взять, описано чуть ниже.

7. Добавляем блок — Завершение процесса.

8. Соединить блоки между собой.

9. Процесс по новым заказам готов, запускаем его.

Остальные процессы можно создать копированием. Меняется только правило вхождения объекта.

Где взять ссылку в vakas-tools

Нажимаем кнопку [Ссылки] у нужной Базы.

Переходим на вкладку Оплаты и копируем ссылку для оплаты в Getcourse.

Процесс Частично оплачен

Массовое создание задач: Периодическая проверка. Правило вхождения объекта (условие): Частично оплачен. Дополнительно можно добавить и другие условия.

Рассрочка или разделение на два и более платежей

Если у вас несколько оплат, например контакт делает несколько предоплат или частичных оплат, но процессы в Getcourse запускаются только один раз, поэтому если придет вторая предоплата, она не выгрузится. Необходимо создать копию процесса и указать в нем условие: Есть платеж: равно 2. Таких копий можно сделать сколько угодно, смотря сколько у вас будет предоплат. Т.е. если три предоплаты, то будет два дополнительных процесса. Первый с условием — Есть платеж: равно 2, второй с условием — Есть платеж: равно 3.

Процесс Полная оплата

Массовое создание задач: Периодическая проверка. Правило вхождения объекта (условие): Оплачен или Завершен. Дополнительно можно добавить и другие условия.

Видео-инструкция

Источник

Ошибки при настройке процессов в Геткурс, которые допускают 99% спецов

При настройке процессов есть некоторые нюансы, о которых не каждый спец в курсе, что уж о новичках говорить.

Вроде бы мелочь неочевидная, но из-за неё много косяков в работе.

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

Будьте в курсе и не косячьте. 😊

1. Блок Задержка

К самому блоку претензий нет, всё понятно… но вот галочка “дождаться наступления определённого времени” может вам всё испоганить))

Значится, в чём суть:

1.1. когда ставите задержку 24 часа (или 1 день), помните что пользователь может войти в процесс и в 2 и 3 ночи и в 5 утра на рассвете.

К примеру, пользователь по воле случая, страдая от бессонницы, регистрируется на ваш вебинар в 2 ночи.

На след. день (через 24 часа) вы отправляете ему письмо – во сколько он получит его? БИНГО! В 2 ночи – упс… 🙄

1.2 часто, чтобы такого не было (не слать письма в ночи) юзают галку “дождаться наступления определённого времени”.

Вроде верно, но на деле всё стало хуже, чем было:
зарегался человек, например, 3 марта в 10:03 – мы ждём 24 часа и ждём 10:00
Хорошо – 24 часа это у нас – 4 марта 10:03. Но 10:03, это не 10:00 – потому процесс ждёт ещё почти сутки, пока не будет 10:00.

Когда в итоге пользователь получит письмо? Правильный ответ через 2 дня (5 марта). Так что тут считайте, можно поставить задержку 12 часов или использовать блок Текущее время.

И кстати, используя “дождаться наступления определённого времени”, не оставляйте поле задержки пустым – иначе этот блок не сработает (ставьте хотя бы 1 минуту)

Тупняк намбер ту

2. Та же галка “дождаться наступления определённого времени” в блоке Ожидание условий.

Допустим: ждём пока клиент оплатит, если в течение 24 часов клиент не оплатит, ждём 9 утра и высылаем ему письмо.

Глянь на скрин и ответь себе – всё верно или нет?

И если ты ответил(а) верно, то мы можем вместе пойти поплакать 😫, потому что ты ступил(а) сейчас, как и я когда-то.

Всё соль в том, что это “дождаться” действует ДЛЯ ветки “Условие выполнено”.

3. Штука, которая не работает (для тех, кто юзает Chatium)

Операция Пригласить в Chatium группу – не работает… давайте без вопросов – оно просто не работает и всё 🤷‍♀️

4. Нюансы в блоке Текущее время

1. Время «от» обязательно должно быть раньше, чем «до». Если у вас до = 00:00, лучше указать до 23:59.

2. Если у вас несколько условий, то порядок проверки происходит по очереди сверху вниз – не как в Прокси-скрипт – все ветки сразу, а именно по очереди, т.е. по двум и более веткам сразу этот блок идти не будет – какое время (сверху-вниз) совпадёт первым, по той ветке и будет дальше процесс идти.

НО если время ПЕРЕСЕКАЕТСЯ, то порядок проверки уже другой: 👇👇👇

🍬 любой день – выполнится в первую очередь
🍬 любой будний день / любой выходной день – выполнится во вторую очередь
🍬 конкретный день недели – выполнится в последнюю очередь

На заметку:

🌵 Блок Ожидание условий проверять может до 15 минут, а не раз в 5 минут, как это написано.

🌵 Если в блоке Ожидание условий запускать проверку вручную, то будет всегда удовлетворительное выполнение условия. Поэтому не удивляйтесь, что при таком тестировании у вас всё срабатывает, а при реальной работе процесса – нет.

🌵 Настраивая какие-то процы по пользователям (ученикам), где условие вхождения – имеет покупку/заказ, помните, что если есть возможность того, что пользователь дважды купит это продукт/предложение, то войдёт в процесс он всего ОДИН раз – т.е. по второй покупке/заказу ничего не произойдёт
(да-да, именно поэтому, вы можете получить наши бесплатные мини-курсы по подключению платёжных систем только 1 раз).

🌵 Если отправляете из процесса письма, то отправляться они будут по условиям, которые указаны в самом письме. Поэтому для процессов рекомендуется создавать письма в статусе Черновик, в поле «Кому отправлять» указано «Никому», а в поле «Когда отправлять» – «По готовности».

🌵 Статус “Ложный” процесс не видит, можете в условиях его не юзать – чуда не будет.

Логичная и плавная концовка – не мой конёк. У меня на сегодня всё, буду закругляться.

Если хотите разбираться в процессах, у нас есть Интенсив «Логика процессов» – доступно и наглядно о том, какие блоки есть в процессах и как правильно их выстроить, чтобы всё работало.

Для тех, кто хочет разбираться не только в процессах, но и во всём Геткурсе, есть курс для новичков и курс для специалистов, где вы научитесь решать нерешаемые задачи от заказчиков. 🐱‍👤

Есть чем дополнить?

Пишите в комментах – сделаем одну статью со всеми тонкостями настройки процессов и будем передавать её братьям нашим меньшим – новичкам в Геткурс. Мы-то уже с вами стали опытнее. 😉

Источник

Геткурс как настроить процесс

Сценарии в процессе обработки заказа

Итак, пользователь оставил заявку — у вас появился новый заказ. Это отправная точка для цепочки задач. Как минимум вы должны получить оплату и открыть доступ пользователю к продукту. На деле процесс обработки заказа редко состоит только из факта приёма платежа. Обычно это 10-20 обязательных действий — технических уведомлений, писем и звонков. От того, насколько все они учтены в CRM и автоматизированы, зависит не только скорость обработки заказа, но и ваши затраты на процесс, удовлетворённость пользователя и в итоге ваша прибыль.

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

• заказ создан по ошибке,
• это дубль заказа,
• неверно указан email, номер телефона или не указан вовсе,
• пользователь не отвечает на звонки,
• пользователь сомневается, нужен ли ему продукт, на который он оставил заявку,
• заказ не оплачен в указанную дату,
• пользователь хочет особые условия оплаты — рассрочку, скидку.

Все эти факторы влияют на обработку заказа: в процесс включаются дополнительные звонки или уведомления, заявка может переходить от менеджера к менеджеру. Полную историю коммуникаций с клиентом — обращений, писем, записи звонков, даты платежей важно хранить.

При общении с пользователем менеджер сталкивается с сомнениями и отказами — ему нужно работать с возражениями. Для этого пригодятся скрипты.

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

Источник

Геткурс как настроить процесс

Сценарии в процессе обработки заказа

Итак, пользователь оставил заявку — у вас появился новый заказ. Это отправная точка для цепочки задач. Как минимум вы должны получить оплату и открыть доступ пользователю к продукту. На деле процесс обработки заказа редко состоит только из факта приёма платежа. Обычно это 10-20 обязательных действий — технических уведомлений, писем и звонков. От того, насколько все они учтены в CRM и автоматизированы, зависит не только скорость обработки заказа, но и ваши затраты на процесс, удовлетворённость пользователя и в итоге ваша прибыль.

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

• заказ создан по ошибке,
• это дубль заказа,
• неверно указан email, номер телефона или не указан вовсе,
• пользователь не отвечает на звонки,
• пользователь сомневается, нужен ли ему продукт, на который он оставил заявку,
• заказ не оплачен в указанную дату,
• пользователь хочет особые условия оплаты — рассрочку, скидку.

Все эти факторы влияют на обработку заказа: в процесс включаются дополнительные звонки или уведомления, заявка может переходить от менеджера к менеджеру. Полную историю коммуникаций с клиентом — обращений, писем, записи звонков, даты платежей важно хранить.

При общении с пользователем менеджер сталкивается с сомнениями и отказами — ему нужно работать с возражениями. Для этого пригодятся скрипты.

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

Источник

Запустить процесс в форме

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

Обратите внимание, что процесс должен быть не запущен, с пустым условием входа, логика аналогична настройкам подпроцесса.

А если пользователь уже находится в процессе — внутри какого-то блока «Ожидание», а в это время я его повторно через форму запускаю в процесс — что будет? При этом у меня в форме стоит галка «Запускать повторно, если задача по этому пользователю уже запускалась».

Ожидание отменится?
Или пользователь будет дважды проходить процесс?

Здравствуйте, Алексей.
В данном случае будет создана отдельная задача процесса. В результате у пользователя может быть несколько задач по одному и тому же процессу.

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

«Обратите внимание, что процесс должен быть не запущен, с пустым условием входа, логика аналогична настройкам подпроцесса»

А как тогда исключить участников другой группы?

Здравствуйте, Артур.
В случае необходимости, в самом процессе может быть использована проверка условия «В группе».
Для участников другой группы назначить завершение процесса. Для остальных пользователей — выполнение всех необходимых действий.

Источник