LINE

紹介で来た人を、紹介者との関係で管理したい|友だち紹介だけでは追えない「誰の紹介か」を、QR・自己申告・ASP管理で残す選び分け

広告(アフィリエイトリンク)を含みます。

月末の締めの時間、予約表を見ながら「先月の新規さん、たしか田中さんのご紹介だったはず」と、記憶だけを頼りに顧客メモをさかのぼる。お礼のメッセージを送りたいのに、田中さんが誰の紹介で来たのか、いや田中さんが誰を連れてきてくれたのか、どこにも書いていない。サロンや教室、小さな事務所では、紹介で来てくださった方の「紹介元」を、受付の記憶と手書きのメモで持っていることがよくあります。

この記事は、エルメ(L Message)で「紹介者との関係」を残して管理するための選び分けを整理したものです。結論から言うと、エルメの友だち紹介の機能(紹介時アクション)だけでは、誰が誰を紹介したかは追えません。そのかわり、追えない部分を埋める方法が4つあり、紹介者の人数や特典の種類によって向き不向きがはっきり分かれます。売上を伸ばす話ではなく、お礼の漏れ・特典の渡し間違い・記憶頼みの属人化を減らす、という業務改善の話として書いています。

「紹介者が分からない」は、3つの別々の問題が混ざっている

最初に、何が分からないのかを切り分けます。同じ「紹介の管理」でも、困っている場所が違えば手当ても変わるためです。

この記事の流れ1「紹介者が分からない」は、3つの別々の問題が混ざっている2エルメの紹介時アクションが追えること、追えないこと3紹介者を残す4つの方法と、選び分けの条件4そのまま使える運用ルール案とチェックリスト5活用例(架空の設計例)6向かないケースと、確認が必要な点7私の見立て3点とまとめ
図:この記事の流れ
困りごとの形現場で起きていること先に確認すること
A. 紹介された人が、誰の紹介か分からない友だち追加はされているが、紹介元がどこにも記録されていない。来店時に口頭で聞いて、そのままになっている追加された経路が「紹介リンク」「店のQR」「検索や口コミ」のどれか。経路が違えば記録の取り方も変わる
B. 紹介した人が、何人紹介したか分からないお礼や特典の対象を、スタッフの記憶で数えている。数え漏れと数え間違いが起きる特典が「1人紹介ごと」か「2人以上」か。回数に応じて変わるなら数える仕組みが必須
C. 紹介元と紹介先が、同じ画面で結びつかない友だちリストを見ても、二人の関係が分からない。お礼を送る前に別のノートを開く関係を残す先を、友だち情報・タグ・メモ・外部の台帳のどこにするか
「紹介者が分からない」は、3つの別々の問題が混ざっている表の見出し:困りごとの形A. 紹介された人が、誰の紹介か分からないB. 紹介した人が、何人紹介したか分からないC. 紹介元と紹介先が、同じ画面で結びつかない
図:「紹介者が分からない」は、3つの別々の問題が混ざっている

A・B・Cは、同じ方法で全部は解けません。たとえばBだけなら、紹介元に付く「合図」で足ります。Cまで求めると、記録を人の手で足す作業か、プロプランの機能のどちらかが必要になります。次の節で、公式マニュアルで確認できた範囲の「追えること/追えないこと」を先に整理します。

エルメの紹介時アクションが追えること、追えないこと

公式マニュアル(友だち紹介キャンペーン、QRコードアクションのページ。2026-10-10に確認)によると、紹介時アクションは次のような流れです。紹介コードを友だちに1:1チャットや配信で送ると、その友だちごとの個別URLに変換され、そこから紹介リンクを取得して共有できます。紹介が成立すると、紹介元にはテンプレート送信やタグ付けなどのアクションを、紹介先には登録時のメッセージやアクションを届けられます。

やりたいこと紹介時アクションで補足
紹介が成立したことを、紹介元に知らせるできる(公式に記載あり)紹介元に届くメッセージやアクションを設定できる
紹介が成立した紹介元に、目印のタグを付けるできる(アクションにタグ付けが挙げられている)タグは「誰かを紹介した人」の目印になる。人数は数えられない
紹介先に、登録時のメッセージを送るできるあいさつメッセージと併用すると二重に届く場合がある
どの紹介元が誰を紹介したかを確認するできない(公式に明記)紐付けにはASP管理(プロプラン限定)が必要と案内されている
紹介リンクを経由しない追加を、紹介として扱う公式に記載なし口頭の紹介で、検索やお店のQRから追加された人は、仕組み上は別経路として扱われると考えられる(筆者の読み)

