紹介するお店
退店時のひと言を、
地域ネットワークの入口に。
- ポスターを指して、気軽に案内できる運用を目指す。
- 満席時にも、地域内の別店舗へのご案内という選択肢を作る。
- 紹介が実際の来店につながったかを記録する。
- 自店が紹介を受ける側にもなれる店舗間ネットワークを育てる。
実証では、声を掛けやすいか、通常の接客に無理なく組み込めるか、継続して参加したいかを確認します。
店舗間送客システム / 店舗向けの詳しい説明
実証導入準備中 · 一般利用は未公開
気軽な案内が、
次のお店への入口に。
紹介する店舗、お客様、迎える店舗。それぞれの利用場面から、運用とメリットを説明します。
ポスターから来店まで
レジ横で「よかったら、
こちらを利用してみませんか」。
大がかりな接客ではなく、退店時のひと言で案内できる運用を目指します。紹介先はシステム側で案内する方向です。以下は実証に向けた想定で、利用開始の案内ではありません。
想定場面
「もう一軒、行こうかな。」
いつもの店で食事を楽しんだあと、案内ポスターに気付く。お客様が自分のスマートフォンで確認し、利用するかどうかを決めます。
満席で自店にご案内できない場面も、近隣の参加店舗につなげる利用例として検証します。
- 01
紹介元で案内を見る
QR付きポスターなど、案内を確認する入口を設置する想定です。
- 02
システムが紹介先を案内
近隣の参加店舗へご案内。利用するかどうかはお客様が判断します。
- 03
紹介チケットを受け取る
ご案内した店舗への紹介をチケットでつなぐ想定です。
- 04
紹介先へ来店・到着確認
店舗へ移動し、到着したことを確認します。
- 05
実際の利用を確認・承認
受入店が実際の利用を確認し、店舗側で承認する想定です。
- 06
成立を記録する
その後の確定処理で成立を記録。紹介・到着・成立を分けて評価します。
掲示、QR読取、チケット発行、到着だけで送客成立になるわけではありません。店舗独自特典の適用条件は各店で確認します。詳細な運用条件は実証開始前に合意します。
双方が参加したくなる条件を
紹介する店にも、
迎える店にも意味がある。
他店への善意だけに頼るのではなく、負担とメリットに納得できる運用を実証で確かめます。
退店時のひと言を、
迎えるお店
知らなかったお客様に、
自店の魅力を伝える。
- 近隣店から紹介を受け、新しい来店の機会を作る。
- 空席のある時間帯に、自店を知ってもらう入口を増やす。
- 独自特典で、初めての利用を後押しする。
- 到着と成立を区別し、実際の利用状況を確認する。
売上だけでなく、原価・特典・確認作業などの負担も見て、店舗ごとに採算と納得感を評価します。
お客様にとっての楽しみ
いつものお店の先に、
新しい体験がある。
食事のあとにもう一杯、あるいはカフェへ。地域内の別店舗を知るきっかけを作ります。紹介先はシステムが案内する想定です。
店舗からの紹介だから、入口が見つかる。
普段ならそのまま帰るところを、「もう少し楽しみたい」と思ったときに近隣店舗への案内を確認できる。参加店の紹介や場所、営業時間などを来店前に知る入口を整える構想です。
利用を強制しません。案内を見て利用しないことも、お客様の判断です。
簡易ホームページ・Web集客支援
「どんな店か分からない」を、
来店の前に減らしたい。
ホームページがない、情報が古い、更新しづらい。そんな店舗には、必要な情報に絞った簡易店舗ページを、費用を抑えた個別提案として検討できます。
掲載構成のイメージ / 実際の画面ではありません
店舗写真
店舗名・お店の紹介
営業時間 / 場所 / 電話番号
メニュー地図SNS
情報と写真は店舗の許可を確認して掲載します。
基本情報を、一つの入口に。
- 店舗名、営業時間、住所、電話番号
- 写真、メニュー、店舗紹介
- Googleマップ、SNSへの導線
追加表示・連携は、提供状態を確認して。
店舗独自特典、混雑状況、「今から行く」、予約導線は追加・連携候補です。現時点ですべて利用できる機能ではありません。
作成範囲・価格・写真の使用許可・更新と維持管理は個別に確認します。一律の低価格や無料提供を約束するものではありません。
簡易ホームページとWeb支援はReferral本体とは分けた追加支援です。参加の必須条件ではありません。
混雑情報を、お客様にも店舗運営にも
「今、行けそう？」と
「いつ、何人で対応する？」を支える。
Crowdはカメラによる現在の混雑把握に加え、観測記録を曜日・時間帯・期間別に振り返る店舗向け分析を備えています。お客様の来店判断と、店舗のスタッフ配置を考える材料として活用できます。
お客様向け / 現在の状況
来店前の判断材料に。
混雑の目安と更新状況を確認し、来店するタイミングを考える入口に。古い情報や取得できない場合は「状況不明」として扱います。空席・入店・予約を保証するものではありません。
混雑表示の例：呑み処ちょっと店舗向け / 過去の傾向
経験に、データを重ねる。
曜日や時間帯で混み方が違うのか、直近7日間は前の7日間とどう違うのか。スタッフの応援が必要そうな時間帯や、配置を見直したい時間帯を検討します。
曜日・7日分析とスタッフ配置を詳しく適正人数を考えるための参考情報
スタッフの配置に、
データという判断材料を。
混雑の傾向と店舗が設定した対応能力を組み合わせ、スタッフ人数の目安と実際の配置との差を確認します。シフトを自動決定したり、人員削減を指示したりする機能ではありません。
- 01 / 混み方を確認
曜日・時間帯で振り返る
平均・最大の検出人数や観測記録から、忙しい時間帯と落ち着いた時間帯を確認。
- 02 / 店舗の条件を重ねる
人数の目安を確認
スタッフ1人あたりの基準対応人数、最低・最大人数、平均か最大かの設定を反映。
- 03 / 現場で判断
実配置と比べて見直す
配置との差を参考に、応援やシフトを検討。仕込み・片付け・予約・接客内容も考慮。
曜日 × 時間帯
いつ忙しいかをつかむ。
同じ曜日でも、早い時間と遅い時間では混み方が違う場合があります。曜日・時間帯別の人数の目安を、実スタッフ配置と比較する材料にします。
直近7日 × 前の7日
最近の変化を、毎週確認。
平均・最大検出人数などの前期間比較で、最近の変化を確認。次週の応援や配置を見直す入口にします。当日を含む集計のため、集計途中の日は比較に注意します。
直近30日・月別も併用
1週間だけで決めない。
7日間では各曜日が原則1回しか含まれません。曜日の傾向は複数週で確かめ、祝日・天候・イベント・予約の違いも踏まえて判断します。
よくある質問
参加を考える前に。
今すぐお客様が利用できますか？
いいえ。現在は開発・実証導入準備中で、一般利用は公開していません。参加相談を受け付け、実証条件を確認している段階です。
紹介先をお客様が自由に選ぶサービスですか？
現在は、紹介先をシステム側で案内する方向です。お客様はサービスを利用するかどうかを判断します。詳しい案内条件は実証開始前に確認します。
QRを読んだら、送客成立になりますか？
なりません。紹介・到着・実際の利用と店舗承認・成立を区別します。QRの読取や到着だけを実際の送客成果として扱いません。
ホームページやカメラがないと参加できませんか？
簡易ホームページ、Crowd、その他の追加支援はReferral参加の必須条件ではありません。必要な店舗に個別に相談する構想です。
混雑データから、必要なスタッフ人数が自動で決まりますか？
決まりません。店舗が設定した対応人数や最低・最大人数に基づく参考値を示し、実配置と比較する材料にします。仕込み・片付け・予約・接客内容などは店舗側で確認し、最終的な配置を判断します。
直近7日間の分析だけで十分ですか？
直近7日と前の7日の比較は、最近の変化を毎週確認するために使います。曜日ごとの傾向は直近30日など複数週と併せて確認します。記録が少ない場合や欠測がある場合は、必要人数やスタッフ不要を断定しません。
参加条件や料金は決まっていますか？
初期無料トライアルを想定しています。参加条件・料金はお問い合わせください。有料化は実証の成果と課題を確認した後に検討し、自動移行しません。