Клиент не понимает код — он понимает результат: как разработчику продавать через контент на языке выгод
Первый созвон почти всегда выглядит одинаково. Разработчик обстоятельно объясняет, почему предлагает не готовую коробку, а своё решение: рассказывает про очереди, кэш, отдельный сервис интеграции и то, как всё это потом переживёт рост нагрузки. Заказчик — владелец сети автосервисов, скажем — вежливо слушает минут семь. А потом спрашивает: «Ага. Сколько стоит и когда заработает?»
Ничего из сказанного до него не долетело. Дело не в том, что он не старался. Просто у него нет шкалы, по которой можно сравнить ваш стек со стеком конкурента, и он честно пользуется той шкалой, которая есть: деньги, сроки, риск влететь.
Ровно та же история происходит с текстами. Студия пишет в блог статью про миграцию на новую версию фреймворка, гордится ей — и получает ноль обращений. Не потому, что статья плохая. Потому что её адресат — другой разработчик, а платит за проект не он.
Что вы узнаете из статьи
- Почему технически честный текст о разработке не приводит заявки
- На какие вопросы заказчик отвечает про себя, пока читает вас
- Рабочий приём перевода технического решения в выгоду
- Чем «просто» отличается от «поверхностно»
- Как удержать регулярность публикаций, когда вы в спринте
Почему грамотный технический текст не приводит клиентов
Заказчик разработки находится в непривычно уязвимом положении. Он покупает то, чего пока не существует, за сумму, которую не может проверить, у людей, чью работу не в состоянии оценить. Ни в одной другой закупке у него нет такого разрыва: станок можно потрогать, аренду сравнить по рынку, а вот «интеграция с 1С за восемьсот тысяч» — это просто цифра и обещание.
Из этого положения он читает ваш текст. И задаёт себе не те вопросы, на которые вы отвечаете. Вы объясняете, почему выбрали асинхронную обработку, он в это время думает: сколько заказов у меня сейчас теряется в ручном переносе и вернутся ли эти деньги за год. Вы описываете покрытие тестами, он прикидывает, что будет с его магазином, если через полгода вы перестанете отвечать в чате.
Отсюда неприятный побочный эффект. Когда клиент не видит разницы между подрядчиками, он выбирает по единственному различимому параметру — по цене. Так студия с нормальным процессом, аналитикой и поддержкой проигрывает фрилансеру с ценой втрое ниже. Не по качеству, а по невидимости качества.
Есть и третья вещь, о которой редко думают. Технический текст молча предполагает, что читатель уже решил делать проект и выбирает исполнителя. А в реальности большая часть аудитории ещё на предыдущем шаге: человек не уверен, нужен ли ему вообще сайт, или хватит бота, или проблема вообще не в софте. Именно там теряется больше всего заявок — и там же почти никто не пишет. Отдельного разговора заслуживают страхи заказчика про сроки и поддержку: они всплывают позже, но убивают сделки не менее уверенно.
Что заказчик на самом деле хочет прочитать
Проще всего проверить свой текст четырьмя вопросами, которые крутятся в голове у человека с бюджетом.
Первый: это про мою ситуацию? Заказчик узнаёт себя не по отрасли, а по симптому. «Менеджеры вручную переносят заявки из почты в таблицу» — узнал. «Автоматизация бизнес-процессов» — прошёл мимо, потому что так пишут все.
Второй: что изменится в понятных мне единицах? Не «ускорили выгрузку», а «выгрузка остатков шла сорок минут и падала по ночам, теперь четыре минуты и не падает, кладовщик перестал приходить к семи утра». Единицы измерения у бизнеса простые: рубли, часы, количество ошибок, количество людей.
Третий: почему столько денег? Здесь спасает не оправдание, а разбор состава работы. Когда клиент видит, что в смете есть аналитика, что вы закладываете время на приёмку и правки, что интеграция с чужим API — это отдельный риск с отдельной оценкой, цена перестаёт выглядеть взятой с потолка.
Четвёртый: почему вы, а не тот, кто дешевле? Отвечать на это лобовым «мы профессионалы» бесполезно. Отвечает показанный процесс: как вы собираете требования, что делаете, когда заказчик посреди проекта меняет решение, как передаёте проект и что входит в поддержку. Лучше всего это разворачивается в формате кейс вместо ссылки на репозиторий — там задача, ограничения и результат стоят рядом.
Заметьте, ни один из четырёх вопросов не требует упрощать вас до уровня «делаем сайты красиво». Деталей в таком тексте не меньше — они просто из другого мира.
Рабочий приём: «было — сделали — стало»
Приём звучит примитивно, но именно он вытаскивает большинство технарских текстов.
Берёте любой эпизод из работы. Не проект целиком, а именно эпизод: один спорный момент, одну задачу, одно решение. Дальше три абзаца.
Было. Описываете ситуацию глазами заказчика, с деталями его жизни. «У клиента интернет-магазин запчастей, остатки на трёх складах, синхронизация раз в сутки. Покупатель оформлял заказ на деталь, которой уже нет, менеджер звонил извиняться. Таких звонков было около тридцати в неделю».
Сделали. Здесь можно быть техническим, но коротко — три-четыре предложения. Что именно сделали, почему выбрали этот путь и от чего отказались. Отказ, кстати, читается лучше всего: он показывает, что вы думали, а не брали привычный инструмент.
Стало. Цифры. Даже приблизительные, даже со словом «примерно». «Синхронизация раз в пять минут, звонков с извинениями — два-три в неделю, менеджер вернул себе примерно шесть часов еженедельно».
Из одного такого эпизода получается статья, короткий пост и сценарий видео на минуту. А эпизодов у любой студии за квартал набирается десятки — их не надо придумывать, надо только не забывать записывать по горячим следам. Через месяц вы уже не вспомните, сколько там было звонков в неделю.
Как удержать это, когда вы в спринте
Тут всё и рассыпается. Первая статья пишется на подъёме, вторая через две недели, дальше приходит крупный проект — и блог замирает на полгода. У фрилансера то же самое, только цикл короче.
Между тем решение о разработке зреет медленно. Компания думает про новую систему учёта месяцами: сначала терпит, потом обсуждает внутри, потом собирает предложения. За это время человек заходит к вам не один раз — и если каждый раз видит одну и ту же прошлогоднюю запись, вывод делает соответствующий. Регулярность здесь весит больше, чем блеск отдельной публикации, и это же главный аргумент за то, чтобы выходить на клиентов помимо бирж.
Хорошая новость: сырьё у вас уже есть, оно образуется само в ходе работы. Плохая — превращать его в тексты, посты и сценарии между задачами реально некогда, и это честная проблема, а не лень.
Как понять, что вы пишете не для клиента
Проверьте себя по трём признакам. Первое: в переписке заказчики регулярно просят «объяснить попроще» — значит, ваши материалы этой работы за вас не сделали. Второе: разговор на втором-третьем сообщении съезжает к цене, потому что других различий человек не увидел. Третье: последняя публикация в блоге или канале датирована месяцем, который вы сами уже не помните.
Если хотя бы два пункта про вас, дело не в конкурентах и не в рынке. Дело в том, что самое сильное ваше преимущество — то, как вы думаете и работаете, — остаётся невидимым для человека, который подписывает договор.
Часто задаваемые вопросы
Разве технические подробности не показывают экспертизу?
Показывают, но другому разработчику. Заказчику экспертизу доказывает другое: какие вопросы вы задаёте до оценки и что делаете, когда всё пошло не по плану.
Как писать просто и не выглядеть поверхностным?
Простота — это другой выбор деталей, а не их отсутствие. Опишите ситуацию, в которой решение понадобилось, а не само решение.
Мои клиенты — техдиры, они понимают код. Упрощать всё равно?
Смету режет не техдир. Давайте два слоя: короткий технический абзац и рядом — что это даёт бизнесу.
Что делать, если проект под NDA?
Работает не имя клиента, а задача, ограничения и цифры. «Сеть из двенадцати автосервисов» доказывает не меньше логотипа.
Где взять время на регулярность?
Описание проектов остаётся на вас. Сбор плана, подготовку материалов и публикацию по расписанию можно снять с себя, оставив за собой проверку и согласование.
Заключение
Заказчик разработки покупает то, чего ещё нет, и оценивает это по единственной доступной ему шкале: деньги, сроки, риск. Технически честный текст в эту шкалу не попадает — он написан для коллеги, а не для того, кто платит. Отсюда и разговоры, которые вечно съезжают к цене.
Лечится это не упрощением, а сменой деталей: симптом вместо термина, цифры вместо эпитетов, показанный процесс вместо обещаний. Схема «было — сделали — стало» вытаскивает почти любой эпизод из работы, а эпизодов за квартал набирается больше, чем вы успеете опубликовать.
Дальше остаётся ритм, и здесь стоит честно признать: между спринтами руками это не ведётся. В кабинете вы описываете проект в анкете, платформа подбирает ключевые фразы, собирает контент-план и готовит материалы для сайта и каналов, а вы их проверяете. Наш контроль качества смотрит длину, лимиты площадок и вхождение ключевых фраз, публикация уходит по расписанию — и только после вашего согласования. Подробнее о платформе: dobro-code.ru.
Читайте также
Ещё из блога
Как выпускать контент регулярно, когда вы один: минимальный рабочий ритм
Почему регулярность рушится не из-за лени, что такое минимальный ритм и как его посчитать, работа партиями, запас материалов на две недели и что делать, когда всё сорвалось.
ОбщееСогласование материалов с клиентом: как сократить круги правок
Почему правки идут по третьему кругу, как договориться о критериях до начала работы, чем отличается правка от переделки, регламент согласования и что делать с бесконечными доработками.
ОбщееАнкета проекта: почему без неё контент получается «ни о чём»
Что такое анкета проекта, какие семь блоков в ней должны быть, чем она отличается от описания компании, как её заполнить за час и почему без неё материалы получаются одинаковыми у всех.