人気のキャストが1人辞めました。翌月の売上が目に見えて落ちます。ここまではどの店にも起きることです。問題はその後で、離れていった客が誰だったのかを、店が名前で言えないことのほうです。

コンカフェの客はキャストに付きます。推しに会いに来るのであって、店の看板に来ているわけではない。これは業態の前提であって、直そうとする類のものではありません。ただ、誰がどれくらいの頻度で来ていたのかという記録が、担当キャストの個人アカウントの中にしか存在しない状態は、業態の前提ではなく運用上の選択です。

かといって、店が客の個人情報を無制限に集めればいいという話にもなりません。集めた瞬間から、店には管理する責任が発生します。決めるべきは3つです。どこまで残すか。誰まで見られるか。辞めたらどうするか。順に整理します。

客はキャストに付き、店には来店の事実すら残らない

コンカフェの来店動機は、ほとんどキャスト個人を経由して作られます。出勤日の告知も、イベントの案内も、来店のお礼も、キャストの個人アカウントから流れる。チェキを撮り、その写真がまた個人アカウントに載って次の来店につながる。店が用意した導線ではなく、キャストが自分で回している導線の上に客が乗っています。

結果として、店の手元に残るのはレジに記録された売上の金額だけになります。誰が何回来たのか、前回いつ来たのか、どのキャストの常連なのか。これらは担当キャストの頭の中と、個人のスマートフォンの中にしかない。店は、自分の店の常連客が何人いるのかすら答えられません。

だからキャストが辞めたとき、客も一緒に消えます。しかも店は、消えたことにしばらく気づけません。来店の頻度を数えていないので、客が離れたのか、たまたま間隔が空いているだけなのかを区別する材料がないからです。気づくのは、月次の売上が落ちてからになります。

この構図はキャバクラ・ラウンジでも起きますが、コンカフェは形が少し違います。単価の高い太客を1人失うのではなく、単価がそれほど高くない常連が何十人まとめて動く。1人あたりの重みが小さいぶん、個別の異変として現場に届きにくく、まとまって抜けたときのダメージだけが大きい。太客中心の店で起きる情報の持ち出しと消失については顧客情報の管理と持ち出し対策で扱っているので、あわせて読んでください。

店として残すのは、どこまでか

「店で管理しよう」と決めた途端、情報を取れるだけ取ろうとする店があります。これは設計ではありません。集めた情報は守る対象になるので、必要のない項目を増やすことは、そのままリスクを増やすことと同じです。

店の運営に必要な情報は、実はそれほど多くありません。だいたい次の4つで足ります。

  • 来店の頻度(いつ来たか。日付が並んでいれば間隔は計算できる)
  • 利用額(1回あたりいくら使っているか。物販やチェキの内訳が分かるとなおよい)
  • 担当キャスト(誰の常連なのか。複数いるなら複数)
  • 注意事項(アレルギー、避けたい話題、過去のトラブル)

呼び名は、客が名乗っている通称で構いません。コンカフェは本名や住所を必要とする業態ではないので、そこを無理に取りにいく理由がない。逆に、勤務先、家族構成、恋愛関係、当日どんな話をしたかといった私生活の詳細は、キャスト個人の接客メモとしては価値があっても、店の台帳に残す業務上の理由がありません。残せば、漏えいしたときの被害が増えるだけです。

注意事項の欄だけは、店として持っておく価値が高い項目です。過去に他の客やキャストとトラブルになった、支払いでもめた、といった記録は、次に来店したときの対応を決める材料になります。度を越した迷惑行為への対応や出入り禁止の判断については、2026年10月1日から事業主の義務として強化されるカスタマーハラスメント対策とあわせてカスタマーハラスメント対策で整理しています。

来店履歴も、呼び名と結び付いた利用額も、個人情報です。誰がいつ、どの店に来て、いくら使ったか。これが外に出れば、客にとっては来店の事実そのものが知られたくない情報になり得ます。コンカフェは若い客層も多く、SNSで人間関係がつながっているぶん、漏れたときの広がり方も速い。

個人情報保護法と個人情報保護委員会のガイドライン(通則編)では、事業者に対しておおむね次のことが求められています。利用目的を特定して本人へ通知または公表すること。安全管理措置を講じること。本人の同意なく第三者へ提供しないこと。本人から開示等の請求があったときに対応すること。件数が少なければ対象外になるという扱いは、現行法にはありません。小さな店でも当てはまります。

これを店の実務に落とすと、そう大げさな話にはなりません。何のために記録するのかを決めておく(来店時の接客と店からの案内のため、といった程度で構いません)。記録の置き場所を1か所に決めて、私物の端末や紙のメモに散らさない。外部へ渡さない。本人から「どんな情報を持っているのか」と聞かれたときに答えられる状態にしておく。この4つが回っていれば、日々の運用としてはかなりまともです。

