Lucidchart, від Lucid Software, це візуальна платформа продуктивності, яка допомагає людям зрозуміло ділитися ідеями, інформацією та процесами. Завдяки надійному центру допомоги, онлайн-спільноті та індивідуальному обслуговуванню, команда підтримки Lucidchart обслуговує понад 15 мільйонів задоволених користувачів, при цьому зберігаючи розмір команди та обсяг запитів на підтримку стабільними. Ми поспілкувалися з Keyvan Sadigh, старшим директором з обслуговування клієнтів Lucidchart, щоб дізнатися, як його команда розширила свої можливості підтримки та отримала прибуток, не збільшуючи свій штат.

Дякуємо, що приєдналися до нас, Keyvan! Чи можете ви розповісти про свій досвід та надати трохи контексту про те, як ви стали старшим директором з обслуговування клієнтів у Lucidchart?

Звичайно! У мене була тривала кар'єра з багатьма поворотами. Я закінчив Корнельський університет зі ступенем в біології та думав, що хочу отримати докторський ступінь у галузі генетики. Я працював два роки в біомедичній лабораторії в Бостоні, займаючись генетичними дослідженнями, а потім вирішив, що таке життя не для мене. Я трохи плутався в тому, чим хочу займатися, тому що все своє життя вивчав науку, а тепер не хочував йти в галузь досліджень.

Тож замість цього я працював у Teach for America у Філадельфії, де викладав математику в старшій школі учням-першокурсникам і учням третього курсу протягом двох років. Я вважав, що це буде гарна можливість для мене відрефлексувати та зробити крок назад від всього, чим я займався. Наприкінці свого часу там я почав шукати роботу та звернувся до одного свого товариша, який працював у Google і закликав мене подати заявку на вакансію там. Я приєднався до Google в той час, коли вони дуже зосередилися на побудові своїх центрів допомоги. Gmail був відносно новим продуктом, але його база користувачів швидко зростала. У Google не було номера телефону, за яким люди могли б звернутися за підтримкою, або електронної пошти для підтримки, тому ми працювали над стратегією створення центру допомоги, де користувачі могли б самостійно допомагати собі та один одному.

Я працював над цим протягом приблизно чотирьох років в різних ролях, а потім захотів спробувати себе у керівництві, тому я перевівся до офісу Google в Дубліні, Ірландія, де допомагав запустити їхню стратегію спільноти в кількох європейських ринках. Тож знову, ми мали на думці, що якщо ми зможемо надати платформу для користувачів допомагати один одному, вони зможуть отримати відповіді високої якості значно швидше, ніж інакше.

Я повинен був бути в Дубліні протягом одного року, але врешті-решт залишився майже на чотири. Мені це шалено подобалося, це був такий чудовий час. Я зміг управляти людьми з різних культур, що було для мене абсолютно новим досвідом, який був дійсно чудовим. Наприкінці мого часу там я відчував, що компанія була дуже добре організованою системою, в якій я був лише маленькою частиною, і почав сумувати за запальним духом ранніх днів у Google, де я міг би отримати досвід з багатьох різних завдань, і це була більш філософія "всі на борту".

Я почав дивитися на набагато менші компанії і хотів щось з подібною культурою до Google, тому я переглядав веб-сайт Google Ventures, щоб знайти компанії, в які Google інвестував, і Lucid була однією з них. Наш генеральний директор Карл Сан насправді також колишній співробітник Google, і те, що мені сподобалося в нашій розмові з ним, було #1, його акцент на людях і дійсно будування культури, яка наділяє людей робити великі справи; і #2, створення платформи, Lucidchart, яка дозволяє людям візуально спілкуватися через програмне забезпечення.

Це була нова концепція для мене. Ми всі знаємо, що це означає спілкуватися візуально, але традиційно ми покладалися на такі речі, як зустрічі, нотатки або електронні таблиці, щоб спілкуватися один з одним. Lucid почав розширювати межі можливостей людей у браузері і прагнув дозволити нам думати візуально більш колективним способом. Тож я дійсно захопився місією компанії.

Коли я приєднався, команда підтримки складалася лише з чотирьох осіб, і вона зосереджувалася переважно на підтримці через електронну пошту. Завдання, яке мені дісталося, полягало в тому, що наша база користувачів дуже швидко зростала – вона подвоювалася кожного року протягом чотирьох або п'яти років поспіль – але ми були впевнені, що правильною стратегією буде дозволити нашим користувачам отримувати свої найкращі, найшвидші відповіді, допомагаючи собі. Тож саме це я і мав на меті від самого початку.

