この記事はモチベーションクラウドシリーズ Advent Calendar 2022 22日目の投稿です。
はじめに
私はモチベーションクラウド開発で顧客からの問い合わせを技術的に解決したりする部署に所属しています。
日々様々な問い合わせや技術的な相談が来るのですが、以前はカスタマーサポートとの距離が遠く、内容の詳細把握にも時間がかかっていました。
機能的に実現できないかの相談を受けても「できる/できない」の返事しかできず、顧客理解も進まないという状態が続いていました。
ちなみに以下画像が弊社の顧客問い合わせ対応体制です。
そんな中で、よりカスタマーサポートと協働しようと色々やってきました。
やって良かったこと４つを紹介します！
やったこと
以下を実践しました。
- 依頼ルートの統一
- 背景のヒアリング
- 判断軸の言語化
- エンジニア⇔CSのコミュニケーション
一つずつ何をやったのか書いていきます。
1. 依頼ルートの統一
なぜ必要なのか？
依頼内容の把握を個人ではなくチームでできるようにするためです。
DMで依頼が来たり対応者に電話が来たりすることがありました。
個人で請け負う判断をしなければいけない状態は健全ではないですよね。
どんなタスクを何個受けて実行しているのか、全タスクに対して見える化できることで、優先度判断や重要性の受信につながります。
実施策
依頼の経路を絞り、全てのやりとりの情報を残すようにしました。
弊社ではJIRAを使っています（導入のお話は弊社のアドベントカレンダー8日目の記事にも書いてます）
今でもCSの方から電話で質問が来ることもありますが、基本的に電話できた内容は全てCSの方にJIRAに転記してもらうようにしています。情報集約！
人の目を入れようと思えば入れれる環境を作ることで、変な握りをしそうになったら口を挟めるし、連携内容に誤りがあったら指摘をしてあげられるようになります。
慣れるまでは多少めんどくさいですが、すべての情報が探せばJIRAにあるという環境は安心にもつながるのでおすすめです。
2. 背景のヒアリング
なぜ必要なのか？
顧客・カスタマーサポート・カスタマーサクセス ・開発全員にとっての最適解を出すためです。
依頼はやって欲しいことベースで来るのですが、
依頼されたことをそのまま実施するのでは、プロダクトのルールや工数の問題でできないことも多々あります。
そんな時に別の対応策を提案するためには背景のヒアリングが必須です。
本当に顧客が満たしたい要望を最低限の工数で最適に叶えるために背景のヒアリングを必ずしました。
実施策
これは簡単、JIRAの依頼フォームに「背景」記入欄を加え、記入必須にしました。
ただ、「顧客が分析に使うため」みたいな表面的な理由を記載される場合もあるので、
そういう時は追いヒアリングをかけます。
つまずきポイント
これは結構驚きだったんですが、カスタマーサポートなども顧客の依頼の背景を理解していないことがまあまあ多かったです。
つまり、顧客とカスタマーサポートも仕事の受け渡しのみしていることがあったんです。
そんな関係を止めてあげるのも私たちの仕事だと自己定義をし、めちゃくちゃ根気よく背景を聞いていました。
これは一人でやるとなかなか諦めそうになるので、対応するエンジニアチーム全員の朝会で話し、「深ぼったほうがいいよね」となったものを諦めずにみんなで聞くというアクションをとっていました。
その時「なんでやるの？」と聞いたら角が立つので、
「〇〇さんがお客さんのことを思っているのと同じように、我々もお客さんの要望を可能な限り実現してあげたいので詳しく聞いてきてください！」的に聞くといいですね（目的の共通化ですね）。
3. 判断軸の言語化
なぜ必要なのか
属人性やその時の感情にできるだけ影響されない判断をするためです。
正直私たちも、目の前の人が困ってるんだからできるだけやってあげたいです。
エンジニアは特に、1日とか数時間とかで解決できるものは解決してあげたいと思います。
が、それを続けるとエンジニアチームの仕事は無限に増えていき、仕事を減らすための仕事もできなくなってしまいます…
実施策
判断軸をまとめました。
ここで大事なのはミッションです。
私たちは 全ての お客様に価値を届ける必要があるため、できるだけ特定のお客様だけの価値に注力しないようにしようと話しておりました。
本当に価値のある対応であれば、プロダクトに実装するのが一番ですからね。
そこで有意義だった問いは「イレギュラーの場合、改善策を講じられるか」というものでした。
2回以上依頼が来るならエンジニアの対応工数も大変だし、実装する？みたいな思考回路ができたと思います。
4. エンジニア⇔CSのコミュニケーション
なぜ必要か
解決策の幅が広がるためです。
当時はなぜかエンジニアはカスタマーサポートと連絡をしないという暗黙のルールがありました。
エンジニアが自分のタスクに集中できるようにと作られたルールだったのですが、現状の組織にあっていませんでした。
タスクを実行するのはエンジニアなことが多いので、カスタマーサポートと一緒に解決策を考えたほうが絶対にいいです。
一次情報に触れられなくてもいいが、いつでも触れられるという状態を作ることで、方針に悩んだ時にスムーズに解決に向かうと思っています。
実施策
まず問い合わせ対応のカスタマーサポートへの返事をやってみるなどしていました。
これもJIRA導入の功績ですが、チャット形式になったことで「お疲れ様です、〇〇と申します」とか書かなくてよくなったため、ハードルがグッと下がりました。
エンジニア側の心理ハードルを下げるために、「連絡を取ったことがある人」という前提を作りました。
あとはランチとかいろいろやって、最終的にカスタマーサポートと課題解決定例を始めるまで漕ぎ着けました。
定例で顔を合わせるようになったらだいぶコミュニケーションはしやすくなり、議論できる信頼関係の土壌を築けたかと思います。
最後に
このようなことをして、「顧客のことをよく知っているエンジニア」という立ち位置を作っていきました。
ただただ顧客問い合わせ対応をしているのではなく、
それをプロダクトやプロセスのアップデートに繋げられたらなと思います。
ここまで読んでくださりありがとうございました！