この表のうち、見落とされやすいのは2行目です。「誰を紹介したか」は追えなくても、「紹介を成立させた人」には、紹介元側に付くタグで印を付けられます。つまり、Bの「お礼を送る対象の漏れ」は、紹介時アクションだけで半分は防げます。残りの半分、つまり「誰を」の部分をどう残すかが、このあと選ぶ方法の分かれ目になります。

紹介者を残す4つの方法と、選び分けの条件

ここで挙げる4つは、いずれも公式マニュアルで機能の存在を確認できるものを組み合わせた案です。どれが優れているかではなく、紹介者の人数・特典の種類・プランで向き不向きが決まります。

方法紹介者を特定できる範囲向く規模・条件プランの目安(公式の記載)
① 紹介者ごとにQRコードアクションを作るそのQRから追加された人が、どの紹介者のQRか分かる紹介者が少人数で、QRや名刺カードを手渡しできるフリープランはQRコードアクション3つまで(料金表)。有料プランの上限は料金表で確認
② 紹介先に紹介者名を聞いて、友だち情報とタグに記録する紹介先が名乗った紹介者を、スタッフが記録する。自己申告なので確認が要る人数が多くても回る。手間はスタッフ側に残る友だち情報管理・タグ管理は料金表で件数上限の記載なし
③ 紹介時アクションの「紹介元タグ」と、②の自己申告を突き合わせる紹介が成立した人と、名乗られた人を照合して整合を取る特典の渡し間違いを減らしたい。月次で確認できる体制紹介時アクション自体の対象プランは公式で確認できず
④ ASP管理で、紹介者をアフィリエイターとして登録する紹介者(アフィリエイター)ごとの友だち登録数・成果、成約者名などを画面で確認紹介者が多い、成約ごとの承認や報酬管理まで必要プロプラン(月額33,000円・税込、料金表。2026-10-10確認)

方法①:紹介者ごとのQRコードアクションにタグを付ける

手順は、QRコードアクションを新規作成し、稼働対象を選び、読み込み時アクションにタグ設定を入れる、という流れです。稼働対象は「新規友だちのみ」と「全ての友だち」から選べ、作成後は変更できません。紹介の記録なら、初めて追加した人だけを対象にする「新規友だちのみ」が基本になります。タグ名は「紹介元_【呼び名】」のように、人の名前ではなく呼び名で付けると、あとで友だちリストを共有しても困りません。

つまずきは3点あります。第一に、QRコードのURLは友だちごとに変わりません。つまり、紹介者が受け取ったQRを別の人にも回せば、そのすべてが同じタグになります。「紹介者本人が直接勧めた人」ではなく「そのQRから来た人」という意味です。第二に、フリープランは3つまでなので、紹介者が4人目になった時点で詰まります。第三に、QRコードアクションは手動では削除できず、削除から90日後に自動消去される仕様です。紹介者ごとに作り足す前に、フォルダを分けて管理名を揃えておくと、後から数が増えても迷いません。

方法②:紹介先に聞いて、友だち情報とタグに記録する

紹介リンクやQRに関係なく、最初のメッセージで「ご紹介の方がいらしたら、お名前を教えてください」と一言添え、返ってきた名前をスタッフが記録します。1:1チャットの画面から友だち情報の欄に入力できると公式に書かれているため、友だち情報(記述型)に「紹介者の呼び名」、タグに「紹介あり_要確認」のように残す形です。確認が済んだら1:1チャットの対応ステータスを「完了」にして、未確認の人が残らないようにします。

この方法の弱点は、自己申告であることです。名乗られた名前が、別の常連さんと同姓だったり、旧姓や屋号だったりすると、取り違えが起きます。取り違えを減らすには、紹介者側の友だち情報にも「呼び名」を入れておき、照合するときは呼び名で探す運用にします。

方法③:紹介元に付く目印と、自己申告を月に一度突き合わせる

紹介時アクションで紹介元にタグを付けておき、方法②の記録と月に一度照合します。たとえば、紹介元タグの付いた人が3人、自己申告で「田中さんの紹介」と名乗った人が4人なら、1人は紹介リンクを経由せず口頭で来た人か、記録の取り違いです。差が出た月は、その差を一件ずつ1:1チャットで確認します。この突き合わせは機能ではなく運用なので、手順を台帳に書いておかないと、担当が変わったときに止まります。

方法④:ASP管理は、紹介者が増えてから

