はじめに
予約システムを作っていると、メールの種類がどんどん増えていきます。予約確認、決済完了、キャンセル、エラー通知 — 気づけば15種類になっていました。
この記事では、これらをどう整理し、誰に何をいつ送るかをどう決めたかを紹介します。「送りすぎない」ことも設計のうちです。
予約管理システムのメール機能を使わない
あえて自前で作った理由
予約管理システムには、予約確認メールを自動送信する機能が備わっています。設定するだけで使えるのに、あえて自前で作りました。理由は3つあります。
特に1つ目が大きな問題でした。宿の公式サイトから予約したのに、まったく別のドメインからメールが届いたら、お客様は「詐欺サイトだったのでは」と不安になります。
そこで予約管理システム側の自動送信をすべて無効にし、自社のメール配信サービスから送る形にしました。
OTA経由の予約は例外にする
ただし、OTA経由の予約は別です。予約サイトによっては、お客様の本当のメールアドレスが提供されなかったり、直接の営業行為が規約で禁止されていたりします。
そのためOTAからの予約については、予約管理システム側の通知機能をそのまま使う方針にしました。すべてを自前で統一しないという判断です。
ゲスト向けと運営者向けを分ける
ゲスト向けは5種類
お客様に送るメールは5種類に絞りました。予約確認、決済完了、キャンセル完了、お問い合わせの控え、そして予約確認の変則版（専用ページの発行に失敗した場合）です。
カード登録が完了し、予約が確定した時点。専用ページのURLと課金予定日を記載
チェックイン14日前の自動課金が成功した時点。請求額を記載
お客様自身がキャンセル手続きを完了した時点
リマインドメールを送らない選択
気づかれたかもしれませんが、この一覧には「チェックイン前日のリマインド」も「宿泊後のお礼メール」もありません。これは意図的な判断です。
ポータルがリマインドの役割を果たす
専用ポータルは予約直後から開けて、チェックインが近づくと自動的に情報が増えていきます。お客様は好きなタイミングで確認できるので、こちらから何度もメールを送る必要がありません。メールが多いと重要なものが埋もれる、という判断もありました。
必要な情報がいつでも見られる場所があるなら、通知の回数は減らせます。
運営者向けは10種類
一方、運営者向けのメールは細かく用意しました。予約成立の連絡、専用ページの発行失敗、予約管理システムとの不整合、自動課金の失敗、日次レポート、予約内容の変更検知、キャンセル通知、お問い合わせ通知などです。
運営者向けメールには、共通のルールを設けています。
- 件名に【要対応】を付ける — 人が動く必要があるものだけ。眺めるだけでよい通知には付けない
- 具体的な対処方法を書く — 「エラーが発生しました」ではなく「予約管理システムの画面で該当予約を確認してください」まで書く
- 返信先を設定しない — 誤って返信してもお客様に届かないようにする
最後の点は地味ですが重要です。お問い合わせ通知だけは例外で、そのまま返信できるようお客様のアドレスを返信先に設定しています。
メールの中身を作る
デザインを1つに統一する
予約確認メールとお問い合わせの控えが違う見た目だと、同じ宿からのメールに見えません。そこで全メール共通の外枠を作り、中身だけを差し替える方式にしました。
ロゴはメールに添付する形で埋め込んでいます。外部URLから読み込む方式だと、多くのメールソフトが画像をブロックしてしまい、ロゴのない寂しいメールになるためです。
HTMLメールが表示できない環境のために、テキスト版も必ず用意しています。
4言語の文面を用意する
お客様向けメールは、予約時に選ばれた言語で送ります。文面は言語ごとに用意し、日程や金額といった変わる部分だけを差し込む形にしました。
ここで重要なルールが1つあります。金額・料率・日数といった数値は、翻訳の文面に直接書かないことです。
「14日前に50%」と4言語すべてに記載。規定変更時に一部の言語だけ古いまま残る
文面には差し込み位置だけを書き、数値は設定ファイルから取得。変更が全言語に一度で反映
キャンセル規定を変更したときに、英語版だけ古い数字が残っていた、という事故を防ぐための仕組みです。
文面の管理場所を分ける
メールの文面は、サイト本体の翻訳ファイルとは別に管理しています。メールは定期処理やWebhookから送られることがあり、そうした場面ではサイトの翻訳機能が使える前提がないためです。
「決済は成功したのに、文面が取得できずメールが送れなかった」という事態を避けるための構成です。
管理画面でプレビューできるようにする
15種類のメールがどんな見た目になるか、管理画面から確認できるようにしました。ただし編集はできません。
メールの文面には金額やキャンセル規定が含まれます。管理画面から気軽に編集できると、法的に問題のある表現に書き換わってしまうリスクがあります。確認はできるが変更は開発側で、という線引きです。
まとめ
メール通知の設計で押さえたのは、次の3点です。
- 自社から送る — 差出人とタイミングを自分でコントロールし、宿からのメールとして届ける
- 送りすぎない — ポータルがある前提で、リマインドや宿泊後のメールは省く
- 数値を文面に埋め込まない — 設定から差し込むことで、多言語の食い違いを防ぐ
通知の重複防止や送信漏れへの対策は「通知を二重に送らない」で解説しています。