...

Отправить заявку на SEO-продвижение сайта от Ant-Team.ru

Заказать

Как мы автоматизировали 80% редакторских задач, сократили операционные издержки на 20% и в процессе создали новый продукт

Оптимизируйся или умри — примерно так выглядела ситуация у нас в агентстве в 2023 году. Мы выбрали первое. В результате в 3 раза ускорили  сдачу текстов, автоматизировали 80% рабочего времени штатного редактора, сократили издержки на административку и бюрократию на 20% и теперь можем без проблем писать сотни текстов в месяц.

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

Рис.1. Кейс по автоматизации работы с фрилансерами.

Бизнес либо растёт, либо падает — посередине ничего нет

Все мы сталкивались с проблемами при масштабировании: клиентов и заказов становится больше, обороты растут, сотрудники прибавляются. Старые регламенты и процессы перестают работать, потому что были основаны на меньших объёмах. Речь уже идёт не о масштабировании, а о том, как удержать текущие обороты.

Именно это случилось с нами, когда из-за роста бизнеса в штате стало больше SEO-специалистов и проектов. Отдел копирайтинга не был готов переварить новый объем работы, а это, в свою очередь, мешало дальнейшему росту  SEO-отдела. Нам нужно было решение, с помощью которого можно было бы легко масштабировать работу с текстами. И мы его нашли.

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

Завал и просроченные на месяц дедлайны

Ключевая проблема — большие сроки. В 2023 году средний срок написания текста (от даты постановки до даты закрытия задачи) составлял  44 календарных дня. Летом 2023 случился завал: мы научились нанимать и быстро развивать SEO-специалистов, что привело нас к кратному росту.

Рисунок 2. Слайд с доклада на конференции BDD 2024.

SEO-специалистов и проектов стало больше, это перегрузило отдел копирайтинга. Чтобы справиться с нагрузкой, пришлось подключать дополнительных штатных редакторов и даже ставить на стоп новые проекты (о, ужас!). Нам нужно было кардинально изменить процесс написания текстов, чтобы разгрести завал и дать возможность бизнесу развиваться.

Рисунок 3. Пример задачи с просрочкой на 4 месяца.

Наверное, все видели подобные задачи в своей CRM.

Как был устроен процесс написания текстов

SEO-специалист одновременно ведёт несколько проектов.

Рисунок 4. Блок-схема: SEO-специалист со своими проектами.

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

Рисунок 5. Блок-схема: SEO-специалист со своими проектами разных тематик и редактор с авторами разных тематик.
Рисунок 6. Пример задачи на написание текста в CRM.

Редактор передает задачу на текст авторам. Автор сдаёт текст, редактор отправляет его на проверку внештатным редакторам (для простоты можем называть их младшие редакторы). У них тоже есть специализации.

В итоге редактор подбирает сперва исполнителя, а затем проверяющего.

Рисунок 7. Блок-схема: Процесс взаимодействия 1 SEO-специалиста с редактором для заказа текстов для своих проектов, разной тематики.

В финале редактор-распределитель (будем называть так штатного редактора) отправляет текст клиенту на согласование. Отправляет текст на доработку, если появляются правки. Когда их немного, проверяет сам. После закрывает задачу в CRM.

Прекрасная схема, она позволяет поддерживать высокое качество текстов (пока текстов немного).

Но если в эту схему добавить больше SEO-специалистов, тематик или клиентов, то выглядеть это будет так:

Рисунок 8. Блок-схема: Процесс взаимодействия 6 SEO-специалистов с редактором для заказа текстов для своих проектов, разной тематики.

Очень много связей. И все они проходят через одного человека. Это узкое горлышко.

Когда у нас сформировалось две команды SEO-специалистов по 5-6 человек, количество тематик и клиентов увеличилось в полтора раза.

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

Рисунок 9. Мем.

Формулируем проблему

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

А еще авторы, редакторы внештата и сеошники все свои вопросы, ошибки и сомнения по ТЗ-шкам скидывают редактору-распределителю. На вопросы клиентов в чате тоже отвечать ему.

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

