Ты называешь себя техническим отделом онлайн-школ на аутсорсе. Что это значит? Чем ты отличаешься от обычного техспециалиста по GetCourse?

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

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

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

При этом формат «круглосуточно дергайте меня по любому вопросу» мне не подходит. Я готова брать на себя большой объем задач, но не как хаотичный универсальный солдат, а как специалист, который понимает, что именно нужно проекту и когда, что лучше сделать самой, а что можно делегировать, и как организовать это в единый процесс. Если для решения задачи нужны дополнительные руки или узкие специалисты, я знаю, кого привлечь. Ответственность за результат в любом случае остается на мне.

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

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

В онлайн-образование я пришла в 2016 году. Сначала работала с блогером как личный помощник: тогда курсы запускались прямо в Instagram*, и довольно быстро стало понятно, что так работать неудобно — слишком много ручных действий и ограничений. Я начала искать, как процессы можно упростить и автоматизировать, узнала про GetCourse, стала в него погружаться и постепенно ушла именно в техническую часть.

Уже в 2017 году я с нуля настраивала онлайн-школу для этого проекта. Дальше несколько лет мы развивали ее вместе с экспертом, и по мере того, как усложнялся и масштабировался сам проект, менялась и моя роль внутри него. Со временем я дошла до технического и исполнительного директора.

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

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

Именно так и сформировалась моя сегодняшняя роль. Не в теории и не потому, что однажды я решила «теперь я не техспец, а кто-то больше», а за несколько лет опыта внутри растущего проекта, который в итоге дошел до оборота около $1 млн в месяц. Такой опыт дает не только технические навыки, но и совсем другой уровень понимания.

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

Когда заходишь в новый проект, с чего начинаешь работу? На что смотришь в первую очередь?

Всё начинается с предварительной консультации.

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

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

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

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

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

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

Какие ошибки в технической части онлайн-школ ты встречаешь чаще всего? Что обычно мешает проекту расти?

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

Вторая частая проблема — это так называемый зоопарк сервисов. Когда у школы одновременно есть GetCourse, отдельные боты, какие-то прокладки между сервисами, внешние страницы, дополнительные инструменты, и в какой-то момент уже никто толком не понимает, зачем все это нужно, что на что завязано и как взаимодействует. Бывают случаи, когда это действительно оправдано, но как правило — нет. Часто проект просто обрастает решениями «по случаю»: здесь что-то быстренько поставили, там добавили, тут тестировали, потом сверху еще докрутили, а эту связку гуру в чатах рекомендовал. В итоге школа не только платит за лишние сервисы, но и на стыках между ними теряет данные, лидов и управляемость.

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

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

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

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

Ты говоришь, что твоя задача — не просто настроить школу, а сделать так, чтобы она выдерживала рост и масштабирование. Что это значит на практике?

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

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

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

Масштаб обычно проявляет слабые места сразу в нескольких точках, поэтому и к оценке проекта тоже надо подходить комплексно. Это не работа с каким-то отдельным элементом или косметическая доработка. Это анализ и пересборка всей системы, чтобы даже при внезапном увеличении объемов трафика, задач или прибыли, школа не теряла в управляемости, клиентском опыте и качестве.

Такую систему я и строю.

Ты работала в проекте, который вырос вместе с тобой от первых запусков до оборота около $1 млн в месяц. Как это было и за что именно ты там отвечала?

Внутри этого проекта я была с самого начала, с нуля, когда в нем были только эксперт и я.

Первый заметный рывок у нас случился еще до GetCourse. Тогда, как и все, мы продвигались и проводили запуски в Instagram*. Это был марафон, эксперт давал контент и был лицом проекта, а вся остальная организация была на мне. И в первый же месяц мы сделали 1,1 млн рублей. Без GetCourse, без выстроенной инфраструктуры, с ручными ответами в директ, комментариями под постами и так далее.

Дальше проект рос уже планомерно. Мы постепенно переходили от простых запусков к более сложной системе: появились продукты, воронки, команда, регулярные процессы. В какой-то момент достигли оборотов уже 30–40 млн рублей в месяц, а потом мы пришли к уровню, когда стали делать $1 млн в месяц.

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

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

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

Постепенно нарастала команда. В какой-то момент у меня было семь человек в подчинении, и уже этим составом мы поддерживали тот уровень нагрузки, на котором школа делала $1 млн в месяц.

