Как PR-агентство автоматизировало создание контента с помощью Kaiten API

Систему собрала Екатерина Берестовая, основатель Loft. По образованию она журналист-редактор и раньше не занималась разработкой: ботов Екатерина написала с помощью Claude Code, описывая логику работы как обычный регламент. В кейсе разбираемся, как устроен этот процесс и какие задачи удалось передать автоматизации.

О компании

Loft — контент-агентство, которое с 2008 года занимается контент-маркетингом для компаний. Ежемесячно команда выпускает около 100–300 материалов.

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

Даже относительно простой материал проходит около 15 этапов, а в сложных проектах их число доходит до 19. Один текст может последовательно оказаться у главного редактора, автора, интервьюера, корректора, верстальщика, клиентского менеджера, пиарщика заказчика и спикера.

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

Kaiten выбрали на замену Trello — во многом из-за API

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

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

Kaiten позволял работать через API с карточками, комментариями, чек-листами, пользовательскими полями, файлами и другими элементами рабочего процесса. Это стало одним из решающих аргументов в его пользу.

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

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

На масштабе процесс снова начал распадаться между системами

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

Из-за этого возникли 4 основные проблемы:

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

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

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

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

Можно было обязать сотрудников выполнять все действия только в интерфейсе таск-трекера. Но в Loft решили иначе: если команда привыкла работать в мессенджере, часть возможностей трекера можно перенести туда.

Не вести людей в трекер, а привести трекер к людям

Kaiten остался основой процесса и единым источником данных. В нем по-прежнему хранятся карточки, статусы, дедлайны и ссылки на актуальные файлы.

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

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

Что делают боты

В Loft работает 4 бота, каждый отвечает за свой участок процесса:

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

Добби — создает и обновляет карточки. Для нового клиентского проекта бот заводит папку на диске и карточку в Kaiten, добавляет ссылки и заполняет нужные данные. Когда редактор кладет готовый текст в папку, Добби сам находит файл, считает количество знаков, записывает объем в карточку и отправляет материал дальше по процессу. То же самое происходит с иллюстрациями. За 5–7 дней существования одной карточки бот может выполнить около 50 действий.

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

Писец — дополнительный редактор и корректор. Он проверяет тексты на сомнительные утверждения, логические разрывы и потенциально рискованные формулировки — например, категоричные обещания или медицинские и финансовые заявления без оговорок. Отдельно ищет пиар- и ИБ-риски и проверяет язык по нескольким десяткам критериев. Результат редактор получает в виде файла с правками и комментариями.

Технически все боты написаны на Python, данные хранятся в Postgres и Redis, а сами сервисы развернуты на Railway. Еще 1,5 года назад Екатерина почти не работала с этими инструментами, но постепенно разобралась в них по ходу развития системы.

Здесь важно отметить, что Екатерина — не разработчик, а журналист-редактор. Ботов для Loft она собрала сама с помощью Claude Code: описывала логику обычным языком, почти как рабочий регламент для сотрудника — что должно произойти после конкретного действия, что нужно проверить и куда передвинуть карточку. Модель писала код, а дальше решение тестировали на реальных задачах и дорабатывали по найденным ошибкам.

Что пришлось учесть при работе с API

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

• вебхуки используют для скорости, а не как единственный источник данных. Боты регулярно проверяют карточки сами, поэтому не зависят от одного события;
• важные данные из пользовательских полей дублируют в описании карточки — так их проще восстановить и проверить;
• создание дочерней карточки разбито на 2 шага с небольшой паузой между ними;
• текущий этап работы определяют по состоянию карточки, а не пытаются восстановить его из истории перемещений;
• чек-листы запрашивают вместе с конкретной карточкой, поскольку в общих списках они не разворачиваются.

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

Kaiten остался центром процесса, даже если сотрудники редко открывают его

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

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

Менеджеры по-прежнему регулярно заходят в Kaiten для планирования, когда важно увидеть общую картину по клиентам и проектам. Исполнители при этом получают задачи и уведомления в мессенджере, а передачу файлов, смену статусов и переход между этапами в Kaiten за них выполняют боты.

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

Успешные компании уже используют Кайтен Попробуйте расширенный функционал на своем проекте бесплатно

Попробовать

Что в итоге

За несколько лет Loft выстроил вокруг Kaiten систему, в которой:

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

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