Привлекаем дополнительно редактора и пробуем SCRUM — не помогает

Теперь разберём, как пытались решать проблему.

  • Наняли дополнительного редактора-распределителя

Цель: распределить нагрузку.

Наняли дополнительного редактора, но обязанности распределить не удалось (пробовали делить по отделами и тематикам). Нагрузка была неравномерная — ведь это агентство. В результате новый редактор стал помощником.

  • Начали работать по SCRUM

Цель: планировать нагрузку на неделю вперёд, по дням.

В 2023 мы внедрили SCRUM в SEO-отделы и кайфанули: все завалы были разобраны. Поэтому идея внедрить скрам-подход пришла и в отдел копирайтинга, но она не сработала.

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

В итоге сейчас из методики у редакторов есть только еженедельное ретро — анализ времени.

Создаём инструмент для разгребания завалов

Опыт с неудачными решениями помог — стало понятней, что нам нужно:

  1. автоматизировать процесс распределения задач между авторами и младшими редакторами;
  2. передача информации должна идти напрямую, без посредников;
  3. уменьшить количество коммуникации во всём процессе работы с текстами;
  4. разобрать завалы и не допустить их в будущем;
  5. ну и скорость подготовки текстов разогнать до ранее невиданных значений, сохранив при этом качество.

Мы посмотрели на эти требования и поняли, что нам нужен не процесс, а продукт. На рынке подходящих решений не нашли. Поэтому разработали его сами. Фактически мы создали корпоративную биржу фрилансеров, где сеошник просто ставит задачу, автор берёт её в работу, младший редактор проверяет.  Ничего лишнего.

У биржи есть три вида пользователей:

  1. Заказчик — сотрудник компании, ставит задачи, может их проверять и закрывать.
  2. Исполнитель — берет в работу задачи, поставленные заказчиком.
  3. Проверяющий — проверяет задачу и закрывает её.

Разработали MVP-продукта и начали внедрять, параллельно собирая обратную связь и дорабатывая решение.

Платформа работала со следующими статусами, по которым ходила задача:

Рисунок 10. Статусы на платформе.

Заказчик (в нашем случае сеошник) ставит задачу, она попадает в очередь. Исполнитель сам берёт самую старую задачу в работу, выполняет и нажимает кнопку для перехода задачи в статус «На проверке». Проверить может заказчик или другой проверяющий, если был указан при постановке задачи. Если заказчика всё устраивает, задача переходит в статус «Готово».  Нужна доработка — присваивается соответствующий статус. Исполнитель не может брать новые задачи в работу, пока у него есть задачи «На доработке».

Внедряем, ловим ошибки и адаптируемся

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

Какие проблемы случились и как мы строили конвейер:

  • Авторы берут задачи с темами, в которых они не разбираются

У всех авторов стояла одна роль — «Копирайтер».

Они видели только название и краткое описание задачи, без подробностей. Такое ограничение мы выставили для большей конфиденциальности: хотим, чтобы пароли/явки знал только человек, который возьмёт задачу в работу.

 

Рисунок 11. Как видели задачу исполнители.

Из-за этого авторы брали задачи, в которых не разбирались. Кто-то тратил время на выполнение, потом приходил и просил снять задачу с него без оплаты, так как не справляется. Но чаще авторы сразу писали штатным сотрудникам, до которых могли дотянуться: в комментарии в задаче, редакторам в мессенджерах, в телеграм-канале для фрилансеров.

Для решения внедрили «специализации» (тематики) — это второй уровень роли. Теперь у «Копирайтера» может быть размечено несколько более узких специализаций. Мы добавили их для каждого автора, исходя из его экспертизы.

Рисунок 12. Внедрили специализации для исполнителей.
  • Исполнители берут больше задач, чем могут сделать

Наша идея: взял задачу, сделал сразу и сдал на проверку. Авторы стали набирать много задач в работу. При ручном распределении их тоже иногда перегружали: «Ну это же Галина, она справится!». А потом Галина не справлялась.

