kintone問い合わせ管理の設計方法｜受付・担当・対応履歴・FAQ化まで

kintoneで問い合わせ管理を作るとき、最初に考えやすいのは問い合わせ一覧です。

受付日、会社名、担当者名、メールアドレス、問い合わせ内容、対応担当、ステータス、回答内容。

これを1つのアプリに並べれば、問い合わせ管理アプリらしい画面は作れます。

フォームからkintoneに登録したり、メールの内容を転記したりすれば、Excelや個人メールよりは見える化できます。

ただし、問い合わせ対応で本当に崩れるのは、問い合わせを登録できないことではありません。

実務で困るのは、次のような状態です。

• Webフォーム、メール、電話、Slack、営業経由の問い合わせが別々に残る
• 同じ顧客からの過去問い合わせが見えない
• ステータスは「対応中」だが、誰が次に何をするのか分からない
• 担当者が変わったとき、過去の判断や返信理由が引き継がれない
• 返信内容がコメント欄やメールボックスに散らばる
• 添付ファイルやスクリーンショットの確認状態が残らない
• 初回返信期限や解決目標がなく、滞留に気づけない
• 同じ質問が何度も来ているのにFAQやナレッジにならない
• フォーム、メール共有、Slack、CRMのどれを正本にするか決まっていない

問い合わせ管理は、問い合わせを一覧化する仕事ではありません。

受付した内容を、顧客、担当者、対応履歴、返信、FAQ、改善テーマへつなぐ業務です。

kintone問い合わせ管理で最初に決めるべきなのは、ステータス名ではなく、「問い合わせの正本と対応履歴の正本をどこに置くか」です。

この記事では、kintoneで問い合わせ管理を対応漏れのない業務システムとして設計する方法を整理します。

kintone顧客管理の設計方法はこちら
kintoneタスク管理の設計方法はこちら

先に結論：問い合わせ管理は「受付」「対応」「ナレッジ」を分ける

kintoneで問い合わせ管理を作るとき、問い合わせアプリ1つだけでも始めることはできます。

ただし、チームで対応するなら、最初から次の情報を分けます。

分けるもの	1レコードの意味	役割
受付レコード	1回の受付	フォーム、メール、電話、営業経由などの入口を記録する
問い合わせ	1件の対応対象	件名、種別、優先度、状態、担当を持つ
顧客マスタ	1社、1顧客、1担当者	顧客情報、契約状態、過去問い合わせを参照する
製品・契約	1サービス、1契約	どの商品、契約、環境に関する問い合わせかを見る
対応履歴	1回の対応行動	返信、電話、社内確認、調査、差し戻しを残す
担当者・チーム	1人、1チーム	一次対応、二次対応、承認者を分ける
対応期限	1つの期限	初回返信、次回回答、解決目標を追う
返信文案	1つの回答候補	返信テンプレート、承認、送信内容を管理する
FAQ候補	1つの再利用候補	よくある質問、回答例、改善メモを蓄積する
連携ログ	1回の外部連携	メール送信、Slack通知、フォーム登録の成否を追う

受付レコードは、問い合わせがどこから来たかを残す場所です。

問い合わせは、チームが対応すべき作業単位です。

顧客マスタは、誰から来た問い合わせかを確認する辞書です。

対応履歴は、誰がいつ何を判断したかを残す場所です。

FAQ候補は、次に同じ質問が来たときに使うための知識です。

これを1つのアプリに混ぜると、問い合わせは登録されているのに、返信、引き継ぎ、期限管理、ナレッジ化ができません。

kintone公式の問い合わせ管理用途ページでも、問い合わせ内容や対応状況をチームで一元管理し、対応漏れや二重対応を防ぐ使い方が紹介されています。

kintone公式：問い合わせ管理にkintone

重要なのは、この考え方を「問い合わせ一覧」ではなく、受付から対応完了、FAQ化までの流れとして設計することです。

問い合わせ管理で正本にするデータ

問い合わせ管理で最初に決めるべきなのは、ステータスの名前ではありません。

どの情報をどこで正本にするかです。

