ДеньгиКак в Томору автоматизировали сопровождение клиентов

Эксперт Константин Седых, ИТ-директор Томору. Записала Мария Колесникова.

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

Проблема: передача проекта между отделами затягивалась

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

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

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

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

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

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

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

Стало понятно, что процесс нужно унифицировать и автоматизировать.

Шаг 1. Запустили алгоритм, чтобы не передавать данные между отделами вручную

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

Мы пробовали работать по отдельности в Трелло, гугл-таблицах, пытались выстроить воронку производства в Амоцрм. Мы дошли до того, что хранили информацию в гугл-таблицах, задачи вели в Трелло, а общались по проектам в Слаке и Телеграме одновременно.

Однажды Денис Балюра, СЕО и основатель Томору, увидел видео Константина Кузнецова, который рассказывал, как они управляют проектами в компании «Рокет сейлз». Денису понравился подход, и мы решили попробовать. Прошли курс по управлению проектами в Асане и начали работать на этой платформе.

На каждого клиента Томору мы заводим проект в Асане:

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

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

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

Микросервис распределяет информацию по соответствующим задачам:

Скриншот интерфейса Асаны, на котором видны этапы создания робота для клиента Томору
Скриншот интерфейса Асаны, на котором видны этапы создания робота для клиента Томору и задачи сотрудников
В проекте клиента расписаны задачи сотрудников. Чтобы создать одного робота, нужно закрыть больше ста задач

Раньше информацию передавали менеджеры, поэтому был риск ошибок из-за человеческого фактора. Теперь у нас настроена автоматическая передача проектов от отдела продаж в отдел производства. Оставалась последняя задача — придумать, как валидировать данные.

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

Шаг 2. Настроили аналитику, чтобы видеть весь путь клиента, и работаем еще быстрее

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

Но аналитика от Асаны нам не понравилась. Поэтому мы решили оцифровать и ее. Для этого подготовили проекты в Асане и стали выгружать данные:

На скриншоте написан список данных, которые выгружаются из Асаны в гугл-таблицу и формируются в базу данных аналитиков
Данные о проектах и роботах Томору выгружают в базу данных из Асаны

В Томору много разных таблиц, где хранится информация о клиентах и роботах, но если обобщить, то все данные собраны в трех основных базах данных:

отдела продаж из црм-системы — информация, которую собирают до создания робота;

аналитиков из Асаны — это то, что собирается во время внедрения робота, например выбор голоса и озвучка;

биллинга Томору — это финансовые показатели нашей платформы, где «живут» роботы. Здесь мы отслеживаем количество минут, диалогов и стоимость.

Каждая база данных отвечает за отдельный этап в работе с клиентом. Чтобы видеть весь путь клиента, мы объединили три базы и создали customer journey map, или CJM (англ. — «карта путешествия клиента»), — это инструмент визуализации. У нас используется гугл-таблица. CJM показывает путь клиента от момента, когда он заинтересовался роботом, и заканчивается на данных о том, сколько раз и когда он использует робота после внедрения.

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

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

с когортой клиентов, которые оставили заявки полгода назад, — остались ли клиенты с нами, каких роботов они купили;

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

с рекламной кампанией — как прошел запуск, сколько мы получили заявок;

на этапе внедрения робота — какой аналитик собирал робота и сколько часов потратил.

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

Письмо с лучшими статьями. Без спама

У нас есть политика конфиденциальности и условия обработки персональных данных, и при подписке вы соглашаетесь с ними автоматически

Зин в Телеграме