How Lucidchart’s Support Team Drives Revenue by Helping Customers Help Themselves
Команда поддержки клиентов Lucidchart радует клиентов и способствует доходу, помогая им самим находить ресурсы в центре помощи и сообществе. Узнайте, как их команда из 10 человек поддерживает стабильное количество заявок и делает счастливыми 15 миллионов клиентов.
Lucidchart, разработанный Lucid Software, является визуальной платформой для продуктивности, которая помогает людям четко делиться идеями, информацией и процессами. С помощью обширного центра помощи, онлайн-сообщества и индивидуальной помощи команда поддержки Lucidchart обслуживает более 15 миллионов довольных пользователей, при этом сохраняя размер команды и объем заявок стабильными. Мы встретились с Кеваном Садигом, старшим директором по работе с клиентами в Lucidchart, чтобы узнать, как его команда расширила свои возможности поддержки и увеличила доход, не увеличивая при этом состав команды.
Спасибо, что присоединился к нам, Кеван! Можешь рассказать о своем опыте и немного контексте о том, как ты стал старшим директором по работе с клиентами в Lucidchart?
Конечно! У меня была долгая карьера с множеством поворотов и изменений. Я окончил Корнелл с дипломом по биологии и думал, что хочу получить степень PhD по генетике. Два года я работал в биомедицинской лаборатории в Бостоне, занимаясь генетическими исследованиями, а затем решил, что такая жизнь не для меня. Я немного запутался в том, что хочу делать, потому что всю свою жизнь учился науке, а теперь не хотел идти по исследовательскому пути.
Поэтому я вместо этого пошел в Teach for America в Филадельфии, где два года преподавал математику в старшей школе ученикам первых и вторых курсов. Я думал, что это будет хорошая возможность для меня поразмышлять и отойти на шаг назад от всего, чем я занимался. В конце моего времени там я начал искать работу и связался с другом, который работал в Google и подтолкнул меня подать заявку на работу там. Я присоединился к Google в то время, когда они сильно сосредоточились на создании своих центров помощи. Gmail был относительно новым продуктом, но его база пользователей росла очень быстро. У Google не было номера телефона, по которому люди могли бы позвонить, или электронной почты для поддержки, поэтому мы работали над стратегией создания центра помощи, где пользователи могли бы самостоятельно находить ответы и помогать друг другу.
Я занимался этим около четырех лет в разных ролях, а затем захотел попробовать свои силы в управлении людьми, поэтому я перешел в офис Google в Дублине, Ирландия, где помог инициировать их стратегию сообщества на нескольких европейских рынках. Таким образом, снова, наша мысль заключалась в том, что если мы можем предоставить платформу, чтобы пользователи могли помогать друг другу, тогда они смогут быстрее получить качественный ответ, чем они могли бы иначе.
Я должен был находиться в Дублине год, но остался на почти четыре. Мне это понравилось, это было отличное время. Мне удалось управлять людьми из разных культур, что было совершенно новым для меня опытом и очень здорово. Ближе к концу моего срока там, мне казалось, что компания была очень хорошо управляемым механизмом, в котором я играл лишь небольшую роль, и мне стало не хватать той настойчивости, что была в ранние дни Google, когда я мог получать опыт в разных задачах и это был больше подход "все руки на палубе".
Я начал рассматривать намного более мелкие компании и хотел что-то с культурой, похожей на Google, поэтому я посмотрел на сайт Google Ventures, чтобы найти компании, в которые Google инвестировал, и Lucid была одной из них. Наш CEO Карл Сан на самом деле также бывший сотрудник Google, и что мне понравилось в моем разговоре с ним, это #1, его акцент на людях и действительно построение культуры, которая дает возможность людям делать великие вещи; и #2 создание платформы, Lucidchart, которая позволяет людям общаться визуально через программное обеспечение.
Это была новая концепция для меня. Все мы понимаем, что значит общаться визуально, но традиционно мы полагались на такие вещи, как встречи или заметки или таблицы, чтобы общаться друг с другом. Lucid начал разрушать границы того, что люди могут делать в браузере, и стремился позволить нам мыслить визуально более совместным образом. Итак, я был очень вовлечен в миссию компании.
Когда я присоединился, команда поддержки состояла всего из четырех человек и была очень сосредоточена на поддержке по электронной почте. Задача, которую мне дали, заключалась в том, что наша база пользователей росла чрезвычайно быстро – она удваивалась каждый год в течение четырех или пяти лет подряд – но мы были уверены, что правильная стратегия заключалась в том, чтобы позволить нашим пользователям самостоятельно получать лучший и быстрый ответ. Вот для чего меня и пригласили.
Удивительно, похоже, вы действительно получили ту настойчивость, которую искали, переходя от команды поддержки размера Google к команде из четырех человек в Lucidchart!
Совершенно верно.
Теперь, когда вы масштабировались в Lucidchart, я слышал, что вы с тех пор удерживали свою команду поддержки на уровне 10 человек и объем заявок оставался стабильным в последние несколько лет. Какова роль маленькой команды в вашей стратегии поддержки?
Моя стратегия действительно сосредоточена на предоставлении качественного контента, который наша команда может измерить, чтобы позволить пользователям находить то, что им нужно. Я всегда использую пример банкомата, чтобы проиллюстрировать это: когда вы приходите в банк в обычное время работы, вы сталкиваетесь с этим вопросом: хочу ли я зайти в банк, постоять в очереди и задать свой вопрос? Или я хочу помочь себе с помощью банкомата? Обычно это банкомат. И если мы возьмем эту аналогию и применим ее к технологическому миру, в Lucidchart мы считаем, что хорошо написанная статья в центре помощи не только достаточна, но и предпочтительнее для 90% того, что наши пользователи пытаются сделать.
Кроме того, центр помощи на самом деле является отличным способом измерить спрос на множество различных вещей. Если вы можете показать, что десятки тысяч людей приходят к статье по определенной теме, вы можете затем использовать эту информацию в инженерах и добиваться изменений, подтвержденных реальными данными клиентов. В то время как, когда пользователи отправляют электронные письма в нашу команду поддержки, объем, как правило, гораздо меньше, и, следовательно, данные менее применимы, когда мы представляем их нашей инженерной команде. Для нас было бы отлично показать, что даже если только 15 пользователей отправили электронное письмо с просьбой о функции, тысячи пользователей посещали статьи в центре помощи, которые также относятся к этой функции.
Второй момент заключается в том, что наш контент центра помощи теперь локализован на шесть различных языков, так что есть внутренние затраты на создание качественного контента вашей командой. Таким образом, для контента длинного хвоста мы предоставляем сообщество, где пользователи могут отправлять свои собственные материалы, и другие пользователи могут извлечь из этого выгоду. Пример, который мне нравится использовать для этой концепции, заключается в том, что у нас есть Android-приложение для Lucidchart, и таких различных Android-телефонов буквально тысячи, поэтому, если у пользователя есть проблема с их конкретным телефоном и его взаимодействием с нашим программным обеспечением, шансы на то, что мы сможем на самом деле получить именно этот телефон, довольно низки. Но один из наших 15 миллионов пользователей, вероятно, имеет этот телефон и, возможно, даже столкнулся с точно такой же проблемой. Итак, иногда наша работа заключается в том, чтобы соединить наших пользователей, чтобы они могли помогать друг другу.
И это было действительно приятно видеть, потому что, когда мы смотрим на трафик нашего центра помощи и сообщества, он на самом деле превысил рост базы пользователей. И затем, относительно вашего комментария, когда мы смотрим на объем заявок на поддержку товара за последние три года, он фактически остался стабильным. Что, по моему мнению, подразумевает, что пользователи на самом деле очень довольны и тянутся к этой модели самопомощи.
Когда дело касается вашего онлайн-сообщества, есть ли у вас представление о том, какие люди вносят знания и помогают другим пользователям? Это крутая концепция подумать о том, как кто-то тратит свое личное время, обсуждая ваш продукт, чтобы помочь людям, которых он не знает.
Наше сообщество все еще в процессе – часто пользователи зададут вопросы, и мы те, кто отвечает им в сообществе, но затем другие пользователи все равно могут извлечь пользу из этого ответа. С увеличением числа мы видим, что другие пользователи приходят и предлагают ответы, что является лучшим вариантом для наших целей.
Отвечая на ваш вопрос о том, почему, в мире очень немногие продукты вызывают у пользователей такую сильную страсть, но мне повезло работать над одним из таких товаров, как Lucidchart, который определенно попадает в эту категорию. Потому что даже когда наш продукт не совсем соответствует потребностям пользователя, и им приходится проходить через порой сумасшедшие обходные пути, чтобы продолжать его использовать, они выбирают это.
Один из примеров этой страсти – это пользователь, который на самом деле настроил приложение Lucidchart для iPhone, чтобы оно стало его ежедневным календарем. Это случай использования, который наша команда никогда бы не представила для продукта, но по какой-то причине этот пользователь решил, что наше решение на самом деле лучше, чем календари Google и Apple, и несмотря на то, что мы вообще не нацелены на этот случай использования, они превзошли себя, чтобы сделать это рабочим.
Поэтому, если мы подумаем об этом менталитете, много того, что пользователи пытаются сделать, это раздвинуть границы того, что способен сделать наш продукт. И, помогая другим и делясь своими случаями использования, они подогревают свою страсть. Они любят этот продукт и хотят делиться этой страстью с другими.
Это удивительно. Как ваша команда следит за этими идеями и предложениями пользователей?
В нашем сообществе есть раздел под названием поделитесь своими диаграммами; мы хотим услышать от пользователей о новых способах использования нашего продукта. Так что это один из способов, как мы узнаем о некоторых из этих случаев использования. Более распространенный способ заключается в том, что наша команда все еще активно отвечает на электронные письма. Несмотря на то, что объем заявок остается стабильным, мы все еще получаем примерно 600 электронных писем с вопросами по продукту в неделю. Итак, пользователь выходит на связь с нами и говорит: "Я пытаюсь сделать это, но столкнулся с этой проблемой. Не могли бы вы взглянуть на мой документ и помочь мне с этой проблемой?" Часто документы, с которыми они хотят помощи, довольно простые в использовании шаблонов, но иногда мы видим действительно инновационные случаи использования нашего продукта, и в таких случаях мы часто спрашиваем их, не против ли они разместить их в сообществе, чтобы другие пользователи тоже могли извлечь из этого выгоду.
Появляются ли инновационные идеи, которые таким образом поступают, когда-нибудь в вашем продукте? Как вы делите эту работу внутри компании?
Мы сотрудничаем с нашими командами по работе с клиентами и решениями по инженерии, чтобы составить отчет "Голос клиента", который собирает запросы по функциям от всех наших клиентов. А в случае запросов на шаблоны у нас есть команда по шаблонам продукта, которой мы передаем новые идеи и идеи, созданные пользователями. Эта команда проводит свои собственные исследования по предложенным материалам, а затем оценивает возможность добавления официального шаблона в продукт. У нас также есть галерея шаблонов в нашем центре помощи, и некоторые из наших материалов, созданных пользователями, оказываются там и становятся доступными таким образом.
Я думаю, что наша долгосрочная цель – сделать так, чтобы центр помощи и сообщество в совокупности были значительно более местом для вдохновения и проактивной помощи, а не местом, куда пользователи идут только тогда, когда что-то сломано. Мы хотим заставить людей выйти за рамки восприятия, что это все еще общий стандарт в отрасли.
Похоже, вы представляете себе больше взаимодействия между вашей компанией и вашими клиентами.
Совершенно верно.
Это напоминает мне основные ценности Lucid: Командная работа важнее эго; инновации во всем, что мы делаем; индивидуальная ответственность, инициатива и собственность; и страсть и стремление к совершенству во всех областях. Создание двустороннего общего подхода освещает многие из этих идей. Как вы еще воплощаете эти основные ценности в вашем подходе к CX?
Это здорово, потому что эти основные ценности установлены на уровне всей компании, и они особенно актуальны для нас, потому что мы находимся на стороне компании, взаимодействующей с клиентами. Помимо этого, эти основные ценности – это то, что мы подчеркиваем на каждом открытии компании и на каждом обновлении компании. И раз в год мы проводим выездное совещание для всей компании, где берем три дня праздников, чтобы поехать в национальный парк Зайон или на озеро Бер, чтобы провести командные строительные мероприятия и сосредоточиться на нашей стратегии на следующий год, а также еще раз подчеркнуть наши основные ценности всем новым сотрудникам, которые участвуют в своем первом выездном совещании.
Как ваша команда подходит к проактивному обучению клиентов? Каково соотношение между проактивными и реактивными аспектами работы команды CX?
Начнем с реактивного, что, по моему мнению, мы сейчас делаем очень хорошо. Если пользователь знает, что он пытается сделать в продукте, и приходит в наш центр помощи или сообщество, чтобы разобраться, как это сделать, мы предоставим им необходимый контент и часто дополним его видео и скриншотами, чтобы убедиться, что они подготовлены к успешному запуску.
Я думаю, что модель, к которой мы стремимся, которая является проактивной моделью, не просто рассказывает людям, как что-то сделать, но и объясняет им почему делать это именно так. Представьте, что пользователь приходит в наш центр помощи, и другими средствами и сигналами мы знаем, что он является учителем биологии. Мы хотим предоставить этому учителю персонализированный контент, который не только показывает им пошаговые инструкции о том, как сделать то, что они ищут, но и на самом деле говорит им, какой шаблон использовать для этого. Наши специализированные команды – в этом примере команда по образованию – работают над предоставлением лучших, более информативных случаев использования.
Поэтому, если клиент читает о том, как использовать определенную функцию, мы можем собирать некоторые продуктовые сигналы от других пользователей, которые использовали эту функцию, и предоставлять эту информацию клиенту, вместе с другими функциями, с которыми работали аналогичные пользователи. Затем мы берем эту концепцию в центр помощи и говорим: "Хорошо, вы только что прочитали статью о презентациях. Теперь вам следует прочитать эту статью о слоях и о том, как отображать и скрывать разные слои, поскольку мы знаем, что эти две функции идут рука об руку в продукте." Это немного того, чего мы пытаемся достичь.
Как вы формализуете эту стратегию в цели? Похоже, ваши цели выходят за рамки удержания объема заявок стабильным и сокращения времени первого ответа.
Наш «Святой Грааль» для метрик поддержки – это связывать то, что пользователь делает в центре помощи, с тем, что он делает в продукте. Когда мы смотрим на определенную статью, скажем, о связанности данных, мы хотим иметь цель, такую как: из каждой 1 000 пользователей, прочитавших эту статью, 700 из них затем заходят в продукт и используют функцию связности данных. И в последние дни нам удается связывать использование центра помощи с использованием продукта. Так что мы можем затем экстраполировать оттуда и находить корреляции между использованием центра помощи и использованием продукта.
Я считаю, что это действительно суть того, что мы пытаемся сделать: увеличить использование нашего продукта. И затем быть в состоянии оценить эффективность удержания пользователей. Затем мы можем сказать, что если сравнить 1 000 пользователей, которые посетили центр помощи, с 1 000 пользователей, которые этого не сделали, наши показатели удержания увеличились на этот процент, потому что мы научили их чему-то ценному. Или даже пойти еще дальше, чем удержание, и рассмотреть, увеличились ли их показатели вовлеченности.
Мне это очень нравится. Недавно я поговорил с несколькими лидерами CX, и тема поддержки как генератора дохода, а не как центра затрат, продолжает подниматься. Ты звучишь так, будто подписываешься на эту модель, где поддержка может приносить доход, а не только требует затрат?
Абсолютно, но наша команда делает даже больше. Часто пользователь обращается к нам и говорит: "Эй, нам нравится использовать Lucidchart, но у нас возникла проблема с импортом документа. Наши импортированные документы выглядят странно. Если бы мы могли решить эту проблему, мы смогли бы расширить использование Lucidchart в нашей компании." Так что мы поможем с вопросом поддержки, а затем передадим это нашей команде продаж.
"В прошлом году поддержка на самом деле стала третьим по величине источником продажных контактов в компании. Если посмотреть на сумму дохода, приходящего через этот канал поддержки, она значительно превышает зарплаты, которые получает команда. Так что на самом деле мы вовсе не центр затрат."
Это просто впечатляюще! Какие еще метрики отслеживает ваша команда? И какие метрики вы бы порекомендовали другим лидерам по поддержке, которые восхищаются вашей моделью?
Одно из вещей, которыми мы гордимся, – это то, как быстро растут наш центр помощи и сайты сообщества – то, что мы называем масштабированной поддержкой – по сравнению с поддержкой один на один, что включает в себя электронные письма, телефонные звонки и поддержку в чате.
Один из способов измерить рост поддержки один на один – это посмотреть на количество электронных писем на один пользовательский баз. Поэтому мы отслеживаем, насколько быстро растет наша пользовательская база, и мы отслеживаем, насколько быстро растут каждую из наших платформ поддержки, а затем нормализуем одну относительно другой, чтобы выяснить количество отправленных писем на 10 000 активных пользователей продукта. А в сравнении, сколько просмотров страниц в центре помощи мы получаем на каждые 10 000 активных пользователей продукта.
Если посмотреть на сторону поддержки один на один, она более традиционная: мы смотрим на такие вещи, как время первого ответа, удовлетворенность клиентов и то, что мы называем временем ожидания пользователей, то есть временем, необходимым с момента подачи заявки до ее разрешения, за вычетом времени, когда мы ждем, чтобы клиент снова связался с нами с дополнительной информацией.
Когда мы смотрим на масштабированную поддержку, она немного отличается от поддержки один на один. Итак, из тех пользователей, которые используют масштабированную поддержку – будь то центр помощи или сообщество – что они делают в продукте? Каковы их показатели удержания за семь дней по сравнению с удержанием за 30 дней по сравнению с показателями удержания тех, кто не использует центр помощи? И затем мы также можем связать это с доходом. Люди, которые посещают центр помощи, имеют ли свойство чаще обновляться? Становятся ли они более распространенными по количеству пользователей на своем аккаунте? Я бы сказал, что это основные метрики, которые мы отслеживали, хотя это остается настоящей работой в процессе.
Вы раньше же говорили о том, как много используется определенная статья в вашем центре помощи, и что эти данные помогают в принятии будущих продуктовых решений. Это немного связано с тем, что мы делаем в Guru в терминах знаний, так как вы рассматриваете данные и знания, собранные через ваш центр помощи, как часть своей стратегии?
Это отличный вопрос. Мы всегда говорим, что поддержка один на один информирует нашу масштабированную поддержку. Если мы видим проблему, которая обсуждается в сообществе, например, если пользователь размещает что-то в сообществе и хочет узнать, как что-то сделать, и мы видим, что это получает много просмотров страниц, тогда мы фактически улучшаем это в статью для центра помощи и локализуем ее, чтобы привлечь еще больше трафика. И затем, если посмотреть на объем заявок, то же самое можно сказать. Если мы получаем много электронных писем о том, как сделать что-то в продукте, то мы посмотрим на эти письма и подумаем: "Хорошо, имеет ли это больше смысла как пост в сообществе или как статью в центре помощи?" Так что есть своего рода процесс перехода, когда, если мы видим много электронных писем по какому-то вопросу, оно переходит в пост сообщества. Если это затем получает много трафика, оно переходит в статью центра помощи.
И затем, мы можем измерить успех того, что мы делаем. Так что, когда мы создаем эту статью в центре помощи, мы можем вернуться и посмотреть, снизилось ли количество таких заявок, потому что теперь мы привлекаем больше трафика к масштабированной поддержке.
Последний аспект касается просмотров страниц. Просмотры страниц для нас могут часто заменить объем электронных писем. Если мы получаем пост в сообществе, который является запросом на функцию, мы можем показать вовлеченность и просмотры страниц по этому посту и передать эти данные команде инженеров и сказать: "Эй, есть спрос на это. Давайте добавим это в дорожную карту продукта."
У вас есть последние советы для лидеров поддержки, стремящихся масштабировать свои организации так же, как и ваша?
Мои другие советы сосредоточены на том, как набирать и удерживать лучшие таланты. У многих организаций поддержки есть большие проблемы с тем, что их удержание, как правило, довольно низкое. Одно из вещей, которые действительно позволили нам добиться успеха, это то, что удержание нашей команды чрезвычайно высоко. За последние 18 месяцев только один член моей команды перешел на другую работу, что в этой области довольно нехарактерно. А те сотрудники, которые покинули мою команду за последние три с половиной года, все остались в Lucid и перешли в другие отделы, принося с собой пользовательские идеи, которые они получили в других частях компании. Но я думаю, что если вы дадите людям в организации поддержки возможность действительно взять на себя ответственность за стратегию на высшем уровне, а не просто прорываться через электронные письма или решать телефонные звонки, это действительно придаст им сил и поможет им развить навыки, которые они могут затем применить в других сферах, будь то другая позиция в компании или внутри команды.
Это то, что я люблю повторять вновь и вновь: включайте команду в как можно больше стратегий, потому что в конечном итоге это будет тем, что будет удерживать их заинтересованными, вдохновленными и развивающимися.
Какой замечательный способ закончить. Большое спасибо за ваше время, Кейван! Как наши читатели могут связаться с вами, если у них есть вопросы о вашей философии поддержки или Lucidchart?
Lucidchart, разработанный Lucid Software, является визуальной платформой для продуктивности, которая помогает людям четко делиться идеями, информацией и процессами. С помощью обширного центра помощи, онлайн-сообщества и индивидуальной помощи команда поддержки Lucidchart обслуживает более 15 миллионов довольных пользователей, при этом сохраняя размер команды и объем заявок стабильными. Мы встретились с Кеваном Садигом, старшим директором по работе с клиентами в Lucidchart, чтобы узнать, как его команда расширила свои возможности поддержки и увеличила доход, не увеличивая при этом состав команды.
Спасибо, что присоединился к нам, Кеван! Можешь рассказать о своем опыте и немного контексте о том, как ты стал старшим директором по работе с клиентами в Lucidchart?
Конечно! У меня была долгая карьера с множеством поворотов и изменений. Я окончил Корнелл с дипломом по биологии и думал, что хочу получить степень PhD по генетике. Два года я работал в биомедицинской лаборатории в Бостоне, занимаясь генетическими исследованиями, а затем решил, что такая жизнь не для меня. Я немного запутался в том, что хочу делать, потому что всю свою жизнь учился науке, а теперь не хотел идти по исследовательскому пути.
Поэтому я вместо этого пошел в Teach for America в Филадельфии, где два года преподавал математику в старшей школе ученикам первых и вторых курсов. Я думал, что это будет хорошая возможность для меня поразмышлять и отойти на шаг назад от всего, чем я занимался. В конце моего времени там я начал искать работу и связался с другом, который работал в Google и подтолкнул меня подать заявку на работу там. Я присоединился к Google в то время, когда они сильно сосредоточились на создании своих центров помощи. Gmail был относительно новым продуктом, но его база пользователей росла очень быстро. У Google не было номера телефона, по которому люди могли бы позвонить, или электронной почты для поддержки, поэтому мы работали над стратегией создания центра помощи, где пользователи могли бы самостоятельно находить ответы и помогать друг другу.
Я занимался этим около четырех лет в разных ролях, а затем захотел попробовать свои силы в управлении людьми, поэтому я перешел в офис Google в Дублине, Ирландия, где помог инициировать их стратегию сообщества на нескольких европейских рынках. Таким образом, снова, наша мысль заключалась в том, что если мы можем предоставить платформу, чтобы пользователи могли помогать друг другу, тогда они смогут быстрее получить качественный ответ, чем они могли бы иначе.
Я должен был находиться в Дублине год, но остался на почти четыре. Мне это понравилось, это было отличное время. Мне удалось управлять людьми из разных культур, что было совершенно новым для меня опытом и очень здорово. Ближе к концу моего срока там, мне казалось, что компания была очень хорошо управляемым механизмом, в котором я играл лишь небольшую роль, и мне стало не хватать той настойчивости, что была в ранние дни Google, когда я мог получать опыт в разных задачах и это был больше подход "все руки на палубе".
Я начал рассматривать намного более мелкие компании и хотел что-то с культурой, похожей на Google, поэтому я посмотрел на сайт Google Ventures, чтобы найти компании, в которые Google инвестировал, и Lucid была одной из них. Наш CEO Карл Сан на самом деле также бывший сотрудник Google, и что мне понравилось в моем разговоре с ним, это #1, его акцент на людях и действительно построение культуры, которая дает возможность людям делать великие вещи; и #2 создание платформы, Lucidchart, которая позволяет людям общаться визуально через программное обеспечение.
Это была новая концепция для меня. Все мы понимаем, что значит общаться визуально, но традиционно мы полагались на такие вещи, как встречи или заметки или таблицы, чтобы общаться друг с другом. Lucid начал разрушать границы того, что люди могут делать в браузере, и стремился позволить нам мыслить визуально более совместным образом. Итак, я был очень вовлечен в миссию компании.
Когда я присоединился, команда поддержки состояла всего из четырех человек и была очень сосредоточена на поддержке по электронной почте. Задача, которую мне дали, заключалась в том, что наша база пользователей росла чрезвычайно быстро – она удваивалась каждый год в течение четырех или пяти лет подряд – но мы были уверены, что правильная стратегия заключалась в том, чтобы позволить нашим пользователям самостоятельно получать лучший и быстрый ответ. Вот для чего меня и пригласили.
Удивительно, похоже, вы действительно получили ту настойчивость, которую искали, переходя от команды поддержки размера Google к команде из четырех человек в Lucidchart!
Совершенно верно.
Теперь, когда вы масштабировались в Lucidchart, я слышал, что вы с тех пор удерживали свою команду поддержки на уровне 10 человек и объем заявок оставался стабильным в последние несколько лет. Какова роль маленькой команды в вашей стратегии поддержки?
Моя стратегия действительно сосредоточена на предоставлении качественного контента, который наша команда может измерить, чтобы позволить пользователям находить то, что им нужно. Я всегда использую пример банкомата, чтобы проиллюстрировать это: когда вы приходите в банк в обычное время работы, вы сталкиваетесь с этим вопросом: хочу ли я зайти в банк, постоять в очереди и задать свой вопрос? Или я хочу помочь себе с помощью банкомата? Обычно это банкомат. И если мы возьмем эту аналогию и применим ее к технологическому миру, в Lucidchart мы считаем, что хорошо написанная статья в центре помощи не только достаточна, но и предпочтительнее для 90% того, что наши пользователи пытаются сделать.
Кроме того, центр помощи на самом деле является отличным способом измерить спрос на множество различных вещей. Если вы можете показать, что десятки тысяч людей приходят к статье по определенной теме, вы можете затем использовать эту информацию в инженерах и добиваться изменений, подтвержденных реальными данными клиентов. В то время как, когда пользователи отправляют электронные письма в нашу команду поддержки, объем, как правило, гораздо меньше, и, следовательно, данные менее применимы, когда мы представляем их нашей инженерной команде. Для нас было бы отлично показать, что даже если только 15 пользователей отправили электронное письмо с просьбой о функции, тысячи пользователей посещали статьи в центре помощи, которые также относятся к этой функции.
Второй момент заключается в том, что наш контент центра помощи теперь локализован на шесть различных языков, так что есть внутренние затраты на создание качественного контента вашей командой. Таким образом, для контента длинного хвоста мы предоставляем сообщество, где пользователи могут отправлять свои собственные материалы, и другие пользователи могут извлечь из этого выгоду. Пример, который мне нравится использовать для этой концепции, заключается в том, что у нас есть Android-приложение для Lucidchart, и таких различных Android-телефонов буквально тысячи, поэтому, если у пользователя есть проблема с их конкретным телефоном и его взаимодействием с нашим программным обеспечением, шансы на то, что мы сможем на самом деле получить именно этот телефон, довольно низки. Но один из наших 15 миллионов пользователей, вероятно, имеет этот телефон и, возможно, даже столкнулся с точно такой же проблемой. Итак, иногда наша работа заключается в том, чтобы соединить наших пользователей, чтобы они могли помогать друг другу.
И это было действительно приятно видеть, потому что, когда мы смотрим на трафик нашего центра помощи и сообщества, он на самом деле превысил рост базы пользователей. И затем, относительно вашего комментария, когда мы смотрим на объем заявок на поддержку товара за последние три года, он фактически остался стабильным. Что, по моему мнению, подразумевает, что пользователи на самом деле очень довольны и тянутся к этой модели самопомощи.
Когда дело касается вашего онлайн-сообщества, есть ли у вас представление о том, какие люди вносят знания и помогают другим пользователям? Это крутая концепция подумать о том, как кто-то тратит свое личное время, обсуждая ваш продукт, чтобы помочь людям, которых он не знает.
Наше сообщество все еще в процессе – часто пользователи зададут вопросы, и мы те, кто отвечает им в сообществе, но затем другие пользователи все равно могут извлечь пользу из этого ответа. С увеличением числа мы видим, что другие пользователи приходят и предлагают ответы, что является лучшим вариантом для наших целей.
Отвечая на ваш вопрос о том, почему, в мире очень немногие продукты вызывают у пользователей такую сильную страсть, но мне повезло работать над одним из таких товаров, как Lucidchart, который определенно попадает в эту категорию. Потому что даже когда наш продукт не совсем соответствует потребностям пользователя, и им приходится проходить через порой сумасшедшие обходные пути, чтобы продолжать его использовать, они выбирают это.
Один из примеров этой страсти – это пользователь, который на самом деле настроил приложение Lucidchart для iPhone, чтобы оно стало его ежедневным календарем. Это случай использования, который наша команда никогда бы не представила для продукта, но по какой-то причине этот пользователь решил, что наше решение на самом деле лучше, чем календари Google и Apple, и несмотря на то, что мы вообще не нацелены на этот случай использования, они превзошли себя, чтобы сделать это рабочим.
Поэтому, если мы подумаем об этом менталитете, много того, что пользователи пытаются сделать, это раздвинуть границы того, что способен сделать наш продукт. И, помогая другим и делясь своими случаями использования, они подогревают свою страсть. Они любят этот продукт и хотят делиться этой страстью с другими.
Это удивительно. Как ваша команда следит за этими идеями и предложениями пользователей?
В нашем сообществе есть раздел под названием поделитесь своими диаграммами; мы хотим услышать от пользователей о новых способах использования нашего продукта. Так что это один из способов, как мы узнаем о некоторых из этих случаев использования. Более распространенный способ заключается в том, что наша команда все еще активно отвечает на электронные письма. Несмотря на то, что объем заявок остается стабильным, мы все еще получаем примерно 600 электронных писем с вопросами по продукту в неделю. Итак, пользователь выходит на связь с нами и говорит: "Я пытаюсь сделать это, но столкнулся с этой проблемой. Не могли бы вы взглянуть на мой документ и помочь мне с этой проблемой?" Часто документы, с которыми они хотят помощи, довольно простые в использовании шаблонов, но иногда мы видим действительно инновационные случаи использования нашего продукта, и в таких случаях мы часто спрашиваем их, не против ли они разместить их в сообществе, чтобы другие пользователи тоже могли извлечь из этого выгоду.
Появляются ли инновационные идеи, которые таким образом поступают, когда-нибудь в вашем продукте? Как вы делите эту работу внутри компании?
Мы сотрудничаем с нашими командами по работе с клиентами и решениями по инженерии, чтобы составить отчет "Голос клиента", который собирает запросы по функциям от всех наших клиентов. А в случае запросов на шаблоны у нас есть команда по шаблонам продукта, которой мы передаем новые идеи и идеи, созданные пользователями. Эта команда проводит свои собственные исследования по предложенным материалам, а затем оценивает возможность добавления официального шаблона в продукт. У нас также есть галерея шаблонов в нашем центре помощи, и некоторые из наших материалов, созданных пользователями, оказываются там и становятся доступными таким образом.
Я думаю, что наша долгосрочная цель – сделать так, чтобы центр помощи и сообщество в совокупности были значительно более местом для вдохновения и проактивной помощи, а не местом, куда пользователи идут только тогда, когда что-то сломано. Мы хотим заставить людей выйти за рамки восприятия, что это все еще общий стандарт в отрасли.
Похоже, вы представляете себе больше взаимодействия между вашей компанией и вашими клиентами.
Совершенно верно.
Это напоминает мне основные ценности Lucid: Командная работа важнее эго; инновации во всем, что мы делаем; индивидуальная ответственность, инициатива и собственность; и страсть и стремление к совершенству во всех областях. Создание двустороннего общего подхода освещает многие из этих идей. Как вы еще воплощаете эти основные ценности в вашем подходе к CX?
Это здорово, потому что эти основные ценности установлены на уровне всей компании, и они особенно актуальны для нас, потому что мы находимся на стороне компании, взаимодействующей с клиентами. Помимо этого, эти основные ценности – это то, что мы подчеркиваем на каждом открытии компании и на каждом обновлении компании. И раз в год мы проводим выездное совещание для всей компании, где берем три дня праздников, чтобы поехать в национальный парк Зайон или на озеро Бер, чтобы провести командные строительные мероприятия и сосредоточиться на нашей стратегии на следующий год, а также еще раз подчеркнуть наши основные ценности всем новым сотрудникам, которые участвуют в своем первом выездном совещании.
Как ваша команда подходит к проактивному обучению клиентов? Каково соотношение между проактивными и реактивными аспектами работы команды CX?
Начнем с реактивного, что, по моему мнению, мы сейчас делаем очень хорошо. Если пользователь знает, что он пытается сделать в продукте, и приходит в наш центр помощи или сообщество, чтобы разобраться, как это сделать, мы предоставим им необходимый контент и часто дополним его видео и скриншотами, чтобы убедиться, что они подготовлены к успешному запуску.
Я думаю, что модель, к которой мы стремимся, которая является проактивной моделью, не просто рассказывает людям, как что-то сделать, но и объясняет им почему делать это именно так. Представьте, что пользователь приходит в наш центр помощи, и другими средствами и сигналами мы знаем, что он является учителем биологии. Мы хотим предоставить этому учителю персонализированный контент, который не только показывает им пошаговые инструкции о том, как сделать то, что они ищут, но и на самом деле говорит им, какой шаблон использовать для этого. Наши специализированные команды – в этом примере команда по образованию – работают над предоставлением лучших, более информативных случаев использования.
Поэтому, если клиент читает о том, как использовать определенную функцию, мы можем собирать некоторые продуктовые сигналы от других пользователей, которые использовали эту функцию, и предоставлять эту информацию клиенту, вместе с другими функциями, с которыми работали аналогичные пользователи. Затем мы берем эту концепцию в центр помощи и говорим: "Хорошо, вы только что прочитали статью о презентациях. Теперь вам следует прочитать эту статью о слоях и о том, как отображать и скрывать разные слои, поскольку мы знаем, что эти две функции идут рука об руку в продукте." Это немного того, чего мы пытаемся достичь.
Как вы формализуете эту стратегию в цели? Похоже, ваши цели выходят за рамки удержания объема заявок стабильным и сокращения времени первого ответа.
Наш «Святой Грааль» для метрик поддержки – это связывать то, что пользователь делает в центре помощи, с тем, что он делает в продукте. Когда мы смотрим на определенную статью, скажем, о связанности данных, мы хотим иметь цель, такую как: из каждой 1 000 пользователей, прочитавших эту статью, 700 из них затем заходят в продукт и используют функцию связности данных. И в последние дни нам удается связывать использование центра помощи с использованием продукта. Так что мы можем затем экстраполировать оттуда и находить корреляции между использованием центра помощи и использованием продукта.
Я считаю, что это действительно суть того, что мы пытаемся сделать: увеличить использование нашего продукта. И затем быть в состоянии оценить эффективность удержания пользователей. Затем мы можем сказать, что если сравнить 1 000 пользователей, которые посетили центр помощи, с 1 000 пользователей, которые этого не сделали, наши показатели удержания увеличились на этот процент, потому что мы научили их чему-то ценному. Или даже пойти еще дальше, чем удержание, и рассмотреть, увеличились ли их показатели вовлеченности.
Мне это очень нравится. Недавно я поговорил с несколькими лидерами CX, и тема поддержки как генератора дохода, а не как центра затрат, продолжает подниматься. Ты звучишь так, будто подписываешься на эту модель, где поддержка может приносить доход, а не только требует затрат?
Абсолютно, но наша команда делает даже больше. Часто пользователь обращается к нам и говорит: "Эй, нам нравится использовать Lucidchart, но у нас возникла проблема с импортом документа. Наши импортированные документы выглядят странно. Если бы мы могли решить эту проблему, мы смогли бы расширить использование Lucidchart в нашей компании." Так что мы поможем с вопросом поддержки, а затем передадим это нашей команде продаж.
"В прошлом году поддержка на самом деле стала третьим по величине источником продажных контактов в компании. Если посмотреть на сумму дохода, приходящего через этот канал поддержки, она значительно превышает зарплаты, которые получает команда. Так что на самом деле мы вовсе не центр затрат."
Это просто впечатляюще! Какие еще метрики отслеживает ваша команда? И какие метрики вы бы порекомендовали другим лидерам по поддержке, которые восхищаются вашей моделью?
Одно из вещей, которыми мы гордимся, – это то, как быстро растут наш центр помощи и сайты сообщества – то, что мы называем масштабированной поддержкой – по сравнению с поддержкой один на один, что включает в себя электронные письма, телефонные звонки и поддержку в чате.
Один из способов измерить рост поддержки один на один – это посмотреть на количество электронных писем на один пользовательский баз. Поэтому мы отслеживаем, насколько быстро растет наша пользовательская база, и мы отслеживаем, насколько быстро растут каждую из наших платформ поддержки, а затем нормализуем одну относительно другой, чтобы выяснить количество отправленных писем на 10 000 активных пользователей продукта. А в сравнении, сколько просмотров страниц в центре помощи мы получаем на каждые 10 000 активных пользователей продукта.
Если посмотреть на сторону поддержки один на один, она более традиционная: мы смотрим на такие вещи, как время первого ответа, удовлетворенность клиентов и то, что мы называем временем ожидания пользователей, то есть временем, необходимым с момента подачи заявки до ее разрешения, за вычетом времени, когда мы ждем, чтобы клиент снова связался с нами с дополнительной информацией.
Когда мы смотрим на масштабированную поддержку, она немного отличается от поддержки один на один. Итак, из тех пользователей, которые используют масштабированную поддержку – будь то центр помощи или сообщество – что они делают в продукте? Каковы их показатели удержания за семь дней по сравнению с удержанием за 30 дней по сравнению с показателями удержания тех, кто не использует центр помощи? И затем мы также можем связать это с доходом. Люди, которые посещают центр помощи, имеют ли свойство чаще обновляться? Становятся ли они более распространенными по количеству пользователей на своем аккаунте? Я бы сказал, что это основные метрики, которые мы отслеживали, хотя это остается настоящей работой в процессе.
Вы раньше же говорили о том, как много используется определенная статья в вашем центре помощи, и что эти данные помогают в принятии будущих продуктовых решений. Это немного связано с тем, что мы делаем в Guru в терминах знаний, так как вы рассматриваете данные и знания, собранные через ваш центр помощи, как часть своей стратегии?
Это отличный вопрос. Мы всегда говорим, что поддержка один на один информирует нашу масштабированную поддержку. Если мы видим проблему, которая обсуждается в сообществе, например, если пользователь размещает что-то в сообществе и хочет узнать, как что-то сделать, и мы видим, что это получает много просмотров страниц, тогда мы фактически улучшаем это в статью для центра помощи и локализуем ее, чтобы привлечь еще больше трафика. И затем, если посмотреть на объем заявок, то же самое можно сказать. Если мы получаем много электронных писем о том, как сделать что-то в продукте, то мы посмотрим на эти письма и подумаем: "Хорошо, имеет ли это больше смысла как пост в сообществе или как статью в центре помощи?" Так что есть своего рода процесс перехода, когда, если мы видим много электронных писем по какому-то вопросу, оно переходит в пост сообщества. Если это затем получает много трафика, оно переходит в статью центра помощи.
И затем, мы можем измерить успех того, что мы делаем. Так что, когда мы создаем эту статью в центре помощи, мы можем вернуться и посмотреть, снизилось ли количество таких заявок, потому что теперь мы привлекаем больше трафика к масштабированной поддержке.
Последний аспект касается просмотров страниц. Просмотры страниц для нас могут часто заменить объем электронных писем. Если мы получаем пост в сообществе, который является запросом на функцию, мы можем показать вовлеченность и просмотры страниц по этому посту и передать эти данные команде инженеров и сказать: "Эй, есть спрос на это. Давайте добавим это в дорожную карту продукта."
У вас есть последние советы для лидеров поддержки, стремящихся масштабировать свои организации так же, как и ваша?
Мои другие советы сосредоточены на том, как набирать и удерживать лучшие таланты. У многих организаций поддержки есть большие проблемы с тем, что их удержание, как правило, довольно низкое. Одно из вещей, которые действительно позволили нам добиться успеха, это то, что удержание нашей команды чрезвычайно высоко. За последние 18 месяцев только один член моей команды перешел на другую работу, что в этой области довольно нехарактерно. А те сотрудники, которые покинули мою команду за последние три с половиной года, все остались в Lucid и перешли в другие отделы, принося с собой пользовательские идеи, которые они получили в других частях компании. Но я думаю, что если вы дадите людям в организации поддержки возможность действительно взять на себя ответственность за стратегию на высшем уровне, а не просто прорываться через электронные письма или решать телефонные звонки, это действительно придаст им сил и поможет им развить навыки, которые они могут затем применить в других сферах, будь то другая позиция в компании или внутри команды.
Это то, что я люблю повторять вновь и вновь: включайте команду в как можно больше стратегий, потому что в конечном итоге это будет тем, что будет удерживать их заинтересованными, вдохновленными и развивающимися.
Какой замечательный способ закончить. Большое спасибо за ваше время, Кейван! Как наши читатели могут связаться с вами, если у них есть вопросы о вашей философии поддержки или Lucidchart?