問い合わせの記録はマーケの資産｜サポートと組む理由

「記事の企画を出すとき、読者の悩みを想像で書いている」「顧客の生の言葉が社内のどこにあるのか分からない」——マーケの現場でよく聞く行き詰まりです。顧客の言葉は、外から買ってくるものではありません。問い合わせの記録として、すでに社内にたまっています。この記事では、サポートの記録から企画の材料を取り出す手順と、連携が続く形を整理します。

対応の履歴という誤解

サポートの記録は、対応が完了すれば役目を終えると考えられています。この理解が、材料を捨てています。

記録には、顧客が自分の言葉で書いた困りごとが残っています。この形の資料は他にありません。

マーケの側が想像で書いている読者の悩みは、多くの場合こちらの言葉に翻訳されています。

翻訳された言葉は、検索の言葉と一致しません。顧客は、業界の用語ではなく自分の言葉で検索します。

問い合わせの本文には、その言葉がそのまま入っています。翻訳の前の状態です。

さらに、記録には困りごとの前後の状況も入っています。何をしようとして詰まったのかが書かれています。

この前後の状況が、記事の構成を決める材料になります。想像では作れません。

加えて、同じ問い合わせが繰り返される場合、その内容は多くの人が詰まる点です。優先度の判断ができます。

件数の多い順に記事を作れば、需要のある順に対応できます。推測で順序を決める必要がなくなります。

つまりこの記録は、読者の悩みと優先度の両方を教えてくれる資料です。

それでも活用されないのは、価値が分からないからではありません。取り出す手間が大きいためです。

以下では、まず使える3つの用途を示し、その後に取り出す仕組みを扱います。

仕組みの話が本題になります。用途は分かっていても、続かないのが実情です。

記録に含まれているもの

実際にどんな情報が入っているのかを整理します。用途の判断の前提になります。

記録に残っている情報	そこから読み取れること	使いどころ
困りごとの本文	顧客が使う言葉と、詰まった前後の状況	記事の題名と冒頭の書き方
問い合わせの件数と分類	多くの人が詰まる場所と優先度	記事の企画の順序
受け付けた時期	年度や季節による偏り	記事を出す時期の判断
対応の履歴	どう説明したら理解されたか	手順の書き方と説明の型
問い合わせ前に読まれたページ	記事を読んでも解決しなかった箇所	既存の記事の改善

含まれているのは、困りごとの内容、使っていた状況、そして使った言葉です。

加えて、いつ問い合わせが来たか、どの機能に関するものかという分類も残ります。

時期の情報は、季節性の判断に使えます。年度の初めに増える問い合わせがあります。

機能の分類は、どの部分が分かりにくいかを示します。改善の優先度の材料になります。

さらに、対応の記録には、どう説明したら理解されたかが残っています。説明の型の材料です。

理解されなかった説明の履歴も残ります。避けるべき説明の仕方が分かります。

この後半の情報は、記事の書き方に直接使えます。理解されない説明を記事に書いても、同じことが起きます。

また、問い合わせの前に読まれたページが分かる場合もあります。記事を読んでも解決しなかった証拠です。

この情報は、既存の記事の改善の材料として最も価値があります。読まれたのに解決していません。

解決しなかった理由は、記録の本文から推測できます。多くは、前提の説明が足りていません。

以上を踏まえて、使える用途を3つに整理します。全部を使う必要はありません。

1つから始めて、続く形を作るのが実務的です。

記事の企画に使う

最も分かりやすい用途は、記事の企画です。書くべき題材が記録の中にあります。

件数の多い問い合わせを上から並べれば、それが記事の優先度になります。

件数が多いということは、多くの人が同じ場所で詰まっているということです。検索もされています。

記事にすれば、問い合わせの件数が減ります。サポートの側にも利点があります。

この利点が、連携を続ける動機になります。一方的にもらう関係では続きません。

記事の構成も、記録から作れます。問い合わせの本文が、そのまま読者の状況の説明になります。

