宿泊を終えた客ごとに、滞在中の利用と要望の記録から次の滞在につながる案内メールの下書きを作り、配信の前にフロントの確認に回す

処理の起点を決める

Google Sheets の New or Updated Spreadsheet Row で、「送る準備」の列が変わったときに動かします。 このトリガーは、一定の間隔で変化を確かめる方式（Polling）で、行が足されたときにも変更されたときにも動きます。トリガーの列を指定すると、その列が変わったときだけ動きます。

列を指定しないと、記録の欄を書き足すたびに Zap が動きます。 Zapier のヘルプでも、どの列でも動く設定ではちょっとした編集のたびに動くこと、入力の途中の自動保存で書きかけの行が送られることが、意図しない実行の原因として挙げられています。対策として「Send to Zap」のような専用の列を設ける方法が示されており、「送る準備」の列はこれに当たります。

PMSからの書き出しの行を起点にしないのは、記録がまだ空だからです。 New Spreadsheet Row は行が一覧の末尾に足されたときに即時に動くトリガーですが、書き出された直後の行には、フロントが書き足す記録が入っていません。 起点はフロントの手で「済」にしたときにします。

一覧に行を足したり消したりするときは、Zap を止めてから作業します。 動いたまま行の並びを変えると、データの処理が乱れるとされています。月末に古い行を別のシートへ移すときなどが、これに当たります。

入力データを集める

質を決めるのは、滞在中の記録の書き方です。 「誕生日」とだけあるのと、「奥様のお誕生日。デザートにプレートをご用意」とあるのとでは、文面に書ける中身がまったく違います。記録の書き方の例を、フロントと客室係で共有しておきます。

季節のプランの一覧には、「向いている客」の列を必ず書きます。 「記念日のご夫婦向け」「三世代のご家族向け」「おひとり様向け」と書いておけば、AIはその列と滞在の記録を照らして、勧めるプランを選べます。 名前と料金だけの一覧では、どの客にも同じプランを勧めます。

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

トリガーが渡す行の値をそのまま使います。 一覧の1行に、滞在の基本・記録・送る条件がそろっているので、別の表を引く手順はありません。 季節のプランと文面の決まりは、AI by Zapier のナレッジのソースとして付けておきます。

AI by Zapier に渡す欄は、行のすべてではありません。 渡す欄を手順の入力に1つずつ割り当て、渡さない欄は割り当てません。

いちばん下の行を別の列に分けておくのが、この構成の下ごしらえです。 記録の欄が1つの自由記入だと、体の状態も会話も同じ欄に入り、渡すか渡さないかを Zap の側で分けられません。

ナレッジのソースは、季節が変わるたびに差し替えます。 AI by Zapier は実行のたびにナレッジを最初の状態に戻すとされているので、ソースのファイルを更新すれば、次の実行から新しい一覧で選びます。 差し替えを忘れると、終わった季節のプランを勧めます。

AIへ渡す前に整形する

Filter の手順で、次のすべてを満たす行だけを通します。

1. 配信の同意が「あり」
2. 苦情の有無が「なし」
3. 送った日が空
4. メールアドレスが空でない
5. 出発日から14日以内

2番目の「苦情の有無」は、フロントが選ぶ欄にします。 記録の文から AI に苦情を読み取らせる設計にはしません。「お詫びした」「提供が遅れた」の書き方は人によって違い、読み落としがあると取り返しがつかないからです。 選ぶ欄にしておけば、空のまま「済」にすることもできないよう、一覧の入力の規則で止められます。

5番目は、時機を外した案内を送らないためです。 出発から日がたった客に「先日はありがとうございました」と送っても、印象がずれます。14日を過ぎた行は送らず、季節の一斉の案内に回します。

同意の欄は、PMSから書き出された値をそのまま使います。 フロントが手で書き換えられる欄にすると、「たぶん同意していたはず」で「あり」にされることがあります。書き換えは配信停止の連絡を受けて「なし」にするときだけと決めておきます。

3番目は、同じ客に二度送らないためです。 「送る準備」の欄を一度「未」に戻してから「済」にすると、Zap はもう一度動きます。送った日が入っていれば、そこで止まります。

AIに処理させる

させるのは、記録に書かれたことに触れたお礼の文と、季節のプランの一覧から選んだ次の滞在の案内を、1通のメールにまとめることです。

4行目がいちばん気をつけたい点です。 記録には、車いすの利用、食事の制限、体調を崩されたことなど、接客のために書かれた情報が入っています。 それをメールの文面に書くと、本人だけでなく、同じアドレスを見る家族にも伝わります。 文面に使ってよいのは、食事・館内の利用・記念日・次の予定の会話に限ります。

指示内容を固定する

あなたは温泉旅館のフロントで、お泊りいただいたお客様に
お礼と次のご滞在のご案内のメールを書く立場です。
次の滞在の記録と、ナレッジの「季節のプランと催し」「文面の決まり」だけを根拠に書いてください。

【滞在の記録】
お名前：{guest_name} 様　ご来館：{visit_count}回目
ご滞在：{arrival}〜{departure}　{guests}名様　プラン：{plan}
お夕食で追加されたもの：{dinner_extras}
館内のご利用：{facility_use}
記念日：{anniversary}
会話の中のご要望・次のご予定：{guest_comments}

【書き方】
- お礼の段落では、上の記録に書かれた出来事に1つか2つだけ触れてください。
- 次のご滞在の案内では、ナレッジの「季節のプランと催し」から1つ選び、
  「向いている客」の列と、記録の記念日・ご要望を照らして理由を添えてください。
  合うものが無ければ、プランを勧めず、季節の催しを1つだけ案内してください。
