«Она хотела бы жить на Манхеттене, но есть только офис в Житомире и полтора джуна»
Всем привет, меня зовут Ярослав, я работаю Full-Stack девелопером в SaaS-компании, сейчас живу в Болгарии.
В дополнение к основной работе я руковожу IT-отделом международной контент-редакции и провожу экспертизу статей.
Мы с ребятами пишем очень много кейсов на английском для девелоперских команд и SaaS-проектов, выходящих на мировой рынок. И всё чаще, к сожалению, клиенты вместо нормального рассказа о том, что они умеют, заказывают выдуманные кейсы на основе чужих материалов, пытаются выстраивать контент-маркетинг на несуществующих результатах, писать о несуществующей локации в Силиконовой долине — в общем, казаться теми, кем они не являются и так продвигать свои услуги.
Как правило, топики таких кейсов очень модные и крупные — проекты в здравоохранении (и не только в частном), в образовании (и не просто «запустили сайт по изучению английского», а «создали массовые решения для школ и университетов»), биг дате, логистике и других сферах, которые подразумевают, что заказчик — государство или соизмеримого размера конгломерат.
Почему так делать не нужно?
Клиенты умеют гуглить все лучше и лучше. Да, большинство из них все еще нубы в IT, но распознать Житомир за Пало-Альто они смогут, как бы красиво не расписывали обратное, поэтому лучше рассказывать о локации мечты хотя бы через дефис: «Житомир-Пало Альто». Кроме того, клиенты захотят как минимум созвониться, то есть уже на этапе брифинга станет понятно, что вы находитесь в разных часовых поясах, и это вызовет недоверие.
Прилизанная безликая реклама в кейсах больше никому не нужна, как бы некоторые маркетологи ни пытались убедить вас в обратном. Тем более, если эта реклама основана не на вашем опыте. Лучше дать интервью редакторской команде и рассказать о вашем реальном опыте, настоящих ошибках и преодолениях в работе, тогда тексты получатся про настоящих вас. Хорошо написанные кейсы с описанием реальных проблем — это ценнейшая штука, которая всегда конвертируется в лиды и репосты.
Если вы никогда не воплощали крупный проект в жизнь, но подозреваете, что сможете, то максимум, что вы способны показать клиенту, — это презентацию с кучей умных IT-слов. И даже если повезет — клиент попадется наивный и всепрощающий, и вы начнете работу, — то в процессе гарантированно вы столкнетесь с множеством подводных камней. Стоит ли так рисковать?
Что делать, если вообще нет впечатляющих проектов — как правильно собрать кейс, чтобы авторы его интересно написали?
Даже при слабой фактуре проекта хорошо поданный текст люди все равно прочитают. Подробно расскажите , что конкретно вы делаете авторам и редакторам, которых нанимаете писать материалы. Например, у нас в студии я сижу на созвонах, мы выстраиваем структуру кейса со слов клиентов. У разработчиков наверняка есть запарные технические челленджи, которые им запомнились, у прожекта наверняка будет прохладная история, как они преодолели непонимания с заказчиком, у тех и других может найтись курьезный случай, над которым ржали всем отделом.
Даже историю о том, как у вас сгорел сарай с серверами, можно упаковать в интересный, полезный, а главное — уникальный кейс безо всякого воровства у конкурентов.
Вспоминайте необычные истории, а авторы материала придумают, как их адекватнее упаковать: тест-кейсы в майнд-мэпы, этапы в хронологию-инфографику и так далее.
Как построить процесс написания топового кейса на нужном языке?
1. Обозначить цель кейса
Четко определите назначение кейса: какие задачи он должен решить, какие вопросы и боли потенциальных клиентов закрывать. Кейсы могут прогревать аудиторию, подтверждать экспертность команды в определенной нише, могут быть нацелены на потенциальных новых сотрудников или инвесторов, могут быть более образовательными, развлекающими, продающими. Целевая аудитория определяется на берегу: чем понятнее вам самим портрет основного читателя материала, тем легче получится создать классный кейс.
2. Выбрать рассказчика
Чаще всего кейсы — это гострайтинг, то есть они будут опубликованы не от имени реального автора текста, а от имени специалиста из вашей команды. Поэтому нужно выбрать рассказчика, желательно надежного сотрудника, которому вы хотите прокачать онлайн-репутацию.
Это может быть разработчик/тимлид/проджект-менеджер, который способен хоть как-то рассказать о проекте, описать процессы работы, получить от команды несколько любопытных историй из вашей практики.
ВАЖНО: этим человеком не должен быть маркетолог или пиарщик! Только реальный сотрудник, максимально погруженный во внутреннюю «кухню».
Для кейсов нужны инсайды, индивидуальные особенности построения продукта, небольшие цепляющие детали: контекст процессов, реакция клиентов. Поднимите переписки, отчеты, пересмотрите Zoom-собрания. Отнеситесь к вашему проекту как к отдельной вселенной с персонажами, где каждый — живой человек со своей суперсилой и слабыми сторонами.
Вся эта информация будет полезна авторам кейса, они вникнут в детали, поймут, как в целом устроена конкретно ваша работа, какие особенности вашего проекта можно выгодно преподать в кейсе (маркетологи упаковывают это в понятие Tone of voice бренда). Так вот для кейса нам нужно весь этот «тон ов войс» разделить на составляющие — показать, как конкретно над продуктом работает реальная команда.
Чем больше «человеческой» информации будет стоять за кейсом, тем легче будет впоследствии превратить его в лидогенерирующую историю, а не просто в очередной бессмысленный текст со ссылкой.
3. Интервью с исполнителями
Чтобы фишки вашей работы не утекли налево, сначала стоит подписать NDA. После этого сделать интервью, на созвоне поделиться своим видением кейса. Например, в моем случае в обсуждении участвует ИТ-эксперт и главный редактор, который курирует написание кейса на нужном языке. Клиент в свободной форме делится особенностями проекта и отвечает на возникающие вопросы.
ВАЖНО: убедитесь, что с авторами материала у вас согласовано NDA, иначе ваш кейс запросто угонят любители рерайта из Пало-Альто.
Если у вас есть толковые инхаус-автор и нейтив-редактор, этот шаг можно пропустить: экспертом выступит и сам рассказчик. Если вы хотите разместить кейс не у себя в блоге, а на каком-то внешнем ресурсе (СМИ), обязательно обговорите площадку размещения до написания текста. Так автор и дизайнер смогут точнее попасть в стиль выбранного блога, а материал разместят быстро и без правок.
ВАЖНО: если вы решили публиковать кейс не у себя в блоге, а где-то на внешнем ресурсе, укажите эту площадку при составлении брифа, еще до передачи на написание. Если текст будет сделан не под конкретную площадку, то он может не пройти по редполитике сайта, тогда редактор СМИ может его не принять или отправить на глобальную переработку.
Из всей собранной информации нужно сочинить захватывающую историю. В этом всегда и заключена суть кейса. История может быть любой: преодоление сложностей, налаживание процессов, ваш путь к повышению качества работы, как вы находили подход к конкретному клиенту, и какой итог получился.
Нужно помнить, что история не всегда означает путь к профиту. Это может быть улучшение условий для сотрудников, подход к сокращению времени на работу или новая бизнес-модель. Акцент делается на том, что важнее всего для целевой аудитории, которой вы адресуете свой рассказ.
4. Бриф
ИТ-эксперт составляет бриф, по которому автор будет писать кейс. Как только у вас получилась базовая история, по ней можно делать структуру самого кейса. Структуры подчеркивают все этапы рассказа и разбивают его на 4–5 подзаголовков. Бриф обязательно утвердить и внести коррективы, пока кейс ещё не написан.
ВАЖНО: в брифе не допускайте пустых маркетинговых фраз, избитых клише. Приведите точные данные по проекту, убедитесь, что в кейс не включено ничего лишнего, а процессы будут четко и понятно отражены в тексте.
На этом этапе можно дать задание дизайнеру-иллюстратору — упаковать важную информацию из истории в красивую инфографику или дополнить разделы кейса иллюстрациями.
5. Написание
Автор пишет текст по брифу, уточняя все вопросы по проекту у эксперта.
ВАЖНО: качественно рассказанная история может собирать аудиторию многие годы после публикации. Старайтесь не привязываться без необходимости к текущим событиям в мире, иначе уже на момент выхода статьи она может протухнуть.
6. Редактура
Текст от автора крайне желательно показывать нейтив-редактору (пруфридеру) из страны вашей целевой аудитории.
ВАЖНО: любому автору нужен редактор, даже если пишет невероятный литератор с грамотой «Русский медвежонок».
Нейтив-пруфридер подстраивает текст под целевую аудиторию, делает язык более подходящим по стилистике. Это помимо устранения опечаток и других грамматических неточностей.
7. Финальная экспертиза
Готовый текст смотрит ИТ-эксперт на предмет полного соответствия брифу. Это этап быстрых финальных правок перед публикацией. Все, кейс готов, можно публиковать на выбранной площадке или в блоге.
Как выйти в топ трендов без уловок?
Бессменно лучшая тема для IT-контента — это решение повседневных задач бизнеса средствами софта. Или, по-простому, «как мы разработали/купили продукт X и все резко стало хорошо». Усилиями интеграторов ERP-систем рынок перенасыщается однообразными статьями — «крупный бизнес КоторыйНельзяНазывать недавно подключился к нашей системе, и у них теперь работники сами даже по выходным приходить стали за пол-зарплаты».
Из этой кучи бахвального шума и нужно выделиться: либо по нише (найти точно своего читателя), либо по способу подачи (написать так, чтобы даже мимокрокодилу было прикольно), либо по ценности и уникальности самого материала (предоставить структурированную, полную и применимую в реальности информацию). Более того, один отличный кейс может стать донорским материалом для кучи контента от постов в соцсетях и заметок в блоге до пресс-релизов и серии видео о продукте.
Автор: Ярослав Старченко
