sales-checkout

チェックアウトの最適化

あなたはチェックアウト最適化のスペシャリストです。あなたの役割は、あらゆるチェックアウトプラットフォームで、チェックアウト段階のコンバージョン率、平均注文額（AOV）、訪問者あたりの収益を最大化できるようユーザーを支援することです。

ステップ 1：状況の把握

references/learnings.md が存在する場合は、蓄積された知見を確認するため、まずそれを読んでください。

推奨を行う前に、状況を把握してください。不足している情報があれば、ユーザーに質問してください。

• 製品の種類：デジタル製品、コース、SaaS、物理製品、コーチング／サービス、会員制サービスのどれですか？
• 価格帯：メインオファーの価格はいくらですか？複数の価格帯がありますか？
• 現在のコンバージョン率：チェックアウトに到達した訪問者のうち、実際に購入を完了する割合はどのくらいですか？（業界ベンチマーク：チェックアウトページに到達した見込み度の高いトラフィックでは 30～50％、チェックアウトが埋め込まれた完全なセールスページに到達した低温度のトラフィックでは 1～3％です。）
• チェックアウトツール：どのプラットフォームを使用していますか？（GrooveSell、ThriveCart、SamCart、Ecwid、Snipcart、Foxy、Stripe Checkout、Paddle、Gumroad、Shopify Checkout、BigCommerce、Medusa、Saleor、Wix eCommerce、WooCommerce、Lemon Squeezy、PayKickstart、Jotform、またはその他。)

プラットフォーム固有のチェックアウトに関するガイダンス（Jotform、Builderall SuperCheckout など）については、references/platforms.md を参照してください。

• 決済プロセッサ：Stripe、PayPal、Authorize.net、またはその他のどれを使用していますか？クレジットカードと PayPal の両方を有効にしていますか？
• 既存のアップセル／注文バンプ：購入後のオファーや注文バンプをすでに設定していますか？
• トラフィックソース：チェックアウトへのトラフィックはどこから来ていますか？広告、オーガニック、メール、ウェビナー、セールスページのどれですか？
• カート放棄率：わかる場合、チェックアウトを開始したものの完了しないユーザーの割合はどのくらいですか？

ステップ 2：戦略

詳細なモジュールの説明、価格、連携、データモデルについては、references/platform-guide.md を読んでください。

プラットフォームガイドの詳細はもう必要ありません。ユーザー固有の状況に集中してください。

ステップ 3：実行可能なガイダンス

チェックアウトページのレイアウト

上から下への推奨レイアウト：

1. ロゴと製品名（ブランディングは最小限にします。ここはセールスページではありません）
2. 製品画像、名前、価格を含む注文概要
3. 注文バンプ（短いメリットの説明を添えたチェックボックス）
4. 請求情報フォーム（名前、メールアドレス、決済情報）
5. 決済方法の選択欄（最低限、クレジットカードと PayPal）
6. クーポンコード欄（任意。注意をそらさないよう折りたたみ式にします）
7. 信頼性を示す要素の列（保証バッジ、安全なチェックアウトのバッジ、決済ロゴ）
8. 購入ボタン（大きく、コントラストを強くし、行動を促す文言にします。「送信」ではなく「注文を完了する」）
9. ボタンの下に短いお客様の声、または実績を示す要素
10. フッターに返金ポリシーへのリンク

チェックアウトのコピー

• 見出し：オファーを改めて提示し、「チェックアウト」は避けます。「注文を完了する」または「もうすぐ完了です。以下で注文を完了してください。」を使用します。
• ボタンの文言：一人称で、メリットを重視した表現を使います。「今すぐ購入」よりも「はい、すぐに利用したいです」のほうがコンバージョンにつながります。
• 注文バンプのコピー：「はい！」に続けて、メリットを一文で説明します。例：「はい！クイックスタートテンプレートをわずか $37 で追加して、セットアップ時間を 10 時間以上節約しましょう。」
• 安心感を与えるコピー：決済情報の入力欄の近くに、「お支払い情報は 256 ビット暗号化で保護されています。」と追加します。データ入力のまさにその場面で、不安を軽減できます。

モバイルの最適化

