宿泊予約の取消のアンケートとメッセージを取消の理由に分類し、毎月の理由別の件数と取り戻せそうな取消の一覧を作る

処理の起点を決める

入口は2つあります。 アンケートの回答は Google Forms の Watch Responses で、取消の連絡のメールは Gmail の Watch emails で拾います。どちらも15分ごとに動かし、同じ後段の処理に流します。

メールの入口は、Gmail のフィルターで先に絞ります。 代表のメールアドレスには予約・問い合わせ・営業のメールが混ざって届きます。件名や本文に「キャンセル」「取消」「取り消し」を含むものに Gmail の側で「取消」のラベルを付け、Make はそのラベルの未読だけを見ます。 処理が終わったら、Update email labels で「取消_処理済み」のラベルに付け替えます。

予約サイトから届く取消の通知メールは拾いません。 通知には客の理由が書かれておらず、分類する材料がありません。客が自分で書いた文があるものだけが対象です。

月次の集計は、別のシナリオで毎月1日の朝に動かします。 Make のスケジュールの「月次」で日と時刻を指定します。1件ずつの分類と同じシナリオに入れないのは、失敗したときにどちらが止まったか分かるようにするためです。

入力データを集める

アンケートに「別の日の案内を希望するか」の選択を足すのが、最初の大事な変更です。 案内を送ってよいかを客に聞いておけば、見込みが「高」でも希望しない客には送りません。 案内を送る根拠が、客自身の選択になります。

予約の情報のうち、宿泊日と予約日の差（リードタイム）と、取消日と宿泊日の差が効きます。 3か月前に予約して2週間前に取り消した客と、前日に取り消した客では、同じ「予定の変更」でも事情が違います。 区分はAIが付けますが、この2つの差は Make で計算してから渡します。

区分の定義は、例文つきで持ちます。 区分の名前だけを渡すと、AIは名前から意味を推測します。「料金」と「他の宿」の境目のように迷いやすい区分は、例文で線を引きます。

データの取得方法を決める

予約番号は、アンケートなら事前入力の欄から、メールなら本文と件名から取り出します。 メールでは「予約番号」「Reservation No.」「確認番号」のように書き方がばらばらです。Make の正規表現で英数字の並びを拾い、予約の台帳を引いて当たったものだけを予約番号とします。 当たらなければ、送信元のメールアドレスと宿泊日らしい日付で台帳を引き直します。

予約の台帳は、予約システムから毎日書き出したものを使います。 予約システムに直接つながず、書き出しのシートを読むだけにします。取消の直後で台帳にまだ載っていない予約は、翌朝の書き出しの後にもう一度引きます。

AIへ渡す前に整形する

1. 引用と署名の除去 … メールの返信の引用部分（「>」で始まる行、「-----Original Message-----」の後）と署名を落とします
2. 予約番号の取り出しと照合 … 上の方法で取り、台帳で当たるかを確かめます
3. 日数の計算 … 予約日から宿泊日までの日数と、取消日から宿泊日までの日数を Make で計算します
4. アンケートとメールの重複の確認 … 同じ予約番号でアンケートとメールの両方があれば、1件にまとめて両方の文を渡します
5. 個人の情報の除去 … 氏名、電話番号、メールアドレスはAIに渡しません。予約番号と、予約の情報のうち分類に要る項目だけを渡します
6. 言語の確認 … 外国語のメッセージもそのまま渡します。根拠の文は原文のまま返させ、日本語の要約を別に付けさせます

4番目を省くと、同じ取消が2件に数えられます。 法人の担当者がメールで連絡し、出張者本人がアンケートに答える、ということがあります。

5番目は、分類の精度に影響しません。 理由の判断に氏名は要らず、送らないほうが第13章の扱いが簡単になります。

AIに処理させる

させるのは、1件ごとに理由の区分と再予約の見込みを付け、根拠の文を書き出すことです。

「案内の対象外」を見込みの一つとして持たせるのが要点です。 体調・家族の事情の取消は、理由としては数えますが、見込みは必ず「案内の対象外」にします。 これは指示で決めるだけでなく、Make の側でも「主な理由が体調・家族の事情なら通知しない」という条件を Router に置きます。AIの判断と規則の両方で外します。

3行目を守らないと、月次の表が意味を失います。 「都合により」とだけ書かれた取消を、AIは予約の情報から推測して「料金」や「他の宿」に入れたがります。書かれていなければ「判別できない」に入れ、その件数自体を月次の表に出します。 判別できない取消が多いこと自体が、アンケートの聞き方を直す材料です。

指示内容を固定する

あなたはホテルの営業部で、宿泊予約の取消の理由を整理する担当です。
客が書いた文と予約の情報を見て、取消の理由と再予約の見込みを付けてください。

【付けるもの】
1. primary_reason：主な理由を、区分の定義から1つ
2. secondary_reasons：ほかに書かれている理由を、区分の定義から0〜2個
3. rebook_potential：再予約の見込みを high / medium / low / not_applicable から1つ
4. evidence：理由と見込みを決めた客の文を、原文のまま抜き出す
5. guest_request：客が求めていること（書かれていなければ空）
6. summary_ja：客の文の日本語の要約を1文で

【厳守事項】
- 客の文に書かれている理由だけで決めてください。
  予約の情報（料金・プラン・日数）から理由を推測しないでください。
- 理由が書かれていない、または「都合により」「事情により」だけの場合は、
  primary_reason を undetermined にしてください。
- 体調、病気、けが、妊娠、家族の不幸・介護に関わる取消は、
  primary_reason を health_family にし、rebook_potential は必ず
  not_applicable にしてください。
