Мало написать кейс о том, как IT-компания помогла своему клиенту. Важно, чтобы написанная история была не только интересной, полезной, но и эффективной. Хорошие кейсы приносят лиды, растят узнаваемость и делают из продукта полезный пример. О том, как написать эффективный кейс, как правильно изложить историю о клиенте, его проблеме и решении с помощью IT-продукта, рассказывает основатель агентства PR Doctor и премии «Громче!» Валерия Мингова.

Первый этап работы над кейсом. Сбор информации

Сбор первичной информации — о компании, ее продукте, об аналогах от других разработчиков, о пользователях.

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

• Основные моменты, которые важно прояснить: «Почему решили внедрить новый продукт? Как этот круг задач решался ранее? Насколько важное место данный продукт (ПО, например) занимает среди всех процессов в учреждении?» Эти вопросы помогают выяснить, какие проблемы стояли перед заказчиком и почему он выбрал это решение.
• Следующий этап — выяснить, как проходило внедрение: «Расскажите об основных этапах внедрения? Сколько времени оно заняло?» Ответы дадут понять, как был организован процесс, какие этапы включены во внедрение и сколько времени это заняло.
• Ключевой момент — выбор. Уточните, почему клиент остановился именно на этом продукте: «Почему выбрали именно это ПО? Какие альтернативы рассматривали?» Важно не критиковать конкурентов, лучше их даже не упоминать напрямую, а объяснить, по каким причинам было выбрано именно это ПО и не подошли другие. Например, данное ПО имеет уникальный функционал, которого нет у других, разработчик готов помочь на всех этапах внедрения и т. д.
• Далее выясните, как именно клиент использует продукт: «Какой именно вариант поставки был выбран? На каких платформах или операционных системах будет использоваться». Эти вопросы помогают понять техническую сторону внедрения и оценить, насколько продукт интегрируется в существующую инфраструктуру клиента.
• Следующая часть вопросов относится к этапам реализации проекта: «Когда стартовала работа? Насколько сложен был процесс развертывания? На каком этапе проект находится в настоящее время? Сколько сотрудников уже использует продукт, а сколько будет их в перспективе?» Полученные ответы дадут представление о том, как идет процесс, сколько людей вовлечено и насколько активно используется новый продукт.
• Затем стоит выяснить, насколько продукт соответствует ожиданиям: «Какие задачи ставились перед новым ПО, какие функции оно призвано было выполнять? Насколько успешно выбранный продукт справляется с задачами? Возможно, были какие-то моменты, которые стали “приятной неожиданностью” для пользователей?» Здесь важно услышать реальные примеры использования.
• Возможность интеграции и ограничения — еще один важный аспект, который поможет оценить, как продукт взаимодействует с другими системами и насколько удобно его использовать в комплексе: «С какими уже существующими информационными системами предстояло продукт интегрировать? Насколько сложна была интеграция, какова ее архитектура, удобство работы с API, например?»
• Любое внедрение нового продукта неизбежно сталкивается с трудностями. Не забудьте выяснить, с какими именно и как они были решены: «Какие сложности в ходе внедрения пришлось преодолеть? Представлял ли собой проблему процесс перехода для пользователей — приходилось ли их дополнительно обучать?» Здесь не нужно бояться критики, если в процессе инсталляции, развертывания, внедрения были какие-то сложности, неполадки, несовместимости. О них нужно рассказать и особо подчеркнуть, как они решались. В таком случае, когда следующий заказчик будет внедрять ваше решение и столкнется с такими же вопросами, он будет знать, что это нормально, преодолимо и не влияет на использование в дальнейшем.
• Обязательный вопрос — оценка эффективности внедрения и полученные результаты: «Как оцениваете эффективность внедрения в целом, по каким показателям? Как внедрение способствовало продуктивности работы?» Будет очень полезно, если можно назвать какие-то цифры экономии, роста продуктивности, — например, после промышленного внедрения время обработки задачи снизилось на 30%.
• Ну и последний вопрос про будущее: «Каковы планы по масштабированию практики использования внедренного решения?»

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

Второй этап. Выбор, где разместить кейс

Мало написать эффективный текст, важно разместить его там, где он будет эффективен.

Где ваша ЦА?

Размещать описание кейса надо не там, где бесплатно или легко возьмут, а там, где есть ЦА. То есть выбор канала размещения зависит от целей текста. И лучше не на сайте заказчика-разработчика (исключение — блог на сайте с большим количеством активных читателей, который является целевой аудиторией), а на независимых, охватных, посещаемых площадках с дальнейшей дистрибуцией по своим каналам.

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

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

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

Третий этап, творческий. Как написать кейс

В написании кейса мало творчества и писательства ради писательства. Надо последовательно выполнять несколько шагов при описании кейса.

Составление плана или структуры кейса. Читатель должен получить историю с контекстом работы заказчика и его партнера.

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

Кейс строится по следующим принципам. Завязка — какая работа была проделана: рассказ о задаче, которую надо было решить, развитие сюжета; и развязка — результат работы.

Выбор формата кейса: интервью, текст с картинками или видео.

И коротко еще пройдемся по структуре кейса.

• Начнем с рассказа о компании, ее сфере деятельности, масштабе бизнеса. Например, «Наш заказчик (или мы) — крупная строительная компания, работающая в нескольких регионах. У них 10 филиалов и более 500 сотрудников».
• Далее описываем задачу, которую нужно решить. Проблемы до внедрения нового продукта (процесса), почему стали искать новое решение. Например: «Компания столкнулась с проблемой управления проектами. Старая система не справлялась с объемами данных и не поддерживала нужные функции [здесь подробности, какие данные, какие функции]. Решили внедрить новое ПО для оптимизации процессов».
• Далее опишите, как проходило внедрение, какие этапы были включены, сколько времени это заняло. «Процесс внедрения занял шесть месяцев. Начали с анализа текущих процессов, затем выбрали ПО. Развертывание прошло без серьезных проблем, все этапы были завершены в срок [здесь напишите, как и с чем интегрировали, с какими ИС, на каком количестве или объеме тестировали]».
• Самый важная часть кейса — рассказ о результатах. Лучше всего, если возможно, показать цифры — экономию, отказоустойчивость, повышение производительности, долю рынка, трафик, выручку. Если цифр нет, покажите, в чем главная польза от проделанной работы: «Благодаря изменению архитектуры и увеличению производительности повысилась отказоустойчивость ИТ-систем клиента. Отдельные системы показали улучшение производительности в 1,5–2 раза после актуализации архитектуры».
• Завершите блок планами клиента на будущее: «В 2023-м началось масштабное развертывание продукта. На июль 2023 года в компании работало около 30% сотрудников организации (примерно 1500 человек). До конца 2023 года планируется увеличить это число до 70–80%».

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

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

Все под NDA или можно ли написать обезличенный кейс? Да, можно. Не надо писать название компании клиента, все остальные детали кейса можно описывать.

Этап согласования текста. Как договариваться о кейсе и согласовывать его

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

Этап внесения правок и редактуры

После внесения правок от экспертов следует проверить текст на чистоту — орфографию и пунктуацию, уникальность, заспамленность, водность и легкость прочтения.

Сколько времени занимает работа с кейсом

В этом уравнении есть постоянные числа и переменные. Постоянные: подготовка вопросов — 2 дня, написание драфта или «рыбы» — 3 дня, согласование с редакцией — неделя. Переменная — это согласование с экспертами внутри заказчика-разработчика.

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

Второе дыхание текста

После публикации текста в основном издании нужно дистрибутировать дальше.

• Разместить в соцсетях компаний и спикеров. В том же объеме, а можно и в дополненном, если формат издания был жестким и не удалось в него вместить все интересные факты.
• Ресайз текста — разобрать на небольшие материалы, если возможно. То есть использовать как информационные поводы и описать отдельно события, технические решения и решенные задачи. Эти небольшие материалы можно размещать на других платформах.
• Использовать части кейса в таргетированной рекламе — целевой, выборочной рекламе на ЦА.
• Подавать кейс на премии и конкурсы.
• Выступать с описанным кейсом на мероприятиях.

• Об авторе
• Недавние публикации

Digital Report

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

Digital Report недавно публиковал (посмотреть все)

• Как ИТ-компании написать хороший кейс — 30/07/2024 19:45
• Павел Дуров стал отцом более 100 детей — 30/07/2024 17:30
• Sony в России: Минимальное присутствие в 2024 году с перспективой возвращения — 29/07/2024 15:07