maximum80の日記

「Empower Engineering!」をテーマに自立自走エンジニア組織によって日本を元気にするため日々奔走している事業家のブログ

Customer Reliability Engineering実践 ~顧客を成功に導くカスタマーサクセスオートメーションの構築~

新田です。

弊社では現在プログラミングスキルチェックツールtrackというプロダクトを2018年3月にリリースしたのですが、それと同時に、本格的にカスタマーサクセスチームを立ち上げました。

(正直右も左もわからなかったので、皆さんが読破している青本や、馬田さんの記事を読みながら手取り足取り。。。)

本日はその中で、より技術的な観点から顧客を成功に導くCREチームに関する紹介と、弊社が実際に実践しているカスタマーサクセスマネジメントのオートメーション手法について、ご紹介したいとおもいます。

trackにおけるCREについて

そもそもCREとは

「カスタマーサクセス」という職種は日本国内にも徐々に浸透しつつあるかと思いますが、CREという言葉はまだ馴染みがない方が多いかもしれません。

そもそもCREとは、Customer Reliability Engineering(顧客信頼性エンジニアリング)の略で、Googleが2016年に提唱したばかりの新しい職種です。

Google の新しい専門職 : CRE が必要な理由

日本国内においては、はてな社やミクシィ社、メルカリ社がこの職種の募集を始めたりしています。

セールスエンジニア 改め Customer Reliability Engineer (CRE) になりました