データ	正本にする場所	理由
顧客情報	顧客マスタ	社名、担当者、契約状態、過去接点を統一する
問い合わせ本文	問い合わせアプリ	対応対象として管理する
受付経路	受付レコード、問い合わせアプリ	どこから来たかで対応ルールが変わる
返信内容	対応履歴、メール共有	送信事実と判断理由を残す
社内確認	対応履歴	調査、承認、保留理由を残す
担当者	問い合わせアプリ、プロセス管理	次に動く人を明確にする
添付ファイル	問い合わせ、対応履歴	スクリーンショットや資料を確認できるようにする
FAQ候補	FAQ/ナレッジアプリ	再利用できる形に変える
メール送受信	メール共有サービス、連携ログ	送信・受信の事実を追う

問い合わせ管理でよくある失敗は、問い合わせ本文だけを正本にすることです。

問い合わせ本文は重要ですが、それだけでは対応は進みません。

実務では、次の情報も同じくらい重要です。

• どの顧客の問い合わせか
• どの製品、契約、案件に関係するか
• 誰が一次対応するか
• 誰にエスカレーションするか
• いつまでに初回返信するか
• どの回答を送ったか
• その回答をFAQ化すべきか
• 再発防止や製品改善に回すべきか

問い合わせ管理は、顧客対応の作業管理です。

問い合わせ本文を保存するだけではなく、次の行動と責任者を明確にします。

受付経路・顧客・問い合わせを分ける

問い合わせは、いろいろな入口から入ってきます。

Webフォーム、メール、電話、チャット、営業担当、サポート窓口、紹介、社内依頼。

入口が違うと、必要な項目や対応ルールも変わります。

そのため、まず受付経路を分けます。

受付経路	kintoneに入れる情報	注意点
Webフォーム	氏名、会社、メール、問い合わせ内容、同意	入力必須、スパム、重複
メール	差出人、件名、本文、添付、受信時刻	送受信履歴の正本
電話	受付者、聞き取り内容、折り返し先	聞き漏れ、録音有無
営業経由	顧客、案件、営業担当、要望	案件管理との接続
Slack・Teams	社内依頼、チャンネル、依頼者	対応対象か相談かの判定
既存顧客ポータル	ログインユーザー、契約、対象環境	顧客本人確認、権限

トヨクモの操作ガイドでは、FormBridgeでフォームを作成し、入力データをkintoneに自動登録する問い合わせ管理の流れが紹介されています。

トヨクモ：問い合わせ管理を行う

フォーム連携を使う場合でも、kintone側では「フォーム回答」と「対応対象」を分けて考えます。

フォーム回答は、受付された入力です。

問い合わせは、チームが対応するレコードです。

同じ人が連続で送ったフォーム、スパム、営業メール、既存問い合わせへの追記を、すべて新規問い合わせとして扱うと対応が崩れます。

問い合わせアプリに持たせる項目

問い合わせアプリは、対応対象の中心です。

フィールド	型	設計意図
問い合わせ番号	文字列、採番	対応対象のキーにする
受付日時	日時	初回返信期限や集計に使う
受付経路	ドロップダウン	フォーム、メール、電話、営業経由など
顧客	ルックアップ	顧客マスタと紐づける
問い合わせ者	ルックアップ、文字列	担当者マスタや入力者と紐づける
件名	文字列	一覧で内容を判別する
問い合わせ種別	ドロップダウン	不具合、使い方、見積、契約、要望など
優先度	ドロップダウン	通常、重要、緊急、保留
状態	ステータス	受付、担当割当、対応中、回答待ち、完了など
一次担当	ユーザー選択	最初に対応する人
二次担当	ユーザー選択	技術、経理、営業などへの引き継ぎ
初回返信期限	日時	SLA管理に使う
解決目標日	日付、日時	滞留確認に使う
関連案件	ルックアップ	商談や契約に関係する場合に使う
FAQ候補	チェックボックス	ナレッジ化するか

顧客マスタと製品・契約を参照する

問い合わせを顧客マスタとつなげると、過去の対応、契約状態、担当営業が見えます。

kintone顧客管理の設計方法でも触れたように、顧客情報は問い合わせごとに自由入力しない方がよいです。

参照先	問い合わせで使う情報
顧客マスタ	会社名、顧客区分、契約状態、担当営業
担当者マスタ	氏名、メール、電話、役割、退職・異動
製品マスタ	製品名、バージョン、担当部署
契約マスタ	契約プラン、保守範囲、期限
案件管理	進行中の商談、導入作業、見積
請求・契約確認	契約変更、請求前確認

