Lucidchartは、Lucid Softwareが提供するビジュアルプロダクティビティプラットフォームで、住民がアイデア、情報、プロセスを明確に共有できるように支援します。 堅牢なヘルプセンター、オンラインコミュニティ、一対一のサポートを通じて、Lucidchartのサポートチームは1500万人以上の満足したユーザーにサービスを提供しており、チームのサイズやチケットの数を維持しています。 私たちは、Lucidchartで顧客業務のシニアディレクターを務めるKeyvan Sadigh氏と対談し、彼のチームがどのようにしてサポート能力を拡大し、チームを拡大せずに収益を上げたのかを探りました。

参加してくれてありがとう、Keyvan！ あなたの経歴をざっと歩きながら、Lucidchartの顧客業務シニアディレクターに就任するまでの経緯を教えていただけますか？

もちろん！ 私は多くの曲がりくねった道を経て長いキャリアを持っています。 私はコーネル大学を生物学の学位で卒業し、遺伝学の博士号を取得したいと思っていました。 私はボストンのバイオメディカルラボで2年間遺伝学の研究を行いましたが、その生活は私に合わないことに気付きました。 私は自分が何をしたいのか少し混乱していました。なぜなら、私は生涯にわたって科学を学んできたのに、研究の道には進みたくなかったからです。

だから私はフィラデルフィアでTeach for Americaを行い、高校の1年生と3年生に2年間数学を教えました。 これは、自分がしてきたことから一歩引いて考える良い機会だと思いました。 私の在任期間の終わりには、仕事を探し始め、Googleで働いている友人に連絡を取り、そちらに応募するよう勧められました。 我々はGoogleに加わる時期に、彼らはヘルプセンターの構築に非常に重点を置いていました。 Gmailは比較的新しい製品でしたが、そのユーザーベースは非常に急速に成長していました。 Googleにはサポートの電話番号やメールアドレスがなかったため、ユーザーが自分自身で助け合いできるヘルプセンターを構築する戦略に取り組みました。

私は約4年間、さまざまな役割でそれを行い、その後、人事管理に挑戦したいと思ったので、Googleのダブリンオフィスに転勤し、いくつかの欧州市場でコミュニティ戦略を立ち上げました。 再び考えたのは、ユーザー同士で助け合うプラットフォームを提供できれば、彼らはそれ以外の場合よりもはるかに早く高品質な回答を得られるだろうということでした。

私はダブリンに1年間いる予定でしたが、結局4年近く滞在しました。 私はそれを愛していました、とても素晴らしい時間でした。 私は異なる文化から来た人々を管理することができ、これは私にとって非常に新しい経験であり、非常に素晴らしいものでした。 その期間の終わりに、会社は非常に良く機能しているエンジンのように感じ、小さな役割しか果たしていないと感じ、Googleの初期の頃の様々なタスクに関与できたことが恋しくなりました。

私はもっと小さな企業に注目し、Googleと類似した文化を持つものを求め、Googleベンチャーズのウェブサイトを調べて、Googleが投資している企業を見つけ、その中にLucidが含まれていました。 私たちのCEOであるKarl Sunは実際に元Googleの社員でもあり、彼との会話で気に入った点は、#1、人と本当に素晴らしいことをするために人々を力づける文化を築くための強調；#2、 사람들이 비주얼적으로 소통할 수 있도록하는 플랫폼인 Lucidchart의 구축입니다.

それは私にとって新しい概念でした。 私たちは視覚的にコミュニケーションを取ることが何を意味するのかを皆知っていますが、伝統的には会議やメモ、スプレッドシートなどに頼って、互いにコミュニケーションを取ってきました。 Lucidは人々がブラウザでできることの限界を押し広げ、より協力的に視覚的に考えることができるようにしました。 だから私はこの会社の使命に本当に共感しました。

私が加わるとき、サポートチームはわずか4人で、主にメールサポートに重点を置いていました。 私に与えられた課題は、私たちのユーザーベースが非常に急速に成長していることでした – それは4年か5年にわたって毎年倍増していました – しかし、私たちは、ユーザーが最良で最速の回答を得るためには、自分で助けられるようにすることが正しい戦略であると確信していました。 だから、私はそのために雇われたのです。