Чтобы все справлялись, мы поставили максимальный лимит на 2 задачи «В работе». Это привело нас к другой проблеме: задачи стали брать в работу только через 7+ дней, так как авторы обычно тратят около недели на подготовку текста и пишут параллельно сразу несколько. В итоге увеличили лимит до 6 задач в работе.

  • Непонятно, как оценить стоимость задачи 

Ранее редактор вёл подсчёт в специальной таблице, где учитывалось количество символов, тематика текста, опыт автора. Вносил в таблицу ссылку на ТЗ, ФИО автора, итоговое количество написанных символов, а таблица автоматически считала стоимость.

Мы передали данные для подсчёта SEO-специалистам, но никому эта арифметика без помощи редактора не давалась. Да и это не их работа.

Поэтому внедрили алгоритм расчета прямо на платформу. Разметили стоимость за 1000 символов по каждой специализации и присвоили авторам личные коэффициенты.

Для расчета стоимости текста внедрили специальное поле — алгоритм считает знаки, применяет ставку по специализации и коэффициент копирайтера.

 

Рисунок 13. Расчет стоимости.

Все эти данные настраиваются:

1. Стоимость оплаты за 1000 символов или стоимость часа работы

Рисунок 14. Ставка роли.

2. Коэффициент наценки. Это наценка, с которой данные по расходам будут переданы в CRM. К примеру, мы платим автору 200 рублей за 1000 символов. Но продаём это конечному клиенту за 310 рублей (200*1,55).

Рисунок 15. Коэффициент наценки для продажи конечному клиенту.

3. В профиле у исполнителя также настраивается его внутренний коэффициент. Он зависит от его скилов и опыта:

Рисунок 16. Коэффициент исполнителя.

Эти данные позволяют автоматически рассчитывать стоимость задачи.

  • Всё ещё необходимо распределять задачи между редакторами для проверки

При постановке задачи на платформе заказчик мог указать, кто будет проверять задачу. Все указывали штатного редактора-распределителя, а тот уже распределял задачи между внештатными редакторами в CRM для трека времени. Это было неудобно. В результате мы сделали дополнительные канбан-статусы и дали возможность внештатным редакторам брать текст автора на редактуру самостоятельно. У них такой же принцип ранжирования — видят только одну самую старую задачу.

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

Штатный редактор всё-таки должен видеть все задачи, чтобы контролировать процесс. Поэтому мы разделили проверяющих на старших и обычных.

Старший проверяющий, он же штатный редактор, видит все задачи, которые размечены в его профиле. А обычный проверяющий — внештатный редактор — видит только свои.

Всё ещё необходимо распределять задачи между редакторами для проверки

Теперь внештатным редакторам приходилось пользоваться двумя системами: в одной выполнять задачи, в другой (CRM) создавать эти же задачи, чтобы трекать время.

Добавили внесение расходов на проверку задачи на бирже, чтобы уйти от работы внештатных редакторов в CRM.

Рисунок 17. Поле для внесения расхода проверяющего.

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

Вот как изменился путь движения задачи по статусам. Появились два сценария. Задачу проверит сам заказчик или проверяющий.

Рисунок 18. Сценарии статусов задач в зависимости от проверяющего.

На этом моменте ключевой сотрудник (редактор-распределитель) в разгаре процесса перехода на новые методы работы уволился, но это не нанесло никакого вреда. Мы в спокойном режиме подключили нового редактора.

Завал, кстати, к этому моменту полностью разобрали.

Завал разобрали, улучшаем качество и скорость

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

  • Тот, кто очень хорошо разбирается в медицине, пишет тексты про шторы, и наоборот

Вот очередь задач и 2 автора, которые могут писать тексты и про медицину, и про юриспруденцию. Но первый лучше разбирается в медицине, а второй — в юриспруденции. При ранжировании “самая старая задача самому первому освободившемуся” будет выглядеть так:

Рисунок 19. Очередь задач.
Рисунок 20. Распределение задач по дате создания.

Разница взятия задач всего 1 час. В идеале задачи должны быть распределены таким образом:

Рисунок 21. Распределение задач по дате создания с учётом приоритета роли.

