画面を作る前に顧客リクエストのライフサイクルをマッピングする

画面を作る前にリクエストのマップが必要な理由

見た目の整ったリクエストフォームでも、業務プロセスが混乱することがあります。チームはフィールド、ボタン、ダッシュボードを先に決めがちですが、顧客が「送信」をクリックした後に何が起きるのか、誰も合意していなかったと気づくことがあります。

画面は個々の瞬間を示します。一方、顧客リクエストのライフサイクルは、リクエストがどこに届き、誰が確認し、何を判断し、いつ作業が始まり、何をもって完了とするのかという一連の流れを示します。このマップがなければ、それぞれの画面は意味を持っていても、画面と画面の間にある作業が不明確なままです。

ステータスが「対応中」になっているサポートフォームを考えてみましょう。これは、誰かがリクエストを読んだという意味でしょうか。担当者が決まった、顧客に連絡した、実際の作業を始めた、という意味かもしれません。スタッフが同じラベルを異なる意味で使うこともあります。顧客からは進展が見えず、マネージャーもリクエストがどこで止まっているのかわかりません。

画面から始めると、引き継ぎも見えにくくなります。リクエストがサポートから請求担当に渡り、その後アカウントマネージャーに移ることもあります。各ステップの担当者を決めていなければ、誰かが対応するだろうと全員が考えてしまいます。リクエストは顧客から催促されるまで、共有キューに残り続けます。

リクエストワークフローをマッピングすると、画面設計の前にこうした抜け漏れを見つけられます。チームは次の点を決める必要があります。

• リクエストを開始する情報は何か
• 次のアクションを担当するのは誰か
• それぞれの判断の後に、どの状態へ移れるか
• 期限はいつ始まり、いつ停止し、いつ終了するか
• リクエストが変わったとき、誰に通知するか

マップは、誤解を招くダッシュボードも防ぎます。「未完了」の件数に、新着、顧客情報待ち、別チームの作業待ちがすべて含まれていれば、その数字からわかることはほとんどありません。状態を分ければ、スタッフは共通の言葉で話せますし、顧客にもより正確な進捗を伝えられます。

マップは複雑である必要はありません。実際に人が行っている作業を、足りない情報、却下されたリクエスト、再オープンされたケースも含めて説明できれば十分です。流れが明確になれば、画面も設計しやすくなります。各ページに、情報を集める、担当者の作業を助ける、顧客に現在の状態を示す、といった明確な役割を持たせられるからです。

1つのリクエストと明確な完了条件から始める

まず、チームが最も頻繁に扱うリクエストを選びます。返金依頼、配送中の破損報告、アカウント情報の変更依頼などが考えられます。1つの図にあらゆる顧客ニーズを詰め込もうとしないでください。広すぎるマップはすぐに曖昧になります。

開始イベントを平易な言葉で書きます。たとえば、「顧客がサポートフォームから注文の返金を申請する」です。これでライフサイクルの開始点が決まります。また、後から起こりがちな議論も避けられます。リクエストは顧客が送信した時点で始まるのか、サポートが読んだ時点か、誰かがチケットを作成した時点か、という議論です。

次に、顧客側とチーム側の両方から完了条件を定義します。完了した返金依頼とは、顧客が明確な判断を受け、承認された場合は決済チームが返金を実行した状態です。サポートチームには、判断、理由、金額、日付の記録も必要です。「完了」と表示する画面より、こうした情報のほうが重要です。

完了条件と画面を混同しないようにします。「緑色の成功メッセージを表示する」は画面の説明です。「顧客が返金額と入金予定日を記載した確認通知を受け取る」は、実行すべき作業の説明です。再設計で画面が変わっても、Webポータル、モバイルアプリ、メールのどれを使う場合でも、基礎となる作業は一貫していなければなりません。

設計前に、短い定義だけでも書いておくと、足りないルールが見えてきます。

• リクエストの種類: 支払い済み注文の返金
• 開始: 顧客がフォームを送信する、またはサポートに連絡する
• 終了: 顧客が承認または却下の判断を受け、チームが記録を残す
• 例外: サポートが判断前に不足している注文情報を求める