顧客や製品を参照できると、問い合わせを見た瞬間に、どの契約や案件に関係するか判断できます。

kintone公式ページでも、問い合わせ内容を登録し、同じ顧客からの過去問い合わせを同じ画面で参照する使い方が紹介されています。

kintone公式：問い合わせ管理の利用イメージ

担当アサインとステータス

問い合わせ管理では、ステータスだけでは足りません。

「誰が次に動くのか」まで決める必要があります。

例えば、次のようなステータスを使います。

ステータス	意味	次に動く人
受付	問い合わせが入った	一次担当、振り分け担当
分類中	種別や優先度を確認中	一次担当
担当割当済み	対応者が決まった	担当者
調査中	社内確認や技術調査中	担当者、二次担当
顧客回答待ち	顧客からの追加情報待ち	顧客、担当者
社内確認待ち	承認や判断待ち	上長、専門部署
回答準備中	返信内容を作成中	担当者
回答済み	顧客へ回答した	担当者
完了	対応が終了した	管理者、担当者
FAQ化候補	ナレッジ化する	管理者、サポート責任者

kintoneのプロセス管理は、ステータス、作業者、アクションを設定して、業務の進捗を管理できます。

kintoneヘルプ：プロセス管理

問い合わせ管理では、プロセス管理を使うか、ステータスフィールドで運用するかを決めます。

方法	向いているケース	注意点
プロセス管理	担当者、承認、引き継ぎが明確	複雑にしすぎると操作が重い
ステータスフィールド	小規模、一覧更新が中心	誰が次に動くか曖昧になりやすい
タスクアプリ併用	調査、返信、資料作成を分けたい	問い合わせとの紐づけが必要
Slack・Teams通知併用	早く気づく必要がある	通知過多に注意

問い合わせ管理では、「対応中」という状態だけでは不十分です。次の作業者、次の期限、次のアクションを同時に持たせます。

担当割当では、問い合わせ種別と優先度を使います。

条件	割当先
契約・請求	経理、管理部門
技術的な不具合	技術担当、二次対応
使い方の質問	サポート担当
見積・商談	営業担当
既存案件の相談	案件担当者
重要顧客	専任担当、マネージャー
緊急	当番担当、チーム通知

ただし、最初から自動割当を作り込みすぎない方がよいです。

分類ルールが固まるまでは、一次担当が確認し、分類と割当を直せる状態にします。

対応履歴・返信・添付ファイル

問い合わせ管理で特に重要なのは、対応履歴です。

問い合わせ本文だけがあっても、なぜその回答をしたのか、誰が何を確認したのか、次に何が必要なのかは分かりません。

対応履歴は、コメントだけに頼らず、構造化して残します。

対応履歴に残すもの	例
対応日時	2026-06-09 10:00
対応者	一次担当、二次担当、承認者
対応種別	返信、電話、社内確認、調査、保留、再依頼
対応内容	何を伝えたか、何を確認したか
判断理由	なぜその回答にしたか
次回アクション	追加調査、顧客回答待ち、上長確認
添付ファイル	画面キャプチャ、ログ、資料、見積
顧客への送信有無	下書き、送信済み、送信失敗

メール返信を扱う場合、kintoneだけで完結させるか、メール共有サービスを使うかを決めます。

kintone公式ページでは、メール共有オプションで問い合わせメールの送受信履歴と顧客情報を紐づけて管理できることが紹介されています。

kintone公式：問い合わせ管理とメール共有

返信文をkintoneに持たせる場合は、次のように分けます。

項目	役割
返信テンプレート	よくある回答の型
返信文案	個別問い合わせ向けの下書き
承認状態	上長確認、法務確認、技術確認が必要か
送信方法	メール共有、外部メール、手動送信
送信結果	送信済み、失敗、保留
顧客反応	解決、追加質問、未返信

添付ファイルも同じです。

スクリーンショットやログを添付するだけではなく、どの対応履歴に紐づく添付なのかを分かるようにします。

特に、個人情報、契約情報、エラー画面、請求書、ログファイルを扱う場合は、閲覧権限も確認します。

通知とSLA管理

問い合わせ管理では、通知を増やせばよいわけではありません。

必要なのは、対応漏れを防ぐ通知です。