Для этого мы внедрили обязательный выбор одной основной специализации. Задачи автор видит в первую очередь по ней, а уже потом по всем другим специализациям.

Рисунок 22. Настройка приоритетной роли.
  • SEO-специалисты закрывают задачи больше 20 дней

Задачи висели в статусе “Проверено” неделями. Стали разбираться. Поняли, что уходит время на согласование с конечным клиентом — тем, на чей сайт будет размещён текст. Внедрили статус “На согласовании”.

Если в течение 7 рабочих дней задача не согласована, она автоматически переходит в статус выполнено: любая доработка будет платной. Клиентов предупредили.

Также на статус “Проверено” заложили 3 рабочих дня. Если sео-специалист решил по какой-то причине ничего не делать, задача также закрывается и любая доработка будет платной. Уведомления на почту и/или в телеграм приходят.

Некоторые задачи могли висеть в ожидании исполнителя больше 10 дней. 

Тут целый набор небольших проблем:

  • Все исполнители отказались от выполнения задачи

Задачу могли пропустить все. Добавили статус “Не найден исполнитель” для таких случаев. Заказчик увидит причины пропусков, которые указали авторы, сможет скорректировать задачу и перевыставить её. Тогда авторы вновь увидят задачу в выдаче, причём сохранится изначальная дата создания — задача будет в самом начале очереди у всех исполнителей.

Если заказчик не знает, что делать, он может обратиться за помощью к специалисту поддержки.

  • Нет активных исполнителей для нужной тематики 

Ситуация редкая. Раньше штатный редактор мог сам понять, что нет специалиста при распределении задач. Постучался в личку автору, тот сказал, что больше не хочет работать. В реалиях биржи вовремя заметить, что нет исполнителя, может быть сложно. Поэтому вывели информацию в дашборды редактора для еженедельной аналитики активности авторов.

Активностью считается комментарий в задаче, факт взятия любой задачи в работу или переноса её на проверку.

Рисунок 23. Отслеживания загрузки на активных исполнителей.
  • Исполнители, заказчики, проверяющие не отвечали на комментарии

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

Рисунок 24. Непрочитанные уведомления.

Поэтому разделили уведомления о комментариях и смене статуса задачи на разные блоки. Все комменты отображаются в чатах. Красные “Чаты” — нужно прочитать.

Рисунок 25. Непрочитанные уведомления и чаты.

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

Делаем ещё кайфовей

Это уже чисто про удобства, которые даёт инструмент для бизнеса и штатного редактора:

  • Убрали резиновые бюджеты

Бюджеты проектов хранятся в CRM, т.к. идёт оплата за часы. Ранее редактор в конце месяца садился и считал, сколько денег нужно заплатить авторам по всем проектам, а после вносил расходы в бюджеты проектов в CRM. Случалось, что в итоге бюджет уходил в минус.

Мы настроили передачу расхода сразу при закрытии задачи.

  • Стало легко искать проверяющих (редакторов)

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

Рисунок 26. Простановка разрешения проверять.
  • Было много спорных моментов между авторами и сеошниками

Ситуация:

  1. Сеошник: автор плохой, просто не нравится его работа, не хочу за это платить.
  2. Автор: задача некорректно поставлена, сеошник плохой.

Подключался штатный редактор и пытался решить подобные спорные моменты. На это уходило время. Чтобы такие задачи решались быстрее и редактору не нужно было отвлекаться, мы добавили возможность написать в арбитраж. Теперь вопросы решает поддержка. Они более независимы и следуют чётким правилам, учитывая интересы обеих сторон.

В поддержку можно обратиться и по другим вопросам.

Рисунок 27. Саппорт.
  • Делаем вывод средств для исполнителей прямо с баланса

Мы продолжали запрашивать у всех самозанятых счета и чеки — это неудобно. Поэтому доработали дополнительные интерфейсы и сделали роль “Бухгалтер”.
Теперь исполнитель из личного кабинета биржи запрашивает сумму для вывода с баланса: он видит, сколько стоил материал и сколько указать в счёте для компенсации налога (налог система считаем автоматически, а мы его компенсируем).