Вау, здається, ви справді отримали той запал, якого шукали, переходячи з команди підтримки розміром з Google до команди з чотирьох осіб у Lucidchart!

Абсолютно.

Тепер, коли ви розширилися в Lucidchart, я чув, що ви зберегли свою команду підтримки стабільною на 10 осіб і обсяги запитів залишилися стабільними за останні кілька років. Яку роль у вашій стратегії підтримки відіграє мала команда?

Моя стратегія справді зосереджена на наданні якісного контенту, який наша команда може виміряти, щоб дозволити користувачам самостійно знаходити те, що їм потрібно. Я завжди наводжу приклад банкомату, щоб проілюструвати це: Коли ви приходите в банк під час звичайного робочого часу, ви стикаєтеся з цим питанням: чи хочу я зайти в банк, почекати в черзі і запитати своє питання? Або чи хочу я допомогти собі в банкоматі? Зазвичай це банкомат. І якщо ми візьмемо цю аналогію і застосуємо її до технологічного світу, то в Lucidchart ми вважаємо, що дуже добре написана стаття в центрі допомоги не лише достатня, але насправді є кращою для 90% того, що наші користувачі хочуть зробити.

Крім того, центр допомоги насправді є відмінним способом виміряти попит на багато різних речей. Якщо ви можете показати, що десятки тисяч людей відвідують статтю про певну тему, ви можете взяти цю інформацію для інженерів і натиснути на зміни, підтримувані реальними даними користувачів. Тоді, коли користувачі надсилають електронні листи нашій команді підтримки, обсяги зазвичай значно нижче, і відповідно дані є менш дієвими, коли ми їх представляємо нашій інженерній команді. Для нас було чудово показати, що навіть якщо лише 15 користувачів надіслали електронні листи з проханням про функцію, тисячі користувачів відвідали статті в центрі допомоги, які також стосуються цієї функції.

Другий аспект полягає в тому, що контент нашого центру допомоги тепер локалізовано на шість різних мов, тож існує певна вартість надання якісного контенту, написаного вашою командою. Отже, для довгострокового контенту ми надаємо спільноту, де користувачі можуть надсилати свої власні матеріали, а інші користувачі можуть отримати від них користь. Приклад, який мені подобається для ілюстрації цієї концепції, полягає в тому, що у нас є Android-додаток для Lucidchart, і є тисячі різних телефонів Android, тому якщо у користувача є проблема з його конкретним телефоном і тим, як він взаємодіє з нашим програмним забезпеченням, шанси на те, що ми зможемо дістатися до цього конкретного телефону, досить низькі. Але один з наших 15 мільйонів користувачів, ймовірно, має цей телефон і, можливо, навіть зіштовхнувся з цією ж проблемою. Тож іноді наша роль полягає в тому, щоб з'єднувати наших користувачів один з одним, щоб вони могли допомагати один одному.

І це було дійсно дивно побачити, адже, коли ми переглядаємо трафік нашого центру допомоги та спільнот, це насправді перевищило зростання бази користувачів. А коли ми переглядаємо обсяги квитків продукту за останні три роки, він, по суті, залишався стабільним. Що, на мою думку, свідчить про те, що користувачі насправді отримують задоволення і орієнтуються на цю модель самообслуговування.

Коли мова йде про вашу онлайн-спільноту, чи є у вас уявлення про те, які люди вносять знання та допомагають іншим користувачам? Це цікава концепція подумати про когось, хто витрачає свій особистий час на обговорення вашого продукту, щоб допомогти людям, яких вони не знають.

Наша спільнота все ще в процесі розвитку - багато разів користувачі задають питання, і ми відповідаємо на них у спільноті, але тоді інші користувачі все ще можуть отримати користь від цієї відповіді. Однак, все частіше ми бачимо, що інші користувачі входять і надають відповідь, що є найкращим випадком для наших цілей.

Відповідаючи на ваше запитання про те, чому, є дуже мало продуктів у світі, які викликають у користувачів таку пристрасть, але мені пощастило працювати з одним з них – Lucidchart, який безумовно підпадає під цю категорію. Оскільки навіть коли наш продукт не зовсім відповідає потребам користувача, і вони повинні проходити через часом божевільні обхідні шляхи, щоб продовжувати його використовувати, вони вирішують це зробити.

