カードは使えますか?レストランが公開していない支払い方法
現金、カード、振込、請求書発行といったレストランの支払い方法を、お客様が注文する前にページで公開しておけば、カード決済の最低金額やサービス料込みの会計が、思わぬサプライズに感じられることを防げます。
金曜日、夜9時40分。ビジャエルモサにあるルベンのピザ屋の配達員が、ファミリーサイズのピザ2枚を手にドアをノックする。会計は340ペソだ。
—カード端末は持ってます?
—いえ、現金のみです。
お客さんは500ペソ札しか持っておらず、家の中には誰もお釣りを持っていない。配達員は小銭を取りに店まで往復15分、その間ピザはバイクの上で冷めていく。結局お客さんは支払ったものの、次からは別の店に注文するようになる。そして、その理由をルベンに話すことは決してない。
このお客さんを失ったのは、料理のせいでも値段のせいでもない。ピザ屋の支払い方法——現金、カード、振込、請求書発行など、受け付けている決済手段——が、注文する前に誰でも読める場所に書かれていなかったからだ。わずか三十文字の情報——「お届け時にカード決済可」、あるいは「現金のみ、お釣りをご用意ください」——があれば、その夜の結末は違っていたはずだ。
なぜレストランの支払い方法を公開すべきなのか?
なぜなら、会計はレストランの中で唯一、サプライズがほぼ必ず悪い結果につながる瞬間だからだ。支払い方法を公開すること——つまり注文前に何が使えるかを伝えること——で、お客さんが正当なルールを、もう何もできない段階になってから知る、という事態を避けられる。
レストランの中の他のことなら、サプライズは良い方向に働くこともある。店内が想像より素敵だったり、料理が思った以上に大盛りだったり、予想していなかった音楽が意外と気に入られたり。
しかし会計は別だ。会計の場で、お客さんが事前に知らなかった情報はすべて同じように感じられる——隠されていたように。悪意がなかったとしても関係ない。200ペソ以上でなければカードが使えないという最低金額、すでに含まれていた10%のサービス料、会計時に告げられる「カードは取り扱っていません」——どれも、最後になって現れた小さな注意書きのように読めてしまう。
そして、そのどれも本当は問題ではない。カード決済に最低金額を設けるのは正当だし、カード端末がないのも正当、大人数の席でサービス料を含めるのも正当だ。お客さんを不快にさせるのはルールそのものではなく、もう何もできない段階でそのルールを知ることだ。公開すれば、支払いの受け方を何も変えずにこの問題は解決する——ただ、前もって伝えるだけでいい。
レストランのページにはどの支払い方法を書くべきか?
必要な情報は五つだけで、そのうち四つがあればほとんどのレストランはカバーできる。
- 受け付けている支払い方法を順番に。「現金、デビットカード・クレジットカード、振込」。カード端末がない場合は、そのままはっきりと書く:「現金のみ」。
- 宅配でもカードが使えるかどうか。 これは店内での会計とは別の問題で、答えている店はほとんどない。配達員がカード端末を持っていくなら明記する。持っていかないなら「宅配は現金のみ、お支払い金額を事前にお知らせください」と書く。
- 最低金額があれば、それも。 一行で十分:「カードは150ペソ以上から」。
- 請求書(ファクトゥーラ)を発行するかどうか、そして発行に何が必要か。
- サービス料が含まれているかどうか、何人以上から、何パーセントか。
それだけでいい。VisaやMastercardのロゴが並んだ「お支払い方法」セクションなんて必要ない。必要なのは、レジに立つ人の頭の中以外の場所に、その答えが存在することだ。
カード決済に最低金額を設けるべきか?
設けてもいいし、それは正当なことだ——ただし、公開するか、完全にやめるかのどちらかにすること。中途半端に運用するのは、ないよりも悪い。
このアドバイスには実際のコストがあることも言っておかなければならない。「カードは150ペソ以上から」と公開すれば、120ペソの注文をいくつか失うだろう。見えていないのは、その注文は今すでに失っているということだ。違うのは、失うタイミングが後になる、つまりお客さんが席に着いて、すでに不機嫌になったレジの場面になるという点だけで、それは高い代償を払って失うバージョンにすぎない。
しかし、もっと悪い罠がある。それは最低金額を中途半端に運用すること——誰がレジに立っているか、お客さんがどんな顔をしているかによって、適用する日としない日があることだ。これではルールが抽選になってしまい、適用されたお客さんは「自分だけ選ばれた」と感じる。最低金額を設けるなら、ページに書いて、その通りに運用すること。公開するのが気まずいと感じるなら、それはもうそのルールをやめたいという良いサインだ。120ペソの会計にかかる端末の手数料はせいぜい3〜4ペソ。お客さんを一人失う方が、よほど高くつく。
レストランが請求書を発行するかどうかはページに書くべきか?
書くべきだ——これはほとんどのレストランが公開していない情報であり、オフィスの大口注文を決める決め手になる情報でもある。
近くのオフィスが12人分の食事を注文するとき、注文する人が選んでいるのは一番おいしい料理ではない。選んでいるのは、どこなら請求書を発行してもらえるかだ。それによって経費が戻ってくるかどうかが決まるからだ。あなたのページに何も書いていなければ、聞かれることもなく候補から外されてしまう。
二行あれば十分だ:
「はい、請求書を発行しています。ご利用当日にWhatsAppで税務登録証明書(constancia de situación fiscal)をお送りいただければ、24時間以内に発行いたします。」
発行していないなら、それも書くべきだ。「請求書の発行は行っておりません」と書けば、どうせ最終的に「できません」で終わるはずの三往復のやり取りを省ける。請求書が必要な人はあなたの時間を取る前に離れていき、必要ない人はそもそも気にも留めない。
会計を分けられることや、サービス料が含まれていることはどう伝えるべきか?
席で説明するのではなく、ページで公開すること——会計につき何枚までカードで分けられるか、そして大人数の席にはすでにサービス料が含まれているかどうかを。
一つの会計でカードを何枚まで分けられるか。 最大3枚までなら、そう書いておく。8人のグループが会計を8分割にしたいと言うのは、あなたを困らせたいわけではなく、単に知らなかったからだ。事前にそれを読んでいれば、1人が払って残りのメンバーが振込で返す、というやり取りは彼らの間で済み、あなたを巻き込むことはない。
サービス料がすでに含まれているかどうか。「8名以上の席には10%のサービス料を含みます」。これを公開することは、心配しているのとはまったく逆の効果を生む。来店前にそれを読んだ人は文句を言わないし、ウェイターも、良い夜の最後に悪い知らせを伝える役目から解放される。
会計の場で勝手に決められたチップは、お客さんが後で誰かに話してしまう数少ないことの一つで、しかも良い話としてではない。同じチップでも、ページで事前に知らされていれば、誰も話題にすることはない。
ページに公開してはいけない支払い情報は何か?
二つある。完全なCLABE(銀行標準化口座番号)と、イベントの予約金・前払い金だ——どちらも支払い方法のセクションには書かない。
誰でも見られる場所にCLABEを公開すること。 インターネットに公開された銀行口座はコピーされ、流用され、最終的には自分のお客さんに、あなたの名前を使って勝手にお金を要求するスクリーンショットとして使われてしまう。「振込を受け付けています」とだけ書き、口座情報は求められたときにWhatsAppで送るようにする。
イベントの予約金・前払い金。 これは支払い方法ではなく、まったく別の話だ——いくら前払いするのか、いつまでに、キャンセルした場合はどうなるのか——これらは専用のセクションにまとめるべきだ。
はっきりさせておきたいのは、これは決してオンライン決済の導入ではないということだ。決済ゲートウェイを設置するわけでも、何かを連携させるわけでもない。今までとまったく同じように、店内やお届け先で支払いを受ける。変わるのは、それが文字として書かれているという一点だけだ。
あとは説明するだけ
自分で何かを組み立てる必要はない。説明すれば、ページができあがる。
「ビジャエルモサにあるルベンのピザ屋のページ。価格付きのメニュー、ピザの写真、火曜から日曜の13時から23時までの営業時間、そして支払い方法のセクションには:現金、150ペソ以上からデビット・クレジットカード、振込、当日の税務登録証明書があれば請求書も発行可能、と記載。宅配の配達員はカード端末を持参。注文用の大きなWhatsAppボタンも設置。」
ページはリンク付きで公開され、誰かに聞かれたときはそのリンクを送るだけでいい。
レジに立つ人に聞いてみる
今日の営業が終わったら、レジに立っていた人にひとつだけ質問してみてほしい。「今日、お会計のときに何を聞かれた?」
その人は何か月も同じ質問のリストに答え続けているのに、誰からもそれを聞かれたことがない。あなたが自分のお店を知らないわけではなく、単にその時間帯の現場はあなたの担当ではないというだけのことだ。三十秒もあれば二つか三つは出てくるはずで、そのうち少なくとも一つは、あなたが想像していなかったものだろう。
それこそが、あなたのページに足りていない項目だ。推測する必要もないし、数える必要もないし、二週間待つ必要もない——答えはすでに、一緒に働いている誰かの頭の中にある。
proyecta.devで説明して、公開しよう。