相談と事案を同じ台帳で扱うときのステータス設計— 段階・権限・秘匿を混ぜない

1. なぜステータスが混ざるのか

1-1. 相談は「聴く」、事案は「動く」

相談は従業員の不安や情報提供が中心で、すぐ事案化しないケースもあります
事案は顧客対応の履歴と措置の記録が中心で、閉店前に一次記録を残す必要があります
同じ「対応中」ラベルを付けると、相談の待機と現場の進行中が区別できません

1-2. 閲覧権限がステータスに引きずられる

店長が「進行中の全件」を見られる設定だと、窓口の匿名相談まで一覧に出ることがあります
窓口設計の基本は相談窓口の設置に沿い、レコード種別（相談／事案）で権限を分ける方が安全です
ステータスだけで権限を切ると、完了後に秘匿が解ける事故が起きます

1-3. 集計指標が誤解を生む

「未完了件数」に相談の保留と事案の未入力が混ざると、経営会議の数字が読めません
効果測定では種別ごとの完了率を分ける必要があります（効果測定とPDCA）

2. 推奨ステータス体系

2-1. 共通の「種別」＋別々の「段階」

まずレコードに種別フラグ（相談／事案／相談から昇格した事案）を必須にします
相談の段階例: 受付 → ヒアリング中 → 方針確認 → クローズ（事案化なし）／事案へ昇格
事案の段階例: 一次記録済み → 対応継続 → 外部連携中 → クローズ

2-2. 「クローズ」の定義を文書化する

相談クローズは「相談者への返答完了と、事案化しない判断の記録」とします
事案クローズは「必須記録の充足と、フォロー完了日の記入」とします
記録項目の土台は記録様式の9項目を参照し、ステータス遷移条件と1対1で結びます

2-3. 昇格ルールを明示する

相談から事案へ昇格する条件（例: 顧客行為の再現可能性が高い、複数名が被害を申告）をマニュアルに書きます
昇格時は新しい事案IDを発行し、相談IDを参照リンクとして残します
同一レコードを上書きすると、相談時点の秘匿メモが店舗権限へ漏れるリスクがあります

3. 権限と画面の分け方

3-1. 店舗画面は事案のみ既定表示

店長ダッシュボードの既定フィルタは「事案」だけにします
相談一覧は人事・コンプライアンス担当など限定ロールに限定します
中小でもロール名を2つに分けるだけで事故は減ります（中小での対応）

3-2. 方針・マニュアルに同じ言葉を書く

「相談は秘匿、事案は店舗共有（個人名は最小）」を方針に明記します
ひな形は方針ひな形、手順はマニュアル作成で揃えます
システム設定だけ変えて文書が古いと、現場は文書側を信じます

3-3. Excel運用でも列で種別を固定する

シートを分けられない場合でも、A列に種別、B列に段階を置き、フィルタ前提を周知します
シートが増えすぎる問題はExcel管理の限界を踏まえ、早めに権限付きツールへ移す判断材料にします

4. 現場で使える運用会話例

店長が「相談も全部見せて」と言った場合: 「相談は窓口担当の閲覧範囲です。事案化した案件は事案一覧で共有します」と返す
窓口担当が「店舗にすぐ共有したい」場合: 昇格条件を確認し、事案IDを新規発行してから共有する
週次会議では「相談クローズ件数」と「事案クローズ件数」を別行で報告する
研修ではステータス遷移図を1枚配り、ロールプレイで誤クリックを防ぐ（研修記録の残し方）
義務化対応の全体準備は準備チェックリストと突合します

5. ステータス設計の導入チェック

既存レコードに種別フラグが無ければ、まず全件を「事案」仮置きし、窓口担当が相談分だけ付け替える手順にします
画面の既定フィルタが「すべて」のままなら、店長権限では事案のみ表示へ変更します
ステータス名が「対応中」一択なら、相談用と事案用に名称を分割してから移行します
昇格ボタンが無いツールでは、新規事案ID発行→相談側にリンク記入→相談をクローズ、の手作業手順をマニュアルに書きます
週次会議の資料は相談件数と事案件数を別行にし、合算しないことを徹底します
権限ロール名は「店舗運用」「窓口秘匿」「全社閲覧」の3つから始め、増やすのは実害が出てからにします
テスト店舗で2週間回し、誤って相談が店舗一覧に出ないかを毎日確認します
問題が無いこと確認後に全店展開し、展開日を方針の改訂履歴へ残します

6. 誤遷移を防ぐ画面・運用の工夫

4-6-1. 色とラベルで種別を固定する

相談レコードは見出し色を変え、事案と並べたときに一目で区別できるようにします
ステータス選択肢も種別ごとに出し分け、相談画面に「外部連携中」が出ないようにします
選択肢が多いほど誤クリックが増えるため、各種別は最大5段階までに抑えます

4-6-2. クローズ時の確認ダイアログ

クローズ前に「必須項目は埋まっているか」「相談なら事案化しない判断理由があるか」を確認します
ツールにダイアログが無ければ、紙のクローズチェックを印刷して署名欄を設けます
クローズ取消は管理者のみとし、履歴に残る形で再オープンします

4-6-3. 週次の異常値レビュー

「相談なのに店舗閲覧ログがある」「事案なのに秘匿メモが長い」などの異常を週次で見ます
異常は個人攻撃にせず、権限設定と教育の修正材料にします
同じ異常が続く店舗には、ロールプレイで昇格手順を再訓練します

7. 今日からやること

台帳の既定フィルタを事案のみにし、相談の閲覧ロールを確認します
クローズ定義を方針・マニュアルへ同じ文言で追記し、昇格手順を1枚化します
テスト店舗で1週間、誤表示が無いかログを見てから全店へ広げます

8. よくある質問

Q. 相談と事案を最初から別台帳にすべきですか？

人員が少ない場合は同一台帳＋種別フラグでも回せます
ただし閲覧権限が分離できないツールなら、別シート／別システムの方が安全です

Q. 「対応継続」を何日で警告しますか？

事案は3営業日、相談のヒアリング中は5営業日など、種別ごとに期限を分けます
同じ日数にすると相談が急ぎ扱いになり、丁寧な聴取が雑になります

Q. 警察・弁護士連携中のステータスは？

事案側に「外部連携中」を設け、店舗裁量でのクローズを止めます
連携の考え方は弁護士・警察連携を参照してください

Q. 義務化でステータス設計は必須ですか？

法令が特定のラベル名を指定するわけではありません
ただし相談体制と適切な対応の説明には、状態が追える運用が実質必要です（義務化の整理）

Q. 完了後にステータスを戻してよいですか？

原則は新規レコードまたは再オープン履歴を残し、完了を上書き消去しない方が監査に耐えます
いつ誰が何をしたかを追えることが目的だからです

9. 導入後30日の見守り指標

相談の店舗誤表示件数、昇格手順の遵守率、種別ごとの平均滞留日数を週次で見ます
数値が悪い場合は機能追加より、権限と教育の修正を先に行います

10. まとめ

• 相談と事案は種別フラグで分け、ステータス名を共用しない
• クローズ定義と昇格ルールを文書化する
• 店舗画面の既定は事案のみ、相談は限定ロール
• 集計指標も種別ごとに分けて報告する
• 方針・マニュアル・システムの言葉を一致させる

11. 注意

本記事は台帳ステータスの設計例であり、法的助言ではありません。
相談の秘匿範囲や人事権限の分け方は就業規則・個人情報方針と合わせて、自社で確定してください