Автоматизация VS Клиентоориентированность в рекламном агентстве. Не нужно выбирать

Как наладить автоматизацию, на 30% сократить количество рутинных задач, увеличить eNPS и не упасть в NPS? Эта статья о том, что иногда не нужно выбирать между автоматизацией и клиентским сервисом

Всем привет, меня зовут Марченков Георгий. Я (CDO) директор по цифровым технологиям рекламного агентства DeltaClick | Deltaplan Group. Сегодня хочу поделиться с вами историей про цифровую трансформацию операционных процессов нашего агентства.

Три года назад на базе Bitrix24 мы организовали бизнес-процессы, которые систематизировали работу по маршрутизации задач.

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

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

Какие это были причины:

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

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

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

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

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

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

Так как предыдущие три года занимался разработкой продуктов по оффлайну прямо с нуля, то я порядочно подустал от тяжелой разработки и, изучая лучшие практики рынка, мне всегда хотелось сделать продукт в лучших традициях No-Code/Low-Code решений. Поэтому начал погружаться в облачные решения, которые мне помогут. При этом не надо будет держать штат в 15 разработчиков.

Так наш выбор пал на экосистему google workspace, на тот момент они выкатили вроде бы 4 поколение апи, которое прямо скажем развязало руки и сулило блага в интеграциях. Сами продукты гугла давно позиционировались как стандарт рынка и совместную работу они практиковали задолго до ковида и локдаунов.

Было понятно, что гугл не решит все задачи, придется формировать ядро, которое будет выступать в роли интеграционной шины, так как помимо инструментов гугла, надо было связать систему с битриксом, 1с, внутренним DWH компании, Power BI и еще кучей всего в перспективе. Тут мы выбрали Symphony. Не буду рассказывать почему, тут на вкус и цвет все фломастеры разные.

Вот так выглядел плановый стек и основные задействованные элементы. Система получила рабочее название Кликач

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

Начинается все с Брифинга клиента, который формирует ТЗ на задачу по конкретному инструменту. В группе компаний Deltaplan порядка 100 рекламных продуктов. В digital-агентстве Deltaclick около 30 - это значит 30 форм.

Раньше были формы в Excel, трудно было донести до человека нужные подсказки и рекомендации. Это формировало множество икселей, часть которых были плохо заполнены, люди были не рады - это снижало enps. Нам нужен был конструктор брифов.

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

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

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

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

Вот тут пригодился великолепный Google sheets. Мы научились создавать документы и наполнять их контентом, а главное - следить за изменениями в них и использовать это для триггеров, но по порядку.

На первой странице разложили все ТЗ которые заполнил менеджер в Кликаче. Команды в задаче в Bitrix24 получали нужные ссылки в sheets, там изучали задачу, задавали уточняющие вопросы, получали ответы (для комментариев и навигации по ним же google sheets просто великолепен).

Дальше специалист переходит на страницу по своему инструменту, где получал табличку, справочники и нужную ему структуру. Там он заполняет строчки по своему инструменту в большом медиаплане. Когда заканчивал работу, нужно просто поставить галочку на своих строчках для отправки их менеджеру.

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

Ниже общий свод для менеджера

Получается у каждого участника своя страничка в google sheets и свой функционал.

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

Помимо Google sheets в проекте фигурируют текстовые документы (договора, приложения). Для таких нужд по шаблону генерировали нужный документ в гугл документах, ставили задачи, привлекали в нее людей (например, юристов), которые совместно этот документ разрабатывали и акцептовали.

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

В отличии от папок и документов он позволил нам ехать дальше по процессу, так как медиапланом дело тут не кончалось, это только 2 этап из 5. Надо тащить всю эту телегу дальше.

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

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

После того, как документ показали клиенту и получили обратную связь , можно поставить статус “Отправить на доработку”. Система в задаче специалиста прислала уведомление “нужна доработка”. После доработки, по привычной схеме, медиаплан уходит менеджеру. На последнем этапе система передает данные в 1С, но это тема отдельной публикации.

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

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

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

Если такой формат вам понравился - расскажу как мы создаем МРМ-систему для рынка и уже получили с ним резидентство Сколково.