カスタマーサービス
住所変更の依頼と該当する注文を確認する。必要な顧客確認を終えた後に訂正を申請できる。荷物を転送済みとして扱うことはできない。
発送担当
発送待ちの注文と受け付けられた住所変更を確認する。合意した規則の範囲で発送を準備し、変更に失敗した場合に対応できる。
業務管理者
未解決の依頼と待機時間を確認する。例外の対応者を割り当てられる。この役割に全注文の編集権限が必要とは限らない。
顧客から注文の変更を頼まれたら、スタッフは注文を探し、適切に変更し、反映されたか確認する必要があります。管理システムの検討は、このような実際の仕事を依頼から結果までたどることから始めましょう。

顧客から、注文した品の配送先住所を変えたいと電話がありました。同僚は注文を探し、依頼を確認し、住所を変更して、結果を顧客に伝えます。一つの仕事に見えますが、終えるまでにいくつのツールが必要でしょうか。
社内の管理システムを検討するときは、こうした仕事から始めます。担当者が何を見る必要があり、何を変更でき、変更が成功したとどう確かめるかを決めましょう。ダッシュボードの一覧を作るより、要件がずっと明確になります。
修理した機器を顧客へ返送する架空の修理工房を考えてみます。顧客から別の住所へ送ってほしいと頼まれました。工房は修理注文を一つのシステムで管理し、配送は別のサービスで手配しています。
この例では、修理注文システムがその注文で承認された返送先住所を保持します。配送サービスは発送予約を保持し、まだ変更できるかを確認します。顧客の連絡先全体を更新するかどうかは、別に判断します。
それぞれの情報がどこに属するかを書き出しましょう。二つの画面で住所が違う場合、スタッフはどちらの記録を信頼し、誰が食い違いを解決するのでしょうか。同じ画面に両方を表示するだけでは、その答えは出ません。
Microsoftのモデル駆動型アプリの構築ガイドでは、データ、業務プロセス、アプリ画面、セキュリティロールを別々の要素として扱っています。Power Appsについての説明ですが、画面を決めることは、業務を定義する作業の一部だとわかります。
作業画面を描く前に、役割、仕事、許可される操作を整理します。架空の工房なら、例えば次のように分担できます。
住所変更の依頼と該当する注文を確認する。必要な顧客確認を終えた後に訂正を申請できる。荷物を転送済みとして扱うことはできない。
発送待ちの注文と受け付けられた住所変更を確認する。合意した規則の範囲で発送を準備し、変更に失敗した場合に対応できる。
未解決の依頼と待機時間を確認する。例外の対応者を割り当てられる。この役割に全注文の編集権限が必要とは限らない。
これは提案上の役割分担であり、そのまま使える権限規則ではありません。変更に承認が必要だったり、特定の顧客記録へのアクセスを制限したりする場合もあります。画面上の操作と変更を受け付けるシステムの両方で、その規則を守る必要があります。
管理者の概要画面と担当者の作業キューは、目的が違っても同じアプリに置けます。次に行う仕事に合わせて表示を決めましょう。
依頼を見つける。住所変更の依頼を、担当が明確なキューに入れます。対象の修理注文、受け付けた時刻、すでに対応中の人がいるかを表示します。顧客履歴の中に埋もれたメモでは、未処理のまま残りかねません。
まだ変更できることを確認する。注文に登録された現在の返送先住所と、発送の最新の既知の状況を示します。情報の取得元と確認時刻も明らかにします。配送情報を取得できない、または古くて頼れない場合、変更を約束する前に担当者がわかるようにします。
許可された変更を行う。工房が求める顧客確認と必要な承認を経たら、権限のある担当者が新しい住所への変更を申請できます。この操作が修理注文を更新するのか、既存の発送の変更を依頼するのか、あるいは二つの別の手順なのかを設計で明示します。
使いやすい管理画面は、担当者に必要な仕事を示し、仕事に必要な情報と権限を与え、変更が実際に反映されたかを示します。
適切な確認を待つ。修理注文に住所が保存されても、配送サービスが変更を受け付けたことにはなりません。二つの結果を別々に表示します。返答待ちの依頼は保留のままにし、スタッフが顧客へ状況を説明できる情報を示します。
役立つ履歴を残す。誰が訂正を依頼・承認したか、変更前後の値、配送サービスの返答など、記録する事柄を指定します。誰が履歴を見られ、どう確認するかも決めます。「履歴」タブがあるだけでは、何が記録されているかわかりません。
例外の行き先を決める。荷物がすでに発送された、配送サービスが変更を拒否した、接続に失敗したなどの場合は、未解決の依頼を指定された担当者やチームに渡します。曖昧な返答を受けて同じ操作を繰り返さないよう、再試行前に確認すべきことを示します。
システムによって、注文の状態や住所の意味が異なることがあります。Microsoftのシステム間の意味を変換するための設計ガイドは、この問題と変換を維持する手間を説明しています。一つの技術的なパターンを紹介するもので、どの管理システムにも必要な部品というわけではありません。
工房で問うべきことは単純です。それぞれのシステムで「変更済み」は正確には何を意味するのでしょうか。接続が完成したと考える前に、項目、状態の意味、確認方法、失敗時の扱いを取り決めます。一つの画面でも、複数のシステムがそれぞれの役割を果たす必要があります。
対象にする仕事ごとに、役割、最初に入るキュー、情報の取得元、許可される操作、確認方法、履歴、例外の担当者を記録します。通常の流れに加え、発送先をもう変更できない場合のような難しい例も含めます。
私たちは業務向けのカスタムソフトウェアを開発しています。スタッフが終えるべき仕事の流れと、今つまずいている箇所をお持ちください。その仕事をもとに、考えられる案件の範囲と条件を話し合えます。
いいえ。既存のシステムの情報や操作を一つにまとめることもできます。各情報の確定記録をどのシステムが持ち、各操作をどのシステムが確認するかを決めましょう。共通の画面を作るだけでは、その判断は終わりません。
役割ごとに、仕事に必要な情報と操作を与えます。管理者には未完了の仕事の概要が必要でも、カスタマーサービスには個別の依頼が必要です。同じ画面を使っても、すべての権限を共有する必要はありません。
依頼を見える状態に保ち、明確な状況と次の対応を担う人やチームを示します。わかっていること、まだ確認が必要なこと、再度操作してよいかを説明します。担当システムが確認する前に、依頼された変更を完了済みと表示しないでください。
前回のニュースレター:すでにお持ちのサブスク型サイトやアプリで、もっと収益を上げる方法。
その前の回:本物の成功事例から AI のたわ言を見抜く方法。
気になりますか?
毎週 もしくはお知らせいただければ、ご希望に合わせて調整します。いかがですか?