アフィリエイト成果の承認フローを作る方法

01 / DIRECT ANSWER

成果承認は、注文を『支払う報酬』へ変える判断

承認フローは、不正を疑うためではなく、ストアと紹介者が同じ基準で報酬を確認するための仕組みです。状態ごとの意味と確認タイミングを画面上で揃えます。

アフィリエイトリンクやクーポンから注文が入ると、まず成果が発生します。しかし決済が完了していない、対象外商品が含まれる、返品・取消の可能性がある、自己購入や重複帰属を確認したい場合があるため、その瞬間に報酬を確定しません。一定期間を保留とし、ストアが条件を確認した後に承認することで、確定報酬と支払い対象へ進めます。

承認が遅れると紹介者は報酬を受け取れず、早すぎると返金後の回収や相殺が発生します。最適な日数は商品と返品ポリシーで異なります。自動承認を使えば放置を防げますが、すべてを即時承認する機能ではありません。設定した確認期間が過ぎ、問題がない成果を、定めた締め日にまとめて承認する仕組みとして設計します。

ストアが毎回一件ずつ押す必要もありません。アフィリエイター別、期間別、状態別に絞り、選択・全選択・一括承認できると、月次作業を短縮できます。ただし一括操作ほど、対象件数、合計売上、報酬、支払いへの影響、取消できる範囲を確認してから実行できる画面が必要です。

02 / STATUS DESIGN

発生・保留・承認・支払い済みを分ける

状態名を分けることは、会計上の見栄えではなく紹介者との約束です。『発生』は紹介経由の注文候補、『保留』は決済・返金・帰属を確認する期間、『承認済み』はストアが支払い対象として確定した報酬、『支払い準備』は最低支払額・締め日・原資等を満たした状態、『支払い済み』は実際の振込処理と明細が完了した状態です。

管理画面とポータルで同じ用語を使います。管理者には内部理由が必要でも、紹介者には『確認中』『確定』『次回へ繰越』『振込予定』『振込済み』など、自分の次の状態が分かる表現を追加します。『承認済み』を『もう銀行へ着金した』と誤解させないよう、確定報酬と支払済みを別に表示します。

03 / APPROVAL CRITERIA

承認前に確認する八項目

承認基準は担当者の記憶に置かず、注文ごとのチェックと自動判定へ分けます。決済済み、返金なし、対象商品、計測期間内、帰属ルール一致など機械的に確認できる項目は自動化し、不自然な注文、例外クーポン、法人・高額注文などは人が見ます。すべての注文を詳細に開くのではなく、問題のないものと確認が必要なものを分けます。

1. 01

   1. 支払い済み注文か

   未払い、失敗、テスト、下書き注文を成果確定へ含めないよう、Shopifyの注文・決済状態を確認します。

2. 02

   2. 対象商品か

   除外商品、ギフトカード、税、送料、定期初回・継続など、プログラムの対象を確認します。

3. 03

   3. 割引後小計が正しいか

   クーポン・セール・部分返金後の対象額へ、正しい率・固定額が適用されているか見ます。

4. 04

   4. 帰属ルールに合うか

   リンク、クーポン、複数紹介、キャンペーン、計測期間の優先ルールで一人へ帰属しているか確認します。

5. 05

   5. 返品・取消がないか

   返品可能期間とShopifyの返金状態を確認し、全部・一部返金を報酬へ反映します。

6. 06

   6. 自己購入・関係者購入の扱い

   許可・禁止・手動確認のどれかを規約化し、メール一致だけで誤判定しないようにします。

7. 07

   7. 不自然な注文でないか

   短時間の大量注文、高い返品率、クーポン転載など兆候を確認し、証拠なく不正と断定せず保留します。

8. 08

   8. 支払い先と条件が整っているか

   承認と送金は別ですが、最低支払額、口座登録、方式、手数料の状態を確認できるようにします。

04 / AUTOMATIC APPROVAL

自動承認は、三十・四十五・六十日から選ぶ

自動承認をデフォルトでオンにすると、ストアが操作を忘れて紹介者の報酬が止まる問題を減らせます。ただし注文直後ではなく、設定した保留期間が経過し、返金・取消・確認フラグがない成果だけを対象にします。商品特性に応じて三十日、四十五日、六十日から選び、返品期間より短くしないことを基本にします。