たとえば、顧客が月曜日に二重請求を報告したとします。チームが請求が重複しているか確認し、判断を伝え、返金があれば記録して初めて、リクエストは終了します。最初の返信後にチケットを閉じるだけでは、実際の作業が未完了のままです。

開始点と終了点が正確に決まれば、推測に頼らず状態、担当者、期限、通知を追加できます。AppMasterを使えば、後からこのマップをビジネスプロセスや画面に変えられます。ただし、先に作業そのものをマップで定義しておくことが大切です。

リクエストが入り得る状態を列挙する

状態は、顧客リクエストが今どこにあるかを全員に示します。小さな作業をすべて記録するのではなく、業務上意味のあるポイントに絞りましょう。スタッフがステータスを読めば、次に何をすべきかわかることが重要です。

一般的なサポートまたはサービスリクエストには、次のような状態があります。

• 新規: システムはリクエストを受け取ったが、まだ誰も確認していない
• 確認中: チームメンバーが詳細を確認し、対応方法を判断している
• 顧客待ち: 顧客からの回答、ファイル、確認が必要
• 対応中: 誰かが作業を引き受け、対応を進めている
• 承認または外部作業待ち: マネージャー、サプライヤー、決済事業者、別の関係者などに進行が依存している
• 解決済み: チームが依頼された作業を完了した
• クローズ: 顧客が結果を受け入れた、または決められた期間の後にチームがリクエストを閉じた

すでに人々が使っている言葉に合わせて名前を付けます。「入力待ち」より「顧客待ち」のほうが明確です。「アクティブ」より「対応中」のほうが通常はわかりやすいでしょう。ポータルに表示されたステータスを理解するために、顧客が社内用語集を読む必要があってはいけません。

待機状態には特に注意が必要です。待機状態は、チームが今日できる作業と、誰か別の人に依存する作業を分けます。返金依頼では、領収書が必要になったときに「確認中」から「顧客待ち」に移ることがあります。財務マネージャーの承認が必要なら、「承認待ち」に移します。こうした遅延には、それぞれ異なるリマインダーと期限ルールが必要です。

重複するラベルは避けます。「オープン」「割り当て済み」「対応中」が、同じような状況を指していることがあります。それぞれのラベルによって担当者、スタッフのアクション、適用される期限のいずれかが変わる場合だけ、別の状態にします。明確な状態と遷移が少数にまとまっているほど、レポートも信頼しやすくなります。

どんなリクエストにも、簡単な質問をしてみましょう。1つのリクエストが同時に2つのステータスに入ることはあるでしょうか。あるなら、名前が重複している可能性があります。それぞれのステータスが1つの明確な条件を示すまで見直します。

遷移を描き、誰が起こすのかを決める

状態名だけでは、ワークフローは説明できません。リクエストがどのように移動し、誰が移動させ、移動前に何が満たされていなければならないかを記録します。これにより、画面上のボタンが誤ったタイミングでリクエストを変更するのを防げます。

それぞれの遷移を、平易な文章で書きます。たとえば、「サポート担当者は、顧客が注文番号を記載していることを確認した後、リクエストを新規から確認中に変更する」です。この文章には、アクション、実行者、条件が含まれています。

簡単なマップには、次のような移動を含められます。

• 顧客がリクエストを送信すると、新規のリクエストが作成される
• サポート担当者が専門担当者に割り当て、確認中に変更する
• 詳細が不足している場合、専門担当者が顧客待ちに変更する
• 顧客が返信すると、確認中に戻る
• 作業が完了したら、専門担当者が解決済みにする
• 顧客またはサポートリーダーが確認後にリクエストをクローズする

すべての矢印に、実行できる担当者を記載します。「チーム」では曖昧すぎます。顧客、サポート担当者、請求担当者、チームリーダー、自動処理など、役割を明記します。システムルールが変更を起こすこともあります。たとえば、方針に合っていれば、自動処理で顧客待ちのリクエストを、返信がないまま14日経過した時点でクローズできます。