kintoneの通知設定では、レコード操作、レコード条件、リマインダー条件などに応じた通知を設定できます。

kintoneヘルプ：アプリの通知設定でできること

問い合わせ管理では、次の通知を分けます。

通知	目的	通知先
新規受付通知	問い合わせに気づく	一次担当、当番担当
担当割当通知	自分の対応対象を知る	担当者
緊急通知	重要顧客や障害を早く拾う	マネージャー、専門部署
初回返信期限通知	放置を防ぐ	担当者、チーム
解決目標超過通知	滞留を見つける	担当者、管理者
顧客回答待ち確認	長期保留を整理する	担当者
FAQ化通知	完了後のナレッジ化を促す	管理者、サポート責任者

SLAという言葉を使う場合も、最初から厳密な契約指標にしなくてよいです。

まずは、対応目標として次の項目を持たせます。

期限	意味
初回返信期限	受付後、何時間以内に一次返信するか
次回回答期限	調査中の問い合わせで、次に回答する日
解決目標日	完了までの目安
エスカレーション期限	専門部署へ回す期限
顧客回答待ち期限	顧客から返信がない場合の確認日

kintoneのリマインダーの条件通知は、日付や日時フィールドを基準に通知できます。

kintoneヘルプ：リマインダーの条件通知

ただし、通知だけに頼ると見落とします。

一覧やグラフも用意します。

一覧・グラフ	見ること
未担当一覧	担当者が決まっていない問い合わせ
初回返信期限超過	一次返信が遅れている問い合わせ
顧客回答待ち一覧	顧客からの返信待ち
社内確認待ち一覧	専門部署で止まっている問い合わせ
種別別件数	何の問い合わせが多いか
担当者別滞留	誰に負荷が集中しているか
FAQ候補一覧	ナレッジ化すべき問い合わせ

通知、一覧、定例レビューをセットで設計します。

FAQ化・ナレッジ化

問い合わせ管理の価値は、対応を完了するだけではありません。

同じ問い合わせを減らすことにもあります。

そのためには、問い合わせをFAQや社内ナレッジに変える設計が必要です。

kintone公式ページでも、対応履歴やノウハウを蓄積し、過去の対応履歴から回答を生成する使い方が紹介されています。

kintone公式：対応履歴やノウハウの蓄積

ただし、AIで回答を作る前に、ナレッジの粒度を整える必要があります。

問い合わせ履歴そのものは、そのままFAQではありません。

FAQ化するには、次のように整理します。

問い合わせ履歴	FAQにする時の整理
顧客固有の事情	一般化できる条件だけ残す
長いメール本文	質問と回答を短く分ける
社内判断メモ	公開してよい情報だけにする
添付ファイル	画像や資料の公開可否を確認する
一時的な不具合	再発する場合だけ残す
契約・請求の話	個別条件を伏せる

FAQ候補アプリを作る場合は、次の項目を持たせます。

フィールド	型	設計意図
FAQ番号	文字列、採番	ナレッジ単位のキー
元問い合わせ	ルックアップ	どの問い合わせから生まれたか
質問	文字列複数行	ユーザーが聞きそうな形にする
回答	文字列複数行	再利用できる形にする
対象製品	ルックアップ	製品や契約に紐づける
公開範囲	ドロップダウン	社内のみ、顧客公開、営業向け
確認者	ユーザー選択	誰が内容を確認したか
有効期限	日付	古い回答を放置しない
改訂状態	ステータス	下書き、確認中、公開、廃止

FAQ化の判断もルール化します。

FAQ化すべき問い合わせ	理由
同じ質問が繰り返し来る	返信時間を減らせる
新人が迷いやすい	対応品質を揃えられる
製品仕様の説明が必要	説明のブレを減らせる
契約・請求の基本質問	誤案内を防げる
不具合時の一次回答	初動を早くできる

逆に、個別契約、個人情報、未確定仕様、社内だけの判断は、そのままFAQにしない方がよいです。

問い合わせ履歴を溜めるだけではナレッジ化になりません。再利用できる質問と回答に編集し、公開範囲と確認者を決めて初めてFAQになります。

フォーム・メール・Slack連携の境界

問い合わせ管理では、外部連携をどう使うかも重要です。

ただし、連携ツールを増やす前に、責任範囲を決めます。