三十日は一般的な返品確認と運用速度のバランス、四十五日は配送・使用確認が長い商品、六十日は高額・予約・検討や返品が長い商品に向きます。法定・契約上の期間を一律に代替する数字ではないため、ストアの返品ポリシーと専門家の確認を優先します。途中で期間を変える場合は、既存成果に旧・新どちらを適用するか決めます。

05 / MONTH-END BATCH

月末に集約し、一人への振込を不必要に分けない

承認ボタンを押すたびに即時送金すると、同じ月に追加成果が発生するたび振込手数料や明細が分かれる可能性があります。承認と実際の送金を分け、対象月の確認期間が終わった成果をアフィリエイター単位で月末に集約します。ストアはその人の対象注文、商品小計、報酬、返金、合計を確認して一回承認し、次の支払日に一つの明細として処理します。

即時承認が必要な特別案件は例外にし、通常は『今月分をまとめて承認する』をおすすめ表示にします。月末直前に発生した成果は保留期間が終わっていないため翌月以降へ回ります。会計上の対象月、注文月、承認月、支払月を混同せず、レポートでそれぞれ確認できるようにします。

1. 01

   注文をアフィリエイター別に集約

   同じ人の対象成果を一覧にし、件数、売上、返金、報酬合計を確認します。

2. 02

   保留期間を満たした成果だけ選ぶ

   月末だから全件を承認するのではなく、各注文の確認期限と例外フラグを守ります。

3. 03

   選択・全選択で一括承認

   対象件数と合計を確認し、除外した成果は理由と次の確認日を残します。

4. 04

   送金は支払単位でまとめる

   承認の履歴を保ちつつ、同じ人への振込と明細を一つに集約して手数料の重複を減らします。

06 / MANUAL APPROVAL

手動承認画面に必要な操作と安全策

手動承認は、判断が必要な注文を丁寧に扱える一方、件数が増えると放置されます。画面上部に未承認件数を表示し、ダッシュボードから直接移動できるようにします。注文番号、紹介者、注文日、商品小計、報酬、帰属、返金、確認期限、状態を同じ一覧で見せ、詳細を開かなくても通常成果を選べるようにします。

チェックボックスは、現在のページ、検索結果、全対象のどれを選んだかが分かる表示にします。承認前の確認ダイアログで件数、合計報酬、支払いへの影響を示し、二重送信を防ぎます。承認済みを取り消せる場合は、送金開始前だけなど安全な範囲を決め、送金IDがある成果は安易に戻しません。

1. 01

   個別選択

   返金、帰属、商品条件を確認した成果だけ選びます。行全体を押し間違えないチェックとラベルを用意します。

2. 02

   アフィリエイター選択

   一人の当月対象をまとめ、同じ月の追加成果と手数料重複を確認して承認します。

3. 03

   全選択

   検索・フィルター対象の範囲と件数を明示し、画面に見えていない行を含むかを表示します。

4. 04

   一括承認

   合計売上・報酬・件数を再表示し、承認者、時刻、条件バージョンを監査履歴へ残します。

5. 05

   除外・保留

   理由、次回確認日、紹介者へ見せる説明を分け、放置された保留をアラートします。

07 / EXCEPTIONS

返金・取消・不正疑い・誤帰属の扱い

全部返金は報酬をゼロ、部分返金は対象商品小計に応じて再計算する方法が基本です。承認前なら保留額を更新し、承認後・支払い前なら支払対象を更新します。すでに送金した後は、自動回収できるとは限らないため、次回相殺、ストア負担、個別返金のどれかを規約で決めます。紹介者へ責任がない配送事故やストア都合の取消を同じ扱いにするかも検討します。

不正疑いでは、クーポン転載、自己購入、関係者購入、短時間の大量注文、返品偏りなどを確認します。兆候だけで没収せず、成果を保留し、確認した事実と判断期限を残します。誤帰属を修正する場合、一人から消して別の人へ付ける処理を同時に行い、二重報酬と履歴消失を防ぎます。

08 / TRANSPARENCY

紹介者には、承認結果と次の支払いを同時に見せる

承認後に『承認されました』だけ通知しても、いつ受け取れるか分かりません。確定した注文件数、確定報酬、最低支払額までの残り、次回支払予定、支払い方式、手数料、口座登録の状態をポータルに表示します。承認されなかった成果は、個人情報を含まない範囲で理由と問い合わせ方法を示します。

