カスタマーサポートの機能を整理する

カスタマーサポート Ops

カスタマーサポートの機能について自分なりの考えを整理してみたので、備忘録として残しておく。以下、カスタマーサポート＝SP、カスタマーサクセス＝CSとする。

SPのアウトカム

  • プロダクトをストレスなく活用できるようにする
  • そのために、ユーザーが機能面で戸惑ったときに支援をする／ニーズを吸い上げて新規機能開発の起点となる

※ 問合せに回答するのは手段でしかない

SPの機能

  • ①すでにできることをできるようにする
  • ②まだできないことをできるようにする
  • ③上記2点の機能を最適化する

※SPの領域を機能＝技術仕様に限定して、CSは目的＝活用方法の模索を取り扱う形が1つの考え方。CSにエクスパンションの役割を担わせるのであれば、CSはBiz側／SPはDev側で切り分けるこのやり方は妥当に思う。どう分けるかは目的次第。

改善に向けた検討の観点

①すでにできることをできるようにする

  • 問合せから回答までの業務フローは以下の通り。とにかく早く回答するのはもちろん、できれば今後発生しうる問題も予防しておくのがポイント。
    すでにできる場合の業務フロー

1）問合せを発生させない

  • そもそも問合せが発生するのはプロダクトが使いにくいからであり、ストレスなく活用してもらうには問合せを撲滅する努力が必要である。
  • 根本解決するには、プロダクトにわかりにくい／誤解を招くものを残さない。ユーザー視点での体験設計が重要となる。
  • 仮にわからないことがあったとしても、ユーザーが自己解決できるようにする。静的＝サポートページを充実させる、動的＝チャットボットで対応する、そしてそこまでの導線をわかりやすくする。

2）問合せ内容を明確にする

  • 問合せ内容の詳細を確かめるためにコミュニケーションをするのは、ユーザーにとって手間なこと。一方で、詳細の確認には詳細な情報が必要になる。
  • そこで、問合せ内容をフォーマット化や注意書きをすることによって、ユーザーからもう少しリッチな情報を出してもらうのは1つの方法となる。
  • ただし、上記はユーザーに負荷をかけることになるので、システムログから操作環境を特定したり、別システムから顧客情報を取得するなど、補完情報を取得するやり方がある。

3）回答精査のコストを削減する

  • 自分でわかっているから回答できる（自力）、確認すれば回答できる（セルフサービス）、相談すれば回答できる（SPチーム／Devとの協力）、の3つの方法があり、前のものほど望ましい。
  • 自力：既存機能の理解と新規機能のキャッチアップが必要になる。前者はアサイン時のオンボーディングでの対応、OJTでの対応、日常のナレッジ共有で対応できる。後者は開発時のQAに参加したり機能共有の場を設けるほか、開発に関与するのも役に立つ。
  • セルフサービス：過去の回答履歴の蓄積、ドキュメントの整備などで対応できる。
  • SPチーム／Devとの協力：相談する際のフローやツールが最適化できるとよい。また、個別事案が蓄積されてセルフサービスの情報源とするのも想定しておく。これもなるべくなくす方向で取り組むのが重要である。

4）問合せを予防する

  • 問合せをもらっていた内容そのものに回答することはもちろん、過去の対応履歴からここで疑問を抱くとその後ここで疑問が発生しやすいというのを踏まえて、先回りした助言を入れておく。
  • 予防の観点に関わらず、補足情報を合わせてお知らせするのは顧客体験にとってはよいことである。
  • また、作業代行は原則してはいけない。ユーザーの利用能力を伸ばすのが基本の考え方となる。

②まだできないことをできるようにする

  • 問合せから回答までの業務フローは以下の通り。基本対応としては、一次回答として代替案を提示し、中長期的には機能開発を進める。このとき、スケールするかの観点から個社対応は受けないこともあるので、返答の際には期待値のコントロールが重要になる。
    まだできない場合の業務フロー

1）顧客要望の開発要件への読み替え

  • 顧客の問合せ／要望は言葉のままに受け取らず、何が目的で、それはマクロにみたときにどれだけのインパクトがあるのかを考える。
  • SPのみで進められる話ではないので、どこまでをSPで対応するかは組織内での文脈次第になる。

2）開発効率化への寄与

  • 開発を進めていくにあたって発生した不確実性について、場合によっては問合せのあった顧客も巻き込みながら解消に努める。
  • こちらもどこまでやるかは文脈次第ではある。

3）開発完了の報告

  • 問合せ進捗と開発進捗は別管理されていることが多いので、完了した開発課題がどの問合せに紐づいているのかを特定して報告する。

③上記2点の役割を最適化する

  • 上記のような内容を業務プロセスに落とし込むために、現状の理解と打ち手の整理や実装を行う。いわゆるOpsの役割となる。
  • 業務フローを回すことでデータが自然と生成されるような仕組みを作る。なるべくシステムから拾えるデータはシステムから拾い入力負荷を軽減する。仮に負荷がかかる場合には、コストに対するリターンを正しく提示する。
  • 業務フロー上で生成されたデータを蓄積し、現状のプロセスの理解や打ち手の検討に使えるようにする。
  • システム内部にストックされたデータを、人間の認知負荷を補完するようにチャットツールなどのコミュニケーションフローに落とし込む。
  • 業務プロセスを適切に回せるようにするため、個々人の能力の底上げを行う。いわゆるイネーブルメントの領域。
  • 原則、運用メンバーは認知負荷を軽減するためインターフェイスは限定するため、裏の仕組みはブラックボックスになりやすい。負債化しないように、複数人で運用できる体制やドキュメントを残しておく。
  • 運用とOpsをジョブレベルで切り分けるのは、もちろんグロースするプロダクトでスケールする体制を整備するのもあるが、フォーカスするイシューを短期と中長期で切り分けて、自然と中長期のイシューにリソースを配分できるようにするためであるとも思った。