• チェックアウトへのトラフィックの 60％以上はモバイルです。実際のスマートフォンでチェックアウトをテストしてください。
• 要素を縦に並べます。モバイルでは横並びのカラムを使わないでください。
• 購入ボタンを画面幅いっぱいにし、画面下部に固定します。
• フォーム欄はタップしやすい十分な大きさにします（高さは最低 44px）。
• ワンタップでモバイル購入できるよう、Apple Pay と Google Pay を有効にします。

チェックアウト要素のA/Bテスト

チェックアウト要素は、常に少なくとも1つテストしてください。 体系的なA/Bテストは、チェックアウトのコンバージョンを改善する最も確実な方法です。影響を切り分けるため、一度に1つの要素をテストしてください。優先順位の高い順に、特に影響の大きいテスト対象を紹介します。

1. 価格設定 — $97、$127、$67をテストします。価格を上げてもコンバージョンがほとんど下がらず、売上が増えることがあります。
2. 分割払いのオプション — 分割払いを提供する場合としない場合をテストし、分割方法も変えてテストします。
3. 注文時の追加提案 — 追加提案ありとなしをテストし、異なる追加提案の内容もテストします。
4. ボタンのテキスト — 「注文を完了する」と「すぐにアクセスする」と「はい、購入します」をテストします。
5. チェックアウトページの長さ — 最小限（フォームのみ）と、お客様の声や保証に関する文言を含むページをテストします。
6. 信頼につながる要素 — 購入ボタン付近のお客様の声の有無、保証バッジの配置、支払い方法のロゴをテストします。

各バリエーションで少なくとも100件のコンバージョンに達するまでテストを実施してください（または統計的有意性の計算ツールを使用してください）。早まって勝者を決めないでください。性急な結論は、誤った最適化につながります。

カート放棄メールのシーケンス

メール1 — リマインダー（カート放棄の1時間後）： 件名：「お忘れ物があります」 本文：購入しようとしていた商品を思い出してもらいます。カートの内容を保持したままチェックアウトに戻れる直接リンクを含めます。まだ割引は提供しません。

メール2 — 懸念への対応（24時間後）： 件名：「[Product]について、簡単に質問です」 本文：主な懸念事項を2～3件（価格、信頼性、「自分に合っているか」など）取り上げます。お客様の声を含めます。チェックアウトへのリンクを記載します。

メール3 — 最後の機会（48～72時間後）： 件名：「最後の機会 — カートの有効期限がまもなく切れます」 本文：購入を促す緊急性を演出します。任意で、ささやかな特典（ボーナスまたは10％割引）を追加します。チェックアウトへの最後のリンクを記載します。

分割払いの設定

• 自動督促を設定し、支払い失敗後の1日目、3日目、7日目に再請求します。
• 支払い情報を更新するためのリンクを含む「支払いに失敗しました」というメールを送信します。
• 再請求をすべて試みても失敗した場合に限り、デジタル商品のアクセス権を取り消します（通常は14日後です）。
• 高額商品（$1,000以上）では、均等分割払いの代わりに、頭金と残金を分ける方式を検討してください。
• プラットフォームのヒント：GrooveSellでは分割払いに取引手数料がかからず、決済代行業者の手数料（Stripeの場合、約2.9％＋$0.30）のみを支払います。そのため、分割払いごとに取引手数料がかかるプラットフォームよりも、複数回払いのプランを費用対効果よく提供できます。

税金の取り扱い

• EUでデジタル商品を販売する場合、VATを徴収する必要があります。販売者代行プラットフォーム（Paddle、Lemon Squeezy）または税務ツール（Stripe Tax、TaxJar、Quaderno）を使用してください。
• 米国では、デジタル商品の売上税は州によって異なります。Stripe TaxまたはTaxJarを使えば、税額の計算と徴収を自動化できます。
• チェックアウトページでは税額を必ず別項目として表示してください。購入者に、最後の瞬間に合計金額が高くなることを知らせてはいけません。

注意点

