Ошибки в управлении, автоматизации и найме сотрудников в IT стартапе: советы маркетолога как все исправить
Мой редактор Наташа поделилась опытом работы в проекте, в котором явно не хватало маркетолога. А поскольку я как раз управляю маркетинговым отделом в аналогичном IT стартапе и выстраиваю внутри него рабочие и производственные процессы, мы разобрали 3 проблемы того стартапа, с которыми она столкнулась как наемный сотрудник.
1. Кадровику не было корректно рассказано, какой человек был нужен
Искали копирайтера, а по факту нужен был менеджер по недвижимости начального звена.
Все началось с того, что меня пригласили на собеседование на должность копирайтера в проект по созданию приложения для подбора, бронирования и покупки недвижимости в Дубай. Сказали, что будете писать тексты для новостной ленты, телеграма, инстаграма и рекламы, но сначала нужно будет заняться наполнением сайта - сделать описания к ЖК. А дальше будете заниматься текстами.
Как оказалось уже в процессе работы, надо было заниматься задачами менеджера по недвижимости начального звена - не только заполнять информацию в карточку о ЖК, но и заполнять шахматную раскладку квартир по этажам, разбираться, где у какой квартиры планировка, какой метраж помещений, куда выходят окна, какой из них вид. И вообще связываться с менеджерами застройщиков и запрашивать у них всю эту информацию. Видимо, руководство решило, что раз сотрудник будет писать описание ЖК и пользоваться часто кнопками копировать/вставить, то это что-то на копирайтерском. И мне не показалось, что я поняла что-то не так на собеседовании о своих задачах - мою напарницу уверили ровно в том же.
Мой совет:
Здесь проблема в том, что организация не выписала себе повторяющиеся задачи, которые они хотели бы закрыть новыми людьми. Нанимая человека как бы на должность копирайтера, они пытались закрыть должность брокера. Или же они хотели найти универсального человека, который бы писал статьи с точки зрения копирайтера и был бы в том числе менеджером по продажам или брокером.
Что рекомендую: когда у вас есть какие-то повторяющиеся задачи, нужно обязательно выписать, какие конкретно это задачи. Например: написание статей, написание карточек на сайте, написание карточек в PDF и текстовые материалы, по которыми работают брокеры.
А потом задаемся вопросом: что дальше следует после этих действий? Дальше этот документ высылаем клиенту, связываемся с ним и продаем или просто выкладываем на площадку и приступаем к следующему текстовому заданию?
Все это - разные функции и задачи. Чтобы писать тексты, нужен человек, который хорошо владеет словом и редактурой. А на то, чтобы высылать PDF файлы клиентам и дальше коммуницировать с ними письменный или по телефону, нужен человек, который умеет продавать. То есть, пу сути нужно 2 специалиста.
И второй момент. Если мы ищем универсала, то встает вопрос: есть ли на рынке такие люди, которые одновременно могут и писать продающие тексты, и продавать? Если нет, то возвращаемся к первому пункту - нанимаем 2 человек на разные должности.
2. Не было продуманной стратегии развития приложения и менеджмента
Каждые 3-4 рабочих дня хаотично менялись задачи. Никто не рассчитывал наши мощности заполнения сайта. Давали задачи непосредственно по копирайтингу, в итоге мы не успевали сделать основную на тот момент работу - заполнение сайта.
Всеми вопросами менеджмента занимались 2 человека - руководитель проекта и его заместитель. У заместителя не были четко очерчены его полномочия по принятию решений. Поэтому план контента в телеграме вроде им одобрен, но надо дождаться утверждения от руководителя, который занимается буквально всем в проекте. В итоге мы теряли время и буксовали этапе одобрения руководителем, через него проходило буквально все - вплоть до утверждения финального текста поста в инстаграм.
Не было сегментации аудитории, опираясь на которую выстраивались бы рекламные заходы, тональность взаимодействия с аудиторией. Да и в целом не было понятно, чьи конкретно мы проблемы решаем, создавая платформу и рассказывая о ней через полезный и развлекательный контент и рекламу. Поэтому и правки были соответствующе выматывающими - они давались сугубо по каким-то личным соображениям, а не в соответствии задачи единицы контента.
Мой совет:
Тут я вижу проблему отсутствия первого разбора групп целевых аудиторий. Когда мы создаем некую контент-стратегию, мы всегда должны выделить сначала группы целевой аудитории, для кого мы вещаем. А группы целевой аудитории могут быть очень разные. И после того, как мы понимаем для кого мы все это делаем и какие группы целевой аудитории мы пытаемся охватить, нам становится понятно, что мы транслируем в рекламе и в контенте. Например, в продажах приложения по недвижимости ЦА могут быть не только покупатели , но и арендаторы, партнеры, девелоперы и другие брокеры и риэлторы.
То есть это может быть двоякая, троякая и совсем разная целевая аудитория. И под нее мы уже создаем контент-стратегию, где мы четко определяем, в какой день недели, сколько раз в неделю, сколько раз в месяц мы даем тот или иной контент.
Контент мы делаем как путь клиента, начиная от охвата клиента, прогрева его, продающий контент, возвращающий контент и контент, который учит пользоваться приложением, например. То есть у нас есть несколько таких стратегических шагов в контенте, когда мы создаем стратегию на основе клиентского пути и у нас получается контент-план. И для каждой целевой группы делаем вот этот клиентский путь в соцсетях, из него формируется контент-стратегия.
И следующий момент: когда мы здесь уперлись в проблему согласования с основным менеджером, я считаю, что команда должна уметь действовать самостоятельно и уметь исправлять свои ошибки. А для этого первично менеджер должен был составить tone of voice, то есть то:
- что дозволено
- каким языком мы разговариваем с той или иной группой целевой аудитории
- какой общий у нас язык
- какие ценности у нашей компании есть и как мы их доносим
И также мы заранее определяем, через какие инструменты и доносим все это в постах, текстах и визуале. И если команда знает все это, она с наименьшей вероятностью будет делать ошибки. И менеджер, возможно, бы правил только первое время, обучая свою команду с точки зрения, что можно, что нет. Хотя это тоже текстом можно предоставить. А потом бы спокойно отпускал команду в вольное плавание и уже не проверял бы каждую запятую в тексте.
3. Заранее не продумали, как автоматизировать выгрузку данных об объектах и их ежедневное обновление
В одном ЖК могло находиться 500 квартир. Каждый день идут продажи. Единственный известный нам способ, которым передавались данные о наличии объектов, были обновленные pdf файлы или exel таблицы со списком квартир. Их присылали менеджеры застройщиков в What`sApp: некоторые присылали сами каждый день, некоторым нужно было писать и запрашивать.
Весь этот огромный массив информации не то, что обновлять ежедневно вручную, а просто вносить на сайт руками 2-3 сотрудников - это сомнительная затея, на которую пошло руководство проекта. Обновлять данные о наличии объектов предполагалось тоже вручную на начальном этапе, пока не разработали ПО для этих процессов. Как оказалось, разработать такое ПО - это долго, дорого и они не единственные, кому нужна такая технология.
Мой совет:
Это проблема автоматизации. В данном случае компания решила разработать свое ПО, хотя я считаю, что на рынке есть огромное количество ПО. Можно было сделать проще: сделать выгрузку и хранение данных через “Мой склад”. Представим себе, что каждая квартира - это единица товара. Когда у нас происходит какая-то продажа автоматически с сайта, с приложения брокера или оффлайн, брокер отмечает в приложении продажу или бронь. После этого ”Мой склад” передает данные на сайт и все остальные брокеры видят это. То есть уже никто не сможет ее вторично купить, посмотреть и тому подобное - все происходит в режиме реального времени.
Чтобы осуществить такую схему и закрыть вопрос того, как обрабатывать ежедневные обновленные списки вакантных квартир от застройщиков в разных форматах, нужно разработать загрузчик данных для “Мой склад” или любой другой системы складского учета. То есть, застройщик передает Excel или PDF файл, загрузчик бьет эти файлы по названию строки, например, площадь квартиры и адрес и загружает на сайт. То есть, СRM списывает эту квартиру как проданную или ставит ей метку, например “внесен залог”.
Подписывайтесь на мой канал, гле я рассказываю о маркетинге бизнес услуг и пишу о новостях мира маркетинга, экономики и психологии продаж.