わあ、それはまさにあなたが求めていた身軽さを手に入れられるようですね。Google規模のサポートチームからLucidchartの4人チームに移行することは素晴らしいですね！

全くその通りです。

Lucidchartで拡大した今、私はあなたのサポートチームがここ数年、10人で安定していて、チケットの数は平坦に保たれていると聞きました。 小さなチームを持つことがあなたのサポート戦略にどのような役割を果たしていますか？

私の戦略は、私たちのチームが測定できる豊富なコンテンツを提供することに本当に焦点を当てています。 私は、ATMの例を常に使って、このことを説明しています：銀行の通常営業時間中に行くと、次の質問に直面します。銀行に入って、列に並んで、質問をするのが良いのか？ それともATMで自分を助けるのが良いのでしょうか？ 通常、ATMの方です。 その比喩をテクノロジーの世界に当てはめると、Lucidchartでは、非常によく書かれたヘルプセンターの記事は、ユーザーが求めている90%のことについて、十分であるだけでなく、実際には好ましいと考えています。

その上、ヘルプセンターは多くの異なるものに対する需要を測定するための素晴らしい方法です。 もし特定のトピックに関する記事に数万人が訪れていることを示すことができれば、その情報をエンジニアリングに提供し、実際の顧客データに基づいた変更を求めることができます。 ユーザーがサポートチームにメールを送信すると、ボリュームははるかに少なくなり、エンジニアリングチームに提示する際にデータはあまりアクションを起こしにくいです。 たとえ15人のユーザーが機能を求めてメールを送っていても、何千人ものユーザーがその機能に関連するヘルプセンターの記事を訪れていることを示すことができています。

二つ目のポイントは、私たちのヘルプセンターのコンテンツが現在6つの異なる言語にローカライズされているため、チームによって書かれた高品質のコンテンツを提供する際にはコストがかかります。 長期コンテンツに対しては、ユーザーが自分のコンテンツを提出できるコミュニティを提供し、他のユーザーがそれを利用できるようにしています。 この概念を示すために好きな例は、LucidchartのAndroidアプリがあり、実際に数千種類の異なるAndroid電話がありますので、特定の電話が当社のソフトウェアとどのように相互作用するかに関して問題があるユーザーは、それにアクセスすることができる可能性は非常に低いです。 しかし、私たちの1,500万人のユーザーのうちの誰かがその電話を持っている可能性が高く、同じ問題を経験しているかもしれません。 そのため、私たちの役割は、ユーザー同士をつなぐことが時々あります。

そして、それを見るのは本当に素晴らしいです。私たちのヘルプセンターやコミュニティのトラフィックは実際にユーザーベースの成長を超えています。 あなたの指摘に関して、過去3年間で製品サポートのチケット数は本質的に平坦に保たれています。 これは、ユーザーが実際にこのセルフヘルプモデルを楽しんでいることを意味していると私は思います。

オンラインコミュニティに関して、知識を提供し、他のユーザーを助けているのはどのような人々なのか、何かアイデアはありますか？ あなたの製品について知らない人々を助けるために、自分の時間を使っている人々について考えるのはクールなコンセプトです。

私たちのコミュニティはまだ進行中です - ユーザーが質問をしてくることが多いですが、私たちがその応答を提供し、その後他のユーザーもその答えから利益を得ることができます。 しかし、ますます多くのユーザーが登場し、回答を提供するようになっており、これは私たちの目的にとって最良のシナリオです。

なぜそうなのかという質問に答えると、非常に情熱を持った製品が世界に非常に少なく、私はLucidchartとしてまさにそのカテゴリーに該当する製品に取り組むことができたことは幸運なことです。 なぜなら、私たちの製品がユーザーのニーズと一致しないときでさえ、彼らは通常、使用するのに非常に困難な回避策を通じてそれを続行することを選択します。

この情熱の一例は、実際にLucidchartのiPhoneアプリを日常のカレンダーとして設定したユーザーです。 これは、私たちのチームが決して想像しなかった使用例ですが、なぜかこのユーザーは私たちのソリューションがGoogleやAppleのカレンダーよりも優れていると決定し、私たちがその使用例を全くターゲットにしていないにもかかわらず、それを機能させるために特に努力しました。