Один приклад цієї пристрасти – це користувач, який насправді налаштував додаток Lucidchart для iPhone як свій щоденний календар. Це випадок використання, який наша команда ніколи б не змогла уявити для продукту, але з якоїсь причини цей користувач вирішив, що наше рішення насправді краще, ніж календарі Google і Apple, і незважаючи на те, що ми взагалі не націлені на цей випадок використання, вони пішли далі, щоб змусити це працювати для свого випадку використання.

Тож, якщо ми подумаємо про цей менталітет, багатьох з того, що намагаються зробити користувачі, є розширення меж того, що здатний наш продукт. А, допомагаючи іншим і ділячися своїми випадками використання, це підживлює їхню пристрасть. Вони люблять цей продукт і хочуть поділитися цією пристрастю з іншими.

Це дивовижно. Як ваша команда відстежує ці ідеї та внески користувачів?

У нашій спільноті є розділ під назвою поділіться своїми діаграмами; ми хочемо почути від користувачів про нові способи використання нашого продукту. Це один із способів, як ми дізнаємося про деякі з цих випадків використання. Більш поширений спосіб – наша команда все ще дуже активно займається відповідями на електронні листи. Навіть якщо обсяги запитів стабільні, ми все ще отримуємо близько 600 електронних листів на тиждень, пов'язаних з продуктами. Тож користувач зв’язується з нами і каже: «Ось що я намагаюся зробити, але я зіштовхнувся з цією перешкодою. Ви не могли б переглянути мій документ і допомогти мені з цією проблемою?» Часто документи, з якими вони хочуть отримати допомогу, є досить прямими використаннями наших шаблонів, але іноді ми бачимо дійсно інноваційні випадки використання нашого продукту, і в таких випадках ми часто запитуємо їх, чи не могли б вони опублікувати їх у спільноті, щоб інші користувачі також зможуть отримати користь від цього.

Чи потрапляють інноваційні ідеї, що надходять подібним чином, назад у ваш продукт? Як ви ділитеся цією роботою всередині компанії?

Ми співпрацюємо з нашими командами з успіху клієнтів та рішень інженерії, щоб підготувати звіт «Голос клієнта», який збирає запити на функції від усіх наших клієнтів. А у випадку запитів на шаблони, у нас є команда товарів і шаблонів, до якої ми надсилаємо нові та користувацькі ідеї. Ця команда проводить власне дослідження щодо надходжень і потім оцінює можливість додавання офіційного шаблону до продукту. У нас також є галерея шаблонів у нашому центрі допомоги, і деякий контент, створений користувачами, потрапляє туди та стає доступним таким чином.

Я вважаю, що наше довгострокове бачення полягає в тому, щоб центр допомоги та спільноти в поєднанні були набагато більше місцем для натхнення та проактивної допомоги, а не місцем, куди користувачі йдуть тільки тоді, коли щось поламалося. Ми хочемо допомогти людям вийти за межі цього сприйняття, яке все ще є загальним стандартом в галузі.

Здається, ви уявляєте більше двосторонній рух між вашою компанією та вашими клієнтами.

Абсолютно.

Це нагадує мені про основні цінності Lucid: командна робота понад его; інновації у всьому, що ми робимо; індивідуальна повноваження, ініціативи та інститут; а також пристрасть та майстерність у кожній сфері. Створення двостороннього руху відображає багато із цих цінностей. Як ви ще втілюєте ці основні цінності у вашому підході до обслуговування клієнтів?

Це добре, тому що ці основні цінності встановлені на загально-компанійському рівні, і вони особливо правдиві для нас, оскільки ми знаходимося на боці компанії, що взаємодіє з клієнтами. Крім того, ці основні цінності – це те, що ми підкреслюємо на кожному корпоративному заході і на кожному корпоративному оновленні. І одного разу на рік ми організовуємо корпоративний відступ, коли ми беремо три дні на відпочинок, щоб поїхати в Національний парк Зайон або озеро Беар, щоб працювати в команді та зосередитися на нашій стратегії на наступний рік, а також повторно підкреслити наші основні цінності всім новим людям, які відвідують свій перший відступ.

Це чудово почути. Ми намагаємося втілювати наші основні цінності у всьому, що ми робимо в Guru.

Як ваша команда підходить до проактивної освіти клієнтів? Який розподіл між проактивною і реактивною стороною роботи команди обслуговування клієнтів?

Почнемо з реактивної, що, на мою думку, ми наразі робимо дуже добре. Якщо користувач знає, що він намагається зробити в продукті, і він приходить до нашого центру допомоги або спільноти, щоб з'ясувати, як це зробити, ми надамо їм контент, якого їм потрібно, і часто доповнимо його відео та скриншотами, щоб бути впевненими, що вони готові до успіху.

