同じ数値をコピーすると、異なる損失を生む
記事中心の企業サイトと、購入支援を行うECサイトへ同じしきい値を設定しても、意味は同じになりません。前者では一時停止の影響が小さくても、後者ではテレビ紹介の日に注文を失う可能性があります。
例えば月1万回の呼び出しを全社標準にしても、社内下書き中心のA社では十分、1日で数千件の購入質問が来るB社では繁忙日に不足、1回あたり入力が長い士業C社では金額上限が先に尽きます。数値のコピーは作業を早めますが、契約、顧客導線、単価が違えば同じ保護にはなりません。
標準化するのは五つの質問
各サイトで同じ順番の質問に答え、その結果として設定値を決めます。これなら担当者が替わっても判断理由を追えます。
初回ヒアリングは30分で行い、回答がない項目を推測で埋めません。正常なピークが不明なら、最初の2週間は監視中心の暫定設定にします。止めた場合の顧客損失が大きいのに成果データが取れないサイトは、計測導線の整備を先行タスクとして登録します。標準化とは、不明点を同じ方法で扱うことでもあります。
- AI費用が発生する機能はどれか
- 止めると失う顧客成果は何か
- 正常なピークはいつ起きるか
- 成果のない反復をどこで識別できるか
- 誰が変更・復旧を承認するか
サイト種別ごとの例外を認める
会社案内は固定停止、ECの購入支援は文脈を見た制御、会員サイトはログイン状態を追加材料にするなど、例外を文書化します。ProのSmart Protectionで示されるHuman・Bot・Unknownは完全判定ではないため、各サイトの売上や問い合わせと組み合わせます。例外は逸脱ではなく、事業要件への適合です。
例外票には、標準値との差、理由、承認者、期限、再評価条件を書きます。テレビ放送月だけECの通知基準を2倍にする、会員更新日はログイン済み経路を優先して残す、と期間も限定します。『重要顧客だから』のような説明不能な例外は認めず、推定費用と誤停止損失で根拠を示します。
設定を配る前に1サイトで検証する
テンプレートの変更は、代表サイトで監視モードから始めます。誤停止、推定費用、顧客成果を確認し、戻せることを確かめてから対象を増やします。20サイトへ同時反映すると、問題の原因も20倍に広がります。
順番は、低リスクな社内機能1サイト、顧客向けだが代替導線のある2サイト、売上直結サイトの順です。各段階で少なくとも7日観察し、正当操作の誤停止ゼロ、推定費用の異常検知、ロールバック15分以内を確認します。モデルやプラグイン版が違うサイトは同じ検証群へ入れません。
共通台帳に残すのは値より理由
サイト名、対象機能、制御方式、例外理由、承認者、見直し日を一元管理します。次に確認するのは、同じ設定値かどうかではなく、同じ手順で説明可能な判断ができているかです。
成果物は20社共通の判断台帳とサイト別例外票です。新任担当者に3サイトを渡し、台帳だけで『なぜこの値か』『いつ戻すか』『誰に連絡するか』を説明できるか試します。説明できない行は設定を変える前に情報を補い、期限切れ例外や契約終了サイトを週次で削除します。運用開始後は、誤停止、超過費用、確認工数をサイト別に月次集計し、共通手順そのものが負担を減らしているか評価します。ある例外が3社以上で繰り返されたら標準質問へ昇格し、逆に半年使われない項目は削除候補にします。標準を固定文書ではなく、実績で更新する仕組みにします。契約終了時は例外票の削除だけでなく、許可サイト、担当者権限、通知先が外れたことまで完了条件にします。サイトURL変更は旧URL削除と新URL検証を一組で記録します。
「20社に同じルールを配るだけでは、複数サイト運用は標準化できない」から一律停止が正当な需要まで拒むと分かったなら、さらに粗いルールで解決しないでください。まず無料版をダウンロードして基準値を作り、Human・Bot・Unknownと売上シグナルが必要になった段階でProのSmart Protectionへ移れます。