Как перейти на другую платформу

Вы когда-нибудь переезжали? Меняли квартиры, города, а может даже страны?

Если да, то вы знаете, насколько это может быть воодушевляющим и муторным одновременно.

В этой статье я не буду рассказывать вам о том, как пытаться впихнуть в два чемодана то, что с трудом помещается в грузовую Газель, или как за один день упаковать всё нажитое непосильным трудом и не забыть половину вещей. Нет.

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

Поводов к переезду может быть много.

Функционал текущего сервиса устарел и перестал соответствовать требованиям рынка.

Проект вырос и имеющихся возможностей платформы уже не хватает.

Вроде всё хорошо, но хочется чего-то нового и свежего (прости, дело не в тебе, дело во мне...).

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

Еще одна распространенная причина — выгода. Почему мы используем этот сервис за 500$, когда есть такой же, но за 100$? Зачем платить больше? Да, выгода всегда мотивирует к переходу на другой сервис. Здесь важно проанализировать функционал более дешевого варианта и верно оценить соотношение финансовых, трудовых и временных затрат в работе на нем. Блюдём баланс! А то с появлением новых и, как правило, недорогих платформ можно только переездами и заниматься (и кукухой поехать).

Например. Текущий сервис стоит 500$ в месяц. Есть два других за 300$ и за 100$. Казалось бы, чего тут думать, надо брать самый недорогой, это ж какая экономия. Но если изучить матчасть, то интеграция там сложнее и ее нужно постоянно поддерживать, а это затраты. Да и сам сервис не такой популярный — по нему мало информации и нет специалистов. Поэтому не стоит спешить. Дальше так же анализируем средний по цене сервис, учитываем все плюсы и минусы. В идеале сделать сравнительную таблицу, а потом еще и показать ее другим спецам, которые знают эти платформы. Они точно смогут добавить несколько пунктов, которые могут кардинально поменять ваше решение.

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

• это реклама и ему заплатили (да, вот так просто),

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

• таким образом он хочет устранить конкурента (привет любителям теорий заговора!),

• платформа действительно наилучшим образом подошла его проекту и он со всей искренностью нахваливает сервис, безвозмездно (но это не точно).

И что же делать? Включить голову и критическое мышление.

Оцените функционал и возможности предлагаемой платформы, соответствие потребностей своего проекта и этого функционала — утюг может и классный, только вам надо забивать гвозди, и вроде утюгом тоже можно, но зачем переплачивать за отпариватель? Думаю мысль понятна. Даже если это не реклама и сервис рекомендуют от души, именно вашему проекту он может не подойти.

Обратитесь к тем, кто с этим сервисом работал, чтобы получить от них максимально честный фидбэк по работе с платформой.

И в первую очередь обратитесь к вашему техническому специалисту. Он единственный кто в 99% случаев не заинтересован в переезде! Ему же столько всего придется делать и заново настраивать. А зачем, если всё и так работает нормально? В такой ситуации техспец может выступать в роли оппонента, который будет вас отговаривать и приводить для этого аргументы. В результате получатся дебаты и станут видны все плюсы и минусы переезда. Это идеально.

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

Например, не так давно мне очень рекомендовали сервис А (это не то, что вы подумали...). Я его посмотрел, по первому впечатлению он мне понравился. Но оказалось, что бывают частые сбои в его работе и прочие лаги. И это я мог бы узнать только после переезда, когда начал бы пользоваться сервисом. Обидно бы получилось.

Переезд это практически новая жизнь. Можно начать с чистого листа, а можно захватить с собой важное и лучшее из того, что у тебя есть, и сделать что-то еще более грандиозное.

При переезде на другую платформу не нужно переносить вообще все: старые воронки, неактуальные письма, предложения, курсы и т.д., и т.п. Зачем с собой таскать старый хлам в трех коробках из-под холодильника? Берите только то, что сейчас актуально и действительно нужно. Это ускорит процесс переезда и упростит работу тем, кто его организует.