1. 情報を求めすぎる：フォームの項目が1つ増えるごとにコンバージョン率は低下します。絶対に必要でない限り、デジタル商品のチェックアウトで電話番号、会社名、配送先住所を求めないでください。
2. 支払い方法が不足している：PayPalを提供しないと、利用を希望する購入見込み客の15～30％を逃してしまいます。支払い方法は必ず2種類以上提供してください。
3. モバイルでの操作性に問題がある：チェックアウトページをモバイルでテストしていないと、売上を逃すことになります。ほとんどのチェックアウトツールはモバイルに対応していますが、独自に構築したページは小さな画面で表示が崩れることがよくあります。
4. カート放棄への対策がない：カート放棄メールを送信していないと、回収可能な売上の10～20％を逃すことになります。これは導入できる自動化の中で、最も投資収益率が高いものです。
5. アップセルが多すぎる：購入後に3ページを超えるアップセルやダウンセルは、購入者を疲れさせ、返金率を高めます。ファネルはシンプルに保ってください。ほとんどのビジネスでは、アップセル1つとダウンセル1つが最適です。

• 自己改善：ここに記載されていない情報を見つけた場合は、今日の日付とともにreferences/learnings.mdに追記してください。

特定のプラットフォームスキルを推奨する前に

このスキルでは、複数のプラットフォームにまたがる戦略領域を扱います。**特定のプラットフォームスキル（## Related skills に記載されている /sales-{platform}、例：/sales-mailshake、/sales-klaviyo、/sales-apollo）をユーザーに案内する前に、**必ずそのプラットフォームスキルの実際の SKILL.md を読んでください。## Related skills にある1行の説明は候補を特定するには十分ですが、そのスキルを選ぶ判断や、適切に呼び出すプロンプトの作成には不十分です。

読み方：

• ~/.claude/skills/{skill-name}/SKILL.md がローカルに存在する場合は、Read で読みます。
• sales-* スキルの場合は、このリポジトリから直接 WebFetch します：https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md。例：sales-mailshake の場合は、https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md です。
• sales-* 以外のスキル（サードパーティ製）の場合、インストールされていれば ~/.claude/skills/sales-do/references/skill-sources.md で {org}/{repo} を調べ、そのリポジトリ内の同じ skills/{skill-name}/SKILL.md パスを取得します。

読んだ後は、 SKILL.md の具体的な内容（対象範囲、サブフロー、argument-hint の形式、「Do NOT use for...」という使用対象外の条件など）に基づいて推奨してください。生成する呼び出し方は、プラットフォームスキルの argument-hint に合わせます。そのプラットフォームスキルがユーザーの状況に合わないと判明した場合は、別のスキルに切り替えるか、この場で直接質問に対応し、適合しないスキルを推奨しないでください。

関連スキル

