はじめに
はじめまして。QAエンジニアの佐藤です。
最近、社員数が増え始め、”佐藤”さんが増えてきました。
私が所属している開発チームでユニークなあだ名をつけていただいたものの、日常で呼ばれたことはありません。
あだ名って難しいですよね。
今回は、私が入社して2ヶ月目から取り組み始めたお問い合わせ対応の改善についてお話します。
当初からお問い合わせフローを検討していたのではなく、インシデントフローの改善に着手する中で、別途お問い合わせフローも検討したいと思うようになったことがきっかけでした。
お問い合わせ対応はフローが決まっていない状態だったので、まずは運用に乗せられるか不安もあったため小さく始めることを意識しながら検討を始めました。
課題の整理
まずは現状の把握と課題の整理を行いました。
PdM（プロダクトマネージャー）にヒアリングしてわかったことは以下のとおりです。
- ユーザーからのお問い合わせはCS（カスタマーサクセス）が受けている
- CSはお問い合わせの回答に困ったとき、PdMに口頭またはSlackで確認している
- PdMがCSからのお問い合わせの回答に困ったとき、開発チームリーダーに口頭またはSlackで確認している
このような確認フローはよくあると思いますが、以下のような課題があると感じました。
- 仕様がわからない、意図した挙動となっていない、など困ったときにCSは誰に確認するべきか悩んでしまう
- 確認した方が回答できない場合、別の方に確認することになって回答までに時間がかかり非効率
- CSが困っていることを開発チームが認識しづらく、開発チームの自主的なフォローもしづらい
- お問い合わせ内容が蓄積されづらいため同じようなお問い合わせが発生する可能性がある
QAエンジニアとしては、どんなお問い合わせがきているかを開発チームが把握することで、ユーザー目線での開発に活かせるようになったらいいなと思っていました。（裏目標）
最小コストで取り組んだ4つのこと
お問い合わせは内容によって緊急度が高い場合もあるため、なるべく早く気づき、早期に回答することが望ましいと考えています。
そのため使い慣れている且つコミュニケーションが取りやすいツールでまずは運用したい気持ちがありました。
Tebiki社では職種に関わらずコミュニケーションツールにSlackを導入していたため、Slackを活用していくことにしました。
課題を整理した後、お問い合わせ対応を改善するために取り組んだ4つのことをご紹介します！
１．お問い合わせの回答者を決める
検討当時、私たちのチームにはお問い合わせの一次受けを担う役割のエンジニアがいませんでした。
そのため誰がお問い合わせに回答するかを決める必要がありました。
Tebiki社には「全てのメンバーに「リーダー」としての行動を期待」というカルチャーがあります。
私自身もそうでありたいと思い、「答えられる人が積極的に答える」環境を作りたいと考えました。
お問い合わせに回答するのはPdMだけでなくてもよくて、開発チーム内でお問い合わせに答えられる人が回答できるようにすることを提案しました。
大変ありがたいことにご理解いただいて、お問い合わせに回答するメンバーを含んだSlackのユーザーグループを作成しました。
Slackのユーザーグループには、問い合わせに反応していただきたいPdM、PE（プロダクトエンジニア）、PD（プロダクトデザイナー）、EM（エンジニアマネージャー）、QA（品質保証）を招待しました。
お問い合わせが来た時に誰が回答するのか？という点に関しては、お問い合わせに対してリアクションをつけて意思表示する、という最低限のお願いをしました。
２．お問い合わせの受け付ける場所を決める
お問い合わせを受け付けるSlackチャンネルはどこがよいか悩みました。
お問い合わせの内容も様々で、仕様確認・不具合報告などあると思うのですが、どんなお問い合わせでも一つの場所で受け付ける方針としました。
検討した結果、開発メンバーが全員いる既存のチャンネルでお問い合わせを受け付けることにしました。
新しくお問い合わせ用のチャンネルを作成してやりとりしやすくする案もあったのですが、チャンネルが増えることにちょっとだけ懸念がありました。
また、一次受けとして開発メンバーが回答するので、開発メンバーが全員いるチャンネルでまずはミニマムで始めてみたい、と思いました。
開発メンバーが全員いるチャンネルにCSメンバーを招待し、お問い合わせに関することはそのチャンネルでやりとりを行っていただくようにお願いしました。
CSメンバーに周知したときの投稿はSlackのピン留め機能を活用し、お願いしたいことや背景、目的がいつでも確認しやすいような工夫をしています。
３．お問い合わせ時に必要な情報を決める
お問い合わせを受け付ける際に、情報が不足していて何度もやり取りを行うことがないよう、必要最低限の情報は何かを考えました。
最初はいろいろと情報を求めがちですが、まずは気軽にお問い合わせいただけるように、以下の項目のみを記載していただくことにしました。
- お問い合わせ内容
- 遭遇ユーザーや該当のURL
- そのほか伝えたいこと
入力項目が少ないですよね。
お問い合わせするときのハードルを低くすることを心掛けました。
もし情報が足りなかったら追加でお聞きする、毎回必要な情報が出てきたらテンプレートを見直す、という方針にしました。
４．お問い合わせしやすい工夫をする
より気軽にお問い合わせができるように、Slackのワークフローを作成しました。
ワークフローを作成する : Slack でワークフローを作成する | Slack
Slackのワークフローは導入後すぐに使っていただけて、スムーズに運用に乗りました🙌
欲しい情報も記載いただけており、回答できるメンバーが積極的にやりとりを行ってくださったため本当に嬉しかったです。
ワークフローが投稿されたときに一番反響があったのは水晶玉の絵文字だったので、絵文字のセンス大事かもしれません。笑
運用開始時は、「必ずワークフローを使う」というルールにはせず、「必要に応じてSlackのユーザーグループへ直接お問い合わせいただいてもOK」としていました。
しかし、実際に運用を開始したところ、全てのお問い合わせがワークフロー経由で来たため、結果的に「お問い合わせはワークフローをご利用ください」とシンプルにお願いするのが最も効果的だったようです。
導入時にやらなかったこと
今回は最小コストで始めることが目的でもあったので、導入時にやらなかったこともたくさんあります。
▼チケット管理
チケット管理ツールでお問い合わせを受け付けて、一次対応する方がチケットを取っていくスタイルの導入は見送りました。
チケット管理は、仕様に関するナレッジを蓄積しやすいなど、多くのメリットがあります。
しかし、運用開始までに検討すべき事項が多かったため、まずはSlackのみで運用を始め、後から改めて検討することにしました。
▼ステータスの管理
ワークフロー内にボタンを設置し、お問い合わせのステータス管理を行う運用にはしませんでした。
どれくらいのお問い合わせがあるかわからなかったのと、ボタンの種類や押す基準を定める必要があったため、様子をみてから対応することにしました。
▼分析項目の検討
どんなお問い合わせが多いかや、回答までのリードタイムなど、お問い合わせの後に傾向などを分析することは導入時に検討しませんでした。
まだどんなお問い合わせがくるかもわかっていなかったため、ある程度数が集まってから検討することにしました。
導入時にやらなかっただけであってこれから向き合っていく課題です。
割とすぐに改善したこと
最小コストで始めたものの、割とすぐに改善したこともたくさんありました。
▼お問い合わせ回答者の当番制
「答えられる人が積極的に答える」という環境を目指していましたが、実際にはうまくいかないこともありました。
回答できる人がいない場合や、すぐに反応がない場合に、「誰がこの問い合わせを見てくれているのだろう？」と問い合わせた側が不安になるという問題点がありました。
また、ワークフローを使ったお問い合わせでは、PEにしか答えられないような技術的な仕様に関わる内容がほとんどでした。
この問題点と現状の投稿の傾向を踏まえて、一次回答者にPEを自動でアサインする運用に変更しました。
（自動アサインの部分はPEにご対応いただきました、ありがとうございます！）
運用変更後、EMとQAはサポートという立て付けでお問い合わせ対応に関わっています。
▼ナレッジ共有のためにメンションを追加
Slackのワークフローはお問い合わせに回答するメンバー宛てにメンションをしていましたが、CSメンバーにもお問い合わせ内容を共有したいとCSからFeedbackをいただき、メンションに含めることになりました。
実際に使っていただいているCSからFeedbackをいただけたのはとても嬉しかったです。
▼お問い合わせ一覧の作成とステータス管理
導入時にはステータス管理を行わない方針でしたが、予想以上に多くのお問い合わせがあり、未解決のまま残ってしまうケースも出てきました。
その際、Slackのスレッドを一つずつ確認していくのは大変だったため、ワークフローから投稿されたお問い合わせ内容が自動的にスプレッドシートへ出力されるようにしました。
各行にステータスを追加して、今は完了したお問い合わせがわかるようになっています。
ただまだ手動でステータスを更新しているので、改善の余地ありです。
▼お問い合わせのフローを資料化
運用に乗ってから開発のメンバーが増えたのですが、お問い合わせのフローをまとめた資料がなかったため、新しく入られた方に共有ができていませんでした。
また、お問い合わせ担当者の心構えも改めて伝えたく、現状のフローをまとめたページを作成しました。
さいごに
最小限のコストで始めたお問い合わせフローの改善でしたが、運用に乗るとすぐにアップデートの必要が生じたのは、私にとって大きな学びでした。
CS、開発チームのみなさまに使っていただけるからこそフィードバックが得られるのだと思いますので、今後もCREと協力しながら、より良い運用を目指して改善を続けていきたいと思います。
お問い合わせ対応をどう始めたらよいか？と悩まれている方の参考になれたら嬉しいです。
Tebiki社では一緒に働く仲間を募集しています！
ぜひ採用サイトをご覧ください。
▼採用HP tebiki.co.jp
▼募集中のエンジニア求人一覧 herp.careers
