Теперь мы CRM-group!

Имя новое, подход прежний: профессионализм и забота о вас

Перейти

Что будет, если сделать писателя менеджером

Этой весной команда контента Email Soldiers запустила свой «Курс для неписателей, которым нужно писать». Мы готовили его 10 месяцев, а постарели за это время на все 10 лет, потому что столкнулись с множеством новых задач. Для меня самой сложной оказалась роль менеджера — нужно было ставить задачи коллегам, писателям и дизайнерам, и согласовывать готовую работу.

Оказалось, вносить правки ещё сложнее, чем принимать их. Я постоянно терзалась вопросами: как объяснить исполнителю задачу, чтобы он правильно понял её с первого раза? Мои правки — это объективная претензия или вкусовщина? А не делаю ли я хуже?

Чтобы работать было проще, вместе с другими писателями и дизайнерами Email Soldiers мы придумали 5 правил, как вносить правки в тексты и дизайн. Делимся инсайтами и надеемся, они будут для вас полезны.

Правило 1. Никаких правок, только замечания

Правки — это бескомпромиссные требования, которые нужно моментально внести без «разговорчиков в строю». А замечания можно обсуждать и согласовывать. Как правило, писатель погружён в тему статьи глубже, чем менеджер, а дизайнер лучше разбирается в способах визуализации. Поэтому не стоит игнорировать точку зрения исполнителя. Истина рождается в споре, а лучшие идеи — в обсуждениях.

Читайте также

Как погрузить автора в проект, чтобы его текст был полезен бренду

Когда мы всей командой разбирались в проблеме и находили общее решение, оно оказывалось куда лучше, чем первоначальная идея.

Как штурмили и что наштурмили

Когда мы готовили урок о том, как правильно выбрать структуру будущего текста, мы долго обсуждали способы сделать этот урок нагляднее. Хотелось, чтобы ученик не просто узнал теорию, но и мог использовать наши шаблоны, когда будет писать свои тексты. Урок обсуждали и согласовывали всей командой:

Писатель: Подготовил теорию про 10 видов структур.

Редактор: Предложил добавить к ней схемы — шаблоны будущих текстов.

Писатель: Заметил, что это не решит проблему — чтобы ученик смог воспользоваться схемой, нужно привести примеры статей, которые по ней написаны.

Редактор: Предложил прикрепить ссылки на примеры уже опубликованных статей, составленных по описанной нами структуре.

Писатель: Сделал подборку статей из блогов и СМИ.

Редактор: Всё ещё не хватает наглядности.

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

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

Автор принял правки
Так выглядел бы текст, если бы автор просто «принял правки» редактора.
Текст в виде карточки после правок
Таким стал текст в виде карточки после обсуждения в команде.

Когда мы обсудили задачу с руководителем проекта и дизайнером, удалось решить сразу несколько задач.

  1. Урок стал более наглядным. Используя шаблоны и сравнивая наши тексты о вине, ученику проще понять, как можно работать с той или иной структурой по своей теме.
  2. Урок перестал выглядеть монотонным полотном текста. Появились визуальные якоря в виде карточек с иллюстрациями.
  3. Шаблоны всегда под рукой. Чтобы выбрать структуру текста, ученику не нужно заново перечитывать урок: достаточно пролистать карточки. Мы присылаем их в учебный чат отдельным списком.

Правило 2. Чётко формулировать, что не нравится в готовой работе

При подготовке курса каждый писатель отвечал за свой тематический блок и ставил задачи другим писателям и дизайнерам. Иногда, принимая готовую работу, я не могла объяснить, что именно не так. Вроде всё правильно, но работа в целом не нравится. Так и подмывало сказать «придумай ещё несколько вариантов заголовка» или «нарисуй этот плакат по-другому».

Читайте также

Внутряк: правила общения в рабочих чатах Email Soldiers

Как человек, который обычно находится по ту сторону замечаний, я знаю, насколько бессмысленны и беспощадны попытки попасть пальцем в небо. Можно придумать 20 вариантов заголовка и нарисовать 10 вариантов макета. Если повезёт — угадаешь, что нужно заказчику. Но такой подход неэффективен, потому что писатель и дизайнер не понимают задачу, а просто перебирают варианты. В результате тратятся время, нервы и силы обеих сторон.

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

