注文追跡

概要

RHINOSHIELDの受注生産プロセスには、製造・梱包・出荷に至るまで複数の工程がありました。これらのチェックポイントは社内では有用でしたが、ユーザーからは、注文後に商品がどのような状況にあるのかをほとんど確認できませんでした。

その結果、カスタマーサービスには、注文状況や配送の進捗に関する同じような問い合わせが繰り返し寄せられていました。

そこで私はPMおよび開発チームと協力し、RHINOSHIELD初となるユーザー向けの注文追跡機能を設計しました。複雑な社内業務フローを、ユーザーにとって意味があり理解しやすい少数のステータスに整理し、ユーザー自身で注文状況を確認できる仕組みへと落とし込みました。

01—可視性の問題が、サポートの負担になっていた

2024年、RHINOSHIELDではカスタマーサービスチームの業務負担を軽減することが、重要な目標の一つとなっていました。

実際の問い合わせ内容を確認したところ、注文状況の確認と注文キャンセルが繰り返し発生していることが分かりました。

これらの情報はすでにRHINOSHIELDの社内システム上に存在していましたが、ユーザー自身が直接確認することはできませんでした。そのため、ユーザーはカスタマーサービスに問い合わせる必要がありました。

当時のフローは以下のようになっていました。

1. ユーザーが注文状況を問い合わせる

2. カスタマーサービスが社内システムを確認する

3. カスタマーサービスが現在の状況を説明する

4. ユーザーは回答を待つ

「注文は今どこにあるの？」といった繰り返し発生する問い合わせに対して、ユーザーとカスタマーサービスの双方に不要な負担が生じていました。

02—デザイン上の課題

最も分かりやすい解決策は、注文状況をユーザーが直接確認できるようにすることでした。しかし、本当に難しかったのは、**「どのステータスを、ユーザーにとってどのような意味として見せるべきか」**を決めることでした。

RHINOSHIELDのフルフィルメントプロセスには、製造、印刷、梱包、出荷、配送など、多くの社内チェックポイントが存在していました。これらのステータスは社内の業務管理には必要でしたが、そのまますべてをユーザーに見せてしまうと、社内プロセスの複雑さをそのままユーザーに押し付けることになります。

そこで、デザイン上の課題を次のように設定しました。

• ユーザーに社内のフルフィルメントプロセスを理解させることなく、自分の注文状況を把握するために必要十分な情報を、どのように提供できるか？

03—異なるフルフィルメントの状況に対応できる、共通のトラッキング体験

大きく3つの制約がありました：

1. 社内プロセスの複雑さ

   • RHINOSHIELDのフルフィルメントプロセスには、商品タイプ、印刷工程、梱包方法、配送ルートなどによって異なる、多数のチェックポイントが存在していました。

   • すべての注文が、まったく同じプロセスをたどるわけではありませんでした。

2. 配送の不確実性

   • 海外配送では、配送先や配送業者によって所要時間が大きく異なり、数日から場合によっては数週間の差が生じることもありました。

   • そのため、システム上保証できない配送予定をユーザーに期待させることなく、現在の進捗を分かりやすく伝える必要がありました。

3. モバイルファーストでの利用

   • RHINOSHIELDでは多くのユーザーがモバイル端末からアクセスしていたため、限られた画面幅でも注文状況を直感的に理解できるトラッキング体験が必要でした。

04—体験をシンプルにする前に、まずシステムを理解する必要があった

最初に取り組んだのは、プログレスバーのデザインではありませんでした。まず、注文がRHINOSHIELDのフルフィルメントプロセスをどのような経路で進む可能性があるのかをすべて理解することから始めました。

PMや開発チームと連携しながら、想定される注文パターンを整理し、異なるシステムや配送条件の中で発生し得るチェックポイントを洗い出しました。

最初に作成したマッピングには、ユーザーが実際に必要とする以上の細かな情報が含まれていました。しかし、何を削り、何を残すべきかを判断するためには、まずその複雑さをすべて理解する必要がありました。

05—顧客のメンタルモデルを捉える

社内プロセスを整理した後、次に考えたのはこの問いでした。

「どの変化が、顧客にとって本当に重要なのか？」

すべての業務ステータスをそのまま表示するのではなく、顧客が知りたいことを基準に、関連する工程をより大きなステージにまとめました。

その結果、多くのフルフィルメントパターンに対応できる、6つの顧客向けステータスに整理しました。内部では実際の処理内容が異なる場合でも、顧客には一貫した形で注文の進捗を伝えられるようにしました。

既存のシステムをそのまま顧客に見せる必要はありません。顧客が本当に必要としている粒度に「翻訳」することが重要でした。

06—正確な日付でなくても、役立つ目安は提示できる

海外配送では、配送先、配送業者、通関、その他の物流状況によって配送期間が変動します。そのため、「この日に必ず届く」という正確な到着日を提示することは困難でした。

一方で、到着予定をまったく表示しなければ、そもそも配送状況に関する問い合わせが発生していた「いつ届くのかわからない」という不安は解消されません。

そこで、到着予定を特定の日付ではなく、期間（レンジ）として提示しました。

• 到着予定：5月10日〜13日

一定の幅を持たせることで、通常発生する配送期間の変動に対応しながら、顧客にも「いつ頃届くのか」という実用的な目安を伝えられるようにしました。

07—注文追跡体験の設計

注文追跡の体験は、顧客が最も知りたい3つの問いを軸に設計しました：

1. 注文は今どこにあるのか？

   • 現在のステータスがひと目で分かるようにする

2. これまでに何が完了したのか？

   • 完了したステータスを表示し、これまでの進捗が分かるようにする

3. 次に何が起こるのか？

   • 今後のステータスを表示することで、複雑な社内プロセスを理解しなくても、次の流れを把握できるようにする

08—セルフサービスを会員だけに限定しない

RHINOSHIELDでは、アカウントを作成せずに購入することも可能でした。

もし注文追跡をログイン済みの会員だけに提供すると、ゲスト購入した顧客は、同じ情報を確認するためにカスタマーサービスへ問い合わせる必要があります。

そこで、注文番号やメールアドレスなどの情報を使って注文を検索できる、別の確認方法も用意しました。

これにより、会員・ゲスト購入者のどちらも、自分で注文状況を確認できるようになりました。

09—ステータスを「行動」につなげる

このプロジェクト以前は、注文後に間違いに気づいた場合、キャンセルや変更のためにカスタマーサービスへ問い合わせる必要がありました。特に多かったのが、色を間違えて選択した商品の変更依頼です。そのため、同じような問い合わせ対応が繰り返し発生していました。

注文処理のステータスを整理したことで、そのステータスを「顧客がまだ注文に対して操作できるかどうか」の判断にも活用できるようになりました。

注文がまだ「注文受付（Order Created）」の段階であれば、カスタマーサービスに問い合わせることなく、顧客自身で注文をキャンセルできるようにしました。

＊製造開始後は、すでにフルフィルメント工程に入っているため、セルフキャンセルはできません。

10—成果

このプロジェクトでは、RHINOSHIELDで初となる顧客向けの注文追跡機能を導入しました。これまでカスタマーサービスへの問い合わせが必要だった注文情報を、顧客自身で確認できるセルフサービス型の体験へと変えました。

複雑な社内のフルフィルメント情報を、顧客にとって分かりやすいシンプルな構造へと整理することで、社内の業務プロセスを理解しなくても、自分の注文状況を把握できる体験を実現しました。