本文へスキップ
FrameworkReviewed

B0117:サービス回復プレイブック枠組み

名称バリエーション

英語
B0117: Service Recovery Playbook Framework
カタカナ
サービス / プレイブック
漢字
回復 / 枠組

品質 / 更新日 / COI

品質
Reviewed
更新日
COI
none

TL;DR

サービス回復プレイブック枠組みは障害後のサービス回復対応設計を解決までの時間・満足度回復・再発率で構造化し、対応速度と一貫性の緊張関係を明確にする。前提の共有により議論の再発を防ぐ。

いつ使う/使わない

障害後のサービス回復対応設計で利害や前提が分かれる場合に適する。インシデントログ、原因分析、現場キャパシティを統一し、議論の土台を固定することで後戻りを防ぐ。数値で説明すべき局面で力を発揮する。 対応速度と一貫性の優先順位が変わる条件を明示し、解決までの時間・満足度回復・再発率とインシデントログ、原因分析、現場キャパシティの更新ルールを決めておくと再議論を防げる

手順

  1. スコープと期間を定め、解決までの時間・満足度回復・再発率の定義と計測方法を統一して基準線を固定する。
  2. インシデントログ、原因分析、現場キャパシティを収集し、単位・期間・責任範囲をそろえて比較可能な状態に整える。
  3. 対応速度と一貫性がどの条件で逆転するかを感度分析し、結論が変わる閾値を記録する。
  4. 意思決定基準と制約条件を整理し、承認ポイントと実行責任を明文化する。 承認者が見る指標として解決までの時間・満足度回復・再発率の閾値を示し、インシデントログ、原因分析、現場キャパシティの未確定点を明記する
  5. モニタリング頻度と見直し条件を設定し、判断ログを更新できる運用にする。 インシデントログ、原因分析、現場キャパシティの変化をトリガーとして設定し、解決までの時間・満足度回復・再発率のレビュー周期を固定する

テンプレ

テンプレート: 背景/目的; スコープと期間; 成功指標 (解決までの時間・満足度回復・再発率); 主要前提 (インシデントログ、原因分析、現場キャパシティ); 選択肢A/B/C; シナリオ範囲; トレードオフ整理 (対応速度と一貫性); リスクと緩和策; 判断基準; 推奨案; 体制と期限; 見直し条件。データ出所と信頼度、結論が変わる変数を必ず明記する。 補足説明: 解決までの時間・満足度回復・再発率の閾値、インシデントログ、原因分析、現場キャパシティのばらつき、対応速度と一貫性の許容範囲を一覧化し、再評価の条件を固定する

落とし穴

  • 解決までの時間・満足度回復・再発率の定義が部門でずれると比較が成立せず、結論が揺らぎやすい。
  • 対応速度と一貫性の片側に寄り過ぎると、優先順位の変化で再議論が起きる。 とくに対応速度と一貫性の条件が変化する局面を合意していないと再議論が起きる
  • インシデントログ、原因分析、現場キャパシティの裏取りが不十分だと、監査や反証で手戻りが発生する。

事例

ケース: 障害後のサービス回復対応設計で意見が割れたため、解決までの時間・満足度回復・再発率とインシデントログ、原因分析、現場キャパシティを整理して共通理解を作った。補償ルールを標準化し場当たりの判断を減らした。 対応速度と一貫性の影響を明示したことで合意が進み、再検討の回数が減った。 定例レビューで解決までの時間・満足度回復・再発率を共有し、インシデントログ、原因分析、現場キャパシティの前提差が出たら対応速度と一貫性を再計算したため、関係者の納得感が高まった。結果として解決までの時間・満足度回復・再発率の改善とインシデントログ、原因分析、現場キャパシティの透明性が両立し、対応速度と一貫性の議論が短縮された

出典・信頼

  • Principles of Marketing (OpenStax)