Improvement Customer accounts

バンドル商品と構成品が
「顧客アカウントの下書き注文ステータスページ」に表示されるように

下書き注文(Draft order)の中身が、バンドルとその構成品(components)の両方で、より明確かつ一貫して表示されるようになった改善。顧客アカウントでの購入体験が見やすくなる。

このページの構成
  1. 何が変わったのか(30秒で理解)
  2. 前提となる3つの言葉
  3. 表示イメージ : 従来 vs 改善後
  4. 比較表
  5. 対象範囲とこの記事で「記載なし」の点
  6. 技術者が押さえるべき5つのポイント
  7. 業務に活かせる3つのユースケース
  8. 提案で使える1行サマリ

1何が変わったのか

顧客アカウント(Customer Accounts)の下書き注文ステータスページで、バンドル商品の見え方が改善された。
これまでより、バンドルそのものその構成品(components)が、明確かつ一貫して表示されるようになり、顧客にとって注文内容が分かりやすくなる。

従来の課題感

下書き注文ステータスページ上でのバンドル商品の表現が、必ずしも明確・一貫していなかった(=中身が伝わりづらい余地があった)。

改善後

バンドルとその構成品が、より明確かつ一貫して表示。顧客は下書き注文の中身を正しく把握でき、顧客アカウントでの購入体験が向上する。

2前提となる3つの言葉

下書き注文

マーチャント側で作成し、顧客に確認・支払いを促せる注文。見積りや手動作成の注文などで使われる注文の「下書き」状態。

バンドルと構成品

複数の商品(構成品=components)をひとまとめにして1つの商品として販売する形態が「バンドル」。親(バンドル)と子(構成品)の関係を持つ。

顧客アカウント

顧客がログインして注文や情報を確認できる領域(Customer Accounts)。今回の改善はその中の「下書き注文ステータスページ」が対象。

今回の変更点は「下書き注文ステータスページ上でのバンドル表現」の改善に限定された話。顧客アカウントのカスタマイズ全般については、原文がヘルプセンターを案内している。

3表示イメージ : 従来 vs 改善後

従来 : 構成が伝わりにくい 下書き注文ステータス ギフトセット ×1 └ 構成品の表現が不明瞭… └ 何が入っているか分かりづらい 中身が見えにくく問い合わせの元に 改善後 : 親+構成品を明示 下書き注文ステータス ギフトセット ×1 └ 構成品A(中身が見える) └ 構成品B(中身が見える) 明確・一貫 = 購入体験が向上
上の図は「親+構成品が明確に並ぶ」という改善内容を表したイメージ。実際の正確な画面レイアウト・文言は原文に記載なしのため、表示位置や見せ方は管理画面・顧客アカウントで確認すること。

4比較表

項目従来改善後
表示対象ページ 顧客アカウント内の「下書き注文ステータスページ」
バンドルの見え方 不明瞭 明確・一貫とは限らない 明確 バンドル+構成品を一貫表示
構成品(components) 伝わりにくい 表示される
顧客の購入体験 注文内容を把握しづらい余地 向上 内容が把握しやすい
変更の種類 Improvement(既存機能の改善)

5対象範囲とこの記事で「記載なし」の点

原文で明示されていること

・対象は顧客アカウントの下書き注文ステータスページ
・バンドルと構成品が明確/一貫して表示される
・購入体験の向上が目的
・カスタマイズはヘルプセンター参照
・本機能の API 改善は Developer changelog 参照

?

記載なし(要確認)

・対応プラン/対応国
・有効化のための設定作業の要否
・正確な画面レイアウト・文言
・API の具体的な仕様(→ Developer changelog)
・新しい顧客アカウント以外(レガシー)での挙動

原文は「API 改善が利用可能」とだけ述べ、詳細は Developer changelog に委ねている。API 連携を伴う実装を検討する場合は開発者向けチェンジログを必ず参照すること。

6技術者が押さえるべき5つのポイント

Acct

1. 対象は顧客アカウント側の表示

マーチャント管理画面ではなく、顧客がログインして見る Customer Accounts 内の「下書き注文ステータスページ」での表示改善。影響範囲は顧客が見る画面に限定して捉える。

2. 親子構造(バンドル↔構成品)が保持

バンドル本体と構成品の両方が表示され、両者の関係が一貫して見えるのが要点。顧客は「何のセットに何が含まれるか」を把握できる。

3. これは Improvement

新機能ではなく既存機能の改善(タグ:Improvement / Customer accounts)。設定変更や移行作業が必要かどうかは原文に記載なし。挙動は実環境で確認する。

API

4. 併せて API 改善あり

本機能向けの API 改善が提供されているが、詳細は Developer changelog 参照と案内されるのみ。連携実装を行う場合は開発者向けチェンジログで具体仕様を確認する。

5. カスタマイズは別ドキュメント

顧客アカウントの見た目や挙動の調整可否は、原文がヘルプセンターの「顧客アカウントのカスタマイズ」を案内している。表示の細かな制御を求める場合は、まずヘルプセンターで対応範囲を確認するのが手順上の起点になる。

7業務に活かせる3つのユースケース

バンドル見積
USE CASE 1

B2B・卸売の見積りを「下書き注文」で送るときの内訳明示

課題
バンドルで見積りを作って下書き注文として顧客に送ると、これまでは中身(構成品)が伝わりにくく、確認の往復や問い合わせが発生していた。
打ち手
本改善により、下書き注文ステータスページでバンドル+構成品が明確に並ぶ。顧客が自分でログインして内訳を確認できる導線を案内する。
効果
「セットに何が含まれるか」の確認の手戻りが減り、承認・支払いまでがスムーズに。
技術メモ
対応プラン・設定要否は原文に記載なし。実際の表示は顧客アカウントで確認する。
USE CASE 2

ギフトセット・キット販売の「中身の透明性」確保

課題
複数商品を1つにまとめたギフトセットやスターターキットは、顧客が「実際に何が届くのか」を不安に感じやすい。
打ち手
下書き注文ステータスページでバンドルと構成品が一貫表示されることを活かし、確認画面で中身が明示される状態を前提に運用設計する。
効果
注文前後の認識ズレ・クレームの抑制。セット内容への納得感が上がり購入体験が向上。
技術メモ
正確な表示レイアウト・文言は原文に記載なし。見せ方の調整可否はヘルプセンターのカスタマイズ案内を確認。
サポート問合せ 問い合わせ減
USE CASE 3

サポート問い合わせの削減(セルフサービス化)

課題
「下書き注文に含まれる商品が分からない」という問い合わせがサポートに集まり、人手で内訳を説明していた。
打ち手
顧客アカウントの下書き注文ステータスページで構成品が見えることを案内し、顧客自身で確認できるセルフサービス導線に切り替える。
効果
内訳確認のための問い合わせを削減し、サポート工数を圧縮。一次回答の自動化につながる。
技術メモ
API 連携で確認導線を作り込む場合は Developer changelog の API 改善を参照。

8提案で使える1行サマリ

「顧客アカウントの下書き注文ステータスページで、バンドルとその構成品が明確・一貫に表示されるようになった改善。
セット商品の中身が顧客に伝わりやすくなり、確認の手戻りや問い合わせを減らせる。
API 改善も併せて提供(詳細は Developer changelog)。