問い合わせ管理、案件管理、予約管理、見積管理などの業務システムでは、「今どの段階にあるのか」を誰でも確認できる状態が欠かせません。 その中心になるのがステータス管理です。
ただし、ステータスは単に「未対応」「対応中」「完了」といったラベルを置けば機能するものではありません。 どの状態になったら誰が対応するのか、どの状態が何日続いたら通知するのか、完了にしてよい条件は何か。 この運用ルールが決まっていないと、ステータスは更新されなくなり、一覧画面もレポートも信用しづらくなります。
ステータス設計で最初に分けたいのは、作業名と状態です。 たとえば「メール返信」「社内確認」「見積作成」は作業です。 一方で、「未対応」「対応中」「顧客確認待ち」「社内確認待ち」「完了」は状態です。
ステータスを作業名で作ると、作業が増えるたびにステータスも増えてしまいます。 結果として、担当者がどれを選べばよいか判断しづらくなります。
まずは、次のような基本形から始めるのが現実的です。
ステータス管理でよく起きる失敗は、業務の細かな違いをすべてステータスにしてしまうことです。 「一次回答済」「二次回答待ち」「営業確認中」「技術確認中」「見積作成中」「上長確認中」などを並べると、一見細かく管理できるように見えます。
しかし、実際の運用では次のような問題が起きやすくなります。
ステータスは、細かいほど良いわけではありません。 現場で毎日使うものだからこそ、「状態の意味がすぐ分かる」「更新しやすい」「集計しやすい」数に抑えることが重要です。
画面例 問い合わせ管理のステータスダッシュボード
| 件名 | 状態 | 担当 | 期限 | 次に必要な対応 |
|---|---|---|---|---|
| 製品Aの仕様確認 | 社内確認待ち | 技術サポート | 4/28 | 技術部からの回答待ち。回答後、顧客へ返信。 |
| 資料請求後の個別相談 | 対応中 | 営業1課 | 4/26 | 日程候補を3案送付する。 |
| 申請フォームの入力不足 | 修正依頼 | 受付担当 | 4/27 | 添付ファイルの再送依頼中。 |
| 契約更新に関する質問 | 顧客確認待ち | CS担当 | 5/1 | 顧客から契約番号の返信待ち。 |
状態、担当者、期限、次に必要な対応を一緒に見せると、ステータスが単なるラベルではなく、次の行動を判断する材料になります。
ステータスだけで、すべての状況を表そうとすると複雑になります。 実務では、ステータス、担当者、期限、コメントを分けて考える方が安定します。
| 項目 | 役割 | 例 |
|---|---|---|
| ステータス | 今どの状態かを示す。 | 未対応、対応中、顧客確認待ち、完了。 |
| 担当者 | 現在ボールを持っている人・部署を示す。 | 営業部、技術サポート、経理担当。 |
| 期限 | いつまでに次の対応が必要かを示す。 | 一次回答期限、見積提出期限、確認期限。 |
| コメント | 背景、やり取り、判断理由を残す。 | 顧客へ追加資料を依頼中。技術部に確認済み。 |
たとえば「営業確認中」「技術確認中」をステータスにするのではなく、ステータスは「社内確認待ち」、担当部署で「営業」「技術」を分ける方がシンプルです。 この構成にすると、状態の種類を増やさずに、誰が対応すべきかを表現できます。
ステータス運用が乱れる原因の多くは、「いつ変更するのか」が決まっていないことです。 担当者の感覚で変更していると、同じ対応でも人によって状態が変わります。
最低限、次のような変更条件を決めておくと、運用のばらつきを抑えやすくなります。
| 変更前 | 変更後 | 変更するタイミング |
|---|---|---|
| 未対応 | 対応中 | 担当者が決まり、対応を開始した時。 |
| 対応中 | 顧客確認待ち | 顧客へ質問・資料依頼・確認依頼を送った時。 |
| 対応中 | 社内確認待ち | 社内の別部署や上長の確認が必要になった時。 |
| 対応中 | 修正依頼 | 相手に入力内容・添付資料・申請内容の修正を依頼した時。 |
| 対応中 | 完了 | 必要な回答・処理・記録が終わった時。 |
「完了にしてよい条件」も重要です。 返信しただけで完了なのか、相手の了承まで必要なのか、社内記録の登録まで終えて完了なのか。 ここを決めておかないと、完了の意味が人によって変わります。
問い合わせ管理や申請管理では、相手に修正や追加提出をお願いする場面がよくあります。 この状態を「対応中」や「確認待ち」に含めると、対応の優先順位が分かりにくくなります。
修正依頼を独立した状態にしておくと、次のような管理がしやすくなります。
通知は多すぎると読まれなくなります。 一方で、通知がないと、未対応や確認待ちが放置されやすくなります。
通知設計では、次の2種類を分けると整理しやすくなります。
新規受付、担当割当、修正依頼、完了など、関係者がすぐ知るべき変化を通知します。
未対応のまま一定時間経過、確認待ちが長期化、期限超過など、放置を防ぐために通知します。
通知は、すべてをメールにする必要はありません。 管理画面上のアラート、未対応一覧、期限超過リストなど、日常的に見る画面に出す方が効果的な場合もあります。
ステータスは、現在の状態だけでなく、いつ・誰が・どの状態に変更したかも重要です。 変更履歴がないと、対応が遅れた理由や、どの段階で時間がかかったのかを後から確認できません。
履歴として残したい情報は、次の通りです。
この履歴があると、対応時間の分析にも使えます。 未対応から対応中までの時間、対応中から完了までの時間、社内確認待ちで止まった日数などを見られるため、業務改善の材料になります。
基本のステータス構造は共通でも、業種や業務によって追加した方がよい状態があります。 ここでは、代表的な例を挙げます。
| 業務・業種 | 追加されやすい状態 | 理由 |
|---|---|---|
| 医療・クリニック | 問診未入力、来院待ち、診療完了 | 予約だけでなく、問診・来院・診療の流れがあるため。 |
| 見積依頼 | 条件確認中、見積作成中、承認待ち、提示済 | 金額確定までに社内確認や上長承認が入るため。 |
| 予約管理 | 仮受付、確定、変更待ち、キャンセル | 日程調整や枠の確保が必要になるため。 |
| 品質・不具合対応 | 暫定対応中、原因調査中、対策確認中、クローズ | 原因・対策・効果確認まで段階が分かれるため。 |
医療機関まわりの業務をどこまでWebシステムで支援できるかを確認する場合は、 歯科・皮膚科・美容クリニック向けWebシステム活用アイデア のような業種別ページを見ると、予約・問診・受付・フォローまでの流れをイメージしやすくなります。
ステータス運用は、一度決めたら終わりではありません。 実際に使い始めると、ほとんど使われない状態、担当者によって意味が変わっている状態、長期間止まりやすい状態が見えてきます。
見直しでは、次の観点を確認します。
ステータスを追加する前に、既存の状態で表現できないか、担当者・期限・コメントで補えないかを確認します。 状態を増やすのは最後の手段にした方が、運用は長続きします。
ステータス管理は、業務の進捗を表示するだけの機能ではありません。 誰が対応するのか、何を待っているのか、いつまでに処理するのか、どこで時間がかかっているのかを判断するための基盤です。
まずは、未対応・対応中・顧客確認待ち・社内確認待ち・修正依頼・完了といった基本構造を決めます。 そのうえで、担当者、期限、コメント、通知、変更履歴を組み合わせれば、状態の数を増やしすぎなくても実務に耐えやすくなります。
株式会社インテンスでも、ステータス設計では「状態を細かく分けること」より、「誰が見ても次の対応を判断できること」を重視しています。 現場で毎日使われる画面だからこそ、シンプルで意味がぶれにくい設計にすることが大切です。