Рисунок 28. Вывод заработанного исполнителями.

Бухгалтер оплачивает прикреплённые счета. Чеки создаются автоматически банком после того, как фрилансер подключит банк как партнера в приложении “Мой налог”.

 

Рисунок 29. Интерфейс бухгалтера.
  • Доступы к файлам на гугл диске

У нас в Ant-Team.ru очень строго с доступами к файлам. Шарить открыто для всех нельзя, только на конкретные почты.

Автоматизировали. Достаточно добавить специальный ключ вашего диска и добавить в чёрный список файлы, к которым нельзя давать открытый доступ.

Собираем все ссылки из поставленной задачи на платформе, сопоставляем с чёрным списком, берём почту исполнителя из его профиля и открываем доступ к файлам. После перевода задачи в статус “Готово” все доступы к файлам для исполнителя закрываются.

Сейчас тестируем это доработки, полноценный релиз будет в декабре 2024.

Результаты

В результате работы с биржей за 4 месяца мы полностью автоматизировали:

  • Поиск автора для написания текста, передачу ему информации по задаче.
  • Поиск редактора для проверки текста, передачу ему информации по задаче.
  • Коммуникацию между заказчиком, исполнителем, проверяющим. Все происходит в рамках ветки комментариев в задаче, штатному редактору не нужно быть мостом.
  • Подсчёт, внесение расходов в бюджеты проектов в CRM с учётом всех клиентских коэффициентов, запрос счетов и чеков от самозанятых.

Частично автоматизировано:

  • Согласование текстов с конечным клиентом теперь идет напрямую через SEO-специалиста
  • Повысили качество редактуры, а у распределителя высвободилось время для контроля авторов и редакторов.
  • Для решения спорных вопросов есть специалист поддержки, модератор.
  • Подсчёт сумм к оплате авторам. Нужен только бухгалтер, который оплатит счета.

Средний срок готовности текста сократился с 44 до 15 дней. Если исключить время на согласование и закрытие задачи, текст готов в течение семи дней (постановка задачи, ожидание автора, написание, редактура).

На 10% уменьшили расходы редактора на бюрократию за счёт автоматизации подсчёта оплаты, внесения расходов в проекты. На 70% — расходы редактора на распределение задач и передачу информации.

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

Жизнь изменилась на «до» и «после».

Решение универсально и подходит не только для внештатных копирайтеров, но и для работы с любыми сотрудниками, которые выполняют однотипную проектную работу: контент-менеджеры, разработчики, дизайнеры, seo-специалисты, операторы пунктов выдачи заказов, сотрудники кофеен, сотрудники пищевых точек на стадионах и др. Список можно продолжать бесконечно.

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

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

Рисунок 30. Шаг ⅕ для создания заказа на бирже flow-task.com.

Сколько это всё стоило

Изначально мы отнесли ТЗ на разработку MVP платформы нашим партнёрам-разработчикам. Они посчитали бюджет в 50-100к рублей (нам продают не по рыночной цене). Но вот примерные данные по тратам за год существования платформы:

  • Ответственный за биржу — 300 000 (анализ, постановка задач разработке/аналитике/специалисту поддержки, контроль выполнения).
  • Специалист поддержки — 60 000 (решает вопросы пользователей, арбитраж, контролирует сроки задач — тегает ответственных).
  • Разработка — 600 000 (разработка и последующая доработка).
  • Аналитик — 192 000 (настройка дашбордов для анализа и контроля.)

Итого: 1 152 000 рублей за год.

Мы продолжаем вкладываться в поддержание и улучшение платформы.

В следующей статье расскажем, как устроена наша биржа фрилансеров для бизнеса.

 

Автор: Кирилл Агафонов, продакт-менеджер биржи для работы с фрилансерами Flow-Task.com, руководитель SEO-отдела в Ant-Team.ru. 

Подписывайтесь на наш телеграм-канал, чтобы первыми узнавать о выходе новых материалов. И смотрите наши бесплатные обучающие видео на YouTube, VK и Rutube.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *