問い合わせ管理をスプレッドシートで作る｜持つ項目は7つ、状態は4つ。ツールを選ぶ前に決めること

問い合わせが、メール、電話、フォーム、チャットからバラバラに届く。誰が対応しているのか分からず、同じ相手に二人が返信する。数日前の問い合わせが、返さないまま埋もれる。

この状態を解決しようとして、多くの会社はまず問い合わせ管理ツールを探します。ただ、その前に決めておくことがあります。持つ項目と、状態の区分です。ここが決まっていないと、どのツールを入れても同じ混乱が起きます。この記事では、スプレッドシート1枚で問い合わせ台帳を作る手順と、そこで決めた設計をツール選定にそのまま使う方法を説明します。

ムダの現状：受信箱が台帳の代わりになっている

問い合わせ対応で時間が消えている場所は、返信を書く作業ではありません。

時間を食うのは、その手前です。誰がこの件を見ているのかを確認する、前回どう答えたかを探す、返したかどうかを思い出す。この3つで、対応そのものと同じくらいの時間が使われています。

受信箱が台帳にならない、3つの理由

多くの会社では、個人のメール受信箱がそのまま台帳として使われています。これがうまくいかないのには、はっきりした理由があります。

4つとも、受信箱の使い方が悪いのではありません。受信箱は届いたものを並べる道具であって、状態を管理する道具ではない。役割が違います。

機械に渡せる部分と、人に残す部分

問い合わせ対応のうち、機械に渡せるのは限られています。先に切り分けておきます。

4番目の「滞留の検出」を機械に渡すのが、この記事の中心です。人が覚えている限り、必ず漏れます。

スキームの全体図：入口を1本にして、状態を4つに絞る

順番が重要です。ツールを先に入れると、そのツールが持っている項目と状態に業務を合わせることになります。自社にとって何が必要かを先に確かめてから選ぶと、選定の基準がはっきりします。

必要なツールと費用（2026年9月23日時点）

問い合わせ管理の専用ツールを検討する前に、この5つで3か月回してみてください。月に何件来るのか、どの分類が多いのか、滞留がどこで起きるのか。この3つが分かると、ツールに何を求めるかが決まります。先にツールを入れると、この判断材料が手に入りません。

導入手順：1チャネルだけで台帳を回す

Step 1：入口を数えて、1本に寄せる

最初にやるのは、過去1か月にどこから何件来たかを数えることです。

メール、電話、フォーム、チャット、営業担当への直接の連絡。件数を数えると、たいてい特定の経路に偏っています。まずそこを台帳に乗せます。

あわせて、メールの受け口を個人のアドレスから共有のアドレスに移してください。ここを変えないと、台帳に入らない問い合わせが残り続けます。名刺や署名に個人アドレスが載っている場合はすぐには変えられないので、個人宛に来たものはその日のうちに共有側へ転送するという運用を決めます。

電話については、その場で台帳に入れるのは現実的ではありません。通話の後に30秒で入力できるフォームを用意し、そこから入れる形にしてください。電話を台帳に乗せないと、最も記録が残らない経路が空白のままになります。

Step 2：持つ項目を、7つに決める

台帳の列は7つです。これ以上増やさないでください。

問い合わせの本文は、この7つとは別に1列持たせるか、元のメールへのリンクを置きます。台帳の役割は状態の管理であって、内容の保管ではありません。

増やしたくなる列と、増やしてはいけない理由

運用を始めると、列を足したくなります。「優先度」「対応にかかった時間」「満足度」「再発かどうか」。どれも有用そうに見えます。

ただ、列を足すたびに、入力されない列が増えます。入力されない列が混ざった台帳は、集計に使えません。

足すなら、3か月回してから1つずつにしてください。そして、足すときは「この列を使って何を判断するか」を先に決めます。判断に使わない列は、入力の手間だけが増えます。

Step 3：状態を、4つに絞る

状態の区分は、多くすると使われなくなります。4つで足ります。

要点は3つ目の「返答待ち」を独立させることです。相手の返事を待っている件は、こちらの遅れではありません。ここを「対応中」に含めると、毎朝の通知に待ちの件が混ざり、通知そのものが見られなくなります。

ただし、返答待ちを放置すると別の問題が起きます。相手が返事を忘れたまま数週間経つ、ということが普通に起きるからです。返答待ちにも期限を持たせ、過ぎたら「こちらから一度確認する」という扱いにしてください。通知の宛先と文面を対応中とは分けます。

Step 4：滞留を、毎朝自動で出す

次のApps Scriptは、台帳を見て期限を過ぎた件を担当ごとにまとめ、1本の文面にします。

function buildOverdueReport() {
  var sh = SpreadsheetApp.getActive().getSheetByName('台帳');
  var rows = sh.getDataRange().getValues();
  var head = rows.shift();
  var col = {};
  for (var i = 0; i < head.length; i++) { col[head[i]] = i; }
  var now = new Date();
  var groups = {};
  for (var r = 0; r < rows.length; r++) {
    var row = rows[r];
    var state = String(row[col['状態']]).trim();
    if (state === '完了') { continue; }
    if (state === '') { continue; }
    var due = row[col['期限']];
    if (!(due instanceof Date)) { continue; }
    if (due >= now) { continue; }
    var owner = String(row[col['担当']]).trim();
    if (owner === '') { owner = '未割当'; }
    var days = Math.floor((now - due) / 86400000);
    if (!groups[owner]) { groups[owner] = []; }
    groups[owner].push({ days: days, state: state, who: row[col['相手']], kind: row[col['分類']] });
  }
  var lines = [];
  var owners = Object.keys(groups).sort();
  for (var k = 0; k < owners.length; k++) {
    var list = groups[owners[k]];
    list.sort(function (a, b) { return b.days - a.days; });
    lines.push(owners[k] + '（' + list.length + '件）');
    for (var m = 0; m < list.length; m++) {
      var it = list[m];
      lines.push('  ' + it.days + '日超過 / ' + it.state + ' / ' + it.who + ' / ' + it.kind);
    }
  }
  if (lines.length === 0) { return '期限を過ぎた問い合わせはありません。'; }
  return lines.join('\n');
}

実装で押さえている点を3つ挙げます。

1つ目、状態が空の行を飛ばしていること。台帳に入ったが状態が入力されていない行を通知に混ぜると、毎朝同じ行が並びます。空の行は、台帳の使われ方に問題があるサインなので、通知ではなく別途まとめて確認します。

2つ目、超過日数の大きい順に並べていること。単に期限順に出すと、上のほうに並ぶ件ばかりが処理され、古い件がいつまでも残ります。

3つ目、担当ごとにまとめていること。全件を1つの並びで出すと、自分の件を探すところから始まります。探す手間があると、通知は読まれなくなります。

通知の宛先は、個人ではなくチームのチャットにしてください。個人宛に送ると、休んでいる人の件が誰にも見えません。全員が見える場所に出すことで、手が空いている人が拾える形になります。

Step 5：月に1回、分類の分布を見る

台帳の本当の価値は、対応を速くすることではありません。同じ問い合わせが来なくなることです。

月に1回、分類ごとの件数を集計してください。上位3つに手を打ちます。

手の打ち方は、分類の中身で決まります。使い方が分からないという問い合わせが多いなら、説明の文章か画面の表示を直す。手続きの方法を聞かれるなら、案内のページを作る。同じ不具合の報告が続くなら、それは問い合わせ対応ではなく製品側の問題です。

ここで、分類を細かくしすぎないでください。10個以内に収めるのは、集計したときに件数がばらけないようにするためです。分類が30個あると、どれも数件ずつになり、上位3つを選べません。

最初の1か月は、1つの経路だけで回す

全経路を同時に台帳に乗せないでください。

最初の1か月は、件数が最も多い経路だけにします。入力が30秒で終わるか、状態が更新されるか、毎朝の通知が読まれるか。この3つを確認してから、他の経路を足します。

1か月やってみると、たいてい調整が必要な箇所が見つかります。分類の選択肢が実態と合っていない、期限の初期値が短すぎる、通知の時刻が朝礼の後になっている。こうした細かい問題は、範囲が狭いうちに直すほうが早く終わります。

現場の合意の取り方：件数を評価に使わないと決める

台帳が続くかどうかは、入力が続くかどうかで決まります。そして入力が止まる理由は、面倒だからだけではありません。

個人別の件数を、集計しない

対応件数を個人別に出すと、件数が稼げる問い合わせが選ばれるようになります。時間のかかる件が後回しになり、簡単な件から処理される。台帳の数字は良くなり、実際の顧客対応は悪くなります。

集計の軸は、分類別・経路別・状態別の3つに限ってください。担当者別の集計は作らない。口頭の約束ではなく、集計を作らない設計にすることで担保します。

ただし、滞留の通知は担当ごとにまとめる必要があります。これは評価ではなく、誰に手が回っていないかを見つけるためです。この違いを、仕組みを始めるときに言葉で説明してください。

入力を30秒に収める

7つの項目のうち、人が入れるのは実質3つか4つです。受付日時は自動、経路はフォームなら自動、期限は受付日時から自動で計算できます。

相手と分類と担当を選ぶだけなら、30秒で終わります。この「30秒で終わる」を、説明のときに実際に画面でやって見せてください。言葉で説明するより早く納得が得られます。

そして、入力が30秒を超えている項目があれば、それは自動で入れられないかを先に考えてください。相手の名前を毎回手で打っているなら、過去に問い合わせのあった相手を選択肢に出す。期限を手で決めているなら、分類ごとの初期値を持たせる。入力を軽くする工夫は、ルールで守らせるより確実に効きます。

失敗パターンと限界：台帳は個人データになる

問い合わせ台帳は、個人データとして扱う

問い合わせ台帳には、相手の氏名、会社名、連絡先、問い合わせの内容が並びます。個人を識別できる情報を検索できる形で並べたものは、個人情報保護法でいう個人データにあたります。

同法第23条は、個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならないと定めています。

第24条は従業者の監督を、第25条は委託先の監督を求めています。台帳をスプレッドシートで作る場合、実務上いちばん問題になるのは共有の設定です。リンクを知っている全員が閲覧できる設定にしたまま運用する、というのがよくある形です。

やることは3つです。共有の範囲を必要な人に限ること。閲覧できる人の一覧を、年に1回は見直すこと。そして、外部の業者に対応を委託する場合は、その業者の取扱いについても確認すること。

漏えいが起きたときに、法令上求められること

設計の前に、起きたときに何が求められるかを知っておいてください。

同法第26条第1項は、その取り扱う個人データの漏えい、滅失、毀損その他の個人データの安全の確保に係る事態であって個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定めるものが生じたときは、当該事態が生じた旨を個人情報保護委員会に報告しなければならないと定めています。第2項は、本人に対しても当該事態が生じた旨を通知しなければならないとしています。

ここでいう「規則で定めるもの」は、個人情報の保護に関する法律施行規則第7条が4つ挙げています。

報告の期限も、同規則が定めています。第8条第1項は、第7条各号に定める事態を知った後、速やかに、把握している事項を報告しなければならないとしています。報告する事項は、概要、漏えい等が発生した個人データの項目、本人の数、原因、二次被害又はそのおそれの有無及びその内容、本人への対応の実施状況、公表の実施状況、再発防止のための措置、その他参考となる事項の9つです。

そして第8条第2項は、当該事態を知った日から30日以内（第7条第3号に定める事態、つまり不正の目的をもって行われたおそれがある行為による場合は60日以内）に、同じ事項を報告しなければならないとしています。

この期限から逆算すると、台帳の設計で必要なことが決まります。誰の情報が何件入っているかを、後から数えられる状態にしておくことです。報告事項には本人の数が含まれます。台帳が複数の場所に散らばっていると、この数が出せません。

なお、具体的な報告の手続きや、どこまでが報告対象にあたるかの判断には個別の事情が関わります。実際に事態が起きた場合は、個人情報保護委員会が公表している案内を確認し、必要に応じて弁護士など専門家に相談してください。

消す設計を、先に決める

台帳は、放っておくと増え続けます。

同法第22条は、個人情報取扱事業者は、利用目的の達成に必要な範囲内において、個人データを正確かつ最新の内容に保つとともに、利用する必要がなくなったときは、当該個人データを遅滞なく消去するよう努めなければならないと定めています。

努力義務ではありますが、運用としては先に決めておくほうが楽です。完了から何年で削除するか、削除の対象は行そのものか個人を特定できる列だけか。分類と件数だけを残して個人の情報を消せば、集計は続けられます。

この判断は、自社が問い合わせの記録を何に使うかで変わります。品質改善のためだけなら個人の情報は不要です。契約や請求に関わる記録が混ざる場合は、別の保存の要件が関わるので、対象を分けて考えてください。

この仕組みが向かない場合

月に数百件を超える規模では、スプレッドシートの台帳は動きが重くなります。この場合は、ここで決めた7つの項目と4つの状態を要件として、専用のツールを選ぶ段階です。設計が手元にあれば、ツールの比較は早く終わります。

また、返答までの時間を契約で定めている場合は、この仕組みだけでは足りません。契約で定めた時間を守れたかどうかを記録し、守れなかった場合の扱いまで設計する必要があります。

逆に、問い合わせが月に数件しかない規模では、台帳を作る効果は限定的です。この場合は共有の受け口を作るところまでで十分です。

AIを足すなら、自動返信ではなく分類から

