/w=3840,quality=80,fit=scale-down)
こんにちは。カンムで業務部長してます平湯（ひらゆ）です。
2022年末に過去の問い合わせ率を集計したところ、一番多かった時期と比べると問い合わせ率が半分になってました。（問い合わせ率 = 問い合わせ数 / 稼働会員数） 良きタイミングなので頑張ってきたことを振り返ってみます。
なお、特別なことはやってなくて、シンプルなことを愚直にやってきただけです。スーパーメソッドを期待されてる方はなんだそんなことか、になっちゃうかもしれません。
どんなことをやったか
一次情報から課題特定 →問題提起 →オペ整備 →リリースのサイクルを回した結果です。何よりも一次情報の取得が大事です。時間がかかるし、単純作業なので苦しいんですが、生の声を読むことで感情や背景が頭に染み込みます。問題により深く入り込めているという感じでしょうか。 この課題の解決策をエンジニア・デザイナー陣と考えていきます。カンムはエンジニアメンバーが問題提起から入ってくれるので、解決策の幅が広がります。
この辺は実例で話したほうが分かりやすいので、具体例を挙げます。
アプリ明細表示の改善
バンドルカードアプリに表示される決済履歴の表示名を修正しました。
問い合わせを減らすにあたり、まず件数が多いカテゴリを見ました。効果が一番大きいからです。 （そもそもどこまで細かくカテゴリを分けておくかですが、これは変わっていくので定期的に更新したほうが良いです。）
件数が多いカテゴリの問い合わせを出力して、実際の内容を見ます。ZendskからGASでスプレに出力しました。やり方まとめてるので参考にしてください。
内容を更に仕分けます。コツは分類しすぎないことです。分類が目的になっちゃうので。頑張って5コとかに抑えて、他は「その他」にします。
とはいえ、最初はどれが多いかわからないので50件くらいバーっとコメントを残す →見直して集約する感じですかね。Zendeskなら最初からキーワード検索してなんとなくアタリをつけておくのもありですね。このあたりはテキストマイニングできると早いですが、スキル修得に時間がかかるので愚直にやるでいいと思います。
特にこれから初めてこのへんやっていくぜという場合は、とりあえず今ある能力でやって成功体験を積むことが大事かなと。効率のいいやり方はいくらでもあると思いますが、考え込んで何も進んでないというのがいちばん悲しいので、わからないし高度なことできないならとりあえず手を動かさねば。もうスプレをゴリゴリに使います。
あと自分が大事にしてるのは事象の「事実」を書くことです。やっていくと自然と解決策を書いたりしちゃうんですが、目的は課題特定です。何が起きているかを的確に捉えるために、可能な限り事実確認をしたうえで事象の「事実」を記録します。問い合わせ内容が着地と違う場合もありますからね（「●●になってるんだけどどういうこと？」→調べたら●●になってなかった 等）。集計する対象を正しく整理したうえで仕分けします。
上のイメージで言うと、問い合わせ内容を見る →事実確認する →「事象」に記録する →事象でまとめるほどじゃないけど気になることを「コメ」に書いておく →問い合わせカテゴリを一回書いてみる →数十件やったら問い合わせカテゴリを見直す、という流れです。
そのようにゴリゴリしたところ、「ある明細の名称に覚えがない・わからない」という問い合わせが多いことが分かりました。明細の名称がある時点から、該当の利用とは類推できないような表示名になってしまっていました。 決済情報は、加盟店 →加盟店を管理する会社（アクワイアラ） →カード発行会社（イシュア）、と流れます。（ECサイトは加盟店 →アクワイアラの間に決済代行会社（PSP）が入ってることがほとんどだと思います。）
決済情報の中に含まれている加盟店名称はPSPやアクワイアラが管理しているので、イシュアが受け取った情報をそのまま明細に載せている場合、急に名前が変わってしまうことがあるのです。
このへんで課題感をまとめて、解決案を添えたドキュメントをもって関係メンバー（このときはエンジニアとデザイナー）に声をかけます。経験上、このときに解決案を考えすぎないほうがいいです。エンジニア側しか把握できないシステム上の問題があったり、外部取り組み先（VISAとか）のルールがあったりで、その案の不確実性が高いし、もっといい解決案があるかもしれないからです。だいたい30分とか1h考えてまとめられるくらいのものにするイメージです。議論するたたきがあればいいくらい。この例ではざっくり「明細の名称をカンム側で変更する案」とか「アクワイアラ・決済代行に連絡して名称を変更してもらう案」とかを書き出して、あとは明細名称を変えたときに他に影響はないか思いつくものを書くなどしました。今回は割と方向性が限られていたのでそんなに時間はかかりませんでした。 あと、想定効果はちゃんとまとめておきたいですね。関わる人の優先度の決定とモチベーションに関わります。
課題感からエンジニア・デザイナーに入ってもらって、解決策の方針と要件定義をまとめます。詳細設計でさらに細かい要件を詰めることになりますが、ちゃんと打ち返せるように自分が提起した問題を理解しておく必要があります。このときにも一次情報の取得と類推をどれだけ深くやってきたかが大事になってきます。ここでは新たな論点として、過去分は更新するのか、管理画面側の反映はどうするんだ、などが出てきました。今回も頼りになるメンバーに助けてもらっています。
解決策をリリースしてもらって、これに関する問い合わせは無事にゼロになりました。
ちなみに、課題を特定してからリリースまでにはどうしても時間がかかってしまうので、自分のリソースでできることを見つけて実行しました。このときは本件に関するサポートページを出しました。この明細は「◯◯✕✕」と出てしまうけど本当は「●●」だよ、という内容です。問い合わせるよりはマシな体験であるFAQでの解決を促しました。CSチームはユーザーの問題を解決する手法として、アプリを見れば分かる > FAQ > 問い合わせ、の優先順位と考えているからです。
追跡番号のアプリ表示
リアルカードを送付する際の追跡番号をアプリで表示するようにしました。
これも問い合わせが多いものから見て発見しました。「リアルカードが届かない」関連の問い合わせが多く、その中でも追跡番号を教えてほしいという内容が多いという話をオペレータから聞いており、タグを仕込んで集計してみたら結構な数あることがわかりました。
現行のプロセスでは、追跡番号を受領しているものの、DB上に保管するテーブルが存在しないためスプレに記録していました。DBがないので通知のハードルが高く、問い合わせがあったときにスプレを検索して回答するのが限界でした。
一次情報を確認のうえ課題・解決案・効果をまとめてエンジニア・デザイナーと話します。 当時は開発リソースが限られていたので簡易に実現する方法を選択しました。受領した追跡番号を手動で管理画面から取り込む方法です。 本PJでいちばん難しかったのは外部データの構造やルールを把握することでした。追跡番号は日本郵便が発番しているもので、そのデータの構造、番号の意味するところや有効期限、再利用があり得るのか、などを把握しておく必要があります。例えば再利用が可能なら、同じ番号がレコードとして存在することになるのでどう区別するのかを考慮するなど。 （ここは自分に足りてなかった部分で、要件詰めに時間を取ってしまいました。この点は、本PJ以降強く意識して仕事をしていくことになります。データ構造を理解して、実装するときにどういう考慮が必要かエンジニアと論じれるようになるイメージです。）
今回はアプリのUI変更があったので、デザイナーやフロントエンジニアとUIの修正をしました。あとはリリース準備として追跡番号が表示されるようになったことをFAQに追加しました。
実装後、問い合わせはほぼなくなりました。だいたい300件/月くらいがなくなりました。やったね。
エンジニア/デザイナー陣とやり取りするときに意識してることを再度触れておきます。まずはやっぱり課題感の段階から入ってもらうことですね。問題を同じレベルで理解してもらえるか否かで議論の速度や深さがかなり違います。
次に要件定義を明文化して書くこと。端的に箇条書きで「〇〇は●●できないようにする」「△△が☓☓になった場合は●●テーブルの〇〇を▲▲に更新する」といった具合です。問題を理解してもらい、議論の末に要件が詰まっていきますが、微妙なところで認識ズレが発生することもあります。それをなくすためにハッキリと実現したいことをまとめておきます。「あれ、そういう話だっけ？だとすると…」となったら要件がまだ詰まってない証拠です。白熱教室していきましょう。 そして白熱教室するには、提案者が誰より深く問題を認識している必要があります。一次情報から得た課題感を自分ごととして認識していきたい。
あとこれは抽象的ですが仲良くなるのは大事と思います。言いたいことを言い合える状態・環境にしていく。普段業務から他メンバーに興味を持って接します。slackのいろんな部屋見るだけでもその人が普段どういうことを気にしているかとか知れますよね。
ここまで感情の赴くままに書いたので、CSの改善活動で大事と思う要素をまとめておきます。
- 大きい問題から解く。
- 一次情報から課題感を得る。
- 一次情報の仕分けは細かく分類しすぎない。
- 解決案は考えすぎない。
- 想定効果は必ず出す。
- 問題提起の段階から関係メンバーに入ってもらう。
- 要件を端的にハッキリと書く。問い合わせ率をさらに半分にしていくぞ
今回は例を2つ挙げましたが、これ以外の細かい活動も含めて問い合わせ率の減少に繋がったと思っています。 問い合わせを減らすプロセスは学べることが多いです。課題特定・要件定義・実装までの準備など。やっていて楽しいですね。
カスタマーサポートと聞くと顧客対応が中心なイメージがあるし、求められるスキルも対応品質やコンタクトセンター管理などの印象があると思います。 もちろんサポートの安定稼働がミッションですが、それだけじゃ事業への貢献は遠いし、面白くないというのが持論です。私がバイブルとしてる「おもてなし幻想」にある ”エフォートレス” を実現すべく、ユーザーの「わからない」をなくす（= 問い合わせ自体をなくす）ためにできることを探し続けています。そのあたりの想いは、CSチームにおいて必達目標とは別にOKRとして組み込んでいます。（この辺の目標設計も紆余曲折あったので別途書こうかな）
上記のように、当社CS/Opsチームは分析に基づく改善活動を推進しています。SQLやGASなど分析するためのスキルを学ぶ環境もあります。
今後も問い合わせすることなくサービスを不便なく使えるよう、アプリ/FAQで解決できる環境をつくっていきます。問い合わせ率を今よりさらに半分にします！
こんなCS/Opsチームをリードしていただく方を絶賛募集中です。このポジションでは「安定稼働」と「エフォートレス」という攻めと守りをハンドルする楽しさがあります！お話だけでもぜひ。気軽にメッセージください。