通知はメールを補助とし、ポータルを正本にします。メールには機微な口座情報や購入者情報を載せず、安全なログイン先を案内します。自動承認期間を変更した場合、次に対象となる成果と既存成果への影響を伝えます。紹介者が自分で状態を確認できることが、承認作業の速さと同じくらい重要です。

09 / OPERATIONS

未承認を放置しないための運用設計

ダッシュボードの最上部に『承認の判断が必要な注文が何件あるか』を表示し、承認画面へ直接進めるようにします。未承認がゼロになれば通知は消え、通常の収支と月別レポートを見られます。担当者へ個別メールを送るだけでは退職・休暇で止まるため、管理画面、定期通知、代理担当、期限超過のエスカレーションを組み合わせます。

自動承認がオンでも確認は必要です。期限到来前に返金・不正・対象外のフラグが正しく付くか、定時処理が失敗していないか、承認結果が支払い対象へ反映されたかを月次で監査します。復旧ボタンは通常操作と区別し、『自動処理が失敗・保留した場合だけ再送する』など注釈を付けます。

1. 01

   毎日

   緊急の返金・取消・不正フラグだけを確認します。通常成果を毎日送金しません。

2. 02

   週次

   期限が近い保留、長期保留、担当者未設定、システムエラーを確認します。

3. 03

   月末

   対象者ごとに成果を集約し、選択・全選択・一括承認、支払対象、原資を確認します。

4. 04

   四半期

   自動承認期間、返品率、例外率、承認日数、問い合わせを見直します。

10 / IMPLEMENTATION WORKBOOK

「アフィリエイト成果の承認フローを作る方法」を自社へ落とし込む実践ワーク

ここまでの内容を読んだだけで終わらせず、自社の現在地へ置き換えます。まず、アフィリエイト成果の承認フローを作りたいという目的について、対象商品、対象者、担当者、開始日、完了条件を一枚に書いてください。完了条件は「設定画面へ入力した」ではなく、管理者とアフィリエイターが同じ条件を確認でき、テスト注文または具体的な運用例で期待どおりになった状態とします。分からない項目は空欄のまま公開せず、誰がいつ決めるかを置きます。

次に、現在使っているフォーム、表計算、メール、チャット、銀行、レポートを並べ、情報がどこで転記されているかを確認します。保留・承認・支払い対象の意味を定義する、承認の担当と頻度を決める、承認が遅れる場合の案内を用意するという三つの作業で、同じ名前・金額・状態を二回以上入力している場所があれば、誤りと担当者依存が起きやすい部分です。すぐ全自動にするのではなく、正本を一つ決め、他の場所は通知または参照へ変えます。

さらに、アフィリエイター本人のスマートフォンで同じ流れを試します。招待・応募からログインし、条件を読み、リンクや素材を受け取り、成果・報酬・支払いを確認するまでに、担当者へ質問しなければ進めない箇所を記録します。その質問はヘルプへ追加するだけでなく、疑問が生まれた画面の見出し、注釈、ボタン文言、次の行動を改善する材料にします。自己解決できる画面と、人が判断する相談を分けることが、人数が増えても関係を粗くしない運用につながります。

最後に、初月で変える項目を一つだけ選びます。条件、対象者、商品、報酬、素材、計測、承認、支払いを同時に変えると、何が結果へ影響したか分かりません。基準となる期間を保存し、一つの変更後に同じ指標を確認します。売上だけでなく、開始率、活動率、承認までの日数、未対応件数、問い合わせ、返金、紹介者の継続意向を見て、続ける・直す・やめるを一文ずつ残してください。

11 / TEAM QUESTIONS

導入・見直し会議で確認する八つの問い

会議では機能名の読み上げではなく、誰がどの状態を見て何を判断するかを確認します。次の問いへ具体的な担当、期限、画面、数字で答えられない項目は、公開後に止まりやすい場所です。すべてを一度に決める必要はありませんが、金額、権利、個人情報、支払いに関する未決定は参加者へ案内する前に解消します。

1. 01

   この施策で、誰のどの行動を変えるのか

   アフィリエイト成果の承認フローを作りたいという言葉を、対象者、商品、行動、期限が入った一文へ変えます。認知、応募、クリック、購入、再購入、店頭送客のどれを主目的にするか決め、補助目的を増やしすぎません。

   記録するもの：目的の一文、主KPI、対象期間