例外には、それぞれ専用の遷移が必要です。新規のリクエストは顧客がキャンセルできても、すでに完了したリクエストはキャンセルできないかもしれません。問題が再発した場合、チームリーダーがクローズ済みのリクエストを再オープンすることもあります。担当を間違えた場合に限り、担当者が確認中から新規に戻せることもあります。こうしたルールがあれば、担当者が明確になり、一部のステータス変更ができない理由も説明できます。

画面を設計する前に、ボックスと矢印で経路を描きます。2つの役割がリクエストを何度も送り返すような、終わりのないループを探します。行き止まりも確認してください。承認待ちに入ったリクエストについては、承認者を決め、承認または却下の後に何が起きるか定義します。

AppMasterでは、このマップを後からビジネスプロセスのロジックに変え、各役割によって表示するアクションを制御できます。新しいメンバーでも、送信からクローズまで1つのリクエストを追える程度に、マップを読みやすくしておきましょう。

すべての引き継ぎに担当者を設定する

作業が進行中のリクエストには、必ず1人の明確な担当者が必要です。その人がすべての作業を1人で完了する必要はありません。ただし、現在の状態を把握し、リクエストを前に進め、進捗を尋ねられたときに答える責任はあります。共有担当という状態では、誰も動かないことがよくあります。

リクエストの進行に合わせて担当者が変わることはあります。新しいリクエストはサポート担当者、調査は専門担当者、顧客への最終回答はアカウントマネージャーが担当するかもしれません。スタッフが誰が対応すべきか推測しなくて済むよう、担当者の変更をマップに記載します。

リクエストの担当者と、確認者や承認者は分けて考えます。財務リーダーが返金を承認しても、リクエストの担当者はサポート担当者のままにできます。サポート担当者が承認を依頼し、回答を追跡し、顧客に結果を伝えます。承認ボタンをクリックしただけの財務リーダーが、すべてのフォローアップを引き継ぐ必要はありません。

引き継ぎごとに、現在の担当者とチーム、担当者が変わるきっかけ、次の遷移までに必要な作業、担当者が不在の場合に引き継ぐ人を記録します。

遅延が起きる前に、不在時の対応を決めておきます。チームキュー、名前付きのバックアップ担当者、一定期間後にリクエストを再割り当てするルールなどを使えます。専門担当者が休暇中でも、対応できない担当者のもとにリクエストを残すのではなく、別の人が自分のキューで確認できるようにします。

アプリケーション上で担当者を見えるようにします。プライベートチャットやメールのやり取りは作業を支えるものですが、ワークフローそのものを定義するものではありません。各リクエストの記録には、現在の担当者、直前の引き継ぎ、割り当て時刻、再割り当ての理由を表示します。マネージャーは長時間待っているリクエストを見つけられ、顧客対応スタッフもメッセージを探し回らずに状況を伝えられます。

たとえば、顧客が請求エラーを報告した場合、サポート担当者は財務部門の確認が必要だと判断するまでリクエストを担当します。その後、財務アナリストが調査を担当します。財務部門が判断を記録したら、顧客への回答とクローズのために担当をサポートへ戻します。これで、2人が異なる回答を送ったり、お互いに相手が返信すると思い込んだりすることを防げます。

アプリでワークフローを作るときは、状態遷移そのものに担当者の変更を含めます。AppMasterなら、ステータス変更、割り当てルール、監査記録を1つのビジネスプロセスに結び付けられます。チームが大きくなっても、担当者を明確に保ちやすくなります。

作業に合った期限を設定する

リクエストには、2つの期限が必要になることがよくあります。応答期限は、サポート担当者がリクエストを確認し、追加情報が必要かどうかを伝えるなど、最初の意味のある返信までの期限です。完了期限は、チームがリクエストを解決する、または合意した結果を届けるまでの期限です。

この2つの日付を分けると、顧客にはすぐ確認連絡が届くのに、その後何日もリクエストが放置されるという問題を避けられます。アクセス申請なら、4営業時間以内に返信し、2営業日以内に完了すると決めることがあります。複雑な請求に関する異議申し立てでは、1営業日以内に返信し、完了にはより長い目標期間を設定するかもしれません。

