この記事は hacomono Advent Calendar 2025 の18日目の記事です
みなさん、こんにちは。
hacomonoでサポートOpsを担当しています、あやねです🍵
サポート部が駆け抜けた、2025年という1年
2025年……個人的には、本当にあっという間の1年でした！
この1年、hacomonoサポートはこれまでにないほど多角的なチャレンジを重ねてきました。
- 問い合わせ対応へのAI活用の推進
- 社員・パートナーを巻き込んだプロダクト学習の促進
- セルフソリューション（自己解決）領域のさらなる拡充
- hacomono初のtoC向けサービス「FitFits」ローンチに向けたサポート体制の構築
- 問い合わせデータの分析と利活用の推進
- 顧客体験向上を目指した応対品質の磨き込み etc…
日々の問い合わせという「守り」を回しながら、新しい「攻め」にも踏み込む。
言葉にすると軽く見えますが、実際はなかなかハードです。
それでも、チームの誰かが諦めずに一歩ずつ進めて、少しずつ前に進めた濃度の高い一年だったと思っています。
その中から今回は、私が担当として向き合ってきた 「問い合わせデータの分析と利活用」 の裏側を書きます。
はじめに
私はこの一年、「問い合わせデータ分析」を仕事のど真ん中に置いてきました。
分析という言葉はかっこよく聞こえるわりに、やっていることは地味です😂
数字が揺れる、前提が揃わない、定義が決まらない、、、
画面の前で、同じ列を何回も見比べる時間がいちばん長い。そんな日も普通にあります。
それでも向き合った理由はシンプルで、サポートの肌感を「話せる言葉」にしたかったからです。
「最近この問い合わせ多い」と感覚で話せます。
でも、議論の場に出した瞬間に薄まってしまうことがある。根拠が伝えづらい。
そうやって、お客様の困りごとの芽が、どこにも届かないまま消えていくのが心のどこかで悔しかったんだと思います。
ただ、私が言いたいのは「サポートの意見が正しい」という話ではありません。（誤解のなきよう・・・🙏）
hacomonoは多機能なSaaS。プロダクトの意思決定は、常にトレードオフです。
開発の背景も事情も、私たちサポートが把握しきれないほど複雑です。
サポートが「こうしてほしい」と強く言えば言うほど、誰かの手を止めてしまう気もする。
開発チームが積み上げてきた時間や判断を思うと、果たしてフィードバックを出してもいいのだろうか？と感じた日もありました。
それでも、問い合わせには種があるとも思っています。
プロダクトやサービス、ビジネスをよくするヒントが、毎日そこに舞い込んでくる。
それが「サポートの感想」で終わってしまうのは、やっぱりもったいない。
だから私は、問い合わせを「正しさの証明」ではなく、「優先順位を一緒に決める材料」 にしたいと思いました。
今日書きたいこと
「問い合わせデータ分析」と聞くと高度な解析を想像しがちですが、私が最初にやったのは、器を作ること でした🥣
Looker Studioで、ゼロからダッシュボードを設計する。フィルタや切り口を決める。データソースを整える。
見える器がないと、話が続きません。
毎月の分析レポートも共有も振り返りも、結局は「みんなで同じ景色を見られる場所」が必要でした。
当時のサポート部では、問い合わせ管理ツールやスプレッドシートで集計して、部内で見る動きが中心でした。
ただ、他部署から質問が来たときに、うまく答えられなかったり見せられなかったりすることがありました。
つまり「その場で一緒に確認する」ができない状態です。
そこで私は「毎月同じ型で見られる場所」を作る方向に舵を切りました。
データの取り回しはGoogle Sheetsに寄せてデータベース化する。Looker Studioは「見るための場所」にする。役割を分けて、運用を回しやすくする。
その上でこの一年、私が取り組んだことを3つの章で書きます。
「自分もやってみよう」というサポートに奮闘する方の背中を押し、その隣にいる開発・ビジネスの方には「サポートってそんなこともやってるんだ」と新たな一面を知ってもらう。
会社や組織の枠を超え、そんなきっかけになれば幸いです。
第1章｜「同じ数字」を作るの巻
データ分析の最初の敵は、分析そのものではなく「前提」でした。
Zendeskからデータは出せます。でも、集計しようとすると数字がブレる。
条件を揃えたつもりでも、翌月に同じやり方で再現できないというつまずきもありました。
そこで私がやったのは、まず「正」を決めることです。
- 分析の正本にするデータを一つに固定する
- 列の定義を文章で残す
- 除外条件も明文化する
未来の自分のためでもあります。（だいたい、三か月後の私は忘れています😂）
もう一つ、効果が大きかったのが顧客マスタ連携です。
業種、契約開始日、契約経過月数などの属性が入ると、見える景色が増えます。
ただし、ここは罠も多い。結合キーが弱いと、あっという間に崩れます。
私は途中でキー列を作り直しました。表記揺れに頼らず、揺れないキーを自分で持つ。
地味だけど、とても大事な作業でした。
シートの中身も、少しずつ分析向けに寄せました。いわゆるデータクレンジングです。
たとえば、問い合わせのカテゴリや起因をそのまま使うのではなく、比較したい粒度にまとめ直す。
契約月数の計算列を入れて、同じ軸で並べられるようにする。
#N/Aを潰して、参照先を見直して、列名が変わったら追従する。
派手じゃないけど、ここを整えないと「じゃあ次は何をする？」の話に進めません。
それから、もう一つよく出てくる誘惑があります。
要素を増やせば、それっぽく見える という誘惑です。でも、増やしすぎると誰も使わない。
なので私は、要素を足す前に毎回こう問い直しました。
この要素が増えることで、誰が明日なにを決められる？
答えが出ないものは、いったん足さない。この割り切りがないと、運用が持たないなと感じました。
第2章｜可視化を運用にするの巻
土台が整うと、Looker Studioでの可視化は一気に楽になります。
ただ、ここで終わりではありません。ダッシュボードは、作っただけでは使われません。
リンクを貼っても流れるし、忙しい月は見られません。
そもそも「見る理由」がなければ開かれないのは当たり前です。
私も、作った側として何度も味わいました。
だから私がこの一年やったのは、理想論ではなく「現実寄りの運用」でした。
毎月、特定の機能テーマを決めて分析する。レポートを作って公開する。Slackで共有する。全社MTGなどでも発表する。
これを淡々と繰り返しました。地道だけど、認知はここでしか積み上がらないと思って、草の根活動をやり続けた一年でした。
ダッシュボードの作り方も、途中で変えました。
最初は「見たいものを全部」置いてしまって、開いてもどこを見ればいいか分からない。
そこからは「入口のページ」と「深掘りのページ」を分けました。
入口には、前月の問い合わせ全数、月ごとの推移、社内／社外の内訳など、状況が掴めるものを置く。
深掘りは、セグメント別（業種、問い合わせカテゴリなど）やテーマ別ページへ逃がす。
これで「読めるダッシュボード」に近づくはずと信じて、少しずつ作り替えていきました。
ただ、ここもまだ道半ばです。見せたい軸の整理、指標の置き方、ページの説明、更新のしやすさはもちろん、「見たあとに何をする？」まで繋げる導線。
やればやるほど、次の課題が見えてきます⛰️🚶
もう一つ、運用の中で意識したことは、サポートだけの視点になりすぎないこと です。
数字は便利すぎて、言い方が強くなることもあります。
だから私は、「こうあるべき」と言い切るよりも、こう書くようにしました。
- 今サポートの視点・データではこう見えている
- こんなブラッシュアップが効くかもしれない
- ここはサポートのデータだけでは判断材料が足りない
それは、開発のメンバーが、私たちの何百倍の時間をかけて機能を作ってくれているからです。
私たちが見えている景色だけで語らない。ここはとても意識していることです。（まだまだですが…）
そして最近、ビジネス側から「そのデータ、見せてもらえますか？」と声をかけてもらう場面が出てきました。
最初は正直、「サポートの意見って、やっぱり求められていないのでは…」と不安だったので、その一言だけで救われる日があります。
第3章｜問い合わせのテキストを読んで本質を捉えるの巻
問い合わせの良さは、お客様それぞれの言葉で、お困りごとやご要望が届くことです。
ただ、毎月数千件以上の問い合わせが入る状況では、1件ずつ読んで分析するのは現実的ではありません。
そこで私は、テキストマイニングを試し始めました。（まだ駆け出しで、正直手探りです😇）
やったことは、ざっくりこんな流れです。
- 問い合わせをAIで要約させる
- 要約をベースに、表記揺れを少し寄せる（同義語をまとめる）
- ノイズになりやすい語を外す
- 頻出語やn-gram、キーワード辞書（正規表現）で当たりを付ける etc…
ここで大事にしたのは、「結論を出す」ことではなく「読むべき問い合わせを絞る」ことでした。
大量の問い合わせの中から、テーマの中心に近いものを拾う。文脈を確認する。仮説を立てる。
この順番にすると、テキストが「扱える情報」に近づきます。
たとえば「解約」「退会」は拾いやすいですが、それだけだと偏ります。
実際の問い合わせは、もっと遠回しだったり、別の言い方だったりします。
「高い」「返金」「請求」「変更」みたいに、周辺語で輪郭が出ることもある。
そのため、私は強い単語だけで断定しないようにしました。
この延長線上で、解約予兆やアップセル／クロスセルの話題にも触れ始めました。
ここはまだ「成果」として語れるフェーズではありませんが、「問い合わせからどんなシグナルを拾うか」「拾ったものをどう扱うか」を、ビジネス側のメンバーと議論している段階です。
仮説を置き、検証の設計を作る。少しずつ土台を固める、という挑戦をしています。
この章で一番伝えたいのは、サポートのフィードバックが「サポート視点の要望」だけだと、尖って見えることがある、ということです。
だから私は、意見ではなく「開発ロードマップに活かせる材料」として渡す形に寄せました。
数字、問い合わせテキストの文脈、セグメントの前提などを明確にし、相手が判断しやすいセットにすることを重視しました。
問い合わせデータは、脆いし、扱いが難しい。
hacomonoのような多機能なSaaSだと、特にそうだと思います。
相関を見つけた瞬間に、因果っぽく語りたくなる。
件数が少ないセグメントでも、語りたくなる。
拾った語だけでストーリーを作りたくなる。
私は何度か、その誘惑に引っ張られました・・・😇
なので自分の中で、以下の3つが揃わないときは、断定的な言葉で伝えないというルールを作りました。
- 数字で言い切る前に、定義を説明できるか
- セグメントの母数は十分か
- テキストは文脈まで読んだか
分析は「勝ちにいく道具」という使い方もあるけど、社内の会話を前に進める道具。
そう思うと、分析ってツラい…と悩んでいた心が少し軽くなった気がしました。
おわりに｜問い合わせは、「判断」を助けるために使いたい
サポートとしては、問い合わせが減ったら嬉しいし、お客様が自己解決できて困らないことが理想です。
でも、減らすだけが正義でもない。
プロダクトが伸びる局面では問い合わせが増えることもあります。
どのお客様にも最適なプロダクトにはなりません。
開発にも、いろんな事情があります。
だから私は、問い合わせを「減らすための武器」ではなく、「優先順位を一緒に決めるための材料」 として扱いたいと思うようになりました。
何を直すか。何を今は直さないか。どこに投資するか。
その判断を助ける材料として、サポートのデータが自然に混ざっている状態を作りたいです。
そのために、数字もテキストを強い言葉にしすぎず、余白を残して渡す。
やり始めたら信じてやり続ける。でも、固執しない。柔軟さと俯瞰を忘れない。
このバランスを大切にしながら、来年も積み上げていきたいと思います🙌
ここまでお読みいただきありがとうございました🙇♀️
今回は、サポートの問い合わせデータ分析の裏側にフォーカスしてみましたが、いかがだったでしょうか？
プロダクト・ビジネス・顧客のハブとして顧客体験をアップデートしていくhacomonoサポートにご興味をお持ちいただけたら幸いです！
hacomono note 編集部では、hacomonoサポートの人にフォーカスする「#hacomonoSupportStories」を公開中です✨
▷ 第1弾の記事「サポートは、プロダクトの「外へのインターフェース」──顧客の声を起点に、プロダクトを磨く」
第2弾の記事も公開予定ですので、noteをフォローしてお待ちください🏃♀️