Я вважаю, що модель, до якої ми намагаємось рухатись, яка є проактивною моделлю, полягає не лише в тому, щоб розповісти людям, як щось зробити, а й чому вони повинні робити це саме так. Уявіть собі, що користувач приходить до нашого центру допомоги і через інші засоби та сигнали ми знаємо, що вони є вчителем біології. Ми хочемо вказати цього вчителя на налаштований контент, який не лише демонструє їм покрокові інструкції про те, як зробити те, що вони хочуть, але й надає їм шаблон для використання. Наші спеціалізовані команди – в цьому випадку команда освіти – працюють над створенням якісніших, інформативніших випадків використання.

Тож, якщо клієнт читає про те, як використовувати певну функцію, ми можемо зібрати деякі сигнали продукту від інших користувачів, які використовували цю функцію, і надати цю інформацію клієнту разом з іншими функціями, з якими працювали подібні користувачі. Тож, тоді ми вносимо цю концепцію в центр допомоги і кажемо: «Ось, ви тільки що прочитали статтю про презентації. Тепер ви повинні прочитати цю статтю про шари та показувати і приховати різні шари, тому що ми знаємо, що ці дві функції пов'язані в продукті.” Це трішки те, що ми намагаємося досягти.

Тож, як ви формалізуєте цю стратегію в цілі? Здається, ваші цілі йдуть далеко за межі просто підтримки стабільності обсягу запитів та зниження часу першої відповіді.

Наш «святий грал» для метрик підтримки – це зв'язування того, що користувач робить у центрі допомоги з тим, що вони потім роблять у продукті. При перегляді конкретної статті, скажімо, про зв’язування даних, ми хочемо мати ціль, таку як: з кожної 1 000 користувачів, які читають цю статтю, 700 переходять у продукт і використовують функцію зв’язування даних. І в останній час нам вдалося поєднати використання центру допомоги з використанням продукту. Тож ми можемо екстраполювати з цього і знайти кореляції між використанням центру допомоги та використанням продукту.

Це, я вважаю, суть того, що ми намагаємося зробити: збільшити використання нашого продукту. А потім можливість оцінити цінність утримання користувача. Тож ми можемо порівняти 1000 користувачів, які відвідали центр допомоги, з 1000, які не відвідували, і з'ясувати, що наші показники утримання зросли на цей відсоток, тому що ми навчили їх чомусь важливому. Або навіть йдучи далі у аналізі збереження, погляньте, чи підвищилися їхні показники залучення.

Мені це подобається. Я нещодавно спілкувався з кількома лідерами CX, і темою є те, що підтримка є генератором доходу, а не центром витрат. Ви, здається, підтримуєте цю модель підтримки, яка може генерувати доходи, а не просто нести витрати?

Абсолютно, але наша команда йде ще далі. Багато разів, користувач буде звертатися до нас і говорити: "Привіт, нам дуже подобається використовувати Lucidchart, але у нас є проблема з імпортом документа. Наші імпортовані документи виглядають дивно. Якщо б нам вдалося виправити цю проблему, ми змогли б розширити наше використання Lucidchart у нашій компанії." Тож ми допоможемо з проблемою підтримки, а потім передамо це нашій команді продажів.

"У минулому році підтримка насправді була третим найбільшим джерелом продажів у компанії. Якщо ви подивитеся на суму доходу, що надходить через цей канал підтримки, вона значно перевищує зарплати команди. Тож ми насправді НЕ є центром витрат взагалі."

Це вкрай вражаюче! Які інші метрики ваша команда відстежує? І які метрики ви б порекомендували іншим лідерам підтримки, які цікавляться вашою моделлю, відстежувати?

Одна з речей, якими ми пишаємося, це те, як швидко зростуть наш центр допомоги та спільноти – те, що ми називаємо масштабованою підтримкою – в порівнянні з одноосібною підтримкою, яка є електронними листами, телефонними дзвінками та чатом.

Один зі способів виміряти зростання одноосібної підтримки – це подивитися на кількість електронних листів на кількість користувачів. Тож ми відстежуємо, як швидко зростає наша база користувачів, і ми відстежуємо, наскільки швидко зростуть наші платформи підтримки, а потім нормалізуємо одну по відношенню до іншої, щоб дізнатися кількість електронних листів, що надсилаються на 10,000 активних користувачів продукту. І на контрасті, скільки переглядів сторінок центру допомоги ми отримуємо на кожні 10,000 активних користувачів продукту.

