post-purchase-upsell-flow

広告の費用は見合っているのに、1 件の注文の金額が低すぎるときに効きます。支払いの直後は、客がもう買うと決め、決済の手段も預かり済みで、提案に広告費がかからない、いちばん安い売上だという立場です。

• 客単価を上げたい「1 件あたりの売上を上げるには」「広告費は見合うが注文の金額が低い」
• 提案を足したい既存の注文の流れに、追加・組み合わせ・控えめな代わりの提案を足す
• お礼のページが空今は「ご注文ありがとうございました」だけを出している
• どちらに置くか注文の入力欄に足すか、支払いの後に出すかを決めたい

支払いの前か後か

本文は、支払いの前に入力欄へ添える提案と、支払いの後に出す提案をはっきり比べています。

既定の勧めは支払いの後です。基本の成約の率を食わないので、客単価を上げる手のうち、試しても損の無い唯一の手だからです。支払いの前の提案は後で、基本の成約の率を見張る A/B テストの下でだけ足せ、としています。

承諾の率を決める 6 つの決まり

1. 補うものを売る同じ物の 2 個目の割引より、今買った物を完成させる物（マットを買った人にストラップ）
2. 1 画面に 1 つ4 つ並べるより、はい・いいえがはっきりした 1 つの提案のほうが売れる
3. はいはワンタップカードの入れ直しがあると、承諾の率は崩れる
4. いいえは正直に断りの文を隠したり罪悪感をあおったりしない
5. 値段は払った額と比べる最初の提案は基本の注文の額以下から始める
6. 期限は本当のときだけ偽の残り時間の表示は使わない

断りの文をごまかすと、少しの承諾と引き換えに返金と、カード会社を通した支払いの取り消し（チャージバック）が増えます。取り消しは決済の口座そのものを危うくするので、承諾の率と引き換えにするな、と本文は書いています。

「この値段はこのページだけ」は、客がこのページを二度と見ないので構造的に本当です。だから信じてもらえる、という区別です。

提案は 2 段まで

最初の提案を受けた人には 2 つ目を出してよく、断った人には同じ効き目で負担の小さい代わり（1 個だけ、軽い版、分割払い）を 1 つ出します。どちらもその後はお礼のページへ進みます。

3 画面目は客を疲れさせ、「なぜ何度も買わせようとするのか」という問い合わせが出始めるので、たいていの流れは 2 回の判断で止めるよう勧めています。

画面に書くこと

本文には、見出し・本文・裏付け・値段・承諾のボタン・断りのリンク・確認の文、の 7 項目の型があります。本文は 3〜5 行で 1 つの利点だけ、裏付けは具体的な 1 行、取り消し線の参考の値段はほかで本当にその値段のときだけです。

承諾のボタンは動詞と結果に値段を添え、断りは飾らない文字のリンクにします。承諾の後は、同じ注文に足され同じカードに請求されることをはっきり伝えます。

基本の注文がほとんど入っていないとき

本文は、主な流れの成約がほぼゼロなら先にそちらを直せとしています。来る人がいない所に提案を足しても、ゼロに掛け算をするだけだという理由です。着地のページの申し込みが増えない原因を探すなら cro が向きます（本文が名指しするのは同じリポジトリの landing-page-conversion-audit）。

営業の電話で決める高額の商品

高額で、営業の会話で成約する商品は対象外です。そこでの追加の提案はページではなく、人との会話だと本文は書いています。

ワンタップは決済の側の要件で決まる

本文は、ワンタップで買える本物の提案と、誰も最後まで進まない 2 回目の注文の入力を分けるのは、画面ではなく仕組みだとしています。主な要件は次の 6 つです。

決済サービスごとの注意もあります。Stripe では、注文の時点で後から請求する用途として決済の手段を保存しておく必要があります。PayPal では、承認だけして確定していない注文に品目を足してから 1 回で確定でき、Stripe と動きが違うので両方を扱う必要があります。

測るのはこの 5 つだけ

本文は、流れを評価するときに出すのはこれだけだ、としています。提案ごとの承諾の率、前後の客単価、提案付きの注文と基本の注文の返金の率、基本の成約の率、月ごとの支払いの取り消しの率です。

返金の率は見張りの指標で、提案付きの注文の返金が目立って多いなら、提案か文面が誤解を招いています。承諾の率を伸ばすより先にそこを直せ、という決まりです。支払いの後の提案なら基本の成約の率は変わらないはずで、動いたら注文の入力の画面も何か変わっています。

試すのは 1 度に 1 つ（提案、次に値段、次に見出し）です。ふつうの規模では数ポイントの差はすぐには確かめられないので、40 件の成約で勝ちを決めるな、と書かれています。

本文の後半は公開元の製品の案内

「実装する」の節は、公開元が作るセルフホストの販売ページの仕組み Autonnel（Apache-2.0）の案内です。上の要件の表を実装していること（提案のページを順番付きで持つ、決済の手段の保存、1 つの注文へのまとめ、流れが終わるまで Shopify・WooCommerce・Picocart へ送るのを待つ、請求ごとの返金）が書かれています。

試す手順には、リポジトリの公開版を取って docker-compose.yml を読み、docker compose up で起動する命令があります。本番は Cloudflare Workers の無料の枠に置け、費用になるのは Postgres だけだ、とも書かれています。設計の決まりと要件の表は Autonnel に依存しません。

本番の前に支払いを通して試す

本文は、作る順を「Autonnel を置く → 提案のページを流れに付ける → 本物の試しの取引で確かめる」としています。本物のカードを試しのモードで使い、次に本物の少額の注文を通してから、広告の客を流します。

断りの道筋と返金まで含めた、支払いを伴う通しの試しを 1 回もしていない提案の流れは出すな、と明記されています。Autonnel を置く手順は self-hosted-funnel-launch にあります。

同梱ファイル

同梱ファイルはありません。SKILL.md の 1 枚だけで、大きさは 8,279 バイトです（2026-10-23 時点）。

支払いの前の提案はやらないほうがいいのですか

やってよいが、順番は後です。本文は、まず支払いの後の提案を作り、支払いの前の提案は、基本の成約の率を見張る A/B テストの下でだけ足すよう勧めています。

追加の提案の値段はいくらにすればいいですか

始めは、最初の提案を基本の注文の額以下にしておくのが本文の目安です。上回ってよいのは、明らかに上の段への切り替えになる提案のときだけだとしています。

ホスト型の販売サービスでもできますか

本文によると、ホスト型の販売サービスの多くはワンタップの提案を有料の上位プランの機能として売っています。ふつうのネットショップの注文の流れは、追加のアプリが無いと、そもそも対応していないことが多い、と書かれています。