Волею судеб, запуская очередной проект, я столкнулся с достаточно интересным фактом.
Многие мои знакомые так или иначе пытаются делать проекты, получается у немногих.
Я хочу рассказать на небольших примерах о том, что нужно делать в проекте, а на что можно забить, даже если это противоречит вашим интуитивным устремлениями.
Нижесказанное не является рецептом на все случаи жизни, является моим личным опытом и не претендует на абсолютную истину. Всегда можно два года пилить гениальный nginx, который затем взлетит безо всякого маркетинга за счет исключительного качества и наберет популярности, но вероятность сделать такой продукт IMHO еще ниже, чем успешный типовой стартап.
Итак, мы начали делать проект ассоциации компаний, и центровым разделом должны были стать спецпредложения. У каждой из компаний есть свой сайт, а также один или несколько успешных проектов, и есть акции и скидки.
На сайте предполагалось объединить эти спецакции и скидочные предложения в стиле групона, а на самих проектах разделы убрать, вставив туда виджеты. Программисты знают принцип DRY / SPOT, это работает и в управлении проектами.
Заранее скажу — проект менее чем за месяц стал успешен и себя окупил, стал зарабатывать деньги, но об этом ниже.
В команде было четыре человека: два управленца (я как консультант, в прошлом программист, и сам прожект, в прошлом дизайнер), дизайнер и программист. Дизайнер и верстальщик привлекались на сдельные работы.
Первое, что хотелось бы отметить, так это особенности профессиональной деформации. Это одна из первых причин провала у проектов. Суть в том, что в случае неопределенности каждый специалист либо в начале проекта, либо в момент паузы в развитии тянется делать то, в чем он шарит. Программист садится писать идеальный код или рефакторить существующий, дизайнер — перерисовывать, и так далее. В то время как проблемы обычно лежат в другой области, и их упущение приводит к провалу проекта.
В данном случае мы на начальном этапе тоже стали немного буксовать — продумывали сложную идеальную форму отправки заявки на акцию с сайта, проджект-дизайнер тянулся что-то перерисовать.
Но мы взяли себя в руки и сделали то, что нужно делать каждый раз.
Во-первых, мы поставили цифровые цели проекта под обозначенный вектор. Вектором было создать поток заявок на акции с сайта, которые затем передавались сейлзам для обработки.
Цифровые цели были такие: минимальное количество хостов в день, минимальное количество просмотров на одного посетителя, минимальное количество заявок в день. На каждый показатель три диапазона значений — удовлетворительно, хорошо и отлично (за сто процентов берется идеал, 75% отл, 50% хор, 25% уд). И конверсия из расчета 0.5 процента минимум — 100 хостов дают 0.5 заявок.
Вторым шагом мы сделали статистику на сайте в дополнение к стандартным инструментам, которая позволяет считать клики по всем инструментам и видеть весь цикл — от того, откуда клиент пришел, что нажимал и смотрел, до айдишника отправляемых им заявок.
Это тоже противоречило обычным представлениям, что нужно просто пустить трафик и все. В дальнейшем благодаря замеру количества кликов до заявки мы придумали много вещей, типа акции дня, подбора индивидуальных акций, перенос формы заявки с отдельной страницы прямо на страницу акции для уменьшения кликов, вариации названий кнопки сабмита, a/b тестирования разных вариантов текстов. Генерить идеи (и воровать тоже) и измерять их эффективность без тонкой детальной статистики просто невозможно.
Далее мы расписали, с каких сайтов и как будем наращивать трафик. Запилили статистику для анализа эффективности источников трафика. В процессе работы стартапа мы, измеряя эффективность, также пробовали разные варианты рекламы. Оказалось, что конкретные предложения акций на баннерах в разы эффективнее общих слов «спецакции для турагентств», также эффективными оказались узконаправленные рассылки по клиентам из базы CRM по клиентам-плательщикам, которым могли бы интересны определенные акции в силу структуры их прошлых покупок.
Отлично пошел ход, когда перед 8 марта делалась рассылка тематического плана, и когда объявлялся последний день определенных акций. При обычных пяти заявках в день такие ходы позволяли получать до 20 заявок, причем около 10 процентов клиентов покупало сразу три-пять акций, отправляя несколько заявок с сайта.
Крайне непривычным были ежедневные релизы для программиста. Для нас всех было непростым также то, что у сайта на многих страницах не было текста, был неидеальный дизайн и верстка. Это противоречило идее заполнить сайт и вылизать дизайн, чего так хочется всем. Однако заявки с сайта шли, клиенты покупали, и это радовало.
Еще одной интересной особенностью стало упрощение интерфейса. Рассмотрим на примере формы заявки. Изначально в ней были поля: проект, к которому привязана акция, сам список акций, ФИО, телефон, e-mail, комментарий. После запуска проекта и первых ста хостов три дня не шли заявки, и я решил упростить интерфейс. Поначалу это вызвало протесты в команде. Я оставил: все акции в одном списке, имя (необязательное), и телефон/e-mail (одним полем). И заявки пошли!
После этого мы написали план прокачки трафика, когда стало ясно, что ста хостов мало. И развили до 250 хостов в день, 800 просмотров в среднем. И вот за месяц работы проекта уже более 120 заявок, продано услуг на несколько сотен тысяч рублей!
Возможно, история несколько сумбурная, поэтому попробую подытожить:
1. На момент запуска проекта важным является узкий прицел, вектор, задача, которую он должен решать.
2. Важно четко понимать аудиторию (в нашем случае это турагентства, которые могут купить что-то со скидкой, как правило, из регионов)
3. Важно расписать цифровые цели проекта, анализируя которые каждый день и даже час, вы будете допиливать проект
4. Не являются важными вторичные элементы сайта, которые не связаны с узкой задачей — дизайн, контент, красота и рюшечки.
5. Решительно важным является понимание поведение клиента на сайте до каждого клика и нажатия клавишей, нужно приложить усилия для точнейшего инструмента замера поведения вашего посетителя
6. Маркетинговые усилия по привлечению трафика, и доработка проекта за счет анализа статистики и динамики цифровых целей съедает до 80 процентов времени. Дизайн, верстка, программирования на первой стадии должны работать на это пункт, особенно программинг — максимально быстро должны вноситься изменения.
7. После достижения стадии proof of concept (у нас была идея «твиттер-like фид спецакций со многих сайтов, через который будут заказывать») вы можете выбрать второй вектор, предоставив программистам время на рефакторинг, людям на заполнение сайта контентом, дизайнерам на охренненные тени и моднявый metro ui редизайн. А сами фигарить уже новый раздел.
Мы взяли вторую концепцию под кодовым названием «электронный менеджер».
Желаю успеха всем, кто делаем проекты, и надеюсь, что чем-нибудь помог!
Автор: Cord