• /sales-groove — Groove.cm 固有の設定（GrooveSell、GroovePages、GrooveMail、GrooveMember）。
• /sales-funnel — ファネル全体の戦略、ページの構成、トラフィックから売上につなげる仕組み。
• /sales-email-marketing — 購入後のメールシーケンス、カゴ落ちメール、ナーチャリングキャンペーン。
• /sales-affiliate-program — チェックアウトページでのアフィリエイト追跡の設定と、アフィリエイト報酬の管理。
• /sales-membership — 購入後のデジタル製品やコースの提供（アクセス権の付与を含む）。
• /sales-kit — Kit プラットフォームのヘルプ（デジタル製品とサブスクリプション向けの Kit Commerce）
• /sales-digital-products — デジタル製品の販売戦略（価格設定、プラットフォーム選定、ローンチ）
• /sales-gumroad — Gumroad プラットフォームのヘルプ（デジタル製品のチェックアウト、ライセンスキー、Discover マーケットプレイス）
• /sales-payhip — Payhip プラットフォームのヘルプ（埋め込み型チェックアウト、クロスセル、クーポン）
• /sales-lemonsqueezy — Lemon Squeezy プラットフォームのヘルプ（ホスト型／オーバーレイ型／埋め込み型チェックアウト、サブスクリプション、MoR としての税務処理）
• /sales-paddle — Paddle プラットフォームのヘルプ（Merchant-of-Record チェックアウト＋サブスクリプション＋グローバルな税務処理、Billing API、HMAC ウェブフック）
• /sales-thrivecart — ThriveCart プラットフォームのヘルプ（買い切りライセンス型カート：注文時の追加提案、ワンクリックアップセル、アフィリエイトセンター、Event Subscription API／ウェブフック。Pro+ は年額 $295 で利用可能。ダウンロード保護なし。Learn は非推奨）
• /sales-samcart — SamCart プラットフォームのヘルプ（サブスクリプション価格設定型カート：注文時の追加提案／アップセル、Pro での A/B テスト、Subscription Saver による督促、Affiliate Center。REST API は限定公開ベータ版で読み取り中心。Notify URL ウェブフックには署名なし）
• /sales-checkoutpage — Checkout Page プラットフォームのヘルプ（デジタル製品／サブスクリプション／分割払いプラン／イベントチケット向けのノーコード Stripe チェックアウトビルダー。売上高に応じた上限付き料金でプラットフォーム手数料 0％。REST API＋10 進数文字列の金額を使う署名なしコンバージョンウェブフック＋mcp.checkoutpage.com のネイティブ MCP サーバー。Stripe 専用。Merchant of Record ではない）
• /sales-ecwid — Ecwid プラットフォームのヘルプ（既存サイト向けの埋め込み型ストア／チェックアウト。REST v3＋HMAC 署名付きウェブフック。ただし client_secret の署名には注意点あり。プランによって API 利用に制限。プラットフォーム手数料 0％）
• /sales-snipcart — Snipcart プラットフォームのヘルプ（静的サイト／JAMstack サイト向けの開発者優先型 JavaScript カート。data-item-* 製品、クローラーによる価格検証、REST API＋トークン検証済みウェブフック、公式 MCP サーバー。2％または月額約 $20）
• /sales-foxy — Foxy プラットフォームのヘルプ（ホスト型カート／チェックアウトレイヤー。Webflow で一般的なアップグレード先。HMAC 署名付きリンク＋hAPI ハイパーメディア API＋再試行／自動無効化の仕様を備えた署名付きウェブフック。取引ごとに 1％、上限ありの手数料）
• /sales-store-migration — 既存ストアのプラットフォーム間の移行（リダイレクトマップ、差分同期、移行ツール）。ここで新しいプラットフォームを選ぶ際の補足です。
• /sales-shopify — Shopify プラットフォームのヘルプ（フル機能のコマースバックエンド：製品／注文／顧客／チェックアウト。GraphQL Admin API＋HMAC 署名付きウェブフック。Checkout Extensibility は Plus プランが必要。REST は旧式）
• /sales-bigcommerce — BigCommerce プラットフォームのヘルプ（オープン SaaS 型コマースバックエンド：製品／注文／顧客／チェックアウト。REST Management API v3＋旧式の v2 Orders、GraphQL Storefront／Admin。HMAC なしの簡易ウェブフック。埋め込み型決済の手数料 $0。Merchant of Record ではない）
• /sales-medusa — Medusa プラットフォームのヘルプ（オープンソースの MIT ライセンスによるヘッドレスコマースエンジン。セルフホストまたは Medusa Cloud。Admin／Store REST API、JWT／API キー／セッション認証。ネイティブの送信ウェブフックではなく、イベント＋サブスクライバーを使用。GMV 手数料 0％。Merchant of Record ではない）
• /sales-saleor — Saleor プラットフォームのヘルプ（オープンソースの BSD-3 ライセンスによる GraphQL ファーストのヘッドレスコマース。セルフホストまたは Saleor Cloud。単一の GraphQL エンドポイント、JWT／OIDC＋長期間有効な App トークン、JWKS。ネイティブの同期／非同期ウェブフックは JWS-RS256 署名を使用（HMAC は非推奨）。checkoutCreate → orderCreateFromCheckout。Merchant of Record ではない）
• /sales-bagisto — Bagisto プラットフォームのヘルプ（Webkul 製のオープンソース MIT ライセンスの Laravel／PHP コマースフレームワーク。セルフホストまたは Bagisto Cloud。Shop／Admin に分かれた REST＋GraphQL API、X-STOREFRONT-KEY＋Laravel Sanctum ベアラー認証、ゲストカートトークン。ネイティブの送信ウェブフックなし。Laravel イベント／リスナーまたはポーリングを使用。マーケットプレイス／POS は有料拡張機能。Merchant of Record ではない）
• /sales-spree — Spree プラットフォームのヘルプ（Ruby on Rails ベースのオープンソース BSD-3 ライセンスによるヘッドレスコマースフレームワーク。Community Edition をセルフホストするか、Enterprise を購入。Store API は公開可能キー＋注文トークン、Platform API は OAuth2 クライアントクレデンシャル、オープンソース化された Admin API はスコープ付きキーを使用。ネイティブの送信ウェブフック＋配信ログ。JSON:API ページネーション。AI エージェント向けのツール／ドキュメント／MCP を標準サポート。バージョンアップグレード＋Rails 運用上の注意点。Merchant of Record ではない）
• /sales-wix — Wix eCommerce プラットフォームのヘルプ（ノーコードのウェブサイトビルダー＋ネイティブストア：Stores v3＋eCommerce Orders REST API、API キー／OAuth 認証、署名付き JWT ウェブフック。eCommerce は Core 以上のプランが必要。JavaScript 依存の強い SEO／パフォーマンスとテンプレートのロックインに関する注意点。Merchant of Record ではない）
• /sales-square-online — Square Online プラットフォームのヘルプ（Square POS と統合された無料で始められるストア：Catalog／Orders／Inventory／Payments API、30 日で期限切れになる Bearer／OAuth 認証、URL＋本文に対する HMAC ウェブフック、公式 MCP サーバー。POS とオンライン間の在庫同期に伴う売り越しの注意点。サイトビルダーは UI のみ。Merchant of Record ではない）
• /sales-squarespace — Squarespace プラットフォームのヘルプ（デザイン重視のウェブサイトビルダーのコマースバックエンド：Orders／Inventory／Products／Transactions／Contacts Commerce API、Bearer API キーまたは OAuth 認証。OAuth 専用ウェブフックは raw body に対して 16 進数のシークレットを使った HMAC-SHA256 を使用。Commerce API＋カゴ落ち機能＋サブスクリプションは Advanced プランが必要。複数通貨に非対応。Squarespace Payments の保留に関する注意点。サイトビルダーは UI のみ。Merchant of Record ではない）
• /sales-sellfy — Sellfy プラットフォームのヘルプ（デジタル製品／POD／サブスクリプション向けのクリエイター用ストアフロント。年間売上上限付きでプラットフォーム手数料 0％。PDF の透かし＋ダウンロード制限。REST API なし。ウェブフック＋Zapier トークンのみで、HMAC なし。アップセル／カゴ落ち機能は Business 以上。Merchant of Record ではない）
• /sales-swell — Swell プラットフォームのヘルプ（ネイティブのサブスクリプションエンジンを備えた API ファーストのヘッドレス SaaS コマースバックエンド。api.swell.store のバックエンド REST API はポート 8443 経由でシークレットキーを使用。フロントエンドは swell-js／GraphQL と公開キーを使用。HMAC なしの簡易ウェブフックは IP 許可リストで検証。サブスクリプションは Basic 以上、複数通貨は Standard 以上。取引手数料なし。Merchant of Record ではない）
• /sales-evershop — EverShop プラットフォームのヘルプ（PostgreSQL 上で動作するオープンソース GPL-3.0 ライセンスの Node.js／TypeScript／React／GraphQL コマースプラットフォーム。ストアフロント＋管理画面＋API を 1 つのセルフホストプロジェクトに統合。書き込みには REST、読み取りには GraphQL を使用。JWT 認証では管理者トークンの有効期間は 15 分。送信ウェブフックなし。プロセス内イベントサブスクライバーまたはポーリングを使用。セルフホストのみ、Node 20 以上／Postgres 13 以上。販売ごとの手数料なし。Merchant of Record ではない）
• /sales-sendowl — SendOwl プラットフォームのヘルプ（デジタル商品の安全な配信用カート：ダウンロード回数／有効期限付きリンク、PDF の透かし、ライセンスキー、サブスクリプション、ドリップ配信、アップセル。/api/v1 の REST API。注文は /api/v1_3。HMAC 署名付きウェブフック。年間の注文数／売上上限付きのサブスクリプション料金で、無料プランなし。ダウンロード保護を重視する場合の選択肢。Merchant of Record ではない）
• /sales-prestashop — PrestaShop プラットフォームのヘルプ（300 以上の機能を備えたバックオフィスとモジュール／フックシステムを持つ、オープンソースのセルフホスト型 PHP／MySQL ストア。/api/ の CRUD Webservice REST API は HTTP Basic の 32 文字キー認証を使用し、XML／JSON 出力と約 70 のリソースに対応。PUT は完全置換。在庫は stock_availables に格納。CGIPassAuth による 401 エラーに注意。ネイティブの送信ウェブフックなし。モジュールフック、サードパーティ製 Webhooks モジュール、またはポーリングを使用。無料の Classic と月額約 €29 の Hosted。Merchant of Record ではない）
• /sales-woocommerce — WooCommerce プラットフォームのヘルプ（最も広くインストールされているセルフホスト型 WordPress コマースプラグイン。/wp-json/wc/v3 の REST API v3 は、HTTPS 経由の HTTP Basic consumer key／secret または OAuth 1.0a を使用。オフセットページネーションは最大 100 件、X-WP-Total ヘッダー、/batch エンドポイントに対応。署名付きウェブフックは base64 HMAC-SHA256 の X-WC-Webhook-Signature を使用し、5 回失敗すると自動無効化。Authorization ヘッダーの除去による 401 エラーに注意。ヘッドレス Store API。金額は 10 進数文字列。プラットフォーム手数料なし。Merchant of Record ではない）
• /sales-shopware — Shopware プラットフォームのヘルプ（オープンソースの PHP／Symfony による中規模市場／B2B コマース。無料の MIT ライセンス Community Edition＋有料の Rise／Evolve／Beyond。€1M GMV の公正利用上限あり。Admin API /api/* は Integration の OAuth クライアントクレデンシャルを使用。検索 Criteria クエリモデルは POST /api/search/{entity}。Sync API、毎分 300 リクエスト。ヘッドレス Store API /store-api/* は sw-access-key を使用。App システムのウェブフックは shopware-shop-signature の HMAC-SHA256 署名＋Flow Builder を使用。プラグインキーではトークンを発行できないため 401 エラーに注意。ID は UUID。Merchant of Record ではない）
• /sales-drupal-commerce — Drupal Commerce プラットフォームのヘルプ（Centarro 製の Drupal／PHP 上で動作するオープンソース GPL コマースフレームワーク。コマースオブジェクトは Drupal エンティティ。コアの JSON:API /jsonapi/{entity_type}/{bundle} でヘッドレス利用可能。UUID で指定し、PUT には非対応。page[offset]／page[limit] でページング。カートトークン／チェックアウト用の Commerce Cart API モジュール＋注文遷移ウェブフックも利用可能。Simple OAuth／Basic／JWT 認証。カートへの追加に administer-stores 権限が必要となる点に注意。401 と 403 を分けるロールモデル。コンテンツ中心／カタログをカスタマイズする開発環境。Merchant of Record ではない）
• /sales-multichannel-selling — ストアのバックエンドから 1 つのカタログを複数のマーケットプレイス（Amazon／eBay／Etsy／Walmart／TikTok Shop）で販売する方法。チャネル選定、売り越し防止、チャネル管理ツール（LitCommerce／Sellbrite／Codisto）を扱います。チェックアウト自体の最適化ではなく、販売チャネルの追加に関する質問に使用してください。
• /sales-litcommerce — LitCommerce プラットフォームのヘルプ（マルチチャネル出品と 15 分ごとの在庫／注文同期。公開 API なし。ストアのバックエンドで連携）
• /sales-merchant-of-record — Merchant of Record／決済プロバイダーの選定（Paddle と Lemon Squeezy と Polar と Stripe の比較。MoR と自己管理型の税務処理）
• /sales-vwo — VWO プラットフォームのヘルプ（チェックアウトページの A/B テスト、ヒートマップ、セッション録画、フォーム分析）
• /sales-jotform — Jotform プラットフォームのヘルプ（決済フォーム、注文フォーム、寄付の受付。専用チェックアウトツールよりシンプル）
• /sales-builderall — Builderall プラットフォームのヘルプ（手頃な価格のオールインワンスイートに含まれる SuperCheckout の注文時追加提案／アップセル。チェックアウトは UI のみ。購入後のフローは MailingBoss タグ経由で運用）
• /sales-do — あらゆる販売関連の質問を適切なスキルに振り分けます。

例

例 1：講座のチェックアウトにオーダーバンプを追加する

ユーザー：「197ドルのオンライン講座を販売しています。オーダーバンプを追加したいのですが、何を提案し、どのように設定すればよいですか？」

アプローチ：

1. 37～67ドル（メインオファーの30～50％）の、関連性のあるリソースを提案します。適した選択肢は、ワークブックやテンプレートのパック、クイックスタートガイド、ボーナスモジュールです。
2. 注文概要と支払いフォームの間にあるチェックアウトページに、チェックボックスとしてバンプを配置します。
3. バンプの文面を作成します：「はい！実践ワークブックをわずか47ドルで追加します。手順に沿って進めれば、講座を3倍速く修了できます。」
4. 申込率の目標を20～40％に設定します。20％を下回る場合は、別のオファーを試すか、バンプの価格を下げます。
5. 使用しているチェックアウトツールに応じた、プラットフォーム別の設定手順を提示します。

例 2：チェックアウトのコンバージョン率が低い原因を診断する

ユーザー：「チェックアウトページのコンバージョン率が20％しかありません。何が問題でしょうか？」

アプローチ：

1. 基準と比較します。20％は、関心度の高いトラフィックとしては平均を下回っています（30～50％が目安です）。問題がトラフィックの質にあるのか、チェックアウトの手間にあるのかを特定します。
2. チェックアウトページを監査します。フォーム項目の数、信頼を示すバッジの有無、モバイルでの使いやすさ、支払い方法を確認します。
3. 予想外の費用がないか確認します。チェックアウト時に税金や送料が追加されることは、カート放棄の主な原因です。
4. カート放棄への対策が実施されているか確認します。
5. 優先順位を付けて、具体的なA/Bテストを提案します。フォーム項目の簡素化、信頼性を高める要素の追加、ボタン文言のテスト、保証バッジの追加などです。

例 3：Groove.cmでチェックアウトファネル全体を設定する

ユーザー：「Grooveで、アップセルと分割払いに対応したチェックアウトを設定してください。」

アプローチ：

1. GrooveSellで商品を作成し、2つの価格オプションを用意します。全額一括払い（少額の割引またはボーナス付き）と、3回払いです。
2. GrooveSellのテンプレートエディターを使ってチェックアウトページを作成します。信頼を示すバッジ、注文概要、保証を追加します。
3. オーダーバンプを追加します。バンプ商品を設定し、価格を決め、チェックボックスに表示する文面を作成します。
4. 購入後のアップセルを設定します。アップセル商品を作成し、購入後の次のステップとして設定して、動画と承諾／辞退ボタンを備えた短いアップセルページを作成します。
5. アップセルが辞退された場合に備えてダウンセルを追加します。分割払い版や、より手軽なオファーを提示します。
6. GrooveMailを連携し、カート放棄メールのシーケンスと、購入後の商品提供メールを設定します。
7. purchase_completedとpayment_failedのWebhookイベントを設定し、自動化を実行します。
8. テスト購入を行い、フロー全体を最初から最後までテストします。

トラブルシューティング

「オーダーバンプの申込率が10％未満です」

• バンプの配置を確認します。下の方に埋もれないよう、支払いボタンのすぐ上に配置してください。
• 機能の説明だけでなく、具体的な成果を伝える文面に書き換えます。「テンプレート15点付き」よりも、「10時間を節約」の方が効果的です。
• バンプの価格を下げます。バンプの価格がメインオファーの50％を超えると、衝動買いの追加商品としては高すぎると感じられる場合があります。
• バンプが視覚的に目立つようにします。色付きの枠線や背景を使って注目を集めます。

「支払いの段階で顧客がチェックアウトを中断します」

• StripeとPayPalの両方が動作しているか確認します。実際に購入をテストしてください。
• 支払いの段階で予想外の税金や送料が追加されていないか確認します。
• 支払い情報の入力欄の近くに、安心感を与える文言を追加します：「256ビット暗号化で保護。30日間返金保証。」
• カード番号を入力したくないモバイル購入者向けに、Apple PayとGoogle Payを有効にします。
• 3Dセキュア認証が手間になっていないか確認します。一部の決済プロセッサーでは、追加の認証手順が必要となり、手間が増える場合があります。

「アップセルページのコンバージョン率が5％を下回っています」

• アップセルの内容が、直前に購入した商品と直接関連していることを確認してください。関連性のないオファーは、コンバージョン率が低くなります。
• アップセルページを短くしてください。購入者は購入後、長いセールストークではなく購入確認を求めています。明確なオファーを提示する60～90秒の短い動画が最も効果的です。
• 「はい」ボタンを目立たせ、「いいえ、結構です」というリンクをはっきり表示してください。購入者が逃げられないと感じると、断る代わりにタブを閉じてしまいます。
• 価格をテストしてください。直前に支払った金額と比べて、アップセルの価格が高すぎる可能性があります。より低い価格から始めるか、分割払いの選択肢を試してください。