То есть моя роль там была не только в том, чтобы самой что-то настроить руками или дать кому-то такую задачу, а еще и в системном выстраивании всей работы так, чтобы проект и прибыль не сыпались при растущем масштабе.

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

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

В твоем опыте были запуски на 5000 человек одновременно и вебинары на 40+ тысяч. Что в таких проектах становится самым сложным? Как заранее предусмотреть сбои при таких масштабах?

Вне зависимости от объема запуска или вебинара, гарантировать на 100%, что нигде ничего не сбойнёт, невозможно. Потому что всё равно существуют риски падения каких-нибудь серверов, отключений, блокировок, болезней и так далее — то, что находится вне зоны нашего контроля и влияния.

Но! Всё, что можно предусмотреть, — надо предусмотреть.

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

Если говорить про вебинары на 40+ тысяч человек, то там есть несколько основных рисков. Во-первых, может не выдержать сама комната или сервис. Во-вторых, в любой момент может случиться технический сбой: зависнет платформа, пропадет интернет, комната перестанет пропускать людей. В таких историях у меня всегда есть план С на план Б, дублирующие комнаты и каналы, постоянная связь с техподдержкой сервиса. На больших вебинарах нельзя надеяться на «ну, в прошлый раз сработало, должно и тут сработать». Там нужно заранее подстелить соломку в нескольких местах сразу.

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

На таких объемах важно заранее договориться с техподдержкой сервиса, где будет проводиться вебинар, заранее расширить комнату, проверить технические параметры, все оплатить с запасом и держать руку на пульсе прямо во время эфира. Заранее, а не когда люди уже столпились на входе. Потому что если у тебя в 11 вечера еще идет трех- или пятичасовой вебинар, тебе прямо сейчас нужна техподдержка, а ты их не предупредил, то увидят они твои крики о помощи только утром. К таким вещам я тоже всегда готовлюсь заранее.

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

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

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

Что заказчикам нравится в работе с тобой больше всего?

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

Если смотреть на обратную связь от клиентов, то часто повторяются одни и те же слова: «спокойно», «надежно», «как ты вообще это сделала?» Для меня это, наверное, и есть лучший комплимент. Потому что техническая работа хорошо сделана не тогда, когда все видят, сколько усилий за ней стоит, а когда школа просто нормально работает, процессы идут, рассылки уходят вовремя, ничего не отваливается, и эксперту не приходится погружаться в техническую часть вместе со мной.

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

Еще одна важная для многих вещь — я думаю на шаг вперед. Даже если вопроса или запроса от заказчика еще не было, у меня в голове уже есть несколько вариантов, что делать, если ситуация изменится. Это касается и запусков, и сервисов, и внешних обстоятельств. Например, если один инструмент перестанет работать, я уже понимаю, куда мы уходим дальше. Если условия рынка меняются, я заранее прокручиваю, как это повлияет на проект и что можно перестроить. План Б у меня есть всегда, и когда что-то идет не по плану, я быстро понимаю, где проблема, и знаю, как её решить.

С какими клиентами тебе особенно нравится работать? И кому ты можешь не подойти?

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

Мне интереснее работать с теми, кому нужен именно технический партнер, а не человек на бесконечные мелкие поручения. Когда заказчик приходит не за руками «на подхвате», а за специалистом, который возьмет на себя большой кусок технической ответственности. Это, как правило, проекты, которые уже работают или хотят расти, которым важно не просто что-то настроить, а выстроить систему, на которую можно опираться дальше.

Мне не подходит, когда проект живет в режиме бесконечных созвонов: «давайте созвонимся», «давайте еще раз созвонимся», «давайте обсудим это еще раз». Я не люблю формат, в котором работа подменяется постоянными разговорами о работе. Если нужен человек, который будет два раза в неделю по три часа сидеть на созвонах и проговаривать свой каждый шаг, я, скорее всего, не подойду. Мне комфортнее, когда коммуникация по делу, а основное время уходит именно на получение результата.

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

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

И давай кратко: что в итоге получает клиент, когда приходит к тебе в работу?

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

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

Еще один важный момент — это предсказуемость. Когда нормально выстроены процессы, понятна логика, нет постоянных срочных переделок, команде становится проще работать. А проекту — проще расти. Потому что рост в онлайне часто тормозится не отсутствием гениальных идей, а тем, что внутренняя система не успевает за объемом. Когда эта система собрана качественно, у проекта появляется стабильная опора.

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

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