問い合わせ管理では、まず何を1件として管理するかを決めます。質問への回答、営業案件、予約枠の確保では、完了の意味が異なるためです。この記事では、基本テンプレートとBtoB営業・toCサポート・予約受付・医療系予約の構成例を使い、状態を変更する条件を確認します。
ステータスは、単なる進捗ラベルではありません。 「今どの段階か」「誰の対応待ちか」「次に何をすればよいか」を、担当者が同じ意味で読めるようにするための項目です。 そのため、業務の種類によって、適したステータス構成は変わります。
以下は設計を検討するための例で、導入実績や特定施設の運用を示すものではありません。各状態へ変更できる人、変更の根拠、通知や予約枠に与える影響は、実際の業務に合わせて決めます。問い合わせ種別・原因などの分類は、ステータスとタグの役割分担で扱います。
業種固有の工程が少ない場合は、次の構成から始められます。重要なのは、対応中と完了だけでなく、現在誰の作業を待っているのかを分けることです。
保留は再開を検討する状態、対象外・対応不要は対応を終える状態として分けます。待ち先が顧客や社内担当でも、問い合わせを管理する担当者は残し、確認日を過ぎた時に誰が確認するかを決めます。時間が経過しただけで、未回答の案件を完了へ変更しません。
顧客回答待ちの案件へ返信が来たら、担当者が確認する対象へ戻します。完了後の連絡が同じ問題の続きなら再開し、別の相談なら新しい案件として関連付ける、というルールも考えられます。どちらにするかの判断者を決め、再開時には以前の完了日時を消さず、変更履歴を残します。
法人向けの問い合わせが見積・提案・商談へ進む場合、問い合わせへの回答状況と営業案件の進捗を分けて管理できます。資料を送って問い合わせ対応を完了しても、商談は継続中という状態があり得るためです。問い合わせと営業案件を分ける方式では、両者を関連付けて履歴を参照できるようにします。
見積は提案中に何度も更新する場合があるため、この例では見積の版・提示日を別に記録します。顧客判断待ちから条件変更で提案中へ戻ることも認め、変更理由を残します。「受注」にする根拠は、発注書や契約など実際の運用に従って定義し、見積を開いたことだけで受注扱いにしません。関連する業務例は製造業向けWebシステム活用アイデアを参照してください。
一般消費者向けの問い合わせサポートでも、質問への回答が中心の窓口か、返金などの手続きを担う窓口かで必要な状態が変わります。質問への回答が中心なら、着手状況と返信待ちを区別する構成から検討できます。
ステータス管理の運用ルールと失敗しにくい設計 でも触れたように、ステータスを増やしすぎると、担当者ごとに解釈が分かれやすくなります。 ただし、返品・交換・返金を同じ窓口で扱う場合は、回答を送っただけで完了とは限りません。問い合わせと作業を別に管理するか、必要な作業状態を追加するかを決めます。
クローズの条件は「回答を送信した」「案内した手続きが完了した」など、対応内容ごとに定めます。返信がない場合の終了条件を設けるなら、確認する間隔や案内内容、再開時の扱いも決めておきます。
次の画面は架空のECサポート窓口の静的な表示例です。全12件のうち3件を表示し、全体の未対応は4件としています。選択中の「すべて」には、返信待ち・完了の案件も含みます。実際の操作はできません。
予約受付では、問い合わせ対応とは違い、日程・来場・キャンセルの状態が重要になります。 特に施設見学や個別相談では、申し込みが入っただけでは完了ではなく、日程調整や確定連絡が必要になることがあります。
この構成は、予約カレンダーの空き状況表示パターン集 や 時間枠設計の実務ガイド（業種別サンプル） で扱ったカレンダー表示とも合わせやすい形です。 「申込受付」と「予約確定」を分けておくと、フォーム送信直後が仮受付なのか、すでに枠が確保された状態なのかを明確にできます。
希望を受けて担当者が調整する方式と、空き枠をその場で確保する即時予約方式では、送信後の状態が異なります。上の例は前者です。確定通知の送信結果、決済や返金の状態は別に管理し、通知失敗だけで予約が取り消されたことにはしません。日時変更では、旧予約枠と新予約枠をいつ変更するか、変更できなかった場合に何を維持するかも決めます。
ここでは、診療そのものではなく、予約受付と来院確認を扱います。初診・再診などの区分は予約情報、来院の有無は受付状況、問診の入力状況は補足項目として分ける構成例です。
初診・再診の区分を変更しても、予約の進捗まで受付時点へ戻さないようにします。また、予約時刻を過ぎただけでは来院の有無を断定せず、受付記録や担当者の確認に基づいて更新します。「来院済み」は「診療完了」と同じ意味ではありません。問診・同意・決済を連動する場合も、それぞれ確認できた事実を別に記録します。周辺の構成例は歯科・皮膚科・美容クリニック向けWebシステム活用アイデアを参照してください。
ステータス設計でよく起きる失敗は、進捗以外の情報までステータスに入れてしまうことです。 予約の進捗と支払いの状態のように、別々に変わるものを一つの項目へまとめると、状態の組み合わせが増えます。主となる進捗、補足状態、分類を分けて検討します。
例えば問診には、未入力・入力途中・入力済み・対象外・状況未確認を分ける構成が考えられます。外部サービスとの連携で状況を取得できない場合は、「未入力」と断定しません。入力済みは担当者の確認済みとも区別します。項目ごとに誰が、何を根拠に更新するかを決めます。
既存のステータスを見直す場合は、実際の利用状況を見ながら確認します。 名称が似ている状態でも、次の作業や終了条件が違う場合は残す必要があります。利用件数が少ないことだけで削除せず、次の点を確認します。
移行する場合は、旧状態と新状態の対応を作り、機械的に対応を決められない案件を確認対象にします。例えば旧「保留・対象外」を、新しい「保留」か「対象外」のどちらかへ一律に変換してはいけません。過去の履歴を保持し、移行前後の件数と例外案件を確認してから運用を切り替えます。
これらは、問い合わせ集計レポートの作り方 にも直結する観点です。 ステータスは、日々の運用だけでなく、後から件数や滞留を確認するための基準にもなります。
問い合わせステータス設計は、汎用テンプレートをそのまま当てはめるだけでは不十分です。 BtoB営業、toCサポート、予約受付、医療系予約では、それぞれ管理したい状態が異なります。
状態の名前に加えて、変更条件・担当者・次回確認日・終了条件を決めます。問診入力や支払い確認などの補足状態は別に管理し、分からない状態を確認済みへ置き換えない構成にします。既存システムを変更する時は、案件の履歴と関連する通知・集計も含めて確認します。