逆に危ないのは、店のLINEグループに客の情報を貼る、共有端末を誰でも触れる状態にしておく、退店したキャストのアカウントを止めずに残す、といった日常の光景のほうです。事故はたいてい、悪意ではなく手軽さから起きます。個人情報の扱いの基本的な整理は顧客情報の管理と持ち出し対策にまとめています。

キャストが全顧客を見られる必要はない

記録を店に集めると、次に決めるのは閲覧の範囲です。ここを決めずに共有すると、集めたこと自体が新しい問題を生みます。

基本の分け方は単純で、店長・店舗責任者は全件、キャストは自分の担当分と店の共有事項まで、という形です。日々の接客は、自分の常連の来店履歴と注意事項が見られれば回ります。他のキャストの常連が誰で、いくら使っているかまで見える必要はありません。

むしろ、そこが全員に見えることの弊害のほうが大きい。誰の常連が何人いて、いくら落としているかが全キャストに見える状態は、コンカフェのようにキャスト間の売上比較が可視化されやすい業態では、客の取り合いや人間関係のこじれに直結します。情報を守るためだけでなく、店内の空気を保つためにも範囲は分けたほうがいい。

ただし、全員が見るべき情報もあります。出入り禁止にしている客、要注意として共有しておくべき情報は、担当のあるなしに関係なく全キャストが知っている必要があります。誰が対応するか分からないからです。担当ごとに閉じる情報と、全員に開く情報を、最初から別の区分として設計しておくのが実務的です。

もう1点、全件を書き出せる人を絞ることも決めておきます。閲覧できることと、まとめて持ち出せることは別です。紙のノートやLINEグループで運用していると、そもそも権限という概念が存在せず、グループに貼った瞬間に全員が複製を持てる状態になります。

退店時は、アクセスと記録を分けて扱う

退店の日にやることは3つです。アクセスを止める。記録は店に残す。担当を引き継ぐ。この3つを分けて考えられていない店が多く、「辞めたから全部消す」あるいは「何もしない」のどちらかになりがちです。

アクセスの停止は、退店当日に処理します。共有端末のログイン、台帳の閲覧権限、店の公式アカウントの管理権限。ここを止めないまま数か月放置されている店は珍しくありません。一方で、その人が担当していた客の記録そのものは店に残します。記録を消してしまうと、引き継いだ次の担当が最初から関係を作り直すことになり、客の側にも断絶が伝わります。

難しいのは、個人アカウントで築いた関係のほうです。技術的に止める手段はありません。だから、就業規則や誓約書のレベルで扱いを決めておくことになります。ここで線を引くべきは、私生活のSNS利用そのものではなく、店で得た顧客情報を退店後に使わないという点です。個人のアカウント運用を丸ごと禁止しようとしても実効性がなく、そもそも入店時の合意も取りにくい。線を細く引くほど、守られる確率は上がります。

そして、この合意は退店時ではなく入店時に取るものです。辞める日に持ち出しの話を切り出しても手遅れで、入るときに「顧客情報は店の管理する情報であること」「退店時は引き継いで手元からは削除すること」を書面で共有しておく。手順としてはそれだけです。日常的に業務の連絡が個人アカウントに混ざっているほど、この線引きは曖昧になります。業務連絡と私用連絡を分ける考え方は業務連絡と私用連絡を分ける理由で扱っています。

年齢の若いキャストが多い店では、もう1点注意が要ります。酒類を提供する店では、18歳未満を22時以降に客へ接する業務に就かせることはできません。店内での就業時間は店が管理できますが、個人アカウント上での客とのやり取りには店の管理が及ばない。店の外での個別のやり取りをどう扱うかは、入店時のルールに含めておく価値があります。

誰がいつ入れるかまで決めないと、記録は続かない

ここまでの設計は、記録が実際にたまらなければ何の意味もありません。そして記録が続かない理由は、たいてい入力を求めすぎているからです。

現実的な粒度は2つだけです。会計のときに、来店を1行残す。日付、呼び名、担当、金額。それだけで来店頻度は積み上がります。もう1つは、担当キャストが退勤前に、必要があれば一言メモを足すこと。必要がなければ書かなくていい、というのが大事な部分で、毎回詳しい接客メモを義務にすると2週間で誰も書かなくなります。

この2つが続くと、客ごとの来店日が並びます。並べば間隔が計算でき、間隔が計算できれば「この客、いつもより空いている」が分かる。離反の前兆をどう読むかは常連客の来店が途切れる前兆で詳しく扱っていますが、その入り口にあるのは高度な分析ではなく、会計時の1行です。

