問い合わせステータス管理：ライフサイクル定義、遷移ルール、停滞アラート

問い合わせステータス管理：ライフサイクル定義、遷移ルール、停滞アラート

1. 6つのステータス：なぜ8つでも10でもないのか

多くのチームのCRMには十数の問い合わせステータスがあります：未割当、連絡待ち、連絡済み、商談中、見積送付済み、サンプル段階、サンプル作成中、交渉中、成約、失注、無効、重複、スパム……細かく見えますが、実際には営業はほとんど更新しません。ステータスを1つ更新するのに3クリック必要なら、クリックしないほうがましだと思うからです。その結果、すべての問い合わせが「商談中」で止まり、実際の進捗がどこにあるのかまったく分からなくなります。

この6つのステータスの設計原則は、各ステータスが明確な1つのアクションに対応し、営業はアクションが起きたときに一度クリックするだけでよいというものです。初回返信を送ったら「連絡済み」をクリック、買い手が返信したら「商談中」をクリック、見積を送ったら「見積送付済み」をクリック、成約またはクローズなら最終ステータスをクリック。間に「サンプル段階」「サンプル作成中」といった細分化は不要です。それは備考欄に書くことであり、ステータスで管理することではありません。ステータスが少ないほど営業は更新したがり、データはより正確になります。

シナリオ例：1件の問い合わせが入ると、システムは自動で”新規問い合わせ”から始めます。営業が5分以内に初回返信を送り、”連絡済み”をクリック。翌日、買い手から「ハンブルクまで500台必要」と返信が来て、営業が”商談中”をクリック。3日目に営業が見積書を送り、”見積提出済み”をクリック。1週間後に買い手が発注を確定し、”成約”をクリック。この一連の流れでクリックしたステータスはわずか4回、しかも毎回が実際のアクションに対応しています。これが6つのステータスの実行可能性です。初回返信SLAとステータス遷移の連携については、こちらを参照問い合わせ初回返信のSLAとコンバージョン率。

二、遷移ルール：前にしか進めない、勝手に戻れない

ステータス遷移には厳格なルールがあります。前にしか進めず、後ろには戻れません。”連絡済み”から”新規問い合わせ”には戻れず、”商談中”から”連絡済み”にも戻れません。買い手が「もう少し考えます」と言った場合、それは後退ではなくその場に留まることです。”商談中”または”見積提出済み”のまま止めて、次のフォローを待ちます。戻せるのは次の2つの場合だけです。1つは担当営業の割り当てを間違えた場合、もう1つは重複問い合わせだった場合。戻すときは理由の入力が必須で、勝手にクリックはできません。

遷移ルールの核心的な目的は”ステータスの漂流”を防ぐことです。つまり、3週間も追いかけている問い合わせを、最近動きがないからといって営業が”見積提出済み”から”商談中”へ引き戻し、まだ順調に進んでいると装うことです。この漂流が起きると、問い合わせはまだ生きていると錯覚しますが、実際にはもう死んでいます。だからこそ差し戻しには理由の入力と上長の承認が必須で、営業が気軽に戻せるものではありません。

クローズ理由は必ず入力し、しかも分類する必要があります。よくあるクローズ理由は5つです。買い手の拒否（価格が高すぎる／競合を選んだ／今は不要）、買い手が無効（スパム／同業者／連絡先の誤り）、期限切れで無返信（3回以上フォローしても反応なし）、重複問い合わせ（同じ買い手が重複して送信）、その他。クローズ理由を分類して集計すれば、自分の問い合わせがどの段階で死んだのかが分かります。見積が高すぎたのか、フォローが足りなかったのか。フォローシーケンスの設計については、こちらを参照問い合わせメールのフォローアップ手順。

三、停滞アラート：3段階の警告メカニズム

ステータス管理で一番怖いのは、状態が乱れることではなく、止まったまま誰も見ていないことです。ある問い合わせが「連絡済み」のまま2週間止まっていて、営業はフォローを忘れ、あなたも気づかない。これこそが本当の失客です。停滞アラートは、各ステータスに最大滞留時間を設定し、超えたら自動で警告する仕組みです。どの問い合わせも静かに死なせません。

具体的な数字で見てみましょう。「連絡済み」の最大滞留時間は48時間です。黄信号は72時間（48×1.5）で発動し、営業に「この問い合わせは3日間動かしていません。フォローしてください」と通知します。橙信号は96時間（48×2）で発動し、同時に責任者にも通知します。赤信号は144時間（48×3）で発動し、責任者が必ず自ら対応します。自分でフォローするか、そのままクローズするかです。この3段階の仕組みで、問い合わせが静かに死ぬことはありません。

ステータスごとに最大滞留時間は異なります。「新規問い合わせ」は24時間。まだ割り当てられていないため、割り当てが遅れると初回応答SLAが破綻します。「連絡済み」は48時間。買い手が2日返信しなければ、ほぼ興味なしです。「商談中」は7日。やり取りを1週間続けても見積もりが出ないなら、要件がまだ合っていません。「見積もり提出済み」は7日。見積もりを出して1週間反応がなければ、価格が高いか、買い手が相見積もり中です。各ステータスの最大滞留時間は、それぞれ「これ以上待っても無駄」という時点に対応しています。リードスコアと優先度の全体的な方法は、こちらを参照してください。問い合わせリードのスコアリングと優先順位付け。

4. よくあるステータス管理の誤り

この5つの誤りの中で最も見えにくいのが最後の「アラートはメールのみ」です。営業は毎日何十通ものメールを受け取るので、停滞アラートのメールは埋もれてしまいます。正しい方法は、アラートを営業のワークスペースのトップページにプッシュすることです。CRMダッシュボードに「黄信号の問い合わせが3件、橙信号が1件あります」と直接表示され、CRMを開けばすぐに目に入り、メールを探す必要はありません。可視化ダッシュボードの設計は、こちらを参照してください。AIエンジン引用モニタリングパネルのダッシュボードの考え方。

ステータス管理の最終目的は、CRMを見た目よく整えることではありません。週に一度ダッシュボードを見れば、今週どの問い合わせがどのステータスで止まっているか、どれくらい止まっているか、どの案件に上司が介入すべきかが分かることです。停滞アラートのないステータス管理は、誰も見ない数字の山でしかありません。公式サイトとCRMの連携は、ステータスを自動で動かす前提条件です。この部分はサイトのリードをCRMへ。

FAQ よくある質問

最後に

問い合わせステータス管理は、CRMの設定の問題に聞こえるが、実は自分の問い合わせパイプラインを見る目そのものだ。ステータス管理がなければ、今月何件の問い合わせを受け、何件成約したかは分かっても、途中のどの段階で何件漏れたかは分からない。ステータス管理があれば、一目で分かる。今月「見積提出済み」で止まっている問い合わせが30件、うち12件は1週間以上動いていない。この12件こそがボトルネックだ。

導入は3ステップ。まずステータスを6つに絞り、それぞれに1つのアクションを対応させる。次に各ステータスに最大滞留時間を設定し、3段階の停滞アラートを組み合わせる。最後にクローズ理由の入力を必須にし、分類して集計する。これを運用すれば、週に一度ダッシュボードを見るだけで、誰と話すべきか、どの段階に力を入れるべきかが分かる。

覚えておきたい一言。ステータス管理の目的は営業に表を埋めさせることではなく、どの問い合わせが止まり、どれだけ止まっているかを一目で見えるようにすることだ。6つのステータスと3段階のアラートは、15のステータスと誰も見ないダッシュボードより10倍役に立つ。