それぞれの時計がいつ始まるのかを正確に書きます。多くのチームは、システムがリクエストを受け取った時点で応答期限を開始します。完了期限は同時に始まる場合もあれば、作業に必要な情報が揃った時点で始まる場合もあります。ルールを1つ選び、一貫して適用します。

停止条件も同じように明確にします。顧客の返信、承認された第三者、予定されたメンテナンス時間を待っている間は、時計を止めることがあります。不足情報が届いたとき、または障害が解消したときに再開します。担当者が忙しい、または不在という理由で期限を止めないでください。担当者またはマネージャーが作業を再割り当てします。

期限が近づく前にエスカレーションを設定します。許容時間の75%が経過した時点で担当者にリマインダーを送れば、対応する時間を確保できます。90%の時点では、マネージャーまたは次の責任チームに通知します。期限を過ぎたら、リクエストを期限超過として記録し、次のアクションを示します。

シンプルな方針なら、次のようになります。

• 応答期限は、顧客がリクエストを送信した時点で始まる
• チームが具体的な質問をし、リクエストが顧客待ちになったら、完了期限を停止する
• 顧客が返信すると時計が再開し、リクエストは現在の担当者に戻る
• 期限が近づくと担当者にリマインダーを送り、その後マネージャーにエスカレーションする
• 期限を過ぎたリクエストについては、マネージャーが回復計画を割り当て、顧客に最新情報を伝える

全員がそのスケジュールを受け入れている場合に限り、営業時間を使います。週7日のサポートを約束しているチームが、毎晩ひそかに時計を止めてはいけません。サポートが月曜日から金曜日までなら、ワークフロールールに営業時間、休日、タイムゾーンを定義します。明確なルールがあれば、顧客とスタッフにとって期限通知が公平になります。

通知を計画し、ノイズを増やさない

通知が答えるべき実務上の問いは1つです。今、誰かが知る必要があるか、何かをする必要があるか。どちらでもないなら、更新情報はリクエスト記録の中にとどめます。通知の多い受信トレイでは、顧客もスタッフも重要なメッセージまで無視するようになります。

顧客に影響する形でリクエストが変わったときは、顧客に通知します。受領確認、追加情報の依頼、リクエストの承認または却下、完了予定日の変更、作業完了などが一般的なタイミングです。従業員が誤字を直した、内部メモを追加した、期待される結果を変えずにタスクを再割り当てした、といった理由で顧客に通知する必要はありません。

内部アラートにも、担当者と対応する理由が必要です。リクエストが「レビューが必要」に移ったら、確認担当者に通知します。顧客が質問への返信を追加したら、フォローアップ担当者に通知します。どちらのイベントでも、チーム全員にアラートを送る必要はありません。

メッセージは簡潔かつ具体的にします。リクエスト、現在のステータス、次に起きることを記載します。たとえば、次のようになります。

• 顧客: 「機器リクエスト #1842を受け付けました。火曜日までに確認します。」
• 確認担当者: 「リクエスト #1842は、火曜日15時までに承認が必要です。」
• 顧客: 「リクエスト #1842が承認されました。チームが配送を手配し、金曜日までに更新情報をお送りします。」

文章と同じくらい、タイミングも重要です。期限通知は、期限の5分前ではなく、担当者が対応できる早い段階で届けます。2日間の確認期間なら、通常は前日に1回、期限を過ぎた後にもう1回通知すれば十分です。担当者が作業を完了したら、アプリは保留中のリマインダーを停止します。

マップ上で、それぞれの遷移の横に通知ルールを記録します。誰が受け取るのか、どのイベントが通知を起こすのか、配信チャネルは何か、リマインダーが必要かを書きます。これなら、画面を作ったり自動処理を組んだりする前に、動作を明確にできます。

シンプルな顧客リクエストを追ってみる

顧客がサポートフォームから二重請求を報告します。フォームによってリクエスト #4821が作成され、状態は「新規」、担当はサポートキューになります。顧客にはリクエスト番号と、チームが1営業日以内に確認するという案内がすぐに届きます。