対応の記録が、そのまま解決の手順になります。書く内容を考える工程が短くなります。

ただし、記録の文章をそのまま載せてはいけません。個人や企業が特定される情報が含まれます。

扱いの線引きは後の節で扱います。まずは題材と構成の材料として使います。

月に10件の問い合わせがあれば、そこから2本から3本の記事が作れます。

この2本から3本が、実際の需要に基づいた記事になります。想像で書いた記事より読まれます。

読まれる理由は単純です。実際に困った人がいる題材だからです。

検索の言葉も、記録から拾えます。次の節で扱います。

顧客の言葉を拾う

2つ目の用途は、言葉の選び方です。記事の見出しや資料の表現に使います。

顧客が使う言葉と、こちらが使う言葉は違います。この差が、検索で見つからない原因になります。

たとえばこちらが「配信の到達率」と呼ぶものを、顧客は「メールが届かない」と書きます。

検索されるのは後者です。前者の言葉だけで記事を書くと、検索で出会えません。

記録から拾った言葉は、見出しに使います。本文の冒頭にも入れます。

両方に入れると、検索の言葉と記事の内容が一致します。読者も自分の悩みだと分かります。

拾い方は単純です。問い合わせの本文から、動詞を含む短い言い回しを抜き出します。

名詞だけを抜くと、業界の用語に寄ります。動詞を含む形で抜くのが要点です。

抜いた言い回しは、一覧にして溜めます。月に一度追加する形で足ります。

一覧が育つと、記事の題名を考える時間が短くなります。実際の言葉から選べます。

この一覧は、広告の文面にも使えます。反応の良い言い回しは、顧客の言葉であることが多くあります。

資料の見出しにも使えます。相手が自分の言葉を見ると、読み進めます。

溜める場所は、記事の企画の一覧と同じファイルにします。別だと参照されません。

商談の前の不安を把握する

3つ目の用途は、導入の前後に出る不安の把握です。営業の材料になります。

導入の直後に多い問い合わせは、商談の段階で説明が足りなかった部分を示します。

この情報を営業に渡せば、商談の説明を先に厚くできます。導入後の不満が減ります。

たとえば、設定の手順についての問い合わせが導入の初月に集中しているとします。

これは、商談の段階で設定の負担が伝わっていなかったことを意味します。期待の水準がずれています。

ずれたまま導入すると、初月の満足度が下がります。継続の判断に影響します。

商談の段階で正直に伝えれば、期待の水準が合います。導入後の評価が上がります。

この情報は、商談の資料に反映します。導入の流れの説明を1枚追加する形です。

さらに、よくある質問の資料も更新できます。実際に来た質問から作れます。

想像で作ったよくある質問は、実際には聞かれない項目が並びます。記録から作ると精度が変わります。

この用途は、営業とサポートの両方に利点があります。連携の動機になります。

動機が3方向に立つと、仕組みが続きます。1方向だけの利点では続きません。

次の節から、続く仕組みの作り方を扱います。ここが本題です。

連携が続かない理由

価値が分かっていても、連携は続かないことが多くあります。原因を分解します。

原因は熱意ではなく、取り出す作業の手間です。手間が大きい仕組みは、忙しい月に止まります。

止まった仕組みは、再開しません。再開には最初と同じ労力がかかります。

よくある形は、マーケの担当がサポートに毎月依頼するというものです。依頼される側の作業になります。

依頼される側にとって、この作業は本来の業務の外です。優先度は必ず下がります。

下がった優先度の作業は、繁忙期に飛ばされます。飛ばされた月が2回続くと、仕組みが消えます。

解決の方向は2つあります。作業を減らすか、依頼をやめて自分で取りに行くかです。

後者のほうが確実です。マーケの側が記録を直接読める形にします。

読める形にするには、権限の付与が必要です。ここに個人情報の扱いの問題が出ます。

扱いの線引きを先に決めておけば、権限の話は進みます。線引きが曖昧だと止まります。

線引きは後の節で扱います。まず、作業を軽くする方法を見ます。

