Autifyにおけるカスタマーサクセスツールの導入とデータドリブンな日々の活動が軌道に乗るまでの物語（前編）

こんにちは！ カスタマーサクセスエンジニアの堀です。

2020年8月にAutify二人目のカスタマーサクセスエンジニアとして入社以来、お客様のご利用状況をもとに活動するための基盤の整備を進めてきました。

Autify入社前はSIerの客先常駐SEで、特定のお客様から求められる内容に応じ、あるときはプロジェクトのリード、あるときは障害対応など臨機応変に動く職務を担っており、幅広いお客様を対象としたSaaSのカスタマーサクセスは未経験でした。

求められる職務の幅広さには共通点もありましたが、リアクティブな対応が中心だった前職と比べ、先手を打つことが求められるカスタマーサクセスではときに真逆のマインドセットが求められたため、戸惑うことも多々ありました。

当記事では、そんなカスタマーサクセス一年生がカスタマーサクセスツールを導入し、日々の活動を軌道に乗せるまでの試行錯誤の前編をご紹介します。

ことの始まり

AutifyのCSチームには

• カスタマーサポートエンジニア
• カスタマーサクセスエンジニア

の二種類の職種があります。前者は主にお客様からのお問い合わせを起点にした「守り」のサポート、後者はAutify側からのお客様のご利用状況確認を起点とした「攻め」のアプローチをメインの職務とする違いがあります。 ただし入社後のオンボーディングでは、いずれの職種もお客様からいただくチャットでのお問い合わせを主として対応するところから入ります。多くのお問い合わせに触れることでプロダクトの理解やお客様がどのようにAutifyを利用されるかの理解が進むため、これはとても効果的かつ不可欠なプロセスだと感じています。

さて、数ヶ月のオンボーディング期間が終わると、カスタマーサクセスエンジニアはいよいよサクセス業務に携わることになります。言うまでもなく、Autifyは自動テストのためのプラットフォームを提供していますから、ご利用を成功に導くためにはお客様毎のテストの実行状況を知ることが不可欠です。しかし、早速ここで私は多くの疑問に直面しました。

1. 多くのお客様がいらっしゃる中、限られた時間で、特にどのような状況の方々に目を配る必要があるのか？
2. いかにしてお客様のコンテキストを把握し、何を目的に、どのようなアクションを取ればよいのか？
3. 自分の行動と、お客様の変化をどうやって追跡したらよいのか？

これらについて、順に見ていきましょう。

まず 1. については、Autifyをうまくご利用いただけているかの重要な手がかりとなる

• テストの実行が多い/少ない
• テストの失敗率が高い/低い

といったお客様毎の情報は、プロダクトのデータベースの情報をもとに、既にある程度まで可視化されていました。しかしながら、どのくらいの数字だと注意を要するのかの肌感覚がまだ十分に養われていない自分は、既に延べ200を超えていたお客様の情報量に、それだけで圧倒されてしまうのが実情でした。

続いて 2. については、順調にご利用いただいているお客様にいっそうの活用を促すような選択肢をご提示したり、逆にご利用につまずきがありそうなお客様にアドバイスをしたりする必要性があるのは理解していたものの、欲しいコンテキストの情報にアクセスしづらい背景がありました。たとえば、前者であればご契約プランの推移、後者であれば過去にどのような問い合わせをいただいていたか（あるいは、いただいていなかったか）などを把握したいところですが、情報が複数のツール散在しており横断的に把握するのには労力がかかりました。

最後の 3. は、ずばり効果測定に役立つ部分です。お客様に対して何らかのアクションを取ったとして、何か良い変化をもたらせたかどうかは、今後同様のアクションを取っていくかどうかを判断する上でも重要です。けれども当時は、お客様の変化はおろか、「いつ誰にどのようなアプローチをした」の記録自体も一つのところに蓄積できておらず、場当たり的な対応をしてしまっていました。

「お客様へのアプローチの勘所は、一体どうやったら身につくのだろう？ カスタマーサクセスムズカシイ…」

率直に申し上げて、この頃の私は情報の多さに戸惑いながらうまく動くことができず、引っ込み思案に陥っていたといえます。

その頃、同時に検討が進んでいたのがカスタマーサクセスツールの導入でした。

ツールに期待されたもの

