同じ「決済エラーが発生したので顧客に連絡する」という業務でも、エラー理由ごとに最適な文面は大きく違います。カード期限切れの案内文と、不正検知ヒット時の中立通知を同じテンプレートで送ると、顧客に余計な不安を与え、ブランドへの信頼を損ね、結果として戻ってくる確率も下がります。
本稿では、決済エラー管理（Payment Error Management）の運用で頻出するシナリオ群と、文面設計の方向性を整理します。AI による下書き生成と人間判断による送信を前提とした、Rule-first, AI-assisted の運用に沿った考え方です。
「決済エラー連絡=全部同じ文面」が招く 3 つの問題
多くの事業者様で起きているのは、決済エラー通知を 1〜2 種類の汎用テンプレートだけで運用しているケースです。Webhook を受けたら一律で「お支払いが完了しませんでした」と送るパターン — 一見シンプルに見えますが、実務では以下の問題を起こします。
1. シナリオに合わない文面によるブランド毀損
カードの有効期限が切れただけの顧客に「至急ご確認ください」と書くと、顧客は自分が悪いことをしたかのような印象を受けます。逆に認証エラー時に「カードを更新してください」と書くと、本来問題のないカードを再登録させてしまい、認証フローのつまずきは解消しません。
2. 戻ってくる確率の低下
受動的チャーンの回復率は、最初の連絡文面の精度に強く依存します。海外調査では、シナリオ別に最適化された文面のほうが、汎用テンプレートよりも回復率が 1.5〜2 倍（参考値）高いと報告されています。
3. 不要な問い合わせ増加
「何が原因で止まったのか」が文面から読み取れないと、顧客はサポート窓口へ問い合わせます。曖昧な「お支払いの確認のお願い」を一律送ると、原因問い合わせがカスタマーサポートに集中し、本来不要だった対応工数が積み上がります。
シナリオ別文面設計が必要な 4 つのケース
Recovery Monitor の 5 分類（再試行候補・カード更新候補・顧客対応候補・認証確認候補・リトライ非推奨）のうち、特に顧客連絡が必要なのは次の 4 シナリオです。それぞれ文面のトーン・伝えるべき情報・依頼すべきアクションが異なります。
シナリオ 1: カード期限切れ案内
もっとも頻度が高く、復旧確率も高いシナリオです。顧客に非がないことを明確に伝え、淡々と更新導線を案内するのが鉄則です（送信タイミング設計の詳細はカード更新案内メールの「タイミング設計」を併読推奨）。
シナリオ 2: 残高不足の再決済案内
残高不足は一時的なケースが多く、数日以内に解消することが大半です。顧客に過度な負担をかけず、再試行予定を伝えて落ち着いた印象を持っていただく文面が向いています。
シナリオ 3: 認証エラー時の確認依頼
3D セキュア等の本人認証で止まったケースです。カード自体には問題がないため「カードを更新してください」と書いてはいけません。発行カード会社への確認を促す中立的な案内が適切です。
シナリオ 4: 不正フラッグ時の中立通知
もっとも文面設計が難しいシナリオです。不正検知システムの判定が正しいか誤検知かは事業者側からは判断できません。事業者から再試行・カード更新を促すと顧客とカード会社の認識がずれます。「自社からは追加手続きを行わない」ことを明確にし、顧客自身の判断に委ねる中立文面が適切です。
共通する設計思想 — 状況を正確に、依頼は必要最小限に
4 シナリオに共通するのは「顧客に状況を正確に伝え、必要な判断のみを依頼し、不要な不安を与えない」という設計思想です。シナリオ別の文面を一式整備しておくだけで、決済エラー連絡の精度は大きく上がります。文面のトーンは事業者様のブランド規約に合わせて調整してください — BtoB SaaS なら敬体多めに、コンシューマー向けサービスなら柔らかい言い回しに、というように、ブランドトーンとの一致が信頼性を支えます。
Recovery Monitor の AI 下書き機能 — Rule-first, AI-assisted
Recovery Monitor では、上記 4 シナリオを含む各分類に対して、AI が顧客連絡文面の下書きを生成します。運用にあたっては以下の方針を一貫して守っています。
- 送信は行いません。AI は下書きを生成しますが、送信判断・送信操作はすべて事業者様の担当者が行います。
- PII は AI に渡しません。顧客名・カード番号等はプレースホルダのまま下書きを生成し、送信前に事業者様側で差し替える設計です。
- 「下書き」「参考値」を明記します。最終確認は人間判断で行われる前提を崩しません。
- シナリオ判定はルールベースです。エラー理由コード・カード種別・課金方式から 5 分類への割り当てを行い、AI は文面ドラフト生成と次アクション整理を担当します。
この設計は、決済実行・再請求・再課金・顧客への連絡送信を AI から分離し、人間の判断を介在させるための仕組みです。
まずは自社の決済エラー規模を確認する
「自社で月にどれくらいの決済エラーが発生しているのか」「そのうちカード期限切れ・残高不足・認証エラー・不正検知の内訳はどうなっているのか」を把握するところから、文面整備は始まります。決済エラー損失計算機では、月次決済件数とエラー率から見落としで失われている可能性のある売上を概算できます（参考値）。
実データに対して 5 分類と文面下書きがどう提示されるかを試したい事業者様向けに、30 日間無料トライアルをご用意しています。送信件数・復帰件数を月次レビューで議題化する設計とセットで運用するのが理想です。