PDFを指すQRコードがデジタルメニューではない理由

問題1：誰も読めない

メニューはA4かA3向けに組まれています。スマホの画面幅は約7cm。PDFは縮小された状態で開き、文字の高さは3ピクセル。お客様は指で広げ始めます。3列目を読むには横スクロールし、位置を見失い、探すためにまた縮小します。

これは小さな不便ではありません。スタッフが今も「リゾットの中身は？」と聞かれ続ける理由です。お客様はPDFで諦め、人に尋ねる方法に戻ったのです。QRコードを足しただけで、以前の業務量はそっくり残っています。

問題2：変更は今もデザイン作業のまま

一品の値段を上げるには、元ファイルを開き、編集し、PDFを書き出し直し、同じURLにアップロードし直し、コードがまだ開くか確認する必要があります。レイアウトファイルが外部の制作者の手元にあれば、メール一往復と待ち時間です。だから値上げは次の変更とまとめられ、また次とまとめられ、メニューは3か月古いまま置かれます。紙とまったく同じ問題です。

問題3：今夜の状況を伝えられない

スズキは20時30分に品切れになりました。PDFはそれを知りようがありません。お客様が注文し、スタッフが詫び、お客様は追い込まれて選び直し、たいてい安いものを選びます。ホスティング型のメニューならワンタップで非表示にでき、その隙間を誰も体験しません。

問題4：アレルゲンと言語がファイルを増やす

観光地なら3〜4言語が必要です。つまりPDFが3〜4本、QRコードが3〜4個か選択用の中間ページ、そして値段が動くたびに書き出し直すファイルが3〜4本。アレルゲン列を足せば各ファイルは横に広がり、スマホの問題はさらに悪化します。ホスティング型のメニューは一度翻訳し、アレルゲン情報をレイアウトではなく品目に紐づけて保持します。

問題5：Googleから見えない

人は「[あなたの街] パエリア レストラン」と検索し、Googleはインデックスされたテキストから答えます。QRコードの先のPDFは、通常サイトからリンクもされておらず、有用にクロールもされないため、料理名が表に出ることはありません。ホスティング型のメニューページはただのHTMLで、他のページと同じようにインデックスされます。小さな店では、自社で2番目に閲覧されるページになることも珍しくありません。

問題6：行き止まりである

PDFは注文を受けられず、40人がコース料理を見て誰も注文しなかったことも教えてくれず、厨房に何も送れません。後から欲しくなる改善は、すべて「PDFを置き換える」ところから始まります。

比較

PDFが本当に正解になるとき

2つあります。ひとつは、お客様が印刷する前提の文書。宴会の提案書、団体向けのコース内容、ケータリングの価格表です。それは文書であり、文書にはPDFが正しい形式です。もうひとつは、メニューが変わらず、変える気もない店。2か月の営業で6品しかないビーチバーにシステムは要りません。

メニューを打ち直さずにPDFから移る手順

1. 紙のメニューを撮影するか、PDFそのものをアップロードします。
2. IQ Restがそれを読み取り、カテゴリー、品目、価格を作成します。ひと晩ではなく約5分です。
3. 価格を確認し、読み取りが誤った箇所を直します。
4. 既存のQRコードを新しいメニューに向けるか、テーブルごとに新しく印刷します。