2. 02

   参加前に、本人が判断できる条件はそろっているか

   成果承認は売上を見てボタンを押す作業ではなく、決済・対象商品・帰属・返品・不正を確認して報酬を確定する統制という考え方を、募集ページ、規約、ポータルで同じ言葉にします。報酬、義務、対象、期限、承認、返金、支払いなど、参加の意思に関わる条件を承認後まで隠しません。

   記録するもの：公開条件、適用日、条件の正本URL
3. 03

   ストアの担当者が休んでも、次の作業が分かるか

   発生・保留・承認・支払い済みを分けるについて、担当、代理、期限、未対応アラート、完了条件を決めます。個人の受信箱や記憶だけに置かず、管理画面で現在地と履歴を確認できるようにします。

   記録するもの：担当・代理担当、確認頻度、期限超過時の対応
4. 04

   アフィリエイターは、自分の状態を自分で確認できるか

   自動承認は三十・四十五・六十日など返品期間に合わせ、期限到来時に月末単位で集約すると振込の分割を減らせるという情報が、メールを探さなくてもスマートフォンのポータルで分かるかを試します。リンク、素材、成果、報酬、予定、口座、明細など、本人に関わる状態をストアだけが持たないようにします。

   記録するもの：本人テストの画面、迷った箇所、質問
5. 05

   例外が起きたとき、誰が止めて誰が再開するか

   月末に集約し、一人への振込を不必要に分けないに関係する返金、取消、誤帰属、重複、不正疑い、口座・原資・通信の失敗を想定します。自動処理が失敗したときに二重実行せず、確認・修正・再送の担当と証跡を残します。

   記録するもの：例外一覧、停止条件、再開条件
6. 06

   費用と利益を、同じ注文で説明できるか

   商品売上、購入者割引、アフィリエイター報酬、PAREL等の利用料、決済・振込費、原価、送料、返金を分けます。率だけでなく実額の例を作り、ストアの粗利と紹介者の受取見込が同時に分かるようにします。

   記録するもの：通常注文とキャンペーン注文の試算
7. 07

   法令・規約・個人情報の責任者は決まっているか

   PR表記、商品表現、素材利用、応募情報、本人確認、口座、購入者データを誰が確認するか決めます。アプリの初期値を法的判断の代わりにせず、商材や対象地域に応じて公式情報と専門家を確認します。

   記録するもの：確認者、参照した公式資料、改定日
8. 08

   三十日後に、何を見て継続を決めるか

   手動承認ではアフィリエイター選択・全選択・一括承認・除外理由・履歴が必要という方針に沿い、最初から大人数へ広げません。開始率、活動率、クリック、承認済み成果、粗利、返金、未対応、問い合わせを同じ期間で見て、一項目だけ改善します。

   記録するもの：基準値、変更内容、次回確認日

12 / EVIDENCE & RECORDS

公開・変更・月次運用で残す記録

運用の記録は、問題が起きたときだけ作るものではありません。条件を公開した日、誰が何を承認したか、紹介者へどう表示されたか、テストで何を確認したかを残すと、問い合わせへの回答、担当者の引継ぎ、条件変更、障害対応を早くできます。個人情報や秘密情報をスクリーンショットへ無制限に残さず、必要な項目をマスクし、アクセス権と保存期間を決めます。

1. 01

   公開前の基準

   対象商品、対象者、条件、担当、保留・承認・支払い対象の意味を定義する、完了条件を保存します。画面を作った事実ではなく、テストした入力・期待結果・実結果を記録します。

   残すもの：条件バージョン、テストケース、確認者
2. 02

   参加者への表示

   承認の担当と頻度を決めるという内容が、募集ページ、承認案内、ポータル、規約で一致するか確認します。変更時は旧条件と新条件の適用日を分けます。

   残すもの：公開URL、表示文、通知日
3. 03

   実行した操作

   承認前に確認する八項目に関する登録、承認、変更、出力、送信は、操作者、日時、対象、件数、結果を残します。ボタンを押したことと外部処理の成功を同じにしません。

   残すもの：操作ID、対象件数、外部結果ID