この1行を紙のノートで積み上げると、来店頻度を出すために月末に日付を数え直すことになり、閲覧範囲を分けることも、退店時にアクセスだけ止めることもできません。記録を店の側に集めつつ、見られる範囲を役割で分ける。この形を作るために、私たちは顧客台帳システムをお店ごとに作っています。コンカフェの運用全体で何が詰まりやすいかはコンカフェの店舗運営にまとめました。いまの記録の残し方のどこが不安か、相談だけでも構いません。

よくある質問

コンカフェで客の個人情報はどこまで集めていいですか?

業務上必要な範囲にとどめるのが基本です。店の運営には、来店した日付、利用額、担当キャスト、注意事項の4つがあれば足りることが多く、呼び名も客が名乗っている通称で構いません。勤務先や家族構成、恋愛関係といった私生活の詳細は、店の台帳に残す業務上の理由がなく、漏えいしたときの被害を大きくするだけです。集めた情報は守る対象になるため、項目を増やすことはそのままリスクを増やすことになります。

小さい店でも個人情報保護法の対象になりますか?

なります。取り扱う件数が少なければ対象外になるという扱いは、現行法にはありません。利用目的を特定して本人へ通知または公表すること、安全管理措置を講じること、本人の同意なく第三者へ提供しないこと、本人から開示等の請求があったときに対応することが求められます。実務としては、何のために記録するかを決め、置き場所を1か所にし、外に渡さず、聞かれたら答えられる状態にしておくところから始めれば十分です。

キャストが個人のSNSアカウントで客とつながるのは禁止すべきですか?

全面的に禁止しても実効性を持たせるのは難しく、入店時の合意も取りにくいのが実情です。線を引くなら、私生活のSNS利用そのものではなく「店で得た顧客情報を退店後に使わない」という点に絞るほうが守られる確率は上がります。あわせて、業務の連絡が個人アカウントに混ざらないよう、店の連絡経路を分けておくと線引きが曖昧になりにくくなります。

キャストが辞めるとき、担当していた客の情報はどう扱えばいいですか?

アクセスの停止と記録の保持を分けて考えます。共有端末のログイン、台帳の閲覧権限、店の公式アカウントの管理権限は退店当日に止める一方、その人が担当していた客の来店履歴は店に残し、次の担当へ引き継ぎます。記録ごと消すと、引き継いだキャストが関係を一から作り直すことになり、客の側にも断絶が伝わります。この扱いは退店時ではなく入店時に書面で共有しておくものです。

キャストに顧客リストを見せても問題ありませんか?

範囲を分けたほうが安全です。日々の接客は、自分の担当客の来店履歴と注意事項が見られれば回ります。誰の常連が何人いていくら使っているかが全員に見える状態は、漏えいのリスクだけでなく、客の取り合いやキャスト間の関係悪化にもつながります。一方で、出入り禁止や要注意といった情報は誰が対応するか分からないため全員が見られるべきで、担当ごとに閉じる情報と全員に開く情報は最初から別の区分として設計します。

迷惑客や出入り禁止の記録を店に残しておいてもいいですか?

次の来店時の対応を決めるために必要な情報であり、業務上の目的の範囲で記録すること自体は考えられます。ただし記録の目的と閲覧できる範囲は決めておき、必要以上に詳しい内容を書き残さないことです。度を越した迷惑行為への対応や出入り禁止の判断は、2026年10月1日から事業主の義務として強化されるカスタマーハラスメント対策とあわせて整理しておくと、現場が迷いません。

この記事の課題を、システムで解決するなら

推しに付いた客を、店の記録としても残す

お店専用の顧客台帳システムなら、来店日・利用額・担当キャスト・注意事項を店の側に集約し、担当分だけを見せるキャストと全件を見る店長で閲覧範囲を分けられます。退店時はアクセスだけを止めて記録は店に残せるので、キャストの入れ替わりが引き継ぎで済みます。相談は無料で、導入前提でなくても大丈夫です。

画面も項目も、お店の運用に合わせて一から設計します。何をシステムにするか決まっていない段階のご相談も無料で承ります。

※ 画像は過去の開発例で、実際に開発する画面とは異なります。

実際に開発した画面の一例

画面は開発例です。項目・機能・デザインは、お店の運用に合わせて一から設計します。

使うとどう変わる?

来店・担当・ボトル情報を店の記録として残し、担当変更後も関係を引き継げます。

  1. 1顧客と担当キャストを登録
  2. 2来店・会計・ボトルを記録
  3. 3再来店候補と期限を自動表示
今の運用を無料で相談する この業務の開発内容を見る