カスタマサクセスにおいて、High Touch / Mid (Low) Touch / Tech Touchのモデルでよく下図のようなセグメント分けで説明をしているのをよくみる。
Ref. How to account for customer success
Ref. 逆説のカスタマーサクセス
この切り方だとHigh Touch / Mid Touch / Tech Touchが別のセグメントになっており、またTech Touchは手間をかけずにすることに注力している。
しかし、Tech Touchの本質ではなく、Tech Touchはチャーンやアップせるの予兆を適切なタイミングで検知し、営業やカスタマサクセスが手間をかけずに相手企業にコンタクトできるようにしてあげるものでなければ、数多くのアカウントに対して場を提供するだけの放置状態になってしまう。
そのため、Tech Touchの要素としてヘルスチェックの機構が重要な要素になっている。 プロダクトのヘルスチェックを作ることを考えると、複雑なプロダクトや複雑な顧客ペルソナであればあるほどヘルスチェックの仕組みを作るのが難しい。
たとえば、トレジャーデータの場合は提供するサービスがカスタマーデータプラットフォームであり、データを元に顧客を考えるという観点であればどの顧客も同じだが、そのやり方や目的は業種やマーケティングゴールなどによっても大きく変わってくる。
こうした複雑な顧客を理解し、適切なヘルスチェックを作るには、私たち自身もデータのプラットフォームが必要になり、手間をかけずに実現することはできない。 また、ヘルスチェックの仕組みをHigh Touchに特化したら、Tech Touchの枠組みでHigh Touchのメンバの支援もできる。 つまりTech Touchは全てのセグメントの相補的な仕組みであるはずだ。
そう考えると、従来のTech Touchの場所はLow Touchになり、Tech Touchの関係性は下図のようになる。 Tech Touchは、それぞれのセグメントに対して、ヘルスチェックだったりProduct Usageの詳細な確認だったり、カスタムのアラートだったりができる基盤が必要になる。
この基盤を実現するためには、トレジャーデータが貯める自分たちのサービスログを理解し、またトレジャーデータを扱うのが得意なサポートエンジニアのチームが一番適している。
（ちなみにData Engineerのロールがエンジニアチームにはあるが、このロールは各チームが貯めたログを分析可能な状態に整備したり、お客様の契約情報として提供すべきデータを算出したりするパイプラインを作っている。つまり、プロダクトやサービスとして顧客に提供すべきデータ整備をしている。）
Googleが提唱したCustomer Reliability Engineerと言うロールも、この中のHigh Touch向けかつさらにその中でもテクニカルなレイヤーの顧客向けに対してのロールなんじゃないかな、と勝手に想像している。
とにもかくにも、トレジャーデータ のサポートというのは従来のサポートの枠組みを超えて、昔から活動をしている。 このTech Touchのための基盤をCustomer Reliability Engineerというロールを作って取り組むかサポートエンジニアの活動の一貫として実行するかは悩みどころだが、色々やれるのでぜひトレジャーデータ のサポートエンジニアに応募してみてはいかがだろうか？
もっと話をしたいとなったらTwitter: @nora96o までお声がけください。
