Loading...

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

Ссылка на материал на VC.ru

Оптимизируйся или умри — примерно так выглядела ситуация у нас в агентстве Ant-Team.ru в 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 — не помогает

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

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

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

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

В 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. Ставка роли. 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

Рисунок 19. Очередь задач.

 

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

 

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

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

 

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

Рисунок 22. Настройка приоритетной роли

 

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

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

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

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

 

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

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

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

 

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

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

Рисунок 23. Отслеживания загрузки на активных исполнителей.

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

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

 

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

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

 

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

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

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

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

 

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

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

 

Рисунок 26. Простановка разрешения проверять

 

Ситуация:

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

 

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

Рисунок 27. Саппорт

 

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

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

 

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

Рисунок 29. Интерфейс бухгалтера

 

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

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

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

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

Результаты

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

 

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

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

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

 

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

 

 

Давайте обсудим ваши задачи

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

Написать в Телеграм

* Эксперт по продукту проконсультирует и подберёт индивидуальное решение

Top