Я много лет проработал по специальности в компании, занимающейся автоматизацией. Опыт был безумно интересный: ты отвечаешь за определенную группу товаров и должен обеспечить классные продажи. Для этого было несколько инструментов: поездки по клиентам, настройка приборов на объектах, разработка документации по ГОСТ, внедрение новых приборов, семинары и много чего еще. Но появилась идея продвигать свою продукцию еще и с помощью статей.
Да, я подумал точно так же. «На дворе 21 век, давайте развиваться», — предложил я руководителю, получил одобрение и сел писать статьи по своим направлениям. Для контекста, вот какие темы статей писал (отвечал за направление датчиков):
Темы очень узкие, ориентированные на специфичную ЦА: инженеров КИП, снабженцов, производителей оборудования и так далее. Но в то время я ничего про инфостиль и контент-маркетинг не знал, поэтому качество статей хромало на оба глаза.
Тем не менее статьи временами приводили к сделкам. В этом не было никакой мистики: темы я не выдумавал, а брал самое интересное и полезное из разговоров с клиентами. Руководству все понравилось, поэтому решили поставить публикацию статей на поток, подключив и других инженеров.
Например, вот эта статья про расходомеры привела к сделке на 1,5 млн рублей
Проблема в том, что буквальную каждую статью согласовывал руководитель. Дел у него много, поэтому публикация обычно занимала не одну неделю. Да еще и система премирования была непонятной, из-за чего инженеры воспринимали статьи, как ненужную дополнительную нагрузку. Я взялся исправить это дело.
Вот что я предложил сделать:
👉 Ввести прозрачное премирование, в зависимости от категории статьи: FAQ, обзор новинок, How-to гайд или полноценное научное исследование. Чем более сложная категория, тем выше премия. Так каждый инженер мог планировать ежемесячный доход и загруженность.
👉 Создать пул тем, которые сможет дополнять каждый из инженеров. Условно пообщался с клиентом, выявил какую-то острую проблему и тут же вписал ее в общий excel файл, добавив короткое описание: что за проблема и как она решается.
👉 Разработать систему бронирования. Любой инженер мог застолбить ту тему, которая ему нравилась. Даже если не он ее предложил и вообще это не его направление. С одной стороны, это побуждало инженеров активно брать в работу свои темы, ведь они будут писать статьи по ним быстрее и качественнее других. С другой стороны, если ленишься или тормозишь, кто-то другой возьмет твою тему, прокачает свои знания по ней и получит премию. Особенно круто это работало с молодыми специалистами, которые еще не определились с направлением работы и пробовали все, что можно.
👉 Сократить бюрократию. Нужно было поставить публикацию на потоки выпускать не меньше двух статей в месяц. Поэтому я вызвался выполнять функции редактора: проверять статьи, передавать на верстку, ставить дедлайны и работать с авторами. Руководство получало ссылку на уже сверстанную, но не опубликованную статью, по которой оставалось только дать финальную отмашку.
👉 Описать процесс публикации. Чтобы все работало, нужно было согласовать работу сразу нескольких людей, помимо автора:
Для этого вместе с главным инженером сели и за пару вечеров формализовали весь процесс в виде диаграмм и коротких инструкций. После чего залили в CRM систему и через руководителя «довели до сведения ответственных лиц просьбу ознакомиться с материалами» (с). Теперь все знали свои обязанности и понимали, что нужно делать. Например, верстальщик оформлял таблицы без разделителей, SEO заспамливал статью более дозированно, а дизайнер сам подходил к автору и не ждал отмашку от начальника.
В кейсе хотел показать скриншоты диаграмм редакторских процессов. Но к сожалению, они не сохранились 😭
Процесс сдвинулся с мертвой точки: авторы пишут, получают премии, статьи публикуются за считанные дни — красота, все довольны. Но во всем этом было слабое звено — я. Изначально казалось, что заниматься редакторскими процессами параллельно с основной работой будет нетрудно. Что я, не смогу уделить 5-10 минут на редактуру за чашкой кофе или забуду пнуть дизайнера с верстальщиком? Но как же жестоко я заблуждался.
На тот момент я уже погрузился в редакторский процесс, прошел курсы в «Нетологии» и осознал, что мои же прошлые статьи никуда не годились. Язык, стиль изложения, структура — все было плохо. Та же проблема была и у других. Мой нежный редакторский разум уже не мог пропускать такие статьи. Поэтому приходилось по несколько часов зависать после работы и допиливать статьи до приемлемего качества.
Нагрузка была настолько велика, что через месяц я взвыл и решил упростить процесс. Что для этого нужно сделать? Да просто научить инженеров круто писать, вот и все. Тогда я буду тратить меньше времени на редактуру, а автор не будет получать 100500 правок.
По-хорошему, для этого надо придумать редполитику и организовать внутренние семинары или тренинги по редактуре. Но на все это не было времени. Поэтому решил обойтись чем-то попроще: написать лонгрид, в которому соберу все свои знания, мысли и советы. Тем более самые распространенные ошибки авторов в статьях я уже знал.
Структурно статья состоит из двух частей:
👉 Памятка. Порядок действий по шагам: от выбора темы до публикации статьи. Любой инженер может просто распечатать эту памятку и повесить на стену.
👉 Советы. Основная часть статьи. В ней рассказываю 10 основных моментов, на которые надо обратить внимание в работе. Вот чуть подробнее:
В каждом совете привожу много примеров редактуры именно по теме автоматизации, в формате «Правильно» и «Неправильно».
Для наглядности, в совете «Удалить стоп-слова» взял введение из реальной статьи, которую написал один из авторов-инженеров пару лет назад. По пунктам сначала высушил текст — стало лучше звучать, но по смыслу все равно плохо. Затем переписал введение заново и пояснил, как оно решает изначальную задачу статьи.
Статья получилась объемной, но в ней много успокаивающих элементов: иллюстраций, фактоиодов и плашек с тезисами. Инженеру достаточно почитать ее и можно садиться за свою статью, сверяясь с памяткой. Еще мне понравилось то, что я не упоролся в попытках создать редполитику — на эту работу ушло пару выходных и столько же литров пива.
Когда я показал работу руководству и попросил утвердить, выявилась проблема. Оказывается, всех устраивало и прежнее качество статей: «У нас пишут солидным научно-техническим языком, а не вот этим детсадовским слогом». Инженеры тоже приняли работу в штыки: схема работала, зачем что-то менять и переучиваться?
Мои аргументы про дочитываемость (она была ниже среднего), ясность мысли и заботу о читателе никто не послушал. Поэтому статья-памятка легла в стол, а я продолжил редачить по вечерам после работы. Через время нженерам надоело получать кучу правок: они просто перестали писать статьи и тема сошла на нет.
На самом деле я несильно расстроился, потому что негативный опыт — тоже классная штука. Набить шишек и разобраться, как правильно выстраивать редакционные процессы в компании — это круто.
P.S. Через год я уволился, перешел в редактуру и разместил эту статью-памятку для инженеров в портфолио. К моему удивлению, она принесла мне двух новых заказчиков, с которыми я до сих пор успешно работаю.
