宿泊後のアンケートの回答から、低い評価と苦情の書き込みをすぐに拾って支配人と担当の部署へ回し、お詫びと改善を伝える返信の文案を添える

処理の起点を決める

Google フォームの「New Form Response（Instant）」で、回答が届くたびに動かします。 1日1回の定時にまとめないのは、第3章の（a）を解くためです。夜の9時に届いた苦情が、翌朝の申し送りの前に部署のチャンネルに入っている状態を作ります。

回答を1件ずつ処理するので、件数が多い日にも通知がまとめて飛ぶことはありません。 チェックアウトの翌日の昼にアンケートのメールを送る運用なら、回答はその日の午後から夜にかけて少しずつ届きます。

低い評価でも苦情でもない回答は、Digest にためます。 Digest のアクションでためておき、週次で放出して、支配人に一覧で送ります。良い声も、1件ずつ通知すると誰も読まなくなります。 まとめて読むほうが、部署を褒める材料として使えます。

Digest の上限には注意します。 アカウント全体で1,500件までなので、月400件の回答のうち大半を週次でためても収まりますが、 他の Zap でも Digest を使っているなら合計で数えます。1つの Digest は1MBまでなので、ためるのは自由記述の要旨だけにします。

入力データを集める

質を決めるのは、部署の一覧に書く「担当する範囲」です。 「客室係：客室の清掃、布団、アメニティ、客室の備品」「施設：空調、給湯、照明、大浴場の設備、駐車場」のように書きます。範囲が書かれていないと、空調の苦情が客室係に行くか施設に行くかが回答ごとに揺れます。

宿泊の情報は、アンケートのリンクに埋め込んで渡します。 宿泊日と部屋の種類が分かれば、部署の担当がその日の担当者と部屋を特定できます。宿泊客の名前は、AIにも Slack にも渡しません。

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

連絡先のメールアドレスは、AIのステップに渡しません。 返信の文案は宛先なしで作らせ、Gmail の「Create Draft」のステップで宛先を差し込みます。

回答のスプレッドシートには、処理の結果の列を足しません。 フォームの回答のシートに列を足すと、フォームの側の更新で崩れることがあるので、分類の結果は別の記録のシートに書き込みます。

AIへ渡す前に整形する

1. 点数の判定 … 総合が2以下、または5項目のどれかが1なら low_score の印を付けます。Zapier の Filter と Paths の条件で、数値として比べます
2. 自由記述の有無 … 空欄か「特になし」「なし」だけなら、AIのステップに進みません
3. 言語の確認 … 外国語の自由記述も、そのままAIに渡します。要旨は日本語で作らせ、返信の文案は書かれた言語で作らせます
4. 重複の確認 … 同じ宿泊日・同じ部屋から2件届いたら、同じ組の宿泊客として記録のシートで1つにまとめます

1番目を Filter の条件で書くのは、決まりを誰でも読めるようにするためです。 「総合が2以下」を変えたくなったら、Zap の条件を1か所直すだけです。AIのプロンプトの中に点数の決まりを書くと、どこで判断しているかが見えなくなります。

AIに処理させる

1つ目のステップ（分類）では、自由記述について次の4つをさせます。

（1）担当の部署に分ける

1件の回答に複数の部署が当たるときは、すべてを並べさせます。 第3章の（b）の「夕食の時間に部屋の空調がうるさかった」は、facility と kitchen の両方です。部署ごとに、その部署に関わる部分だけの要旨を作らせます。

（2）声の種類に分ける

complaint（苦情）、request（要望）、praise（お褒め）の3つです。1件の回答に苦情とお褒めが混ざることはふつうで、 部署ごとに種類を付けさせます。

（3）急ぐ事情の印を付ける

印は、当たる記載があるかどうかだけです。 根拠の一文を必ず写させます。点数が高くても、印が1つでもあれば支配人に回します。

（4）日本語の要旨を部署ごとに作る

書かれた言葉に近い形で、2文以内にさせます。宿泊客の感情の強さを和らげて書き直さないように、 「たいへん不快だった」は「不快だった」とせずにそのまま残させます。

2つ目のステップ（作成）では、 連絡を希望する宿泊客への返信の文案を作らせます。お礼、書かれた苦情への具体的なお詫び、部署に伝えたこと、の3つで構成させます。

指示内容を固定する

1つ目のステップ（分類）の指示です。

あなたは旅館の支配人の補佐です。
宿泊後のアンケートの自由記述を読み、担当の部署、声の種類、急ぐ事情に分けてください。

【部署と担当する範囲】
room：客室の清掃、布団、アメニティ、客室の備品、客室係の接客
kitchen：料理の味・量・温度、食事の時間、アレルギーへの対応、食事処の接客
front：チェックイン・チェックアウト、電話、予約の内容、料金、案内
facility：空調、給湯、照明、大浴場の設備、駐車場、館内の段差
bath：大浴場の清掃、混雑、時間
other：どれにも当たらない