したがって、そうした考え方を考慮すると、ユーザーがやろうとしていることの多くは、私たちの製品の提供する限界を押し広げることです。 他の人を助けたり、自分の使用例を共有したりすることで、彼らの情熱を燃やします。 彼らはこの製品を愛していて、他の人とその情熱を共有したいと思っています。

それは素晴らしいです。 あなたのチームはこれらのユーザーアイデアや提出をどのように把握していますか？

私たちのコミュニティ内には、あなたのダイアグラムを共有するセクションがあります；私たちはユーザーがどのように当社の製品を新しい方法で利用しているかについてお聞きしたいです。 これが、私たちがこれらの使用例の一部を聞く方法の一つです。 もっと一般的な方法は、私たちのチームが依然としてメールに回答することに非常に関与しているということです。 チケットの数は平坦ですが、週に約600件の製品関連のサポートメールを受け取っています。 そうすると、ユーザーが私たちに連絡し、「これは私がやろうとしていることですが、こんな障害に直面しました。私のドキュメントを見てこの問題を手伝ってくれませんか？」というようなことになります。 彼らが助けを求めているドキュメントの多くは、私たちのテンプレートのかなり直線的な使用ですが、他の時には製品の非常に革新的な使用例が見られ、その場合、私たちはしばしば彼らにコミュニティの中でそれを投稿して他のユーザーも利益を得られるように尋ねます。 しばしば、彼らが助けを求める文書は私たちのテンプレートのかなり簡単な使い方ですが、他の時には私たちの製品の非常に革新的な使用事例が見られ、それらの場合には、他のユーザーがそれを利用できるようにコミュニティに投稿してもらえないか尋ねることがよくあります。

そのように入ってくる革新的なアイデアが製品に戻ることはありますか？ 内側でその仕事をどのように共有しますか？

私たちは顧客成功チームやソリューションエンジニアリングチームと協力して、顧客の声の報告書を作成し、全顧客からの機能リクエストをまとめています。 テンプレートリクエストの場合、私たちは新しいユーザー生成アイデアを提出する製品テンプレートチームがあります。 そのチームは、提出物について独自の調査を行い、製品に公式のテンプレートを追加する可能性を評価します。 私たちのヘルプセンター内にはテンプレートギャラリーがあり、いくつかのユーザーによって作成されたコンテンツがそこに含まれており、その方法で見つけることができます。

私たちの長期的なビジョンは、ヘルプセンターとコミュニティが組み合わさって、ユーザーが壊れたときだけに訪れる場所ではなく、インスピレーションやプロアクティブな支援のための場所になることです。 ユーザーが通常の業界の基準を超えて、その認識を超えてより良い結果を得られるようにしたいです。

あなたはあなたの会社と顧客の間に二方向の通路を想像しているようですね。

全くその通りです。

それはLucidのコアバリューを思い出させます：エゴよりチームワーク、すべてのことにおける革新、個人の権限、主導権、所有権、そして各分野での情熱と卓越性。 二方向の通路を作ることは、それらの多くに関連しています。 あなたはCXアプローチにおいてこれらのコアバリューをどのように具現化していますか？

企業全体のレベルで設定されたこのコアバリューは、私たちが会社の顧客および外向きの側にいるため、特に私たちに当てはまるという点でクールです。 それを超えて、これらのコアバリューは、会社のキックオフや更新のたびに強調しています。 年に一度、会社全体のリトリートを行い、3日間オフを取って、Zion National ParkやBear Lakeに行き、チームビルディングを行って、来る年の戦略に焦点を当てると共に、初めてリトリートに参加する新しい人たちに私たちのコアバリューを再確認します。

それを聞くのは素晴らしいです。 私たちもGuruでのすべての活動において、コアバリューを体現しようとしています。

それで、あなたのチームはプロアクティブな顧客教育にどのように取り組んでいますか？ CXチームのプロアクティブとリアクティブの側面の内訳はどのようになっていますか？

リアクティブな部分から始めましょう。これは、私たちが現在非常に上手に行っていることだと思います。 ユーザーが製品内でやろうとしていることが分かっていて、彼らがヘルプセンターやコミュニティにそれを探しに来た場合、私たちは必要なコンテンツを提供し、通常、成功のためにセットアップされていることを確認するために動画やスクリーンショットを追加します。

