はじめに
はじめまして。
ゲームのカスタマーサポート(以下、CS)に加え、配信プラットフォームのCSにも携わっている者です。
突然ですが、CS担当というと「お問い合わせ」をいただいてから対応するというイメージが強いのではないでしょうか。
実際その側面も大きいのですが、顧客満足度向上のためには「後追いの対応」だけではなく、開発の上流工程から情報を得て「先手を打つ」ことも重要だと考えています。
本記事では、上流工程で情報収集の取り組みをどのように行ったかと、今後の展望についてお伝えします。
自身の振り返り(反省)でもありますが、今後チャレンジされる方の参考になれば幸いです。
なぜ上流工程の情報が必要か
CS担当者が開発の上流工程から情報を得ることは、顧客満足度や顧客対応の質を高めるうえで重要です。リリース前の仕様や変更点を早期に把握することで、以下のような先回り対応が可能になります。
-
仕様の最適化
CS視点で想定される疑問点や誤解が生じやすいUI、表現について、開発段階からフィードバックを行い、仕様等への調整を行う。 -
お問い合わせ抑制
お問い合わせが発生しそうなケースを事前に想定し、お客さま向けのFAQや告知文を準備することで、リリース後の着信を抑制する。 -
CS運用体制の整備
影響範囲や想定問い合わせ件数を踏まえ、最適な人員配置や対応フローを事前に整備する。
このように、上流工程の情報把握は単なる情報収集に留まらず、CS活動を支える重要な資産となります。
現状の認識
上述の通り、お問い合わせを未然に防ぐためには、プロダクトからの情報を早期に得て行動することが重要です。
一方、実際の運用では、実装情報がリリース直前に共有されるケースもあり、十分な準備ができないまま対応に入らざるを得ない状況がありました。
その結果、以下のような課題が顕在化していました。
-
改善の遅れ
顧客視点で疑問が生じるポイントを開発に伝えても、タイミングが遅く改修に反映されない。 -
想定外の着信
プロダクトからの共有は大きな実装が中心となる傾向があり、共有されない細かなUI変更が問い合わせ増加を招くこともある。 -
後手の対応
結果として実装後に着信が増加し、CS担当者の負荷が高まることで回答をお待たせしてしまう。
CSグループが所属しているCPS部のなかでは、複数のグループ/チームが企画段階から情報連携を行っており、CSにとっても上流工程の情報を得やすい環境が整っていますが、プロダクトや他チームから渡された情報をもとに後手で対策を検討する構造になっていることも課題と考えました。
アクション:情報を取りに行くために
「渡される情報」を待つ受け身の姿勢から脱却するため、以下の行動を積極的に行いました。
-
CS視点の訴求
定例会において上流情報の意義や重要性を共有するとともに、これまで参加できていなかったプロダクト主催のMTGにも積極的に参加し、お客さま視点に基づくCSの観点をより広範に訴求 -
情報取得環境の強化
各種ツールや資料にアクセスできるよう権限拡大を調整し、共有を待つのではなく、CS自身が必要な情報を主体的に把握できる経路を拡大 -
信頼関係の深化
プロダクト側からの相談や依頼には迅速に対応し、信頼関係を強化
これらにより、CSチームが開発プロセスに関わる機会が増え、以前よりも早く情報を把握できるようになりました。

得られた成果
日常的なやり取りを重ねる中で関係性を深めた結果、細かな企画内容についてもCS側で早期にキャッチアップできるようになり、不明点があれば担当者に直接確認できる状態となりました。
その結果、以下のような成果につながっています。
-
CS提案の採用拡大による着信抑制と運用工数削減
上流工程で得た情報をもとに、お客さまが疑問を持ちやすいポイントを事前に洗い出し、CS側から改善提案を行う機会が増えた結果、CS起点の提案が仕様へ反映されるケースが増加しています。
また、リリース前の段階で問い合わせ増加が想定される箇所について、案内文やフローをあらかじめ準備できるようになったことで、初動対応の精度が向上しました。
これにより、プロダクトへのエスカレーション件数の削減や、CS対応工数の抑制にも繋がっています。 -
部内連携の質的向上
CPS部内の他グループ(審査やQAグループなど)に対しても、CSから「実装前」段階の情報を共有できるようになりました。CS観点の情報も加わることで、部内で連携される情報の厚みが増したと感じています。
新たな課題:情報の「量」と「質」
上流工程に入り込めるようになった一方で、「情報を得られるからこそ」の新たな課題に直面しています。
-
情報の取捨選択コスト
膨大な開発情報の中から、CS観点で必要な情報を選別することに多くの工数がかかっています。 -
連携基準の曖昧さ
部内の他グループに連携すべき情報の基準や粒度が未整備なため、共有の質にばらつきが生じています。
これまでは「どの情報が、いつ共有されるか」が主な課題でしたが、今後は集めた情報をいかに効率よく選別し、適切に連携していくか、が新たな課題となっています。
情報量の増加を前提としたうえで、CSとして本当に必要な情報は何か、また、部内でどのような基準、粒度で共有すべきかを整理していく必要があると感じています。

今後の展望
上述の通り、CS観点で必要な情報の範囲や粒度が曖昧なままでは、情報量が増えるほど取捨選択の判断コストが高まり、属人的な対応に陥りやすくなります。
今後は、情報量の増加を前提としつつ、CSとして扱うべき情報を効率的に判断、活用できる状態を目指していきます。
そのために、以下の取り組みを進めていく予定です。
-
仕組み化による工数削減
情報管理ツールの活用や、リアルタイムで情報を可視化できる仕組みを考え、担当者が必要な情報を迅速に把握できる環境整備を推進します。 -
情報共有基準の明確化
「どのような情報を、どのレベルで」共有すべきかの基準を策定し、部内連携を円滑にします。これにより、情報の過不足を防ぎ、適切なタイミングでの連携を目指します。
まとめ
CS担当者が開発の上流工程に関わることは、「お客様のために」より良いサービス提供を実現し、「着信対応工数を抑制」するうえでも効果的だと実感しています。
今後もCPS部内のみならず、プロダクトとも協力しながら、より質の高いCS活動を目指していきます。