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

В блоге

прикол, это если резко приспичит и спросишь где, а тебе покажут рукой на Останкинскую телебашню со словами там. Можете не успеть найти 🤣

всё интуитивно понятно

Добрый день!

Коллеги, кто-нибудь занимался переносом воронки с Бизона на ГетКурс? Включая интеграцию сервисов СМС-центр, Звонопес. Требуется полностью автоматизировать воронку.

Если кто-то уже занимался, напишите в ЛС, пожалуйста.
@Tanya_Solyanik

я реализовывал повышение пакетов в одном проекте через Группы и процесс, который продлевает покупки.

Варианты повышения через сегменты отображал под списком тренингов.

В итоге человек может повышаться с 1 по 3 пакет без участия администраторов.

Например,

Предложение 1 добавляет в группу 1 через Продукт 1
Предложение 2 добавляет в группу 2 через Продукт 2

Предложение-повышение с пакета 1 до пакета 2 продлевает доступ в группу 1 на ХХ дней по подписке

Процесс проверяет наличие учеников с заказами с повышением. Далее при наличии Предложения-повышения с пакета 1 до пакета 2 добавляет в Группу 2 и потом ждет условия, когда закончится действие Продукта 1 (как мы помним, он был продлен благодаря подписке из предложения повышения)

абсолютно

всем удачного дня

Толи я плохо понимаю, толи если «замораживался» - значит завершался, то если убрать кучу слов, вам надо чтобы пользователь с одного тарифа мог самостоятельно перейти на другой с учетом «уплОЧенных» денег. Так?

там все варианты возможны, на любой вкус

Вижу в вопросе только на повышение, на более дешевый перехода нет

Тут два варианта.
1. Дешёвый тариф замораживается на время действия дорогого. Дорогой кончился, клиент вернулся на дешёвый. Допустим, он захотел узнать, что же есть такого на дорогом, и подписался на один месяц, а дешёвый у него был на год, например.
2. Человек решил, что ему точно не нужен дешёвый тариф и захотел полностью перейти на дорогой с учетом остатка денег на дешёвом.

тогда да, вам надо познать всю глубину и красоту процессов

любой вариант возможен. делайте, видимость предложений с заменой с видимостью по сегменту (есть дешёвый заказ не старее дней), процессы которые останавливают (морозят) дешёвый, при оплате дорогого или отменяют дешёвый при оплате переxода. Всё делается

тут получается вся соль "в заморозке", остальное фигня

Процессом можно параллельно проверять есть ли оплата, если есть, например завершать.
Если нет, отправлять письмо

заморозку дешёвого можно добавить в предложение дорогого и тогда без процесса заморозится (если есть дешёвый)

ладно, нужно убегать

Спасибо за ответы. Пойду изучать и тестировать.