私たちが目指しているモデルは、単に何かを行う方法を教えるだけでなく、なぜその方法で行うべきかを伝えるプロアクティブなモデルです。 ユーザーがヘルプセンターにやってきて、他の手段や信号を通じて私たちが彼らが生物学の教師であることを知った場合、 私たちは、その教師を目的にしたコンテンツに案内したいと考えています。それは、彼らが求めることを行う手順を示すだけでなく、実際にそれを行うためにどのテンプレートを使うべきかを示すものです。 私たちの専門チーム – この例では教育チーム – は、より良い情報豊富な使用例を提供するために取り組んでいます。

したがって、顧客が特定の機能の使用方法について読んでいる場合、他のユーザーがその機能を使用したときの製品信号を捉えることができ、顧客にその情報と、類似のユーザーが使用した他の機能を提供することができます。 それで、このコンセプトをヘルプセンターに持ち込むと、「わかりました。あなたはプレゼンテーションについての記事を読んだばかりです。 今、あなたはレイヤーや異なるレイヤーの表示と非表示についてのこの記事を読むべきです。なぜなら、私たちはそれら2つの機能が製品内で一緒に機能することを知っています」となります。 それが、私たちが達成しようとしていることの一部です。

この戦略を目標にどのように形式化しますか？ あなたの目標は、チケット数を平坦に保ち、初回応答時間を短縮することを超えるように思えます。

私たちのサポートメトリクスの「聖杯」は、ユーザーがヘルプセンターで何をしたかと、彼らが製品で何をするかを結びつけることです。 特定の記事、データリンクについて見ているとき、私たちは目標を持ちたいのです：その記事を読んだ1000人のユーザーのうち、700人がその後製品に入り、データリンク機能を使用しています。 最近では、ヘルプセンターの利用を製品の利用に結びつけることができました。 それによって、私たちはそこから逸脱し、ヘルプセンターの利用と製品の利用の相関関係を見つけることができます。

それが、私たちが達成しようとしていることの本質だと思います：製品の使用を増やすことです。 その後、ユーザー保持の価値を付けることができます。 私たちは、ヘルプセンターを訪れた1000人のユーザーと訪れなかった1000人を比較して、保持率がこのパーセンテージ上昇したと言えます。なぜなら、私たちは彼らに貴重なことを教えたからです。 あるいは、保持を超えて、彼らのエンゲージメント率が上がったかどうかも調査します。

それが好きです。 最近、数人のCXリーダーと話をしましたが、サポートがコストセンターではなく収益源であるというテーマが繰り返し取り上げられています。 サポートがコストをかけるだけでなく収益を生み出すというモデルを支持しているようですね？

もちろんですが、私たちのチームはそれをさらに超えています。 多くの場合、ユーザーが私たちに連絡してきて、「ねぇ、Lucidchartの利用が好きだけど、ドキュメントインポートに問題がある」と言います。 私たちのインポートされたドキュメントはおかしく見えます。 この問題を解決できれば、私たちは会社でのLucidchartの使用を拡大できるでしょう。」 だから、私たちはサポートの問題を手助けし、次にそれを営業チームに引き渡します。

「昨年、サポートは実際には当社の販売リードの第3の大きな源でした。 このサポートチャンネルからの収益の量を見ると、チームの給与をはるかに上回っています。 だから私たちは全くコストセンターではないのです。」

それは非常に印象的です！ あなたのチームは他にどのような指標を追跡していますか？ 他のサポートリーダーがあなたのモデルを尊敬している場合、どの指標を追跡することをお勧めしますか？

私たちが自負していることの一つは、ヘルプセンターとコミュニティサイトの成長の速さです – いわゆる拡張サポート – です。一対一のサポート、つまりメール、電話、チャットサポートと比較すると。

一対一のサポートの成長を測る一つの方法は、ユーザーベースあたりのメールの数を見ることです。 だから、私たちはユーザーベースがどれだけ速く成長しているかを追跡し、各サポートプラットフォームの成長の速さを追跡し、そしてそれを互いに正規化して、製品の10,000人のアクティブユーザーあたり送信されるメールの数を調べます。 対照的に、製品の10,000人のアクティブユーザーあたり、どれだけのヘルプセンターページビューがあるかです。