公式マニュアルによると、ASP管理はアフィリエイトセンターを運営する機能で、紹介者にURLから登録してもらい、友だち登録や購入・予約・フォーム回答などを成約条件にして報酬を管理できます。成約状況では、成約日時、アフィリエイター名、成約者名、報酬額、ステータスなどを確認でき、CSV出力もできます。成約の承認を自動にするか手動にするかも選べます。紹介者ごとの友だち登録数や成果報酬件数は一覧で見られるため、「誰が何人」を画面で確認したい場合は、実質的にこの機能が本命です。

ただし、小さなお店の「お友だちに紹介してもらう」使い方には、機能が大きすぎる面があります。紹介者に登録してもらう手間、成約の承認の手間、月額33,000円(税込)のプロプランという条件が重なるためです。また、公式ページから、報酬の実際の振込までエルメが代行するかは読み取れませんでした。お金の受け渡しは別に設計する前提で考えます。仕組みの詳細は、エルメのASP管理(アフィリエイトセンター)とは?できること・使えるプラン・始める前の確認点で整理しています。

どれを選ぶか:判断の基準

状況選ぶ方法理由
紹介者が3人以内で、紹介カードを手渡しできる① + ②の補助QRごとに分かれるので数えやすい。口頭で来た人は②で拾う
紹介者が多く、紹介コードをLINEで送って広めてもらいたい③(紹介時アクション+②)紹介元に印が付き、紹介先の自己申告と照合できる。プランの追加が要らない構成にしやすい
特典が金銭に近く、成約ごとに承認して記録を残したい④承認の流れと成約者名の一覧が画面で残る。プロプランが前提
紹介者がLINEの友だちではない(取引先、家族など)②のみ、または紙の台帳紹介元タグが付けられない。口頭で聞いて記録する運用になる
紹介者が名前を出されたくない様子がある紹介の記録自体を最小限にする「誰の紹介か」を聞くこと自体が負担になる人もいる。聞く前に、記録の用途を伝える

紹介時アクションそのものの設計や、始める前に決めておく特典・期間・重複の扱いは、エルメの友だち紹介キャンペーンの仕組みと、始める前に決めておくことに整理しています。この記事は、その先の「記録をどこに残すか」だけに絞っています。

そのまま使える運用ルール案とチェックリスト

機能を決めても、記録は人が続けないと崩れます。次のルールは、スタッフが1〜3人の事業を想定した案です。自分の事業に合わせて書き換えてください。

記録するのは5項目だけにする

項目置き場所入れ方の例
紹介者の呼び名友だち情報(記述)姓+さん、または常連名簿の通称。LINE名は変えられるので使わない
紹介の経路タグ紹介経路_QR/紹介経路_リンク/紹介経路_口頭
紹介元の成立印タグ(紹介時アクションで付与)紹介成立_済み。外す日と担当を決める
確認状況1:1チャットの対応ステータス未対応=名前未確認、対応中=照合待ち、完了=記録済み
特典の渡し済み友だち情報(年月日)またはメモ特典名と渡した日。2回目の請求を防ぐ

月次の突き合わせチェックリスト

  • 紹介元タグの人数と、自己申告の件数を並べた(差が出た月だけ個別確認)
  • 紹介者の呼び名が重なっている人がいないか見た(同じ呼び名があれば識別の一語を足す)
  • 「未対応」のまま残っている紹介先がいないか、1:1チャットの一覧で確認した
  • 特典を渡した日の記録が、渡した件数と合っている
  • 期限の切れた紹介経路のタグを外し、外した日をメモに残した
  • 紹介者の名前を、紹介先に知らせるメッセージを送っていない
月次の突き合わせチェックリスト紹介元タグの人数と、自己申告の件数を並べた(差が出た月だけ個別確認)紹介者の呼び名が重なっている人がいないか見た(同じ呼び名があれば識別の一語を足す)「未対応」のまま残っている紹介先がいないか、1:1チャットの一覧で確認した特典を渡した日の記録が、渡した件数と合っている期限の切れた紹介経路のタグを外し、外した日をメモに残した紹介者の名前を、紹介先に知らせるメッセージを送っていない
図:月次の突き合わせチェックリスト

最後の項目は、地味ですが大事です。紹介先に「○○さんのご紹介ですね」と自動で名前を入れる文面にすると、紹介者の来店を本人の了承なく伝えてしまうことがあります。記録は内部で持ち、外には出さない、という線を最初に決めておきます。

活用例(架空の設計例)