Представьте, что вы работаете на 1 платформе 10 лет. Сменилось много сотрудников, было много разных тестов, акций, продуктов, воронок и т.п. Если у вас четко выстроенная система, за порядком всегда следили, а не делали работу в режиме «горижопа», то хаоса быть не должно. Но кто из нас идеален? Поэтому скорее всего бардак есть: Что это за теги? Что за название процесса «новый пр1п4»?? Это что-то нужное? Кто-то помнит? А это что за группы? Кто бы знал. Регламент по наименованию и тегам хотели завести, но руки не доходили, да и вроде всё работало...

В итоге на платформе образуется мешанина неопознанных компонентов, что черт ногу сломит. И вот это все не надо переносить на другую платформу при переезде. Оставьте. Забудьте! Берите только важное, рабочее, актуальное.

Не надо переходить на другой сервис, если вы не видите выгоды. И в данном случае речь не только о деньгах, но и об удобстве использования, наличия необходимых функций, которые позволят вашему проекту расти и эффективнее работать, и т.д. Анализируем, взвешиваем, соблюдаем баланс.

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

Итак, вы посчитали все затраты, выгоду и решились на переезд. Что дальше?

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

База. Здесь есть возможность даже улучшить то, что есть. При переносе пользователей можно дополнительно отсегментировать и тогда на новой платформе база будет более упорядочена, с ней будет удобнее работать и она будет меньше перегорать от нецелевого взаимодействия. В этом случае переезд обретает дополнительную выгоду.

Прописываем, хоть на коленке, основы регламента по наименованиям, тегам и вложенности компонентов. Вспомните пример про 10 лет на одной платформой. При переезде вы можете сделать свой проект «порядочнее» и структурнее. Не тащите старый бардак на новую платформу. Не надо так.

Будьте готовы к дополнительным расходам. В процессе переезда у вас параллельно будет функционировать 2 платформы, если, конечно, вы не останавливаете работу проекта при переходе с сервиса на сервис. А это увеличение затрат. К этому нужно быть готовым. Не стоит из-за этого торопиться, чтобы в спешке не создать больше проблем и косяков. Но и затягивать не нужно, делая переезд растянутым во времени и очень дорогим. Баланс. Держите баланс и тут.

Кроме того, нужно время для перехода пользователей и переноса их доступов. Если, например, ученик сейчас в процессе обучения, то будет сложно перенести его прогресс. То же самое, если пользователи сейчас находятся в незавершенных процессах. Поэтому текущих учеников лучше оставить и дать им возможность допройти без лишних сбоев и волнений. Тут речь будет идти о лояльности базы, доходимости и LTV. З — забота. Часто это перевешивает прямую финансовую выгоду. Если, конечно, вы планируете работу в долгосрок. А вот новых пользователей смело ведите уже на новую платформу, как и «старую» базу.

Найдите того, кто будет консультировать при переезде. Как правило это вопрос вашего технического специалиста, если сам он не очень хорошо разбирается в новой платформе. Это было на этой платформе, а теперь нет. Что делать? Чем заменить? Специалист, который будет вам помогать, подскажет обходные пути и альтернативные решения. Некоторые платформы, заинтересованные в новых клиентах, даже предлагают бесплатную услугу переноса данных проекта со старого сервиса на свой. Возможно, есть смысл воспользоваться их предложением, обговорите этот момент со своим техспецом. И поддерживайте связь с их техподдержкой, если она есть и отвечает, конечно.

Вот и всё, ребята!

Надеюсь, у меня получилось систематизировать ваши мысли о переезде и показать, что не так страшен переход на другую платформу, как о нем говорят.

Не гонитесь за дешевизной. Анализируйте и соблюдайте баланс.

А если остались вопросы и нужна помощь — пишите.

Помогу с переездом. Быстро. Дорого.