問い合わせ対応にAIというと、自動で返信を作る使い方が思い浮かびます。ただ、台帳を作った直後に効くのは別の使い方です。

問い合わせの本文から、分類の候補を出させる使い方です。人が選ぶのは変わりませんが、候補が出ていれば選ぶ時間が短くなります。そして、分類の入力漏れが減ります。

自動返信は、分類の分布が安定してからの話です。どんな問い合わせが来るかが分かっていない状態で自動返信を作ると、想定していない問い合わせに的外れな返信をすることになります。順番は、記録する、分類する、多いものに手を打つ、そのうえで定型化できるものを自動にする。この順です。

効果の測り方

1つ目は、平均ではなく中央値で見てください。調査に時間がかかった1件が平均を大きく動かします。中央値なら、ふだんの状態が見えます。

2つ目は、最初の月は増えます。これまで見えていなかった滞留が、通知に出るようになるだけだからです。ここで効果が出ていないと判断しないでください。減り始めるのは、2か月目か3か月目です。

3つ目が、この仕組みの本当の効果を示します。上位3分類に手を打った結果、その分類の件数が減っているか。減っていれば、対応が速くなったのではなく、問い合わせそのものが減っています。こちらのほうが、現場の負担には大きく効きます。

まとめ

問い合わせ対応で時間が消えているのは、返信を書く作業ではありません。誰が見ているかを確認し、返したかどうかを思い出す部分です。個人の受信箱は、届いたものを並べる道具であって、状態を管理する道具ではありません。

やることは3つです。入口を1本に寄せること。台帳の項目を7つに決めること。そして、状態を4つに絞ることです。とくに「返答待ち」を独立させると、毎朝の通知から待ちの件が消え、通知が読まれるようになります。

滞留の検出は機械に渡します。人が覚えている限り必ず漏れます。超過日数の大きい順に、担当ごとにまとめて、チームの全員が見える場所に出す。

合意は、個人別の件数を集計しないと決めることで取ります。集計の軸を分類別・経路別・状態別に限り、担当者別は作らない。設計としてそうしておくことで、正直な記録が続きます。

そして、台帳は個人データです。共有の範囲を限り、消す時期を先に決めておく。ツールを選ぶのは、この設計が3か月回ってからで十分です。

よくある質問

項目は7つで足りますか。優先度の列は要りませんか

最初は7つで始めてください。優先度は、入れても基準がないと使われません。3か月回して、期限だけでは足りないと分かってから足すほうが、実態に合う基準が作れます。列を足すときは、その列を使って何を判断するかを先に決めてください。

「返答待ち」を独立させる意味がよく分かりません

相手の返事を待っている件は、こちらの遅れではありません。ここを「対応中」に含めると、毎朝の滞留通知に待ちの件が混ざります。通知の大半が自分の責任ではない件になると、通知そのものが読まれなくなります。ただし返答待ちも放置はできないので、期限を長めに取って別の通知にしてください。

電話の問い合わせは、どう台帳に入れますか

通話中の入力は現実的ではないので、通話の後に30秒で入力できるフォームを用意してください。電話を台帳に乗せないと、最も記録の残らない経路が空白のままになります。件数が分からない経路があると、分類の分布も偏ります。

滞留の通知は、個人宛に送るべきですか

チームの全員が見える場所に出してください。個人宛だと、休んでいる人の件が誰にも見えません。担当ごとにまとめるのは、誰に手が回っていないかを見つけるためであり、評価のためではないことを、始めるときに説明しておいてください。

台帳のデータは、いつまで残せばよいですか

自社が記録を何に使うかで変わります。品質改善のためだけなら、一定期間を過ぎたら分類と件数だけを残して個人の情報を消す形が取れます。契約や請求に関わる記録が混ざる場合は別の保存の要件が関わるため、対象を分けて考えてください。判断に迷う場合は専門家に確認してください。

専用のツールを最初から入れたほうが早いのではないですか

ツールを先に入れると、そのツールが持つ項目と状態に業務を合わせることになります。3か月スプレッドシートで回すと、月に何件来るのか、どの分類が多いのか、滞留がどこで起きるのかが分かります。この3つが分かった状態で選ぶと、比較が早く終わります。設計はそのまま要件として使えます。

同じ部門の記事

サポート顧客対応の記録と打ち切りの基準｜判断を個人から組織に移す3段階の設計2026年10月2日
サポート問い合わせ対応をAIに任せる前にやること｜過去3か月を数えてFAQを20件固め、答えを決めてから渡す2026年9月26日