一対一のサポート側を見ると、それはもっと伝統的です：初回応答時間、顧客満足度、そして私たちがユーザーの待機時間と呼んでいるもので、これはチケットが提出されてから解決されるまでの時間で、顧客がさらなる情報を提供するのを待っている時間を差し引いています。

拡張サポートを見ると、一対一のサポートとは少し異なります。 それで、拡張サポートを使用しているユーザーは、製品内で何をしていますか？ 彼らの7日間のリテンション率は、30日間のリテンション率と、ヘルプセンターを使用していない人のリテンション率とどう違いますか？ そしてそれを収益に結びつけることもできます。 ヘルプセンターを訪問している人たちは、より多くのアップグレードをする傾向がありますか？ アカウントのユーザー数を拡大する傾向がありますか？ それが私たちが追跡している主要な指標だと言えますが、これは非常に進行中の作業です。

あなたは以前、ヘルプセンターの特定の記事がどのくらい使われるかを調査し、そのデータが今後の製品の決定に影響を与えることについて言及しました。 それは、私たちがGuruで行っていることの一部に関係しています。知識、あなたのヘルプセンターを通じて収集するデータや知識が戦略にどのように影響を与えると思いますか？

素晴らしい質問です。 私たちは常に、一対一のサポートが私たちの拡張サポートに影響を与えると言っています。 コミュニティでトピックが盛り上がっているのを見たら、ユーザーがコミュニティに投稿して何かのやり方を知りたがっていることに気づいたとき、それが多くのページビューを得ているなら、それをヘルプセンターの記事にアップグレードし、それにさらに多くのトラフィックをもたらすようにローカライズします。 それから、チケットのボリュームを見ると、同じことが言えます。 もし製品を操作する方法について多くのメールが寄せられたら、そのメールを見て、「さぁ、これはコミュニティ投稿にする方が合理的か、ヘルプセンターの記事にする方が良いか？」と考えます。 だから、これは段階的なプロセスです。何かについて多くのメールを受け取ったとき、それはコミュニティ投稿に進級します。 それが多くのトラフィックを得た場合、今度はヘルプセンターの記事に進級します。

そして、私たちが何をしているかの成功を測ることができます。 このヘルプセンターの記事を作成すると、どのタイプのチケットが減少したかを確認し、拡張サポートにより多くのトラフィックを送信することで、何ができるかを確認できます。

最後の要素はページビューに関するものです。 私たちにとってページビューは、メールボリュームの代わりにもなります。 もしコミュニティ投稿が機能リクエストであれば、その投稿のエンゲージメントやページビューを示し、そのデータをエンジニアリングチームに提供できます。「ねぇ、これには需要があります。 これを製品のロードマップに載せましょう。」

あなたのように組織のスケールを目指すサポートリーダーへの最後のアドバイスはありますか？

他にも、人材を採用し、維持する方法に関するアドバイスがあります。 多くのサポート組織は、保持が非常に低いという大きな課題を抱えています。 私たちが成功している理由の一つは、私たちのチームの保持率が非常に高いことです。 過去18ヶ月間、私のチームのメンバーは1人しか移行していません、それはこの分野では珍しいことです。 そして、過去3年半で私のチームを離れた個人は、全員がLucidに残り、他の部門に移り、取得したユーザーインサイトを他の会社の部門に提供しています。 しかし、私は、サポート組織の人々に最高レベルの戦略を本当に所有させるなら、ただメールを処理するだけでなく、電話を扱うことに取り組むことは、彼らに力を与え、彼らが他の領域に移行できるスキルを構築する手助けをします。

私が繰り返し述べたいことは、可能な限り多くの戦略にチームを含めることです。最終的には、それが彼らを興奮させ、情熱を持ち、成長させることになると思います。

素晴らしい結びの言葉ですね。 お時間をいただきありがとうございます、Keyvan！ 読者があなたのサポート哲学やLucidchartについて質問がある場合、どのように連絡を取ればよいですか？

私にLinkedInでつながることができます。