もちろん、ツールも万能ではありません。しかしながら、以下のようなことが実現できると前述の課題に対処できそうに感じられました。

📈 お客様の数とCSチームの成長に応じた「スケーラビリティ」

• お客様の数や対応にあたるチームメンバーが増えてもデータ量に圧倒されることなく、特に注目すべきお客様に関してアラートを上げるなど少ない労力で割り出せるようにする
• 自動化できるワークフローは自動化することで、本来注力したいお客様のケアに手を割けるようにする＝人が人にしかできない創造的な仕事に集中できるようにする（おや、どこかで聞いたことがあるようなフレーズです）

🔎 観測情報を一箇所に集めた「オブザーバビリティ」

• 多様なツールに散らばったプロダクト利用情報・契約情報・お問い合わせ情報を、お客様毎に対応づけた形で一箇所で見られるようにする
• 集約した情報をもとにお客様のヘルススコアを算出し、値の変遷を時系列で観測できるようにする

📝 自分たちの行動と、顧客の変化を記録する「トレーサビリティ」

• どのお客様にどのようなアクションを取ったかを記録し、それに応じた顧客の変化を追えるようにする
• ひいては、仮説に基づく行動をとった上で、結果を定量的に見返せるようにする

果たして、カスタマーサクセスツールの導入によって上記のようなことが実現できるようになるのか？ 期待と不安を胸に、ささやかなプロジェクトが始動します。

ツールの選定と構築の過程

選定にあたっては国内外の複数のツールを検討しましたが、将来的にUSのカスタマーサクセスチームが使うことも考慮し、英語のUIを持つことを条件の一つしました。前述の要件を念頭に複数社と会話した結果、ツールの機能面では大きな差異はなかったものの、構築過程やオンボーディングでしっかりサポートが得られそうなChurnZeroに決定しました。

データの特定とマッピング

導入の最初のステップとなったのは、ツールに対して投入するデータの決定です。これは以下のようなステップで行いました。

1. ヘルススコアの決定やアラート通知に必要となる指標から項目を決定
2. 上記 1. で洗い出された項目を実データ項目とマッピング

はじめの 1. については、カスタマーサクセスリードの佐藤が「どのような場合でヘルススコアを上下させるか」「どのような時にアラート通知をとばすか」の条件をくまなくまとめてくれていました。これのおかげで、取得が必要な項目の特定と 2. の作業をスムーズに進めることができました。もちろん、作業の過程で全ての項目が既存のデータから取得できるわけではないことは明らかになるのですが、まずは取れる項目から着実に取得していくことが大事だと感じました。

実装

また、私たちが必要としていたお客様のデータは、以下の複数のプラットフォームに散在していました。

• 契約情報：Airtable
• プロダクト利用状況：PostgreSQLのデータベース
• お客様からのお問い合わせ：Intercom

上記の各々から個別にデータを取得してChurnZeroへ連携する方法もありえましたが、奇しくも同じ頃、これらのデータソースからの情報を統合分析可能にする社内データ分析用データウェアハウスの構築がデータエンジニア主導で進められていました。（社内データ分析についても、ぜひ別の機会に触れられればと思います！）それならば、データウェアハウスのデータを直接参照してカスタマーサクセスツールに投入するのがスムーズなのではないか？ という方針をCTOに打診して承認をもらい、データエンジニアの協力を得ながらデータウェアハウス（Redshift）に対するクエリを組み、バッチ（Lambda）を書いてデプロイし、日次でChurnZeroへデータをアップロードする仕組みを仕上げました。

日次のデータがChurnZeroに入るようになってもしばらくは、データの妥当性を確認しながらクエリに手を入れてはデプロイを繰り返しましたが、時系列でお客様のデータの変遷を追えるようになったことになんともワクワクしましたし、実装レベルで主体的にトライアルエラーが繰り返せるのはカスタマーサクセスエンジニアならではかもしれません。

さあ、これで舞台は整いました。投入されたデータがどのように可視化され、どのようなアクションが展開できるようになるのでしょうか？

このカスタマーサクセスツールを活用し、私たちの活動をどのように軌道に乗せたかの内容については、当記事の後編に譲ります。本稿にご興味をいただけた方は、ぜひ続編をお待ちいただければ幸いです！