連携先	任せること	kintoneで持つこと
Webフォーム	外部からの入力受付	受付内容、対応状態、顧客紐づけ
メール共有	送受信、テンプレート、メール履歴	問い合わせ状態、対応責任、期限
Slack・Teams	担当通知、緊急通知	正式な対応履歴、完了状態
CRM・SFA	顧客、案件、営業活動	サポート対応、問い合わせ履歴
FAQサイト	公開ナレッジ	FAQ候補、確認状態、改訂管理

トライコーンのページでは、問い合わせフォーム、受付自動返信、Slack通知、担当者アサイン、ステータス管理、対応履歴管理、回答メール返信などが、問い合わせ管理で実現できる機能として紹介されています。

トライコーン：kintoneで問い合わせ管理

これらは便利ですが、すべてを入れればうまくいくわけではありません。

重要なのは、どの情報をどこに残すかです。

例えば、Slack通知は気づくための入口です。

正式な対応履歴ではありません。

メール共有は送受信の正本になりやすいです。

ただし、問い合わせの状態や担当責任はkintoneに置いた方が見やすいことがあります。

フォームは受付の入口です。

ただし、フォーム回答をそのまま対応完了までの正本にすると、重複、スパム、既存問い合わせへの追記を扱いづらくなります。

連携設計では、次の3つを必ず決めます。

• 受付の正本はどこか
• 返信の正本はどこか
• 対応状態の正本はどこか

この3つが決まっていれば、外部サービスを増やしても混乱しにくくなります。

権限設計と個人情報の扱い

問い合わせには、個人情報や契約情報が含まれます。

氏名、メールアドレス、電話番号、住所、契約内容、請求情報、障害内容、社内判断、苦情、添付ファイル。

誰でも全問い合わせを見られる設計にしてよいとは限りません。

kintoneでは、アプリ、レコード、フィールドの単位でアクセス権を設定できます。

kintoneヘルプ：アクセス権の設定

問い合わせ管理では、最低限、次の役割を分けます。

役割	見せる範囲
一次対応担当	自分またはチームの問い合わせ
二次対応担当	技術、経理、営業など自分に関係する問い合わせ
営業担当	担当顧客に関する問い合わせ
管理者	全問い合わせ、権限、マスタ、FAQ候補
マネージャー	チーム全体の対応状況、滞留
FAQ編集者	FAQ候補と公開ナレッジ
一般社員	原則、必要な範囲だけ

特に注意すべきなのは、添付ファイルと対応履歴です。

問い合わせ本文よりも、対応履歴や添付ファイルの方が機微な情報を含むことがあります。

次の情報は、フィールドやアプリを分けることも検討します。

• 個人の連絡先
• 契約・請求情報
• 障害ログ
• 顧客からの苦情
• 社内だけの判断メモ
• 法務や経理の確認内容
• 公開前の不具合情報

権限を後から直すと、過去データの閲覧範囲も見直す必要があります。

問い合わせを集め始める前に決めます。

よくある失敗パターン

kintone問い合わせ管理でよくある失敗は、問い合わせアプリを作っただけで運用が回ると思うことです。

失敗	起きること	対策
受付経路を分けない	フォーム、メール、電話が混ざる	受付経路と受付レコードを持つ
顧客を自由入力にする	同じ顧客の過去問い合わせが見えない	顧客マスタと紐づける
ステータスだけで管理する	誰が次に動くか分からない	作業者、期限、次回アクションを持つ
コメントだけに履歴を書く	引き継ぎや集計に使いにくい	対応履歴を構造化する
返信内容をメール側だけに置く	kintoneで回答経緯が追えない	送信結果と要約を残す
通知を増やしすぎる	重要通知が埋もれる	通知対象と条件を絞る
期限を持たない	滞留に気づけない	初回返信期限、解決目標を持つ
FAQ化しない	同じ質問に毎回対応する	FAQ候補と確認者を決める
権限を後回しにする	個人情報や社内判断が広く見える	役割別に閲覧範囲を決める
Slackを履歴にする	後から検索・監査しづらい	Slackは通知、kintoneは履歴に分ける

問い合わせ管理は、件数が少ないうちは個人の頑張りで回ります。

しかし、件数が増えると、受付経路、担当割当、期限、履歴、FAQ化の弱さが一気に出ます。