Узнайте, как мы будем делать

Контент-маркетинг

Правило 3. Иногда задачу можно решить, меняя не текст, а дизайн (и наоборот)

Бывает, что непонятно, кого мучить: автора или дизайнера? Что будет убедительнее: яркая картинка, гифка или подробный текст?

Наше внутреннее правило: формулируйте факты словами, а описания и эмоции доверьте картинкам.

Некоторые товары и услуги — одежда, обувь, детские игрушки, мебель, развлечения — лучше продаются «картинками», чем текстом. Можно подробно описать революционный дизайн кроссовок или горный курорт, но фотография или гифка всё равно сделают это описание нагляднее. Оптимальное решение — показать красивые разноплановые фотографии и тезисно описать предложение.

Сравните:

После правок текст описан тезисно

Иллюстрации хороши, когда нужно показать технологические преимущества продукта. Вы можете подобрать 10 метафор, чтобы рассказать, насколько гибкая подошва у ваших ботинок, а можете просто свернуть их в рулет и сфотографировать.

Второй вариант выглядит более убедительным:

Правки в дизайне в некоторых случаях нагляднее

Но картинки не всегда решают. Если у вас сложный продукт, о котором нужно много и подробно рассказывать, стоит уделить больше внимания тексту, а не дизайну. Яркий макет не продаст вилочный погрузчик, IP-телефонию, курсы по машинному обучению и юридические консультации. Грамотный текст с аргументами — продаст.

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

Читайте также

Что будет, если сделать дизайнера менеджером

Так мы решили проблему с дизайном на карточках для урока «Как написать логически стройный текст». Первоначально мы не знали, как текст будет выглядеть в дизайне, и я не ограничивала себя в количестве знаков.

В результате мой пример не уместился в макет:

Правки по поводу размера текста

Вместо того чтобы менять композицию карточки в дизайне, мы решили сократить количество текста. Это не сказалось на смысле примера, но теперь карточка смотрится более цельно и органично.

Компактный текст после правок

Правило 4. Не все правки влияют на результат

Некоторые изменения субъективны, зависят от личных ассоциаций и не влияют на результат. Например, замена слова синонимом, который не меняет смысл фразы. Или замена одной картинки с енотом на другую.

Об этом легко рассуждать, когда ты исполнитель, и гораздо сложнее, когда ты менеджер. Груз ответственности давит, хочется, чтобы каждая мелочь была идеальной. Признаёмся, нас тоже иногда заносило во вкусовщину.

Чтобы вносить замечания по делу, задайте себе вопрос: «Если я внесу эти изменения, будет ли разница существенной для читателя/зрителя/покупателя?» Если нет, можно смело отметать свою хотелку. Так вы не потратите лишнее время на обсуждения и редактирование.

Читайте также

7 приложений, которые облегчат работу менеджера (и не только)

Правило 5. Не забывать про референсы

Это правило не о замечаниях, а о том, как их избежать. Проще не заразиться, чем лечить; проще оговорить все детали заранее, чем исправлять в готовой работе.

Если у вас есть чёткое видение, как должен выглядеть текст или макет — нужно рассказать исполнителю об этом при постановке задачи. Ещё лучше — прислать образцы, на которые он может опираться.

Не правки, а примеры 1

Не правки, а примеры 2

Наш подход к правкам: памятка Email Soldiers

