案件管理システムのステータス設計｜停滞と次の作業が分かる作り方

案件管理のステータスは、案件が今どの状態で、次に誰が何をすれば進むかを判断できる区分にします。「対応中」のような広い言葉だけでは、作業中なのか返答待ちなのか分かりません。工程の名前より、状態が変わったことを確認できる条件を先に決めると設計しやすくなります。

状態と担当者と作業を分ける

状態は案件の現在地、担当者は責任を持つ人、作業は次に実行する行動です。これらを一つの項目で表すと、「担当変更待ち」「資料送付予定」などの区分が増え、選択する人によって意味が変わります。担当者と次回対応日は別の項目に持たせ、ステータスには工程上の意味を残します。

たとえば「提案中」は、提案書を準備している状態と、相手が提案を検討している状態を含みます。停滞理由を知りたい運用なら、この二つを分ける価値があります。一方、分けても行動や集計が変わらない区分は、追加しない判断が合理的です。

各ステータスに「入る条件」「出る条件」「更新する役割」を書きます。口頭で提案しただけで提案済みにするのか、資料を渡した時点なのかを揃えないと、案件数を比較できません。完了も、契約成立とサービス提供終了のどちらを指すかを明確にしてください。

状態の順番は基本経路を作り、戻る操作を許す場面も確認します。再見積もりで前工程へ戻る場合は、単に古い状態を上書きせず、変更理由を履歴に残せると判断の経緯が分かります。すべての遷移を厳しく禁止すると、例外案件を別管理する原因になります。

保留は再開する可能性がある状態、終了は通常の対応対象から外す状態です。返答待ちを保留に含めるなら、誰の返答を待ち、いつ確認するかを別途記録します。保留という名前だけでは、放置された案件と意図して待っている案件を区別できません。

失注や取り下げの理由も、状態の種類を増やすより理由項目で持つほうが整理しやすい場合があります。「予算」「時期」「対象外」などを設ける際は、推測で選ばず、確認できた内容と未確認を分けます。再相談が来たときに新規案件を作るか再開するかも決めます。

以下は受託サービスの想定例です。「相談受付」は連絡先と相談概要を受け取った状態、「確認中」は要望や制約を確認している状態、「提案済み」は相手へ提案内容を伝えた状態と定義します。名称が似ていても、開始条件が違えば別の状態として扱えます。

「提案済み」の記録例は、「開始条件：提案資料を相手へ共有済み」「次の行動：検討状況の確認」「更新する役割：案件の窓口」「必要項目：提案日、次回確認日」です。この例は契約手続きや検収を含まないため、自社の業務範囲に合わせて後続工程を補います。

順調に進んだ案件、長く停滞した案件、途中で取り下げられた案件を選び、作成した区分へ当てはめます。複数の人が同じ情報から同じ状態を選べるかを確認してください。迷った箇所は利用者の理解不足とせず、定義が重なっていないかを見直します。

画面上では状態に応じた必須入力を検討します。ただし、受付時点で分からない事項まで必須にすると仮の値が入ります。提案済みに変更する際に提案日を確認するなど、その時点で確定できる情報だけを求めるほうが記録の品質を保ちやすくなります。

「対応中」が大半を占める場合は、区分が粗すぎるだけでなく、更新するタイミングが曖昧な可能性があります。会議前だけまとめて修正する運用では、日々の管理に使えません。提案送付や返答受領など、通常作業の直後に状態を更新できる配置を考えます。

状態名を変更したら過去の集計への影響も確認します。旧区分と新区分の対応を決めずに統合すると、過去比較の意味が変わります。定義の版と変更日を残し、集計条件を説明できるようにしてください。保存件数が多いことだけで管理が成立するわけではありません。

区分は細かいほどよいですか。次の行動、責任、必要な記録のいずれも変わらないなら、細分化による入力負担のほうが大きくなります。

自由入力は使えますか。補足には向いていますが、状態の主要項目を自由入力にすると表記が揃いません。集計する区分は選択式にし、例外は理由やメモで説明する方法を検討します。