軽くする方向と、自分で取りに行く方向は、両立します。両方を進めます。

進めるときは、サポートの側の負担が増えないことを最初に伝えます。信頼の前提になります。

取り出す作業を軽くする

作業を軽くする方法を具体的に扱います。仕組みの設計の話です。

最も軽いのは、既存の分類を使って一覧を出す形です。新しい入力を求めません。

サポートの側に新しい項目の入力を頼むと、必ず抵抗が出ます。既にある項目で足ります。

既にある分類が粗い場合も、そのまま使います。粗い分類でも、件数の多い順は分かります。

件数の多い上位5つを見れば、記事の題材としては十分です。細かい分類は必要ありません。

次に軽いのが、月に一度、直近の記録を読む時間を作る形です。30分で足ります。

30分で20件から30件は読めます。読みながら、言い回しを一覧に写します。

この作業は、マーケの側が行います。サポートに依頼しません。

依頼が発生しない仕組みは、相手の繁忙期に影響されません。続く条件です。

読む権限の付与だけを一度お願いすれば、以後の依頼は不要になります。

権限の付与は、1回の相談で終わります。継続の依頼と比べて、はるかに軽い交渉です。

生成AIに要約させる形も使えます。ただし記録を外部に出す場合は、扱いの規程を確認します。

確認せずに使うと、後で問題になります。要約の便利さより、規程の確認が先です。

分類の粒度を決める

記録を使うときに、分類の粒度で迷うことがあります。決め方を扱います。

粒度は、記事の単位に合わせます。記事1本で扱える範囲が、1つの分類になります。

細かすぎる分類は、1つあたりの件数が減り、優先度が判断できません。

粗すぎる分類は、記事の題材にならず、内容を決められません。

目安として、分類の数は10から15に収めます。この範囲だと、月次の件数が意味を持ちます。

分類の名前は、顧客の言葉に寄せます。機能の名前ではなく、困りごとの言い方にします。

たとえば「設定」ではなく「最初の設定でつまずく」という形です。記事の題名に近づきます。

既存の分類が機能の名前になっている場合は、対応表を作ります。分類そのものは変えません。

対応表があれば、サポートの側の運用を変えずに、マーケの側の見方を変えられます。

相手の運用を変えない工夫が、連携を続ける鍵になります。

対応表は1枚で足ります。四半期に一度、実態に合わせて見直します。

見直しの材料は、実際の記録です。分類に入らない問い合わせが増えていたら、分類を足します。

足す判断は、月に3件を超えた時点で行います。基準を決めておくと迷いません。

月に1回の共有の型

読むだけでも価値はありますが、共有の場を作ると効果が広がります。型を決めます。

4つ目が、この型の中心です。結果を返すことが、次の月の協力を作ります。

返す内容は、記事の本数と件数の変化の2つで足ります。詳しい分析は不要です。

3つ目で開発に回すものを分けるのが重要です。記事で解決できない問題を記事にしても減りません。

この判断を月次で行うと、開発への要望も溜まります。優先度の根拠付きで渡せます。

全体の所要は1時間です。1時間の投資で、記事の企画と言葉の材料が両方そろいます。

共有の場は、会議にしなくても構いません。文書を回す形でも成立します。

サポート側の見返りを設計する

連携を続けるには、相手にとっての利点が必要です。設計の考え方を扱います。

最も分かりやすい見返りは、問い合わせの件数が減ることです。記事が同じ質問に答えます。

減ったことを数字で見せると、協力が続きます。見せないと、記事の効果が伝わりません。

次の見返りは、対応に使える記事が増えることです。返信に記事のURLを添えられます。

説明を毎回書く手間が減ります。記事の質が高ければ、対応の質も上がります。

この用途を想定するなら、記事の書き方も変わります。手順を明確に区切って書きます。

区切って書けば、サポートが「3の手順を確認してください」と伝えられます。参照しやすい形です。

3つ目の見返りは、要望が開発に届くことです。マーケが優先度の根拠を付けて渡します。