4. 04

   金額と状態

   発生、保留、確定、支払対象、処理中、完了、返金・取消を区別し、同じ注文・成果・支払いIDで追えるようにします。合計だけでなく構成を確認できる状態にします。

   残すもの：商品小計、率、報酬、調整、手数料
5. 05

   例外と復旧

   注文が入ったらすぐ成果承認してよいですか？への回答を、個別メールだけで終わらせません。原因、影響、停止、修正、再開、本人への説明、再発防止を一つの記録にします。

   残すもの：事象、原因、対応、再確認結果
6. 06

   月次の判断

   承認が遅れる場合の案内を用意することまで確認し、継続、改善、中止を一文ずつ残します。売上だけでなく、参加者と担当者が迷った回数、未対応日数、例外率も見ます。

   残すもの：月次KPI、判断理由、翌月の一変更

13 / FINAL CHECK

このページを閉じる前の最終チェック

最後に、次の項目へ「はい」と答えられるか確認してください。一つでも未決定なら、公開を止める必要がある項目か、限定テストの中で確認できる項目かを分けます。金額・支払い・権利・個人情報に関する項目は推測で進めず、表示と運用を一致させます。

1. 01

   目的と対象を一文で説明できる

   アフィリエイト成果の承認フローを作りたいという目的が、誰、商品、行動、期間まで具体化され、関係者が同じ言葉で説明できます。

2. 02

   三つの基本作業に担当と期限がある

   保留・承認・支払い対象の意味を定義する、承認の担当と頻度を決める、承認が遅れる場合の案内を用意するについて、担当、代理、期限、完了条件、次回確認日が決まっています。

3. 03

   ストアと本人の表示が一致する

   成果承認は売上を見てボタンを押す作業ではなく、決済・対象商品・帰属・返品・不正を確認して報酬を確定する統制という重要条件が、管理画面だけでなく募集・ポータル・明細にも同じ意味で表示されます。

4. 04

   通常・例外・失敗をテストした

   通常の成功だけでなく、取消・返金・重複・期限・再読込・再送など、このテーマで起きる例外をテストしています。

5. 05

   金額の内訳を実例で確認した

   商品小計、割引、報酬、利用料、手数料、返金、受取額を同じ注文で照合し、総額だけに頼っていません。

6. 06

   本人がスマートフォンで完了できる

   アフィリエイターがメールを探し回らず、ログイン、条件確認、リンク・素材、成果・報酬、必要な手続きを完了できます。

7. 07

   個人情報を必要以上に持たない

   応募、審査、発送、本人確認、口座、購入者情報を段階ごとに分け、利用目的・権限・保存・削除を決めています。

8. 08

   外部処理の成功まで確認できる

   メール送信、Shopify課金、決済、振込などはHTTP応答やボタン押下だけでなく、相手側状態・通知・明細まで確認できます。

9. 09

   三十日後の見直し日がある

   初月の基準値、変更する一項目、見る指標、判断者、見直し日を決め、設定して終わりにしていません。

10. 10

    PARELを含む候補を実画面で比較した

    機能表だけでなく、一商品・数名・一件のテストを管理者とアフィリエイターの両方で行い、残る手作業と迷いを確認しています。

14 / WITH PAREL

PARELで、承認判断から振込準備までを一つにする

PARELでは、紹介リンク・クーポン経由の支払い済み注文を成果として受け取り、返金・取消の可能性を確認する保留状態にします。ダッシュボード上部に未承認件数を表示し、『成果・承認を開く』から対象画面へ直接移動できます。注文、紹介者、商品小計、報酬、帰属、状態を見て、個別・選択・全選択でまとめて承認できます。

自動承認は初期オンを基本とし、三十日、四十五日、六十日から確認期間を選ぶ設計です。期限を満たし問題のない成果を月末単位で集約し、同じアフィリエイターへの承認・支払いを不必要に分けないようにします。手動で判断したいストアは自動承認をオフにし、未対応アラートと一括操作を利用できます。

承認後は確定報酬と支払い対象へ進み、紹介者の共通ポータルにも金額と状態が反映されます。まずSandboxまたはFree環境で、通常購入、全部返金、部分返金、別紹介者のクーポン重複をテストし、承認前後の金額が一致するか確認してください。承認の品質はボタンの速さではなく、二重払いと説明の食い違いを起こさないことです。