Как IT-компании постят кейсы, которых не было, и как написать отличный, даже если хвастаться особо нечем

«Она хотела бы жить на Манхеттене, но есть только офис в Житомире и полтора джуна» 

Всем привет, меня зовут Ярослав, я работаю 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-систем рынок перенасыщается однообразными статьями — «крупный бизнес КоторыйНельзяНазывать недавно подключился к нашей системе, и у них теперь работники сами даже по выходным приходить стали за пол-зарплаты». 

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


P.S. Сделал небольшой словарик после прочтения комментариев.

*Кейс. По-английски «case study». Любой интересный опыт компании, изложенный в формате последовательной истории. Кейс может рассказывать о бизнес-процессах компании и технических особенностях создания продукта.

*Гострайтинг. Процесс написания материала, в котором автор текста отдаёт права на публикацию и разрешает подписать текст именем одного из членов команды заказчика.

*Нейтив-пруфридер. Это стилистический редактор текста - носитель языка из той страны, на аудиторию которой нацелено продвижение проекта.


Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 17

    +7
    А главная проблема в том, что «за самым пышным павлиньим хвостом прячется обыкновенная куриная жопа». Компании, которые делают самые обыкновенные вещи и знают это, всё равно имеют что рассказать. Вон Milfgard, как самый яркий пример когда самые обычные и часто даже далёкие от IT вещи про работу ретейлера настолок читаются с неослабевающим вниманием.

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

    Однако таков корпоративный стандарт. Потому что мало кто хочет делать лучше, чем у конкурентов — почти всем надо также.
      +2
      Товарищ Абдульманов, кстати, и для Билайна писал, насколько я помню, так что да, кадры решают всё.
      0
      Ну вообще да, это же просто рекламная гонка. Зачем будучи крупной компанией вести себя скромно, если конкуренты на каждому углу орут о своей невероятной значимости
        0
        Я считаю что абстрактное хваставство а-ля «Да мы самые крутые в нашей области» все-таки не так мелко смотрится. Тем более что даже хвастаться можно не особо кривя душой — «молодая развивающаяся команда», «амбициозные проекты», «100% удачно завершенных заказов» и т.д. — все эти вещи вполне могут быть правдой. К этому слогу все привыкли и читатель за это уж всяко сильно бухтеть не будет.

        Что важно так это избегать это попыток выделиться с помощью выдуманной конкретики, которая в 90% случаев звучит как «ну сел я на пушечное ядро и полетел на Луну».
      +1
      Что такое кейс в данной статье? Бизнес-кейс, статья, use case, ....?
        +2
        image
        Это же чемодан! Для баяна!
        Кейс он как блютус — любая статья становится лучше с кейс!
          +3
          Присоединяюсь к вопросу.
          «кейсы — это гострайтинг».
          Бедный бедный русский язык.
            +1
            Для кейсов нужны инсайды, инхаус-автор и нейтив-редактор, а еще нейтив-пруфридер — какой же бедный? Богатейший! Но непонятный — гострайтинг я так и не перевел на нейтив рашн.
              +1
              Это про кейсы по госту.

              ГОСТ 28631-2005, между прочим.
                0
                Серьезно? А я думал на «ghost writing», потому как «то есть они будут опубликованы не от имени реального автора текста, а от имени специалиста из вашей команды.» — есть такой термин «писатель-призрак».
              0
              Грешен, признаю, никогда даже не задумывался на тему правильного русского звучания профессиональных терминов. Добавлю, пожалуй, словарик. Хотя для меня лично адаптированные версии всегда выглядят примерно так: image
              0
              Под кейсом имею в виду любого рода оформленную историю из жизни компании. Это может быть и история из бизнес-сферы вроде «как мы искали клиента в стране X», техническая история «как мы разрабатывали решение X», просто опыт взаимодействия с другой конторой или продуктом. Кусок реального опыта который удачно ложится в статью.
              0
              конечно, внимание тяжело привлечь, а не быть себе пиарщиком и не уметь себя продать — это уже провал. но по мне, привлечь внимание мало, тирады о своей крутости должны соответствовать действительности, иначе в таких текстах смысла мало
                0

                А сколько Житомира в Пало-Альто!!! Кликбейт он такой, и даже в это статье!

                  0

                  Мы как-то не сразу могли вспомнить значение аббревиатуры SaaS, предподожили что это Service as a Service. Возможно этот SaaS имеется ввиду в статье (ещё со времён учёбы при написании проекта хорошим тоном считалось обьяснять аббревиатуру, даже если все и так знают о чём речь).

                    0
                    По моему редакторскому опыту — если в статье объяснять вообще всё, то можно по итогу получить Википедию. Термины и аббревиатуры объясняются если они только достаточно сложные И достаточно важные для понимания статьи. Если по итогу остается много необъясненных маловажных терминов/аббревиатур — они просто выкидываются чтобы текст не грузил читателя почем зря.

                    В данном случае даже если вы перевели SaaS как Sелёдка as a Sелёдка то вы ничего особо и не потеряли

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое