На многих корпоративных сайтах раздел кейсов запускается с публикацией сразу нескольких проектов, а затем полгода не обновляется. Когда приходит время добавить новые кейсы, выясняется, что у старых изображений разные размеры, названия клиентов написаны по-разному, а на некоторых страницах даже нет даты проекта. Сложность поддержки кейсов не в том, чтобы «опубликовать», а в том, чтобы «публиковать последовательно и без хаоса». Ниже мы рассмотрим три этапа: сбор материалов, публикация и проверка.
1. Создайте привычку собирать материалы заранее, а не искать их в последний момент
Чаще всего работа над кейсами тормозится не из-за неумения пользоваться админкой, а из-за отсутствия доступных материалов. Рекомендуется сразу после завершения проекта или оказания услуги складывать следующие вещи в одно постоянное место (папку в облаке, общий документ — неважно):
- Название проекта и отрасль — можно использовать внутреннее название команды, не обязательно писать рекламный слоган;
- Изображения, которые можно публиковать, с указанием даты съёмки или скриншота;
- Описание проекта объёмом 100–200 слов: с какой проблемой столкнулся клиент, что было сделано, какой результат получен;
- Подтверждение согласия клиента на публикацию названия, логотипа и данных.
Последний пункт чаще всего пропускают. Прежде чем указывать название клиента, товарный знак или данные проекта, убедитесь, что он не против публикации. Если подтверждения нет, используйте обезличенные формулировки вроде «одно производственное предприятие» или «одна сеть магазинов». Это не юридическая консультация, а способ избежать затрат на переделку, если позже попросят убрать информацию.
Имена файлов материалов рекомендуется составлять по схеме «отрасль + краткое название проекта + год», например «общепит-приложение-2024». Когда над кейсами работает несколько человек, по имени файла сразу понятно, можно ли использовать материал, — это быстрее, чем искать в истории переписки.
2. Унифицируйте правила публикации, чтобы потом не править каждый кейс вручную
Страница кейса не обязательно должна быть длинной статьёй, но поля должны быть единообразными. Если в админке есть настраиваемые поля (во многих CMS они называются «пользовательские поля» или «дополнительные свойства»), можно зафиксировать следующие: отрасль клиента, содержание услуги, срок проекта, формат поставки. Единые поля дают основу для фильтрации в списке и рекомендаций похожих кейсов.
Структуру текста рекомендуется свести к трём частям: предыстория и проблема клиента, что мы сделали, текущий статус или отзыв клиента. Если в третьей части нет публичных результатов, напишите, что было передано, — не придумывайте данные ради объёма.
При обработке изображений обратите внимание на три момента:
- Обложки должны быть одного соотношения сторон, иначе в списке они будут разной высоты;
- Имена файлов изображений используйте на английском или в транслитерации с ключевыми словами, например
hotel-booking-page.jpg, — это удобно для поиска в команде и для последующей замены; - Большие изображения в тексте сжимайте перед загрузкой, чтобы страница не тормозила на мобильных.
В заголовках лучше использовать «отрасль + содержание услуги», чем просто название клиента. Например, «Модернизация системы заказов для сети ресторанов» понятнее, чем «Кейс компании такой-то», и лучше соотносится со структурой раздела.
3. Регулярная проверка: раз в квартал просматривайте четыре ключевых момента
Раздел кейсов не нужно обновлять ежедневно, но должен быть фиксированный ритм проверок. Рекомендуется раз в квартал выделять полчаса на проверку:
- Работают ли ссылки: если сайт клиента или адрес проекта, упомянутые в кейсе, больше не открываются, уберите их или замените текстовым описанием.
- Не устарела ли информация: если клиент сменил название или направление деятельности, своевременно обновите или снимите кейс, чтобы он не противоречил текущему положению.
- Разумна ли сортировка: свежие и показательные кейсы ставьте вперёд, старые — в конец, не оставляйте всё в порядке добавления.
- Понятна ли структура раздела: когда кейсов становится много, их можно сгруппировать по отрасли или типу услуги. Если принцип группировки определён, не меняйте его часто, иначе старые ссылки и восприятие пользователей запутаются.
Если кейсов уже несколько десятков, добавьте на страницу списка фильтры, а не выкладывайте всё подряд на одной странице. Пользователь ищет «кейс, похожий на мою ситуацию», а не «все кейсы».
4. Подходы к типичным вопросам
Что делать, если кейсов слишком мало? Можно начать с имеющихся записей об услугах, объединив однотипные проекты в один кейс с описанием объёма работ — не обязательно заводить отдельную страницу для каждого проекта. Важно не количество, а возможность для посетителя понять, что вы уже делали подобное.
Что делать, если клиент против публикации? Используйте обезличенное описание: сохраните отрасль, проблему и решение, уберите название и идентифицирующую информацию. Такие кейсы тоже имеют справочную ценность.
Нужно ли делать отдельную страницу для каждого кейса? Зависит от количества и ресурсов на поддержку. Если кейсов меньше десяти, удобнее разместить их блоками на одной странице. Если их много и нужна фильтрация по отраслям, тогда стоит разбить на отдельные страницы. Но перед разделением подумайте, кто будет этим постоянно заниматься, чтобы страницы не остались без присмотра.
Поддержка раздела кейсов — это прежде всего набор привычек: собирать материалы сразу, публиковать по единым полям, раз в квартал проверять. Запуск — только начало; долгосрочная польза зависит от того, будет ли кто-то регулярно проходить по этому списку.