К середине работы над курсом у нас появилась памятка, как правильно вносить правки. Делимся с читателями и надеемся, что она будет полезна вам в работе.

  1. Оставляйте не правки, а комментарии. Если обсуждать замечания с исполнителем и находить решение вместе — результат работы будет лучше.
  2. Чётко формулируйте, что вам не нравится в работе, а не просите придумать ещё несколько вариантов. Так исполнитель быстрее сделает как нужно.
  3. Иногда задачу можно решить, меняя не текст, а дизайн, и наоборот. Придерживайтесь правила: формулировать факты словами, а эмоции передавать с помощью картинок.
  4. Старайтесь избегать изменений, которые основаны на ваших вкусах и предпочтениях, но не повлияют на результат.
  5. Проще заранее прислать референсы, чем вносить правки.
    • Если у вас есть чёткое представление, как должен выглядеть текст или макет — пришлите референсы.
    • Если вам нравятся отдельные элементы в других работах и вы хотите так же — пришлите референсы.
    • Если вам категорически не нравятся какие-то элементы и вы ни в коем случае не хотите видеть их в готовой работе — пришлите референсы и расскажите, чего точно не должно быть.

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

Узнавайте об обновлениях блога Email Soldiers первым

Спасибо!

Вы подписаны. Свежие материалы блога будем присылать на вашу почту.

Похожие статьи

Продажи в переписке 2026: воронка, фразы и метрики для команды

Продажи в переписке становятся управляемым каналом, когда компания сегментирует диалоги по истории покупок, настраивает шаблоны ответов под сегмент клиента и мерит чат теми же метриками, что email и ...

Что делать, если клиент не согласовывает проект

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

агентство или инхаус
Три причины (не) нанимать диджитал-агентство

Разбираем, почему стоит не нанимать агентство, а предпочесть инхаус-команду. Или наоборот?

▶Сведения для государственной аккредитации в области ИТ

Реквизиты и контакты

ООО «Емейл Солджерс»

ИНН 6234170866 · ОГРН 1176234015660

Основной ОКВЭД: 62.09

390000, г. Рязань, ул. Вознесенская, д. 66

Тел.: +7 495 003-17-94 · manager@emailsoldiers.ru

Коды ОКВЭД

62.01 (разработка ПО), 62.02, 62.09, 63.11, 63.12, 63.91, 63.99, 70.22, 73.20, 82.99, 95.11, 95.12

Виды деятельности в области ИТ
(Приказ Минцифры от 11.05.2023 № 449)

1.01 — проектирование, обследование, разработка и адаптация программ для ЭВМ, баз данных и пользовательских интерфейсов

1.04 — деятельность и услуги в отношении информационных систем (CRM, аналитика, BI)

1.05 — деятельность и услуги в отношении сайтов и страниц сайтов

26.01 — обработка, систематизация и верификация данных

Реализуемые продукты, услуги и работы

Email- и CRM-маркетинг под ключ: разработка триггерных и регулярных рассылок и коммуникационных сценариев, проектирование и автоматизация коммуникаций (email, SMS, push, мессенджеры), сегментация и аналитика клиентской базы, интеграция и настройка платформ рассылок и CRM, дизайн и адаптивная вёрстка писем, веб-аналитика и BI-отчётность, разработка интеграций между платформами рассылок, CRM и сайтом.

Стоимость работ и услуг

Определяется индивидуально в коммерческом предложении по итогам брифа. Ориентировочно: разовый проект email-/CRM-маркетинга — от 150 000 ₽; ежемесячное сопровождение — от 100 000 ₽ / мес. Точная стоимость — по запросу: manager@emailsoldiers.ru.

Технологический стек

Языки: C#, JavaScript, PHP, Python, SQL, HTML/CSS. Платформы и CDP/CRM: ASP.NET Core, Mindbox, Bitrix24, Sendsay, Unisender, Carrot quest. Базы данных: MongoDB, MySQL. Аналитика и BI: Яндекс Метрика, Power BI, Яндекс DataLens. Инфраструктура: WordPress, REST API, вебхуки.

Исключительные права на ПО

Программа для ЭВМ «RACS» (REST API CRUD веб-сервис баз данных) — правообладатель ООО «Емейл Солджерс» (свидетельство о государственной регистрации программы для ЭВМ, автор — Сафоничев А. П.). Назначение: REST API CRUD-интерфейс к облачной нереляционной базе данных — виджеты, голосования, обзоры, комментарии, счётчики статистики. Реализация: C#, ASP.NET Core, MongoDB. Права использования предоставляются по лицензионному договору. Иные работы выполняются на лицензионных платформах и собственных программных решениях (скрипты, шаблоны, интеграции).