サポート担当者がリクエストを開き、注文と決済の記録を確認して、状態を「確認中」に変更します。担当者がリクエストを担当します。決済記録だけでは情報が足りない場合、担当者は「顧客待ち」を選び、銀行取引明細のスクリーンショットまたはカード番号の下4桁を依頼します。

この状態にも期限が必要です。アプリケーションは3日後に顧客へリマインダーを送り、返信がなければ7日後にリクエストをクローズできます。顧客が不足情報を追加したときは担当者に通知し、リクエストがキューの中で見過ごされないようにします。

顧客が返信すると、リクエストは「確認中」に戻り、可能であれば同じ担当者に戻ります。同じ担当者が継続して対応すれば、新しい担当者が同じ質問を繰り返さずに済みます。

担当者が二重請求を確認したら、リクエストを「返金判断」に変更し、財務の確認担当者に割り当てます。財務担当者には、返金を承認または却下するための2営業日があります。期限の1日前にリマインダーを送れば、顧客から催促される前に判断できます。

財務の確認担当者が判断を記録します。承認されたリクエストは「返金処理」に移り、決済チームが返金を実行して参照番号を入力します。却下されたリクエストは理由とともにサポートへ戻り、担当者が顧客に明確に説明できるようにします。

サポートは、チームが返金を実行するか、却下理由を説明してから最終メッセージを送ります。その後、担当者がステータスを「クローズ」に変更します。顧客には結果を記載した完了通知が届き、チームには担当者、判断、期限、メッセージの記録が残ります。

このマップがあれば、ある画面では完了しているように見えるのに、別のチームのキューで対応待ちになっているという、よくある抜け漏れを防げます。

ワークフローを混乱させるよくある間違い

多くのリクエストワークフローがわかりにくくなるのは、設計した人には明確に聞こえるラベルが、毎日使う人には明確でないためです。「保留中」というステータスは、顧客の返信待ち、マネージャーの承認待ち、部品待ちの技術担当者を意味するかもしれません。それぞれに異なる次のアクションが必要です。

曖昧なラベルを、待っている理由がわかる状態に置き換えます。「顧客情報待ち」なら、依頼者がすべきことがわかります。「マネージャー承認待ち」なら、進行を止めているマネージャーにも状況が伝わります。次に誰が対応すべきか説明できないなら、状態名を変えるか、その状態自体を削除します。

担当者も頻繁に問題になります。リクエストにサポート、財務、運用が関わっていても、複数の名前を並べただけでは共同責任になりません。アクティブな状態ごとに1人の担当者を決めます。その人は他の人に意見を求めながら、リクエストを前に進めるか、遅延の理由を説明する責任を持ちます。

期限には、期限を過ぎたときのアクションを結び付けます。リマインダーを送るだけの期限では、誰も対応しなければ意味がありません。担当者への通知、マネージャーへのエスカレーション、レビューキューへの移動など、時間切れに何をするのか決めます。遅延の影響に合ったアクションを選びます。

役に立ちそうな状態名だからという理由だけで画面を作らないでください。すべての画面には、明確な作業、判断、または引き継ぎを支える役割が必要です。「品質確認」画面が意味を持つのは、誰かが定義された基準を確認し、リクエストを承認するか、理由を添えて戻す場合だけです。そのアクションを簡潔に説明できないなら、不確実さを別のページに隠すのではなく、状態を削除します。

画面を設計する前に、ライフサイクルの各部分を次の4つの質問で確認します。

• このステータスは具体的に何を意味するか
• この状態にある間、誰がリクエストを担当するか
• どのイベントで次のステータスに移るか
• 期限を過ぎたら何が起きるか

この確認で、早い段階に抜け漏れを見つけられます。また、各状態に目的、担当者、定義されたアクションがあるため、リクエストワークフローをアプリに変えやすくなります。

画面設計前に簡単な確認を行う

UIビルダーを開く前に、リクエストマップを簡単にレビューします。忙しい火曜日に実際のリクエストを処理するスタッフになったつもりで読み返してください。次に何が起きるかわからないなら、画面を作ってもその問題は解決しません。