【進め方】
1. 自由記述を、部署ごとの話に分けてください。1つの文が複数の部署に当たるときは、両方に入れてください。
2. 部署ごとに、種類を complaint / request / praise から1つ選んでください。
3. 部署ごとに、その部署に関わる部分だけの要旨を日本語で2文以内に書いてください。
   宿泊客が書いた感情の強さを和らげないでください。

【急ぐ事情】次に当たる記載があれば urgent_flags に印を入れ、根拠の一文をそのまま写してください。
safety / hygiene / allergy / lost_item / refund / public_review / discrimination
記載がなければ空にしてください。推し量って印を付けないでください。

【厳守事項】
- 書かれていないことを補わないでください。
- 苦情が事実かどうかを判断しないでください。
- 宿泊客の名前、連絡先、他の宿泊客の様子を要旨に書かないでください。
- 点数については何も判断しないでください。点数の扱いは別の仕組みで行います。

【宿泊日・部屋の種類・食事のプラン】{stay_info}
【自由記述】{comment}

「点数については何も判断しない」を最後に置いているのは、 AIが点数と文を合わせて「全体としては満足」と結論を付けたがるからです。点数の判断は Filter が持っていることを、指示の中でもはっきりさせます。

「感情の強さを和らげない」も必ず入れます。 要旨を作らせると、AIは丁寧な言葉に直します。「二度と来ない」が「再訪の意向は低い」になると、部署の担当には重さが伝わりません。

2つ目のステップ（作成）の指示には、「{summary} の苦情について、具体的にお詫びする。部署に伝えたことを書く。事実を認める・否定する表現、補償・割引・返金、『必ず改善します』、宿泊客の落ち度、他の宿泊客の様子を書かない。書かれた言語で、300字以内。宛名は {宛名} のまま」と書きます。

出力形式を固定する

AI by Zapier の出力項目として、次の項目を定義します。

{
  "response_id": "",
  "language": "",
  "topics": [
    { "department": "room | kitchen | front | facility | bath | other",
      "type": "complaint | request | praise",
      "summary_ja": "" }
  ],
  "urgent_flags": [],
  "urgent_evidence": "",
  "has_complaint": false,
  "reply_draft": ""
}

構造化する理由の1つ目は、Paths の条件に使えることです。 urgent_flags が空でなければ支配人への分岐、has_complaint が true か点数の low_score があれば部署への分岐に回します。分岐の条件が項目の値なので、どの回答がどこに回ったかを後から説明できます。

2つ目は、部署ごとの通知に分けられることです。 topics の部署ごとに、その部署のチャンネルへ要旨だけを送ります。1件の回答の全文を全部署に送ると、自分に関係のない苦情まで読むことになります。

3つ目は、has_complaint を別の項目にしていることです。 topics の中に complaint があるかを後段で数えるより、AIに1つの値で返させて Filter の条件にするほうが、設定が単純になります。

システムへ連携する

宿泊客への返信は下書きまでで、「Send Email」のアクションは置きません。 支配人が下書きを直して送ります。苦情への返信が自動で届くと、宿泊客には機械的な対応に見え、苦情が重くなります。

部署のチャンネルには、要旨と宿泊日・部屋の種類だけを送ります。 部署の担当が対応したら、その投稿のスレッドに対応の中身を書いてもらいます。スレッドに返事がない投稿が、そのまま未対応の一覧になります。

Slack では、アプリから同じチャンネルに送れるのは1秒に1件までとされています。 1件の回答で複数の部署に送る場合も、部署ごとにチャンネルが違えば問題になりません。

人が確認する

支配人は、急ぐ事情の通知を受けたら、その日のうちに事実を調べる担当を決めます。 safety と hygiene は、同じことが次の宿泊客に起きないように、調べる前に現場を確かめさせます。

返信の下書きは、事実を調べてから送ります。 調べた結果、苦情のとおりだったなら、お詫びの文に具体的な対応を足します。苦情と事実が違っていても、宿泊客の落ち度には触れません。

例外に対処する

最後の行で、点数の判定を AIの外に置いた意味が出ます。 AIのステップが止まっても、点数の低い回答は Filter と Paths の条件で支配人に届きます。 自由記述の分類が抜けるだけで、低い評価の見落としは起きません。

Filter で文案を止めるのは、プロンプトの禁止だけでは足りないからです。 宿泊客が「返金してほしい」と書いていると、それを受けた一文を文案に入れることがあります。

記録を残す

• アンケートの回答（回答のスプレッドシートにそのまま残る）
• 分類の結果、urgent_flags と根拠の一文、通知した先と日時（記録のシート）
• 部署の担当が対応した中身（Slack のスレッド）と、対応した日
• 支配人が外した印・足した印と、部署の振り分けを直した記録
• 返信を送った日時と、直したあとの文
• AIのステップの入出力（Zap の実行履歴）

4つ目の「振り分けを直した記録」が、部署の一覧を直す材料になります。 空調の苦情が毎回 room から facility へ直されているなら、部署の一覧の担当する範囲の書き方が足りていません。

記録のシートから、月ごとの部署別・種類別の件数を数えられます。 第3章の6番の月末の集計は、このシートを並べ替えるだけになります。