- rebook_potential を high にするのは、別の日・別のプラン・後日の宿泊の
  意思が客の文に書かれている場合だけです。
- 「別の日の案内を希望しない」と答えた客は、high にせず medium 以下にしてください。
- evidence は客の文をそのまま写してください。言い換えないでください。
- 案内の文面や、取消料についての意見を書かないでください。

【区分の定義と例文】{reason_definitions}
【予約の情報】宿泊日 {stay_date}／泊数 {nights}／プラン {plan}／人数 {guests}／
  経路 {channel}／予約から宿泊まで {lead_days}日／取消から宿泊まで {cancel_lead_days}日
【案内の希望】{wants_offer}
【客の文】{guest_text}

「予約の情報から理由を推測しない」を最初に書くのは、ここが最もずれやすいからです。 料金の高いプランの取消を見ると、AIは「料金」を選びがちです。予約の情報は、見込みの判断の材料として渡しているだけだと明記します。

体調・家族の事情の扱いを、区分の定義とは別に指示の本文に書いています。 定義の表だけに書くと、他の理由と併記された文で見落とされます。「必ず」と書く項目は指示の本文に置きます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "reservation_id": "",
  "source": "survey | email | both",
  "primary_reason": "schedule_change | price | chose_other_hotel | weather_transport | health_family | party_itinerary_change | duplicate_mistake | facility_plan_terms | undetermined",
  "secondary_reasons": [],
  "rebook_potential": "high | medium | low | not_applicable",
  "evidence": [""],
  "guest_request": "",
  "summary_ja": ""
}

1つ目の理由は、月次の集計を Make の集約だけで書けることです。 primary_reason の値が決まっているので、Array aggregator の Group by に指定すれば、区分の値ごとに1つのまとまりが出ます。 自由文の理由では、表記のゆれで同じ理由が別の行に分かれます。

2つ目は、通知の条件を規則で書けることです。 rebook_potential が high で、primary_reason が health_family ではないものだけを Router の経路で通知に回します。AIが誤って high を付けても、規則の側で止まります。

3つ目は、evidence で通知を読む人が判断できることです。 営業の担当者は、通知に載った客の文を読んで案内を書くかを決めます。AIの要約ではなく客の言葉で判断します。

営業のチャットへの通知と、月次の表は次の形にします。

【取り戻せそうな取消】予約番号 R-20261008-0123
宿泊日 11/14（金）1泊・2名・朝食付き・自社サイト／取消は宿泊の37日前
理由：予定の変更（副：なし）
客の文：「仕事の都合で11月は難しくなりました。12月の週末で空きがあればまた予約したいです」
案内の希望：あり
→ 取消の記録の該当行へのリンク

【10月の取消の理由】（取消の記録 312件）
| 理由 | 件数 | 自社サイト | 予約サイト | 電話・メール |
| 予定の変更 | … | … | … | … |
| 判別できない | … | … | … | … |

システムへ連携する

予約システムには書き込みません。 取消の手続きそのものは予約システムで終わっており、この構成は理由を記録するだけです。返金や取消料の扱いには触れません。

客へのメールは、この構成から送りません。 Gmail の下書きも作りません。案内は営業の担当者が自分のメールで書いて送ります。

人が確認する

1件ずつの分類は、人が確かめずに記録します。 分類の結果が直接客に届くことはなく、月次の表の材料になるだけだからです。その代わり、確認は3つの場面に置きます。

1. 通知を受けたとき（毎日） … 営業の担当者が客の文を読み、案内を送るかを決めます。AIの見込みが「高」でも、文を読んで違うと思えば送りません。 送らなかったものは記録に「送らず」と書きます
2. 月次の表を出す前（月1回） … マーケティングの担当者が「判別できない」と「その他」に近い行を流し見し、区分の定義に足すべき型が無いかを見ます
3. 区分の定義の見直し（月1回） … 2番目で見つかった型を例文として定義の表に足します

1番目で「送らず」を記録するのが要点です。 見込みが「高」なのに送らなかった件が多いなら、AIの「高」の付け方が営業の感覚と合っていません。 指示か定義を直す材料になります。

月次の表は、会議に出す前に件数の合計を取消の記録の行数と照らします。 合わなければ集計のシナリオが一部の行を落としています。

例外に対処する

4行目は、メールの入口で毎月何件か起きます。 「11月14日の予約を12月に変えたい」は取消ではありません。予約の担当が手続きすべき依頼なので、分類の前に人へ回します。 指示に「取消か日程の変更の依頼かを先に判定させる」項目を足しておくと拾えます。

構造化出力は、refusal や max_tokens で止まったときにはスキーマに沿わないことがあるとされています。Router のフォールバックで拾い、見直しの一覧に入れます。

記録を残す

• 取消の記録（全件） … 予約番号、入口（アンケート・メール・両方）、予約の情報、primary_reason、secondary_reasons、rebook_potential、evidence、summary_ja
• 通知と対応の記録 … 通知した日時、案内を送ったか、送らなかった理由
• 再予約の結果 … 案内を送った客が再予約したか（予約の台帳で予約番号の後に同じ客の予約があるかを月次で見る）
• 区分の定義の変更履歴 … いつ、どの例文を足したか
• 月次の表 … 月ごとに別のシートとして残す

3つ目の再予約の結果は、この構成の効果を確かめる唯一の材料です。 案内を送った件数と、そのうち再予約に至った件数を毎月数えます。数え方を決めずに始めると、効果があったのかどうかが分かりません。

取消の記録には客の書いた文が残ります。 保存の期間を決め、期間を過ぎた行の evidence は消します。