サポートの側だけでは、要望の優先度を示す材料が足りない場合があります。件数の集計が助けになります。

この3つの見返りを最初に伝えておくと、権限の相談が通りやすくなります。

伝えるときは、こちらの得たいものも正直に伝えます。取引として説明したほうが続きます。

隠して協力を求めると、後で不信が生まれます。目的を明示するのが早道です。

半年後に、見返りが実際に出ているかを確認します。出ていなければ、仕組みを見直します。

個人情報の扱いの線引き

記録を使う上で、避けて通れないのが情報の扱いです。線引きを先に決めます。

記事や資料に載せてよいのは、個人も企業も特定できない形に加工したものだけです。

問い合わせの本文をそのまま引用するのは避けます。特定の可能性が残ります。

使うのは、困りごとの型と、言い回しの傾向です。個別の事例としては書きません。

言い回しを使う場合も、そのままの文ではなく、複数から共通する形に整えます。

整える手間は小さくありません。しかし、この手間を省くと問題が起きます。

社内の規程を先に確認します。記録の閲覧の範囲と、外部の道具への入力の可否が論点になります。

生成AIに要約させる場合は、この2つ目が関わります。規程で禁じられている場合があります。

禁じられている場合は、手作業で読みます。30分の作業なので、実行できます。

規程の確認を飛ばして始めると、後で仕組みごと止められます。最初に確認します。

確認の相手は、法務か情報の管理の担当です。5分の相談で済むことが多くあります。

確認した内容は、文書に残します。担当が変わったときに、また確認する手間が省けます。

残す内容は、閲覧の範囲、加工の要件、外部の道具の可否の3点です。

やりがちな失敗

この連携には、繰り返し起きる失敗があります。

• サポートに毎月の集計を依頼し、繁忙期に止まってそのまま消える
• 新しい分類の入力を頼み、本来の業務の外の作業として抵抗される
• 記録を読むだけで、記事の公開や件数の変化を返さず、協力が続かない
• 問い合わせの本文をそのまま記事に引用し、特定の可能性を残す
• 規程を確認せずに記録を外部の道具に入力する
• 記事で解決できない仕組みの問題を記事にして、件数が減らない

1つ目と2つ目は、相手の負担を増やす設計の失敗です。設計を変えれば防げます。

3つ目は、最も多い失敗です。もらうだけの関係は、3か月で終わります。

4つ目と5つ目は、取り返しがつきにくい失敗です。先に線引きを決めておきます。

6つ目は、判断の工程を飛ばした結果です。記事で解決できるかを毎回判断します。

判断の基準は単純です。手順の説明で解決するなら記事、動作の変更が必要なら開発です。

この基準を月次の作業に組み込みます。組み込まないと、記事の企画に流れます。

定着までの3か月

仕組みが定着するまでの進め方を、月ごとに整理します。

1か月目は、権限の相談と規程の確認だけを行います。記事は作りません。

この月に急いで記事を出すと、線引きが曖昧なまま進みます。後で戻せません。

2か月目に、記録を読み、上位5つと言い回しの一覧を作ります。記事の候補を2本決めます。

この月に、サポートに向けて何をするかを説明します。目的と見返りを伝えます。

3か月目に、記事を公開し、件数の変化を返します。ここで初めて往復が成立します。

往復が1回成立すると、4か月目以降は軽くなります。型が決まるためです。

3か月で成果が出ない場合も、止めません。件数の変化は3か月では見えにくいものです。

半年で判断します。半年で問い合わせの上位の構成が変わっていれば、効いています。

変わっていない場合は、記事の質か、記事の見つけやすさに原因があります。

見つけやすさの問題であれば、サポートの返信に記事のURLを添える運用を加えます。

この運用が入ると、記事が確実に読まれます。検索を待たずに届きます。

届いた記事の効果は、返信の手間の減少で測れます。サポートの側が実感します。

点検の項目

四半期に一度、次の項目を確認します。

