AMP for Emailはメール内で操作できても受付記録の正本を別に持つ

メール本文の中で出欠を返し、予約希望を送り、質問票へ答えられるようになれば、問い合わせの入口は短くなる。ただし、メール内で操作できたことと、依頼を受け付けたことは同じではない。受付の記録、担当者へ渡す通知、読者へ返す案内は、メール画面とは別に確かめられる場所へ残す。

Googleが2月13日に公表したAMP for Emailは、メールから出欠回答、予約、質問票への入力ができる仕組みを示した。仕様は公開されているが、Gmailでの利用はdeveloper previewであり、年内の対応が予定されている段階である。新しい表示方法を、すぐに全ての読者が使える問い合わせ窓口として扱わない。

メールで押した送信と受付済みの記録を分ける

問い合わせformでは、読者が送信ボタンを押した瞬間に終わるわけではない。入力内容が受信側へ届き、必要な項目が残り、誰かが確認できる状態になって初めて受付として扱える。メール内の操作でも、この順序は変わらない。

たとえば、内覧の予約を受けるメールを考える。読者は希望日を選び、送信したつもりで画面を閉じる。一方、受ける側には、希望日時、氏名、連絡先、送信時刻が揃って届かなければ、折り返しの連絡ができない。空き枠を表示する仕組みがあっても、その表示だけでは予約の確定を示せない。別の人が先に同じ枠を選んでいるかもしれないからである。

そこで、操作の結果はWeb側の受付処理へ渡す。処理を受けた側で、必要な内容を記録し、担当者へ通知し、読者には受付番号か次の案内を返す。メールは入力の入口として使えても、受付の正本まで兼ねさせない。この分け方なら、担当者が交代しても、どの依頼を誰が見たかを追える。

メール内の表示を更新できる場合も、同じである。表示が新しく見えることは、読者が見る情報を保つ助けになる。しかし、表示された空き状況と、受付処理で確定した内容は別に残す。画面を見た時点の情報だけを根拠に、予約済みと案内してはいけない。

先に決めるのは画面の便利さではなく受け方である

新しいformを作るとき、最初に考えやすいのは、どの質問をメール内に置くかである。けれども小さな事業では、質問を増やすほど、受け取った後の確認も増える。必要な情報と、受ける人の作業を先に決める方がよい。

予約なら、候補日だけで足りるのか、人数や希望内容まで必要なのかを決める。問い合わせなら、返信に必要な連絡先と、見積りに必要な条件を分ける。どちらも一度の入力で全部を聞こうとすると、読む側は途中でやめやすい。最初の連絡で必要な項目だけを受け、詳しい確認は返信で行う方が、入力する人にも受ける人にも無理がない場合がある。

次に、届いた内容を誰が見るかを決める。個人が一人で対応するなら、通知先は一つでもよい。ただし、外出中に見られないなら、読者へいつ返すかを別に伝える。複数人で受けるなら、全員へ同じメールを送るだけでは、誰が対応するかが曖昧になる。受付記録に担当者を付けるか、確認した人が残る一覧を用意するか、どちらかを選ぶ。

ここでいう一覧は、大がかりな顧客管理の仕組みである必要はない。少なくとも、送信内容が消えず、確認した人が後から読み直せる場所ならよい。反対に、メールソフトの受信箱だけへ任せると、転送漏れ、削除、担当者の変更で経緯を追えなくなる。便利な入力画面より、受け方が続くことを優先する。

通常の問い合わせ先を残してから試す

AMP for Emailは、Gmailでの対応がこれから予定されている段階である。メール内の操作だけを唯一の入口にすると、対応していない環境の読者や、表示を使わない読者が連絡できない。予約や問い合わせのように取りこぼしが困る用件では、通常のWeb pageか、返信先のメールアドレスを残す。

たとえば、案内メールに予約用の操作を置く場合でも、同じ案内の中に予約pageへのlinkを置く。メールで操作できる人はそのまま進める。うまく表示されない人はpageから進める。電話で受ける必要がある事業なら、受付時間と番号も示す。入口を増やす目的は、同じ内容を何度も管理することではない。どの入口から来ても、最後は同じ受付処理へ集めるためである。

通常のpageを残すと、公開前の確認もしやすい。自分のGmailで一度見えたからといって、すべての読者の画面で同じように動くとは限らない。まずWeb pageで入力、送信、受信通知、読者への案内までを通す。その後でメール内の操作を加える。問題が起きたときも、受付そのものを止めずに原因を分けられる。

受付を試す前に通して見る順序

導入を決める前に、実際の連絡を一件だけ通して確認する。架空の名前と連絡先を使い、メールから入力し、受付側へ届くまでを見る。画面の見た目より、途中で内容が変わらないことを確かめる。

まず、読者が送る内容を決める。次に、受信した内容がどこへ記録されるかを確認する。その記録を見た担当者が、読者へ何を返すかを決める。最後に、メール内の操作が使えないときの入口を用意する。この四つが揃えば、新しい表示方法を試しても、受付の仕事が見えなくならない。

AMP for Emailは、メールを読むだけの場所から、何かを進める場所へ変える可能性を持つ。しかし、依頼の内容と対応の責任まで自動で整えるものではない。メール内でできる操作を増やす前に、受付の正本と、読者が必ずたどれる連絡先を決める。そこが曖昧なままなら、便利な画面を作っても、受ける側の仕事だけが増える。