最初の数十件で設計を直しておく方が、後で楽です。

1週間で始めるならこの順番

kintone問い合わせ管理を小さく始めるなら、最初から全チャネル連携を作らない方がよいです。

まずは、問い合わせが入り、担当が決まり、期限までに回答し、履歴が残る最小構成を作ります。

日程	やること	成果物
1日目	問い合わせの入口を棚卸しする	フォーム、メール、電話、営業経由など
2日目	問い合わせアプリを設計する	受付日時、種別、優先度、担当、状態
3日目	顧客マスタと紐づける	顧客、担当者、契約、過去問い合わせ
4日目	ステータスと作業者を決める	受付、調査中、回答待ち、完了
5日目	通知と期限を設定する	新規受付、担当割当、期限超過
6日目	対応履歴と返信文案を作る	返信、社内確認、添付、送信結果
7日目	実際の問い合わせで試す	滞留、二重対応、FAQ候補を確認

最初の検証では、対象を絞ります。

例えば、Webフォームだけ、既存顧客のサポートだけ、営業経由の問い合わせだけ、などです。

この範囲で、次の点を確認します。

• 問い合わせ登録時に必要な情報が揃うか
• 顧客マスタと正しく紐づくか
• 担当者が迷わず決まるか
• 初回返信期限を見落とさないか
• 対応履歴を後から読んで引き継げるか
• 返信内容がkintoneとメール側で二重管理になっていないか
• FAQ化すべき問い合わせを拾えるか
• 権限設定で見せすぎていないか

ここで詰まるなら、連携サービスを増やす前に、データ設計と運用ルールを直します。

実装前チェックリスト

kintone問い合わせ管理を作る前に、次を確認します。

• 問い合わせの受付経路が一覧化されている
• 受付レコード、問い合わせ、対応履歴を分けるか決まっている
• 顧客マスタ、担当者マスタ、製品・契約マスタとの関係が決まっている
• 問い合わせ種別と優先度の選択肢が決まっている
• 一次担当、二次担当、承認者の役割が決まっている
• ステータスごとの次回アクションが決まっている
• 初回返信期限と解決目標を持つか決まっている
• 期限超過や未担当を見つける一覧がある
• 返信内容をどこに残すか決まっている
• メール共有、フォーム、Slack通知の責任範囲が決まっている
• FAQ候補を拾う条件と確認者が決まっている
• 個人情報、契約情報、添付ファイルの閲覧範囲が決まっている
• 連携エラーや送信失敗を確認できる

このチェックリストで詰まるところが、kintoneの設定前に決めるべきことです。

特に、対応履歴、返信の正本、通知条件、FAQ化、権限設計は後から直すと重くなります。

まとめ

kintoneで問い合わせ管理を作ること自体は難しくありません。

受付日、会社名、メール、問い合わせ内容、担当者、ステータスを入れれば、問い合わせ一覧は作れます。

しかし、チームで対応漏れなく回すには、問い合わせ一覧だけでは足りません。

必要なのは、受付レコード、問い合わせ、顧客マスタ、製品・契約、対応履歴、担当者、対応期限、返信文案、FAQ候補を分けることです。

kintoneは、問い合わせを顧客情報、対応履歴、担当割当、期限、FAQ化につなぐ業務DBとして使うと強いです。

一方で、メール送受信、Webフォーム、Slack通知、FAQ公開、CRM連携は、それぞれ外部サービスを使った方がよい領域もあります。

問い合わせ管理をkintoneで始めるなら、まず次の3つを決めてください。

• 問い合わせの受付、対応状態、返信履歴の正本をどこに置くか
• 担当者、期限、次回アクションをどう管理するか
• 完了した問い合わせをFAQや改善テーマへどう変えるか

この3つが決まっていれば、kintone問い合わせ管理は単なる問い合わせ台帳ではなく、対応漏れを防ぎ、チームの知識を増やす業務システムになります。

逆に、ここを曖昧にしたまま問い合わせアプリだけを作ると、問い合わせは登録されているのに、返信、引き継ぎ、期限管理、ナレッジ化が後ろで詰まります。

問い合わせ管理は、問い合わせを受ける仕事ではありません。

顧客の声を受け取り、担当者へ渡し、期限内に回答し、次に同じ問い合わせが来たときに早く答えられる状態を作る仕事です。