• 記録の閲覧の権限が、マーケの担当に付与されているか
• 月に一度、記録を読む時間が予定に入っているか
• 言い回しの一覧が更新され、記事の題名に使われているか
• 公開した記事と件数の変化を、サポートに返しているか
• 記事で解決できない問題を、開発への要望として分けているか
• 個人情報の扱いの線引きが文書に残り、加工の要件が守られているか
• 分類に入らない問い合わせが増えていないか

4つ目が最も飛ばされやすい項目です。忙しい月に返さないと、協力が細ります。

2つ目は、予定に入っていなければ実行されません。定例の予定として確保します。

6つ目は、担当が変わったときに確認します。前任の理解が引き継がれていないことがあります。

7つ目は、事業や商材が変わったときの兆候です。分類の見直しの合図になります。

点検は20分で終わります。項目を減らさず、短く済ませます。

運用に残す取り決め

担当が変わっても続くように、文書に残します。

• 記録の閲覧の範囲と、閲覧できる担当の名前
• 個人情報の扱いの線引き（加工の要件・そのままの引用の禁止・外部の道具の可否）
• 月次の作業の手順（上位5つの抽出・本文を3件ずつ読む・記事の候補2本・結果の返却）
• 分類の対応表（サポートの分類とマーケの見方の対応）と見直しの時期
• 記事で解決するか開発に回すかの判断の基準
• サポートへ返す内容（公開した記事の本数と件数の変化）と返す時期

2つ目を最初に決めるのが順序です。ここが曖昧なまま進めると、後で止まります。

6つ目は、協力を続けるための取り決めです。返す時期を決めておかないと飛ばされます。

この文書は、サポートの側にも共有します。片方だけが持つと、認識がずれます。

更新は、線引きや手順を変えたその日に行います。

半年に一度、サポートと一緒に読み返します。負担が増えていないかを確認します。

使う言葉の整理

この領域では、似た言葉が混ざります。社内で意味を合わせておきます。

問い合わせの記録とは、顧客から届いた本文と、対応の履歴の両方を指します。

件数の集計とは、分類ごとの月次の数のことです。個別の内容は含みません。

言い回しの一覧とは、顧客が使った短い表現を溜めた表です。検索の言葉の材料になります。

分類の対応表とは、サポートの分類とマーケの見方をつなぐ表です。運用は変えません。

記事の候補とは、手順の説明で解決できる題材のことです。動作の変更が必要なものは含みません。

開発への要望とは、動作の変更が必要な問題を、件数の根拠付きで渡す文書です。

これらの言葉を1枚にまとめて、関係者に配ります。会議での認識のずれが減ります。

配る相手は、マーケ、サポート、営業の3者です。開発にも共有すると要望が通りやすくなります。

言葉が合っていない状態で仕組みを作ると、依頼の内容が伝わりません。

1枚の作成は30分です。最初の月に作っておきます。

年に一度見直します。使われていない言葉は削り、新しく生まれた言葉を足します。

削る作業も忘れずに行います。増え続ける一覧は、読まれなくなります。

まとめ

サポートに届く問い合わせの記録は、対応の履歴ではなく、顧客が自分の言葉で困りごとを説明した一次の資料です。件数の多い順に並べれば記事の優先度が分かり、本文からは検索される言い回しが拾えます。導入の直後に多い問い合わせは、商談の段階で説明が足りなかった部分を示します。

連携が続かない原因は熱意ではなく手間です。サポートに毎月の集計を依頼する形は、相手の繁忙期に止まり、そのまま消えます。既存の分類のまま上位5つを出し、マーケの側が月に30分読む形にすれば、依頼が発生しないため続きます。必要なのは閲覧の権限を1回相談することだけです。

進め方は、1か月目に権限の相談と規程の確認、2か月目に記録の読み込みと記事の候補の決定、3か月目に公開と件数の変化の返却です。返すことが次の協力を作ります。個人情報の扱いは先に線引きを決め、本文のそのままの引用は避け、複数から共通する形に整えて使います。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。