- 文面の決まりの書き出しと結びの言葉を使ってください。本文は500字以内。

【厳守事項】
- 記録に書かれていないことを書かないでください。
  「お楽しみいただけたことと存じます」のような推し量りもしないでください。
- 料金、値引き、プランの一覧に無い特典を書かないでください。
- 体の状態、健康、食事の制限、苦情やお詫びに関することを書かないでください。
- 次のご予定を決まったこととして書かないでください。
- 送信者の名称や配信停止の案内は書かないでください（後で固定の文を付けます）。

「推し量りもしない」を明記しないと、どの客にも「ごゆっくりお過ごしいただけたことと存じます」が入ります。 記録が少ない客ほど、AIはこの種の文で行数を埋めます。記録が少なければ短い文面でよいと、文面の決まりにも書いておきます。

配信停止の案内を AI に書かせないのは、毎回同じ文で確実に入れるためです。 Gmail の手順で、本文の後ろに固定の文として付けます。

出力形式を固定する

AI by Zapier の出力フィールドを、次の形で定義します。

{
  "subject": "",
  "body": "",
  "recommended_plan": "秋の記念日プラン",
  "reason": "記録：奥様のお誕生日／会話：次は紅葉の時期に",
  "used_records": ["anniversary", "guest_comments"],
  "note_for_front": ""
}

1つ目の理由は、used_records で承認する担当が根拠を確かめやすくなることです。 文面のどの部分が記録のどの欄から来たかが分かれば、記録に無いことが書かれていないかを短い時間で見られます。

2つ目は、recommended_plan で、どのプランを勧めたかを一覧に残せることです。 月末にプランごとの件数を数えれば、勧め方が特定のプランに偏っていないかが分かります。

作られる本文は、次のような形になります。

山田 花子 様

このたびは当館にお越しいただき、誠にありがとうございました。
奥様のお誕生日のお祝いに、2度目のご滞在をお選びいただけたこと、
係一同うれしく思っております。

「次は紅葉の時期に」とお話しくださったと伺いました。
11月には、記念日のご夫婦向けの「秋の記念日プラン」をご用意しております。
予約ページの「季節のプラン」からご覧いただけます。

またお目にかかれる日を、心よりお待ちしております。

記録の2つの欄（記念日と会話）にだけ触れ、料理の感想は書いていません。 記録に感想が無いからです。

承認の依頼に載せる内容は、次のような形にします。

【案内メールの承認】山田 花子 様（10/4〜10/5 2名様・2回目）
勧めるプラン：秋の記念日プラン
根拠：奥様のお誕生日／会話「次は紅葉の時期に」
件名：先日はお越しいただきありがとうございました
本文：（AIの文面。この画面で直せます）

システムへ連携する

承認の依頼の設定は、次のようにします。 確認者はフロントの担当（特定のメンバー）、通知はメールかSlack、確認者が内容を直せる設定を有効にします。承認の期限は2日にし、期限を過ぎたら実行を終えるほうを選びます。期限を過ぎて自動で先へ進む設定にすると、誰も読んでいない文面が送られます。却下されたときも、実行を止めるほうを選びます。

確認者は Zapier のアカウントを持ち、Zap を共有されている必要があります。 フロントの担当のうち、承認を受け持つ2〜3名に絞ってアカウントを用意します。

Gmail の送信には、Gmail の1日の送信数の上限がかかります。 月300件なら1日あたり十数件で上限には遠いのですが、同じアドレスで季節の一斉の案内も送っている場合は、合わせた数で考えます。 上限を超えると、アカウントが最大24時間止められることがあるとされています。

人が確認する

フロントの担当は、承認の依頼を開いて次の3つを見ます。

1. 記録に無いことが書かれていないか … used_records と本文を見比べます
2. 書いてはいけないことが入っていないか … 体の状態、苦情、料金、特典
3. 勧めたプランが、その客に合っているか … 自分が接客した客なら、会話の印象と照らします

直すところがあれば、承認の画面で直してから承認します。 直した文面がそのまま送られます。合わないと思えば却下し、一覧の「送る準備」を「保留」にして、手で書くかどうかを決めます。

1件にかける時間の目安は3分です。 自分が接客していない客でも、used_records と記録の欄を見比べれば判断できます。3分で判断がつかない文面は、直そうとせず却下し、手で書くほうに回します。 承認の画面で長く直し始めると、手で書くより時間がかかります。

承認した担当の名前は一覧に残ります。 送られたメールについて客から問い合わせがあったときに、誰がどの文面を承認したかをたどれます。

例外に対処する

上から2行目が、いちばん重い例外です。 苦情の有無が空の行を通さないことが、苦情のあった客に案内が届かないことの、ただ1つの守りです。 入力の規則と Filter の両方で止めます。

記録を残す

• 送った文面（件名と本文）と、AIが作った元の文面
• 承認した担当、承認した日時、直したかどうか
• 勧めたプランと、その根拠にした記録の欄
• 却下・期限切れになった客と、その後の扱い（手で書いた／送らなかった）
• 配信の同意を得た日と方法（予約のときの選択）

最後の行は、法令への対応のために残します。 広告や宣伝を目的とするメールは、特定電子メール法で、あらかじめ同意した相手などにしか送ってはならず、同意を受けた側はその記録を保存しなければならないとされています。同意の記録はPMSや予約の仕組みの側にあることが多いので、どこに残っているかを確かめ、一覧から引けるようにしておきます。