Якщо я дивлюся на сторони одноосібної підтримки, це більш традиційно: ми дивимося на такі речі, як час першої відповіді, задоволеність клієнтів і те, що ми називаємо часом очікування користувача, що є часом, що проходить від подачі заявки до її вирішення, віднімання будь-якого часу, коли ми чекаємо, поки клієнт повернеться до нас з додатковою інформацією.

Коли ми дивимося на масштабовану підтримку, це трошки інакше, ніж одноосібна підтримка. Отже, яких користувачів, які використовують масштабовану підтримку – чи то центр допомоги, чи спільнота – що вони роблять в продукті? Яка їхня ставка утримання через сім днів порівняно з 30-денним терміном утримання проти рівня утримання людей, які не використовують центр допомоги? І тоді ми також можемо зв'язати це з доходом. Люди, які відвідують центр допомоги, чи схильні вони до підвищення? Чи схильні вони розширити кількість користувачів у своєму акаунті? Сказав би, що це основні метрики, які ми відстежували, хоча це залишається дуже багато в процесі.

Ви раніше говорили про те, як часто використовується певна стаття у вашому центрі допомоги, і ці дані впливають на майбутні рішення про продукт. Це трохи стосується того, що ми робимо в Guru в термінах знання, тож як ви думаєте про дані та знання, які ви збираєте через свій центр допомоги, що стосується вашої стратегії?

Це чудове питання. Ми завжди любимо говорити, що наша одноосібна підтримка інформує нашу масштабовану підтримку. Тож, якщо ми бачимо проблему, яка з'являється в спільноті, наприклад, якщо користувач публікує щось у спільноті, що вони хочуть дізнатися, як щось зробити, і ми бачимо, що це отримує багато переглядів, то ми насправді оновимо це в статтю центру допомоги та локалізуємо її, щоб залучити ще більше трафіку. І потім, якщо я дивлюся на обсяги заявок, те ж саме можна сказати. Якщо ми отримуємо багато електронних листів про те, як щось зробити в продукті, тоді ми подивимося на ці електронні листи і подумаємо: "Добре, а чи не виглядає це більше як публікація у спільноті чи як стаття у центрі допомоги?" Тож є свого роду цей процес переходу, коли якщо ми бачимо багато електронних листів на щось, воно переходить до публікації у спільноті. Якщо це потім отримує багато трафіку, це переходить до статті у центрі допомоги.

І тоді ми можемо виміряти успіх того, що ми робимо. Отже, як тільки ми створимо цю статтю у центрі допомоги, ми можемо повернутися і подивитися, чи зменшилися ці типи заявок, тому що ми тепер залучаємо більше трафіку до масштабованої підтримки.

Остання частина стосується переглядів сторінок. Перегляди сторінок для нас часто можуть замінити обсяги електронних листів. Якщо ми отримуємо публікацію у спільноті, яка є запитом на функцію, ми можемо показати залучення та перегляди сторінок на цій публікації у спільноті та передати ці дані команді інженерів та сказати: "Гей, є запит на це. Давайте включимо це до дорожньої карти продукту."

Чи є у вас якісь останні поради для лідерів підтримки, які прагнуть масштабувати свої організації так, як ваша?

Мої інші поради зосереджені на тому, як залучити та утримати найкращих фахівців. Багато організацій підтримки мають величезні проблеми в тому, що їхнє утримання зазвичай є досить низьким. Одна з речей, які дозволили нам досягти успіху, це те, що утримання нашої команди надзвичайно високе. Протягом останніх 18 місяців лише один член моєї команди перейшов, що є досить незвичним для цієї сфери. І ті особи, які залишили мою команду за останні три з половиною роки, всі залишилися в Lucid і перейшли до інших відділів, перенісши користувацькі інсайти, які вони отримали, в інші частини компанії. Але я думаю, якщо ви надасте людям у організації підтримки дійсно можливість відповідати за стратегію верхнього рівня, а не просто завертати листи або вирішувати телефонні дзвінки, це справді надихає їх і допомагає їм набувати навичок, які вони можуть потім перейти в інші сфери, чи то інша роль у компанії, чи в середині команди.

Це те, що я люблю повторювати знову і знову: залучайте команду до якомога більшої кількості стратегій, адже зрештою це буде те, що утримає їх в захваті, захопленню та розвитку.

Яка чудова спосіб закінчити. Дякую вам за ваш час, Keyvan! Як наші читачі можуть зв'язатися з вами, якщо у них є питання щодо вашої філософії підтримки або Lucidchart?

Ви можете зв'язатися зі мною через LinkedIn.