Конфиденциальность и кейсы: как показывать работу, не нарушая доверие

Конфиденциальность и кейсы: как показывать работу, не нарушая доверие

В агентском бизнесе есть вечный конфликт.

С одной стороны, нужно показывать кейсы.

Без них сложно продавать, доказывать экспертизу и объяснять, чем ты отличаешься от других подрядчиков.

С другой стороны, почти в каждом нормальном проекте есть конфиденциальность.

Данные клиента.

Внутренние процессы.

Коммерческие показатели.

Архитектура.

Интеграции.

Проблемы, которые клиент не хочет выносить наружу.

И тут важно не превращать кейс в слив чужой кухни.

На мой взгляд, базовое правило простое:

ВСЕГДА нужно согласование.

Даже если формально NDA нет.

Даже если «мы же ничего страшного не написали».

Даже если название компании не указали, но по деталям её легко узнать.

Как можно показывать работу аккуратно?

1. Публиковать обезличенный кейс

Не «сделали CRM для компании X», а:

«Для B2B-компании из сферы производства собрали личный кабинет дилера: заявки, статусы, документы, интеграция с учётной системой».

Так читатель понимает суть работы, но клиент не раскрыт.

2. Показывать процесс, а не коммерческую тайну

Можно рассказать:

— как собирали требования;

— почему выбрали такую архитектуру;

— какие риски нашли на старте;

— как разбили проект на этапы;

— как организовали поддержку после запуска.

Это часто даже полезнее, чем просто написать: «увеличили конверсию на 37%».

3. Согласовывать цифры

Цифры выглядят убедительно, но с ними нужно быть особенно осторожным.

Выручка, конверсия, стоимость лида, количество пользователей, внутренняя эффективность — всё это может быть чувствительной информацией.

Если хочется использовать цифры, лучше согласовать формулировку: не «сэкономили клиенту 4,8 млн рублей», а «снизили ручную нагрузку на отдел за счёт автоматизации повторяющихся операций».

4. Показывать свою часть работы

Не нужно раскрывать весь бизнес клиента, чтобы показать компетенцию.

Можно рассказать конкретно про свой вклад:

— разработали модуль;

— ускорили сайт;

— настроили интеграцию;

— закрыли технический долг;

— стабилизировали проект после предыдущего подрядчика.

5. Заранее прописывать право на кейс

Идеальный вариант — обсуждать это ещё на этапе договора.

Можно ли использовать логотип?

Можно ли называть компанию?

Можно ли показывать интерфейсы?

Можно ли публиковать цифры?

Нужна ли предварительная модерация текста?

Так меньше неловких разговоров после релиза.

Для меня хороший кейс — это не тот, где подрядчик выложил максимум подробностей.

Хороший кейс — это тот, где видно экспертизу, но не нарушено доверие.

Потому что в долгую репутация важнее одного красивого поста.