新卒でCustomer Reliability Engineer(CRE)というキャリアを選んだ理由(+`・д・)≡○

CREチーム始めました

これらの記事を読めば、なんとなくCREという仕事について理解ができるのではないかと思います。

詳細は割愛しますが、簡潔に説明すると、

「セールスエンジニア・テクニカルサポート」×「カスタマーサクセス」

というようなイメージです。

f:id:maximum80:20190117174121p:plain
Customer Reliability Engineerのイメージ

技術的な視点やソリューションによって、顧客と自社製品の信頼を構築するというミッションを達成するお仕事です。

trackのCREの職務範囲

弊社ではカスタマーサクセスチーム内に、CSMチームとCREチームを設けております。 顧客のフロントとしてプロダクトの導入、成功までの支援をするCustomer Success Managementチームと、よりテックタッチにオートメーションや分析、開発チームと連携しプロダクトを改善することで顧客からの信頼を得るCustomer Reliability Engineeringチームです。

f:id:maximum80:20190117174219p:plain
弊社のカスタマーサクセスチームの職務範囲イメージ

弊社(track)のCREの独自な職責としては、 「プログラミング教材、試験問題の開発や導入支援」 を担っている点です。 顧客がエンジニア向けのHRを実施する企業人事、あるいはエンジニアマネージャの方になりますので、そのような方々に、ただプロダクトの導入を支援するだけではなく、組織に最適なプログラミング問題や教材の提案をすることで、社内のエンジニアのHR基盤を構築支援する仕事があります。

また、お陰様でこの一年間でお客様が100社以上増加しました。 メンバーはそれほど増えていませんので(もちろん採用はしていますが)、手厚く1社1社ハイタッチなサポートだけではなく、お客様の利用状況や心理状況を正確に把握し、必要なときに必要な支援を Just In Time に実施するためのオートメーション基盤を構築する必要があります。

今日は、実際にカスタマーサクセスチームを持たれている他のSaaS企業様にも少しでも参考になればと、弊社が実施している カスタマーサクセスオートメーション のツールや施策についてご紹介させていただきます。

trackのカスタマーサクセスオートメーションツールの全体マップとそれぞれのツール紹介

全体像

f:id:maximum80:20190117174323p:plain
カスタマーサクセスツールマップ

こちらが全体のツールマップです。水色で囲われている部分が、普段カスタマーサクセスチームが利用しているツールとなります。 (※すみません、Slackは全部と連携していてビジュアル化するのが難しいので省きました。。。)

これからSaaS系のサービスでCSツールを整えていきたいと考えているCS担当の方に、少しでも参考になれば幸いです。

ごちゃごちゃしているかもしれませんが、ロゴの上にそれぞれのツールの利用目的を記載しており、矢印はツール間で連携している内容を記載しています。(お気づきの方もいらっしゃるかと思いますが、一部まだ願望も含まれています。)

それぞれのツールをどのように利用しているのかについて、これから説明していきます。

1, Intercom ~チャット・通知・ヘルプデスク~

皆さんご存知のIntercomを弊社でも導入しました。 以前のサービスでは、Zopim(現Zendesk Chat)を利用していたのですが、Intercomに乗り換えることにしました。Intercomに乗り換えた理由は

  1. ヘルプデスクも一貫して管理することができる
  2. チャットとメール送信の連携に優れている

という2点です。 Zendeskでは現在どうできるか、正直把握はしていないのですが、チャットウィンドウとヘルプデスクを一括して管理することができる点で、Intercomはとても優れているように感じています。ヘルプデスクも「サイトマップ型(検索)」ではなく、「カスタマージャーニー型(発見)」で設計ができるため、プロダクトの内部グロースと連携した形でポップアップを出したり、情報を提供することができることが魅力なのではないかと思います。

またIntercomでは、いちいち顧客のセッションが切れたとき(オフラインの状態)に、メールで返答をするのではなく、チャットから返答すれば顧客にメールが送られます。それに対して仮に顧客がメールで返信したとしても、チャットに通知やメッセージ内容が届くようになっています。(地味だけどこれが一番大きいかも)

2, Salesmachine ~カスタマーヘルスチェック~

弊社では、導入したお客様のカスタマージャーニーをStage毎に分解し、それぞれにおけるカスタマーヘルスを可視化しています。

このツール導入の目的は、お客様を契約内容やカスタマージャーニー毎のヘルスチェックを実施することで、今何がボトルネックかをすぐに導き出したり、アクションを起こさなければならないお客様を瞬時に把握することをです。

また、Intercomとの連携がめちゃくちゃ優れていたので、このツールを選びました。 お客様のセッション情報や、会話のログ、全てをアカウントベースで一元管理することができます。

f:id:maximum80:20190117183457p:plain
ステージ毎の顧客のヘルス状況一覧のイメージ

まず、お客様がサービスアカウントを開通するとアカウント情報が登録され、「Pre-sales」というStageに分類されます。そこから契約が完了すると「Onboarding」に振り分けられ、CSM担当者が「オンボーディングアクション」を完了し、顧客が最低限サービスを利用すると、次の「training」Stageに移動し、契約満了期間が迫ってくると「Retantion」Stageに移動する、といった具合です。

f:id:maximum80:20190117185901p:plain
Stageが変更されるとSlackに通知が届く(契約更新の通知)

Stageの移動は「顧客の利用率」によって基本的には変更されるように設定されています。 利用状況のデータは、専用のAPIサーバからデイリーでバッチ処理をすることで毎朝Salesmachineに更新されたデータを流し込んでおり、利用状況の変動に応じてStageが移動される仕組みになっています。

Salesmachineではアカウント毎に保管するデータを成形したり、Stageの作成やその条件(特定のデータがX以上になる等)を設定することができるので、全部社内でカスタマージャーニーを書いてカスタマイズしました。

f:id:maximum80:20190117183543p:plain
ヘルス定義の例)利用カウントが0で試験があるというフラグがFalseだとBADヘルスになる

おそらく、このツールは知らない方のほうが多いのではないかと思います。(セールスマネージャの方に聞いてみたら日本での導入企業はまだ殆どないとのこと。)

日本では最近 Hi-Customerという類似サービスが出ていますが、私達がCSチームを立ち上げたときにはまだリリースされていなかったこともあり、こちらの製品を使っています。 日本語対応を気にしていない企業様は、機能的な観点や金額的な観点でもSalesmachineをおすすめしますが、Hi-customerでも十分なのかな。(使ったこと無いのでわかりません。)

その他のツール

Jira ~チケット管理~

主に、プロダクトマネジャーとの連携で利用しています。 お客様からの改善要望をバックログとしてチケット登録をしたり、新しい機能要件のためのエピックやユーザストーリーを書いた上で、ガントチャートとしてスケジュール管理をしています。

「なぜGitHubではないのですか?」という質問に対しては、弊社のプロダクトはリポジトリを複数にまたがるため、開発者は自分が関わっているリポジトリしか閲覧しないようになってるためです。 Jiraに課題チケットを集約させて、開発者にはGitHubでどのように修正するかのissueをつくり、それらがリリースされるとJiraのチケットが更新されるようになっています。

SurveyMonkey ~NPSトラッキング~

ツール内にNPSを埋め込むときに利用しました。特になぜこのサービスなのかの深い意味はないです。 最近はSatisMeterというサービスのほうが気になっています。

Redash ~ダッシュボード・データ検索~

不具合の際に、データベースの情報を参照したり、Administration用のアプリケーションでは調べることのできないデータを調べたりする際にRedashを利用しています。

DataStadio ~ダッシュボード・データ検索~

Redashと同様、毎日どのぐらいの顧客が利用しているかなどのデータをグラフ化して分析するために使っています。「ふーん、なるほど」程度の活用度です。

Papertrail ~ログ監視~

「不具合が起きた〜!」というような問い合わせをいただいた際などに、実際に何がおきていたのかのログを調べる目的で使っています。

オススメのインテグレーション(※イケてるなぁと感じているのをピックアップ)

「オートメーション」というからには、自動で各サービスのデータやステータスを連携して管理していきたいところですよね。今弊社が実施している最もイケてるオートメーションについてご案内します。

1, Salesmachine <-> Intercom 顧客との会話情報とヘルスを一元管理

IntercomとSalesmachineを連携すると、Intercomのユーザアカウントを企業アカウントに紐付けて、SalesmachineでStageの管理やヘルスチェックに利用することができます。

例えば、アカウント作成時にIntercomから配信をされるチュートリアル記事を既読したら、ヘルスをGoodにする、というような設定が可能になります。

f:id:maximum80:20190117184448p:plain
Intercomのデータをヘルスの条件に加える画面

また、GitHubの草のように顧客の利用、ログインステータスを閲覧することや、 アカウント(企業)毎にIntercomの担当者との会話を全てまとめて一元で管理することができます。

f:id:maximum80:20190117184250p:plain
Intercomを活用したログインセッションの可視化

f:id:maximum80:20190117184317p:plain
担当者とのIntercomでのやりとりを一元管理

めちゃくちゃ便利です。

2, Intercom <-> Jira バックログと顧客の会話を連携

Intercomを経由して、エンドユーザや顧客から「XXがうまくいきません!」というようなバグ報告や「XXが〇〇できるようになりませんか?」というような要望の問い合わせが来るとします。 これらの要件をJiraにチケットとして登録する際に、会話元を紐付けることができます。

f:id:maximum80:20190117185007p:plain
Intercomの会話をJiraにコマンドで紐付ける

その顧客の会話に紐付けられた機能がリリースされる(Jiraのステータスが変わる)と、Intercom上に通知がくる(顧客には表示されない)ので、それと同時に「以前ご要望いただいておりました◯◯がリリースされました」という報告を簡単にすることができます。

f:id:maximum80:20190117185035p:plain
Jiraのステータスが変更されると対象のチャットに通知が届く(もちろん顧客には見えない)

カスタマーサクセスオートメーション設計のPOINT

これらのオートメーションを設計する上で、CSチーム内で意識した点は以下の2点です。

1. Be bridge - 顧客から開発までの情報をシームレスにして情報の非対称性をなくすこと

お客様が製品を導入する前に、どのようなきっかけで弊社のサービスを知ったのか、セールスチームとどのような会話をしていたのか、どのような契約内容で利用を開始したのか、というようなセールスやマーケティング側が持つデータから、課題解決をする開発チームに至るまで、全てのステークホルダーが持つ情報を一つに集約すること、時差をなくすことが情報の非対称性をなくしてお客様を速やかに成功に導く上で重要なのではないかと思います。

2. Objective - 客観的なデータから「ファクト」をつかめるようにすること

打ち合わせのときの雰囲気が良かった! きっと良い印象を抱いてくれているだろう!

というような担当者の主観ではなく、NPSによる客観的な顧客からの評価や、データベースと連携したサービスの利用実態からヘルスチェックを実施することで、より正確にChurnのリスクを未然に防いだり、お客様への適切な追加施策の企画につなげることができるのではないかと思います。

最後に

長々となりましたが、弊社もカスタマーサクセスとしてチームを立ち上げてまだ1年程度です。 こういった情報を積極的に発信したり、情報交換することで業界全体を少しでも盛り上げることに貢献できれば誠に幸いです。

弊社でカスタマーサクセスとして一緒に働きませんか?

というような求人アピールオチはしません!!!!