予約や申込フォームは、作るだけなら簡単です。壊れるのは「例外」が出始めてからです。
キャンセル、日程変更、部分返金、無断キャンセル（ノーショー）、悪天候・体調不良などの例外…。
これらを“担当者の経験”に寄せるほど、引継ぎで崩れ、対応の揺れがクレームになります。
本記事では、キャンセル・返金をステータスと運用ルールに落として、現場が迷わない形にまとめます。
キャンセルは、理由によって扱いが変わります。まず分類を固定します。
問い合わせのカテゴリ設計（カテゴリ最適化）と同様に、集計できる粒度まで落としておくと、後で改善に使えます。
分類は“細かすぎる”と入力されません。現場が迷うなら、まず4〜6分類に留めて、タグ（タグ設計）で補うのが現実的です。
「前日までOK」は便利ですが、いつまでが“前日”かで揉めます。以下を決めます。
締切が絡むと、カレンダー表示（空き状況表示）や、フォーム連携（カレンダー×申込）の仕様にも影響します。
「締切を過ぎたらフォームからは変更不可、ただし電話なら相談可」など、運用で逃げ道を残す場合は、その旨をUIで明示して離脱を減らします（エラーメッセージ設計の発想）。
返金の設計で揉めるのは、金額よりも「どう返すか」です。代表的には次です。
「振替」を採用するなら、ステータス運用が重要です。
予約の元データを残したまま「振替済」にするのか、新規予約を作って元を「振替元」として紐づけるのか。
ここが曖昧だと、集計（レポート）と現場がズレます。
キャンセル運用で最低限分けたいのは、「キャンセル自体」と「返金処理」です。
ステータスの基本思想は 運用ルール と同じで、現場の行動が変わる状態だけに絞ります。
「返金待ち」を分けると、担当者のタスクが明確になります。担当振り分け（担当ルール）とセットで、返金が滞留しない運用に寄せられます。
例外はゼロにできません。重要なのは「例外を許す条件」と「記録」です。
対応履歴は 履歴の書き方 の発想で、社内向けの理由（判断根拠）を残し、対外文言は別に分けると揉めにくいです。
キャンセル通知は、文面の丁寧さ以上に「次の一手」が重要です。
確認メールに入れる情報は チェックリスト の考え方で、
以下を最低限揃えると問い合わせが減ります。
宿泊は「日程が先」「部屋タイプで在庫が変動」「直前のキャンセル規定が厳しい」など、条件が複雑になりがちです。
業務像は ホテル向け を前提に、締切の定義（何日前・何時）と例外運用を先に固めると、当日の混乱が減ります。
入庫予約は、作業枠（ピット）や部品手配が絡むため、当日キャンセルの影響が大きいです。
業務像は 自動車販売・整備・タイヤショップ向け を前提に、ノーショーの扱い（連絡がつかない場合の処理）をステータスで固定すると運用が揺れません。
キャンセル・返金は「例外」ではなく「必ず起きる通常運用」です。
分類、締切、返金形態、ステータス（返金待ちの分離）、例外の記録、通知テンプレまでを一貫して決めると、現場の判断ブレと問い合わせが減ります。