以下は実在の事例ではなく、考え方を示すための架空の設計例です。成果の数字は載せません。

想定は、スタッフ2人の小さなネイルサロン。常連のうち、よく紹介してくださる方が4〜5人いて、特典は「次回の施術で使える割引券」です。物の発送がなく、金銭の支払いも発生しないため、③の構成で組みます。

  • QRコードアクションを1つ作り、紹介時アクションを設定。紹介元に「紹介成立_済み」のタグと、お礼のテンプレートを自動で送る
  • 紹介先の最初のメッセージに「ご紹介の方がいらしたら、お名前(呼び名)をお知らせください」と一文を添える
  • 返信を受けたスタッフは、友だち情報に呼び名を入れ、タグ「紹介経路_口頭」または「紹介経路_リンク」を付け、対応ステータスを「完了」にする
  • 毎月第1営業日に、紹介成立の人数と自己申告の件数を比べ、差があれば1:1チャットで確認する
  • 割引券を渡したら、友だち情報の日付欄に渡した日を入れ、同じ人に二度渡さない

この設計の狙いは、紹介元が数人のうちは機能を増やさず、「誰に特典を渡すか」の判断を記憶から台帳へ移すことです。紹介者が十数人に増えたり、特典が割引から金銭に変わったりしたら、④のASP管理を検討する、と決めておきます。

向かないケースと、確認が必要な点

LINEの記録が向かないケース

  • 紹介者と紹介先が家族や職場の同僚で、一方が相手に知られたくない場合。紹介者の名前を聞くこと自体が負担になるため、記録を取らず、特典を一律の条件にするほうが関係を壊しません
  • 紹介の見返りが現金や金券に近く、金額が大きい場合。税務や取引上の扱いは事業ごとに違うため、専門家に確認するのが先です。この記事では判断しません
  • 紹介者が高齢で、LINEより電話や対面でのやりとりが中心の場合。無理にLINEに寄せず、受付で聞いて紙の台帳に書くほうが確実です
  • 紹介者の個人情報を、複数のスタッフが共有する運用が難しい場合。友だち情報を見られる範囲を、先に各自の方針で決めてください

公式で確認できなかった点

次の点は、確認したマニュアルのページに記載が見当たりませんでした。契約前に公式の最新情報で確認してください。

  • 友だち紹介(紹介時アクション)が、どの料金プランで使えるか
  • 紹介時アクションの中で、紹介元にポイントを加算するアクションを選べるか(友だち情報のポイント機能自体は公式に記載あり)
  • 紹介先の最初のメッセージに対する返信を、自動で友だち情報へ記録できるか。この記事では、スタッフが手で入力する前提にしています
  • ASP管理の報酬の実際の振込を、エルメが代行するか
私の見立て3点とまとめ1紹介の管理は、「誰に特典を渡すか」を決める仕組みと、「誰が誰を紹介したか」を残す仕組みを分けて考えると楽になります2紹介者が3人以内のうちは、機能を増やすより、聞き方と記録場所を決めるほうが効きます3「誰の紹介か」を聞くこと自体が、紹介者と紹介先の関係に触れます
図:私の見立て3点とまとめ

私の見立て3点とまとめ

  • 紹介の管理は、「誰に特典を渡すか」を決める仕組みと、「誰が誰を紹介したか」を残す仕組みを分けて考えると楽になります。前者は紹介時アクションの紹介元タグ、後者は自己申告かASP管理です
  • 紹介者が3人以内のうちは、機能を増やすより、聞き方と記録場所を決めるほうが効きます。QRを紹介者ごとに作るのも一案ですが、フリープランの3つという上限に早く当たります
  • 「誰の紹介か」を聞くこと自体が、紹介者と紹介先の関係に触れます。記録は内部だけで持ち、外に出さない、という一線を最初に決めておく運用のほうが長続きすると感じます

まとめると、エルメの紹介時アクションは、紹介が成立した紹介元に印を付けるところまでが得意で、「誰を」の部分は別の方法で補う必要があります。紹介者の数と特典の種類で、①QR、②自己申告、③照合、④ASP管理の順に重くなる、と考えると選びやすくなります。まずは無料プランで、自分のアカウントに紹介元と紹介先の役でテスト登録して、タグが付く流れと二重送信の有無を一周確かめてください。

構築代行のご案内(30万円〜・税別)

紹介の記録設計、タグやフォームの組み立て、テスト登録まで自分で進める時間が取りにくい場合は、構築代行のご案内(30万円〜・税別)もご用意しています。