すべての状態に明確な役割と、少なくとも1つの出口を持たせます。「顧客待ち」はチームが情報を必要としている状態なので、顧客が返信した、キャンセルした、決められた返信期限を過ぎたときに移動できる必要があります。「対応中」のように、チームがそこで何をするのか決まっていない一般的な感覚だけを表す状態は避けます。

すべての遷移について、何がきっかけになり、誰が実行できるかを確認します。サポート担当者は回答を送った後にリクエストを解決済みにできます。顧客はそれを再オープンできます。システムルールは、返信がないまま14日経過した後にクローズできます。誤操作を防ぐため、こうした権限を記録します。

次のチェックリストを使います。

• すべての状態に目的、出口、自然な次の状態がある
• すべての遷移に、きっかけと、開始を許可された人またはルールが記載されている
• すべてのオープンなリクエストに、1人の担当者と期限または応答期限がある
• 顧客に影響するステータス変更が起きたとき、顧客に更新情報を送る
• 期限を過ぎた場合に、誰へ通知し、何をしてもらうかが決まっている

混乱が始まりやすい引き継ぎで、担当者を確認します。サポート担当者が技術的な問題をエンジニアリングへ送るなら、リクエストには新しい担当者を明記します。元の担当者を閲覧者として残すことはできますが、どちらも相手が返信すると思い込む状態にしてはいけません。

期限通知は実用的にします。期限前に内部リマインダーを送り、リクエストが開いたままの場合だけエスカレーションします。顧客には、入力が必要なとき、別のチームに移ったとき、チームが解決またはクローズしたときに知らせます。すべての内部メモを顧客に通知する必要はありません。

紙の上でマップが明確に読めるようになれば、画面の役割も明確です。適切な人に、適切なステータス、アクション、担当者、期限を表示できます。

マップをアプリケーションに変える

顧客リクエストのライフサイクルが明確になれば、マップの各要素をアプリの機能に直接対応させられます。状態はステータスフィールド、担当者は割り当てられたユーザーまたはチーム、期限は日時フィールドになります。遷移は「割り当て」「詳細を依頼」「解決」「再オープン」などのアクションになります。

最初のバージョンはシンプルにします。通常、リクエスト画面に必要なのは、顧客、リクエストの種類、説明、現在のステータス、担当者、期限、アクティビティ履歴、ファイルです。別のキューには、それぞれの人が対応すべきリクエストを表示できます。

ワークフローは、ラベルを表示するだけでなく、アクションを制御する必要があります。サポート担当者はリクエストを「新規」から「確認中」に移せます。「解決済み」にできるのは、割り当てられた解決担当者だけです。解決後に顧客が返信した場合、アプリがリクエストを再オープンし、適切なキューに戻すこともできます。

すべての画面を作る前に、実際のリクエストを受け取り、解決している人たちで動作する試作版を試します。通常のケース、緊急のケース、情報が不足しているケースを処理してもらいましょう。アクションが見つからない、担当者がわからない、質問するためにアプリの外へ出なければならない、といった場面を観察します。

そのフィードバックを、画面だけでなくマップの改善にも使います。2つのチームを混乱させる引き継ぎには、「承認待ち」のような状態が必要かもしれません。長時間滞留するリクエストには、より明確な期限や担当者へのリマインダーが必要かもしれません。小さな活動をすべて表すために状態を追加しないでください。選択肢が多すぎると、ワークフローが追いにくくなります。

AppMasterなら、この設計をノーコードのリクエストアプリに変えられます。Data Designerで、リクエスト、ユーザー、チーム、期限、ステータス履歴をモデル化できます。Business Process Editorでは、割り当て、ステータス変更、リマインダー、エスカレーションを定義できます。Web画面やネイティブモバイル画面で、リクエストキュー、詳細画面、マネージャー向けレポートにも対応できます。

まずは1種類のリクエストと少人数のユーザーから始めます。回避策を使わずに、作成、割り当て、更新、クローズができるようになったら、次のリクエストの種類を追加します。こうして、忙しい日に実際の作業を支えられるアプリになります。見た目は魅力的でも、何をすべきかわからない状態を残す画面だけを作るのではありません。