5.9 サービスデザイン

概要と動機

サービスデザインとは、単一の画面やアプリではなく、あらゆるチャネルにわたり、全期間を通じて人が体験するサービス全体を形づくる実践です。誰かがパスポートを更新し、銀行口座を開き、壊れた街灯を報告するとき、その人はあなたのプロダクトを体験しているのではありません。サービスを体験しています。電話、ウェブサイト、郵便の手紙、行列、届かないメール、ウェブサイトがすでに知っていることが見えないシステムに、詳細を打ち直さなければならない担当者。5.1章は、個々のインターフェースを設計する技芸を扱います。サービスデザインは、ジャーニー全体と、カウンターの手前を機能させるカウンターの奥のすべてへと、ズームアウトします。

その「カウンターの奥」という区別が核心です。サービスデザインは世界を、フロントステージ(ユーザーが見て触れるものすべて)と、バックステージ(サービスを届けるがユーザーには見えない人々、システム、プロセス)に分けます。良いフロントステージの体験は、バックステージがそれを支えられないために、しょっちゅう失敗します。事務員が一日に二回確認するスプレッドシートに流れ込む洗練された予約フォームは、遅いバックステージにボルトで留められた速いフロントステージで、ユーザーはそのミスマッチを三日間の沈黙として感じます。サービス全体を設計するとは、両方の半分と、その間の継ぎ目を一緒に設計することです。

大きなチームにとって、これは避けられず組織の問題です。サービスはほとんど常に複数のチーム、部門、システムにまたがり、それらの所有者の間の境界こそ、ユーザーの体験が崩れる場所です。企業の設定では、単一の顧客ジャーニーが、営業、プロビジョニング、請求、サポートを横切ることがあり、それぞれ独自のツールと目標を持ち、全体に責任を持つ者はいません。政府では賭け金がさらに高い。死別や新生児のようなライフイベントに直面した人は、十数の別々の機関をナビゲートしなければならず、それぞれが同じ証拠を求めます。サービスが、人のニーズではなく政府の構造を軸に組織されているからです。サービスデザインは、その中心にいる人間のために、全体をまとまりあるものにする方法です。

主要原則

単一の画面ではなく、チャネルと時間にわたってサービス全体を設計します。ユーザーは、チームの境界がどこにあるかを気にしません。
フロントステージとバックステージは一つのシステムです。体験は、その背後の運用が支えられる分だけ良いのです。
組織図はサービスに現れます。チームがサイロ化していれば、サービスもサイロ化して感じられるので、チームの設計とサービスの設計は一緒に動かなければなりません。
チャネルとチームの間の引き継ぎは、サービスが壊れる所です。継ぎ目を、ステップと同じく意図して設計します。
スタッフ向けのツールはサービスの一部です。悪いコンソールにいらだつ担当者は、いらだつ顧客を生みます。
ユーザーの最初の意図から本当の成果まで、一つのチャネルの局所的な指標ではなく、サービスをエンドツーエンドで測定します。
内部の部門ではなく、ユーザーの目標やライフイベントを軸に組織します。

推奨事項

あらゆるチャネルにわたってカスタマージャーニーをマップする

より広い顧客体験の一部として、人が成果に至るために実際にたどるジャーニーを描くことから始めます。ジャーニーマップは、ユーザーが通る段階を、ニーズに気づく最初から目標に達してその先まで並べ、各段階で、彼らが何をしようとしているか、何を考え感じているか、どのチャネルにいるかを記録します。価値は、チャネルにまたがることから来ます。実際のジャーニーのほとんどは、ウェブサイト、電話、メール、アプリ、物理的な場所の間を跳び回り、最悪の痛みは、文脈が失われユーザーがやり直さなければならない、それらのチャネルの間のギャップに住んでいます。想定ではなく、リサーチ(5.8章)にマップを根づかせてください。想像するジャーニーと人々が実際にたどるジャーニーは、めったに同じではないからです。「重要な瞬間」、つまり体験が決定的に成功あるいは失敗する少数の点に印を付け、均等に広げるのではなく、そこに労力を集中させます。どの一つのチャネルでも滑らかに見えるジャーニーが、エンドツーエンドでは惨めなことがありえ、チャネルを横断する見方だけがそれを明らかにします。

フロントステージとバックステージを結ぶサービスブループリントを築く

この規律の中核の成果物は、サービスブループリントです。ジャーニーマップがユーザーの視点を取る所で、ブループリントはその下の層を加えます。典型的なブループリントは水平のスイムレーンで進みます。上にユーザーの行動、次に彼らが対話するフロントステージのタッチポイント、その下の「可視線」の下にスタッフが取るバックステージの行動、そして最後に上のすべてを可能にする支援システムとプロセス。列を上から下に読めば、一つのフロントステージの瞬間が機能するために、舞台裏で何が起こらなければならないか、システムが遅かったり引き継ぎが曖昧だったりしたらどこで壊れるかが正確にわかります。ブループリントは、静かな失敗を見つける所です。手作業の再入力、夜間のバッチジョブ、自分が依存先だと知らないチーム。デザイナーだけでなく、実際にバックステージを運営する運用スタッフと一緒に描いてください。彼らが本当の仕事が起こる場所を知っているからです。ハッピーパスだけを示すブループリントは装飾です。失敗と回復の経路もブループリントにしてください。

バックステージとスタッフ向けのツールを第一級として設計する

スタッフが使うツールを、プロダクトの一部として扱ってください。顧客にとってはそうだからです。コールセンターの担当者、ケースワーカー、倉庫のピッキング担当者が、遅く、醜く、半分壊れた社内のコンソールと格闘するとき、その摩擦は、仕えている相手に直接、より長い待ち、間違った答え、目に見えるいらだちとして渡されます。社内ツールが慢性的に資金不足なのは、まさにそのユーザーが逃げられず立ち去れないからで、だから5.1章は、逃げられないユーザーのソフトウェアが、離脱ではなく、エラーと失われた生産性で代償を払うと警告しています。スタッフ向けのシステムに、顧客向けのものに与えるのと同じリサーチ、デザイン、品質の水準を与えてください。引き継ぎ、つまりケースがあるチーム、システム、チャネルから別のものに渡る瞬間に特に注意を払ってください。落とされた引き継ぎは、待たされるユーザーを除く誰にも見えないからです。受け取る側が何を見るか、どんな文脈がケースとともに移動するか、引き継ぎが失敗したときに何が起こるかを設計します。

チームの設計をサービスの設計に合わせる

組織図がサービスに現れると予期してください。これはコンウェイの法則、つまりシステムはそれを築く組織のコミュニケーションの構造を映すようになるという観察で、1.2章で詳しく扱われています。四つのチームがジャーニーの四つのステップを所有し、めったに話さなければ、ユーザーは、間に亀裂のある四つのバラバラなステップを感じます。したがって、サービスデザインとチームデザインは、二つの角度から見た同じ問題であり、根底の所有が断片化していれば、より良い画面だけで断片化した体験を直すことはできません。サービスブループリントとジャーニーマップを使って、チームがユーザーのジャーニーを軸に描かれているか、内部の都合を軸に描かれているかを問い、チームを再編する、あるいは誰かが自分のスライスだけでなく全体に責任を持つよう、エンドツーエンドのジャーニーを明示的に所有する役割を作る覚悟を持ってください。チームを描き直せないときは、せめてそれらの間の引き継ぎを、合意された文脈とサービスレベルを備えた明示的な契約にします。

サービスの品質をエンドツーエンドで測定する

一つのチャネルを単独で持ち上げる指標ではなく、最初の意図から本当の成果までユーザーを追う指標を選びます。ウェブサイトのチームは、フォームの完了率98パーセントを達成しながら、それらの完了の3分の1がバックステージの待ち行列で静かに失敗しているかもしれず、局所的な指標はそれを決して示しません。エンドツーエンドの完了(その人は来た目的を実際に得たか)、エンドツーエンドの時間(意図から成果まで、見えないバックステージの待ちを含めてどれだけかかったか)、労力(使わなければならなかったすべてのチャネルにわたって、どれだけ大変だったか)を測定します。運用データを、取引後の調査、ネットプロモータースコア風の質問、継続的なリサーチを通じた、どう感じられたかの直接の読みと組み合わせます。特にチャネル間の離脱を観察してください。それらの継ぎ目が、測定された品質と感じられた品質が最も乖離する所だからです。これらのサービス指標を、プロダクトマネジメントの成果の追跡(10.14章)に結びつけ、数字が、誰も行動しないダッシュボードに座るのではなく、優先順位づけを駆動するようにします。

トレードオフ: 長所と短所

アプローチ	長所	短所
エンドツーエンドのサービス所有(一つのチームが一つのジャーニーを所有)	明確な説明責任、一貫した体験、継ぎ目が設計される	既存の組織構造を横切る。人員配置と資金が難しい。ボトルネックになりうる
チャネルごと、またはステップごとの所有	既存のチームに合う。局所的な範囲が明確。人員配置が容易	誰も全体を所有しない。チャネル間のギャップ。局所的な最適化
事前の完全なサービスブループリンティング	出荷前にバックステージの失敗を表面化させる。共有の理解	時間がかかる。古くなりうる。行動の前の分析のリスク
軽量なジャーニーマッピングのみ	速く安く、最悪のギャップを見つけるのに十分	ブループリントが捉えるバックステージとシステムの失敗を見逃す
オムニチャネルの一貫性(チャネル間で統一)	シームレスな引き継ぎ、文脈がチャネルをまたぐ	高価な統合。共有のデータと揃ったチームが必要

中心的な緊張は、境界をまたいで流れるユーザーが必要とするサービスと、それに沿って描かれた実際の組織の間にあります。教条的にではなく、比例的に解決してください。一つのサービスをうまく設計するために会社全体を再編する必要はありませんが、エンドツーエンドの成果に責任を持つ少なくとも一人あるいは一つのチームが必要で、バックステージを見えるようにするブループリントと、継ぎ目を直す権限を備えていなければなりません。最も重いブループリンティングは、量が多い、賭け金が高い、失敗が多いジャーニーに使い、残りには軽いジャーニーマップを使います。目標は完璧な成果物ではありません。その中心にいる人にとって機能するサービスです。

チームで議論すべき問い

ユーザーの最初の意図から本当の成果まで、サービス全体をエンドツーエンドで所有するのは誰で、その人は実際にどんな権限を持ちますか。 ほとんどの大きな組織では、誠実な答えは「誰もいない」です。所有がチャネルと部門で分割され、各所有者が自分のスライスで測られるからです。そのギャップこそ、サービスが失敗する所です。所有者の間の継ぎ目は誰にも属さず、注意を受けないからです。明示的なエンドツーエンドの所有者、サービスオーナーあるいはジャーニーオーナーを作るかを決め、その人が実際にバックステージのシステムとチームの境界を変えられるのか、動かせない指標に責任を持つだけなのかを明確にしてください。現在の組織図と、最上位のジャーニーのブループリントを持ち込み、並べて、誰がジャーニーに触れ、誰がそれに責任を持つかを見てください。二つが合わなければ、最悪の引き継ぎの失敗の源が見つかりました。答えは、誰がスタンドアップに参加するかだけでなく、仕事への資金と人員の付け方を変えるべきです。
チームはユーザーのジャーニーを軸に描かれているか、内部の都合を軸に描かれているか。そしてそれを変える意思はありますか。 コンウェイの法則(1.2章)は、意図するかどうかにかかわらず、サービスがコミュニケーションの構造を映すことを意味するので、四つの意思疎通のないチームにまたがるジャーニーは、四つのバラバラなステップのように感じられます。心地よい動きは、画面を直して組織図はそのままにすることですが、それは症状を扱い、原因はそれを再生し続けます。チームの境界が、ユーザーが不満を言うまさにその引き継ぎのギャップを作っているかを誠実に見て、チームの再編の本当のコストを、断片化した体験の継続的なコストと量ってください。ジャーニーマップの痛点を持ち込み、そのうちいくつがちょうどチームの境界にあるかを確認してください。ほとんどがそうなら、より良いUIはあなたを救わず、会話はチームの設計についてでなければなりません。ここで決めることが、サービスの改善が定着するか、静かに侵食されるかを決めます。
スタッフ向けのツールは、それを使う人々にどれだけ仕え、それは顧客にどう現れますか。 社内ツールは、どんな大きな組織でも最も確実に無視されるソフトウェアです。ユーザーが逃げられず、予算が後回しだからですが、壊れたコンソールと格闘するケースワーカーや担当者は、その摩擦を顧客に直接、遅延とエラーとして渡します。最後に自社のスタッフ向けシステムのリサーチをしたのはいつか、あるいは、スタッフは対処するために給料をもらっているのだから、ツールは大丈夫だと思い込んでいないかを問ってください。バックステージが、静かなサービスの失敗の大半が実際に起こる所であり、手作業の再入力と引き継ぎでの文脈の喪失は、フロントステージの指標のどれにも見えないことを考えてください。本物のスタッフを部屋に呼び、一般的なタスクを完了するのを見て、その苦労が顧客にどう届くかをたどってください。社内ツールをプロダクトのように資金を出したことがないなら、これはおそらく、エンドツーエンドのサービス品質に対する最も安い大きな改善です。
サービス全体が実際に機能しているかを教える単一のエンドツーエンドの指標は何で、なぜ今日それを追跡していないのですか。 大きなチームにとって、この問いは居心地が悪い。誠実な答えが通常、すべてのチャネルと部門が緑の局所的な指標を持つ一方で、その人が来た目的を得たかを誰も測っていないというものだからです。フォームの完了率、通話の処理時間、チケットの完了数は、すべて報告する所有者を持ち上げ、結びついた成果がバックステージの待ち行列で失敗している間も、それぞれ健全に保ちえます。最初の意図から本当の成果までユーザーを追う、エンドツーエンドの完了あるいはエンドツーエンドの時間の指標を決め、データを共有するように作られていないシステムにわたって、誰がそれを計装するかを明確にしてください。現在のチャネルごとのダッシュボード、量の多い一つのジャーニーのブループリント、チャネル間の静かな離脱の見積もりを持ち込み、局所的な緑とエンドツーエンドの赤のギャップが見えるようにしてください。企業と政府の設定では、ジャーニー全体の数字に誰が責任を持ち、誰がそれに行動する権限を持つかに合意してください。単一の所有者が動かせない指標は、何も変えない指標だからです。
サービスはどこでユーザーに繰り返しを強いていて、「一度で伝える」版を築くにはどれだけかかりますか。 データの重複した取得は、サービスがユーザーのニーズではなく内部の境界を軸に組織されている最も明確なシグナルで、双方で高くつきます。ユーザーはあらゆる引き継ぎで同じ証拠を再入力し、各部門はそれを再収集して再検証するために払います。相反する考慮は、「一度で伝える」を可能にする共有のレコードが、互いのデータを信頼してきた歴史のないシステムとチームにわたる統合を要することで、構築のコストとデータガバナンスの仕事は本物です。すでに保持している情報をユーザーが提供するすべての点に注記を付けたジャーニーマップと、同じ項目を保存する別々のレコードの大まかな数を持ち込んでください。複数の機関にまたがる政府のサービスでは、機関の間でそのデータを共有する法的根拠を加えてください。同意、プライバシー法、情報ガバナンスのルールが、手頃かを問う前に、それが許されるかそのものを決めるからです。
チーム、システム、チャネルの間で文脈が引き継がれるとき、実際にケースとともに何が移動し、引き継ぎが失敗したときに何が起こりますか。 引き継ぎは、サービスが静かに壊れる所です。失敗は待たされるユーザーを除く誰にも見えず、大きな組織では、各引き継ぎが、落とされたものに誰も責任を感じない境界を越えるからです。どのデータ、履歴、ステータスがケースとともに移動しなければならないか、受け取る側がそれを見られるか、移転が止まったり不完全に届いたりしたときの回復の経路は何かを、意図して決めてください。実際のジャーニーのサービスブループリントを持ち込み、ケースが手渡される各線をたどり、どの文脈が保たれ、どれが再入力あるいは失われるかに印を付けてください。サービスレベル合意や法定の応答時間に拘束される企業と公共部門のサービスでは、各引き継ぎを、合意された文脈と定義されたフォールバックを備えた明示的な契約として扱ってください。文書化されていない引き継ぎは、どのダッシュボードも警告しない、起こりかけている違反だからです。

セクター別の視点

スタートアップ。 少数の人々と手の込んだ成果物の時間がないなら、中核の価値を運ぶ一つのジャーニーだけをブループリントにし、フロントステージが遅いあるいは手作業のバックステージに引き継ぐ所を見るのに十分なだけにしてください。6週間のスタディとしてではなく、午後のホワイトボードで行います。あなたの強みは、サービス全体が少数の頭の中に住んでいるので、壊れた引き継ぎを直すことが、部門をまたぐ交渉ではなく会話になることです。引き継ぎを高価にする境界を育てる前に、その強みを使ってください。

小規模事業者。 サービスデザイナーも、その予算もないので、実用的な動きは、顧客として自分のジャーニーを歩き、誰かに繰り返しを強いたり、手作業のステップを待たせたりする点すべてに気づき、最悪のものを直すことです。維持できない統合を築くより、すでにチャネルを結びつけるツール(共有の受信箱、スタッフに通知する予約システム)を好んでください。システムを買うときは、次のステップへの文脈の渡し方を量ってください。販売と履行の間で顧客の詳細を落とす安いツールは、節約するより多くを、失われたリピートのビジネスで払わせるからです。

大企業。 中核の問題は、単一のジャーニーが営業、プロビジョニング、請求、サポートを横切り、それぞれが緑の局所的な指標を持ち、全体に責任を持つ者がいないことです。量が多く賭け金が高いジャーニーには完全なサービスブループリントに投資し、継ぎ目に権限を持つ名前のあるエンドツーエンドの所有者を任命し、監査に耐えてチームにわたる優先順位づけを駆動するエンドツーエンドの指標を標準化してください。共有のケースレコードとスタッフ向けのコンソールを資金のある製品として扱い、チーム間のあらゆる引き継ぎを、合意された文脈とサービスレベルを備えた明示的な契約にします。

政府。 サービスは、機関の構造ではなく市民のライフイベントを軸に組織され、公表されたサービス標準と、透明性と公的な説明責任に照らして保たれなければなりません。調達規則が築けるものを形づくるので、データを共有する法的根拠が存在する所では、共有のレコードと「一度で伝える」パターンを好み、フローを設計する前にその根拠を文書化してください。最も脆弱な人々を含む本物のユーザーでリサーチし、機関をまたぐバックステージをブループリントにし、各機関のスライスではなくジャーニー全体を測定してください。公衆は、どの部門が成功したかではなく、成果を得たかでサービスを判断するからです。

事例

スタートアップ。 住宅保険を販売する10人のスタートアップは、自らをアプリの会社と考えていて、アプリは本当に良いものでした。しかし解約が多くサポートは溺れていたので、創業者たちは実際の保険金請求のジャーニーをブループリントにしました。本当のサービスは、顧客が真夜中に水道管の破裂を抱える瞬間であることがわかりました。アプリはメールの待ち行列に引き継ぎ、それが顧客には見えないサードパーティの査定人に引き継ぎ、その人は営業時間中に、見知らぬ番号からコールバックして、留守番電話になる。洗練されたフロントステージが、遅く不透明なバックステージの上に座り、「重要な瞬間」であるストレスの多い請求が、まさに失敗する場所でした。引き継ぎを直し、顧客に査定人のステップを見せ、請求のワークフローをプロダクトの一部として扱ったことは、どんな新しいアプリの機能よりも定着に貢献しました。

大企業。 通信会社は、2分のオンライン注文と2週間の配送の悪夢を伴う法人向けインターネットを販売していました。営業、プロビジョニング、現場エンジニアリング、請求がそれぞれジャーニーの一区間を所有し、それぞれ自分の目標を達成しましたが、顧客は同じ情報の繰り返しの要求、逃した訪問の時間枠、見積もりと合わない最初の請求書を体験しました。四つの部門にわたるサービスブループリンティングが継ぎ目を露わにしました。注文の共有レコードが顧客に伴わなかったために、あらゆる引き継ぎで文脈が死んでいたのです。会社は、注文から開通までのエンドツーエンドの所有者を任命し、注文とともに移動する共有のケースレコードを築き、チームのインセンティブを結びついた成果に配線し直しました。局所的な指標はほとんど変わりませんでしたが、エンドツーエンドの開通時間と苦情率は、ともに大きく下がりました。

政府。 ある国の政府は、市民が直面する最も困難なライフイベントの一つである、「家族の死」のサービスを再設計しました。以前は、遺族は税務当局、年金サービス、車両の機関、パスポート事務所、地方自治体にそれぞれ別に通知しなければならず、それぞれが独自のフォームを持ち、それぞれが同じ死亡証明書を要求しました。機関ではなくライフイベントを軸にサービスを組織して、チームは、人が入力した情報を取り、可視線の背後で関連するすべての部門に配布する、単一の「一度で伝える」ジャーニーを築きました。公共部門のサービス標準に合わせ、最近死別した人々とリサーチし、機関をまたぐバックステージをブループリントにし、各機関の部分ではなくジャーニー全体を測定しました。完了は増え、重複した連絡は減り、市民はもう、死別を十数回も追体験する必要がなくなりました。

ビジネスケース: 動機、ROI、TCO

サービスデザインの見返りは、チャネルとチームの間のギャップを閉じることから来ます。価値が漏れ出すのはそこだからです。エンドツーエンドの失敗は、チャネルごとのダッシュボードが隠す形で高価です。オンラインでは完了するがバックステージで失敗するジャーニーは、サポートへの連絡、やり直し、しばしば失われた顧客を生み、それらのコストのどれも、成功して見えるチャネルには着地しません。サービス全体を測定して直すと、重複した労力(同じデータを五回取得すること)、失敗需要(サービスが最初に失敗したことだけが原因の連絡)、各部分が技術的には機能していても壊れて感じられた体験からの解約を減らします。企業では、見返りは、より短い受注から入金までのサイクルとより少ないエスカレーションとして現れ、政府では、より低いサービス提供のコストと、他では得られないサービスのより高い成功した完了として現れます。

総所有コストは、サービスデザインを行うコストと、すでに抱えている断片化のはるかに大きなコストを量らなければなりません。見えるコストは、リサーチ、ブループリンティング、チーム間の調整、ときには共有システムとスタッフ向けツールへの投資です。それをしない隠れたコストは、サポートの予算、運用、評判の損害に散らばっており、だからこそリーダーシップは過小評価します。どの単一のチームの予算も、壊れた引き継ぎの全額を示さないからです。論拠を示すには、量の多い一つのジャーニーで失敗需要と重複した作業に数字を付け、ブループリントにし、既存のチームの間の継ぎ目に、コストのどれだけが座っているかをリーダーシップに示してください。それから、そのジャーニーで限定されたパイロットを実行し、前後でエンドツーエンドを測定し、結果を使って、より難しい構造的な変更を論じます。サービスデザインを、すでに支払われている、ただ見えないコストの除去として枠づけることは、優雅さへのどんな訴えよりも、財務とガバナンスの利害関係者を動かす傾向があります。

アンチパターンと落とし穴

チャネルの孤島。 各チャネルが単独で設計され測定され、ジャーニーはどこでも問題なく見えるが、エンドツーエンドではどこでも機能しないこと。
フロントステージの口紅。 遅い、あるいは手作業のバックステージにボルトで留められた洗練されたUIで、ユーザーがバックステージの応答を必要とした瞬間に体験が壊れること。
サービスとしての組織図。 ユーザーの目標ではなく部門を軸に構造化されたサービスで、ユーザーに内部の境界のナビゲートを強いること。
ブループリントの劇場。 一度描かれ、賞賛され、サービスが実際にどう動くかを変えるのに決して使われない手の込んだブループリント。
ハッピーパスだけのマッピング。 失敗と回復を無視するジャーニーとブループリントで、そこが実際のサービスが痛む所です。
無視されたスタッフ向けツール。 内部のスタッフ向けシステムを二流として扱い、その摩擦が顧客にそのまま漏れること。
引き継ぎの健忘症。 チーム、システム、チャネルの間のあらゆる移転で文脈が失われ、ユーザーが何度も状況を説明し直すこと。
持ち上げる指標。 エンドツーエンドの成果が静かに失敗している間も緑のままの、局所的なチャネルごとの目標。

成熟度モデル

レベル1、開始: 各チャネルとチームが、孤立して反応的に設計され運営されます。誰もエンドツーエンドのサービスを所有せず、ジャーニーマップもブループリントもなく、バックステージの失敗は苦情として表面化するまで見えません。誰も全体を見ていないので、ユーザーはチャネルをまたいで日常的に繰り返しを強いられます。
レベル2、発展: いくつかのジャーニーがマップされ、最悪のチャネル間のギャップは知られていますが、実践はまだらで個人の熱意に依存します。ジャーニーマップは存在しますがバックステージに届くことはまれで、所有はまだチャネルごと、スタッフ向けのツールは後回しで、ブループリンティングは、行われるとしてもチームごとに異なります。
レベル3、標準化: 主要なジャーニーが、運用スタッフとともにフロントステージからバックステージまでブループリントにされ、組織全体で一貫して適用される文書化された方法が使われています。名前のあるサービスオーナーがエンドツーエンドで責任を持ち、引き継ぎは合意された文脈を備えた明示的な契約で、スタッフのツールは意図して設計され、アプローチは任意ではなく徹底されています。
レベル4、管理: サービスがデータで測定され、制御されています。エンドツーエンドの完了、(見えないバックステージの待ちを含む)エンドツーエンドの時間、ユーザーの労力、失敗需要、チャネル間の離脱がベースラインに対して追跡され、引き継ぎの失敗と重複したデータの取得は、想定されるのではなく定量化されます。ブループリントは最新に保たれ、サービスオーナーはエンドツーエンドの目標に責任を負い、変更の実施/不実施の決定は、局所的なチャネルの指標ではなくその証拠に基づきます。
レベル5、オーケストレーション: チームの設計とサービスの設計が揃い、所有がジャーニーに従い、組織は部門ではなくユーザーの目標とライフイベントを軸に構造化されています。エンドツーエンドの指標が優先順位づけを駆動し、組織は体験と運用を一緒に継続的にブループリントにし、測定し、再形成し、ユーザーのニーズ、チャネル、チーム間の境界が変わるにつれて、サービス全体を適応させます。

議論のためのアイデア

ジャーニーが複数のチームをまたぐとき、一人のエンドツーエンドの所有者を任命するのと、ジャーニーを軸にチームを描き直すのとでは、どちらがよく、何がその選択を決めますか。
サービスの品質のどれだけがより良いフロントステージのデザインで直せ、どれだけがバックステージや組織図の変更を要しますか。
サービスのどこで、ユーザーが最も頻繁に繰り返しを強いられ、「一度で伝える」版を築くにはどれだけかかりますか。
ユーザーが逃げられず、足で投票できないとき、スタッフ向けツールにどう資金を出し、優先順位をつけますか。
資金と報告の系統に真っ向から反する場合でも、サービスはライフイベントやユーザーの目標を軸に組織されるべきですか。
サービス全体が機能しているかを最もよく教えるエンドツーエンドの単一の指標は何で、なぜ今日それを追跡していないのですか。

要点

単一の画面ではなく、チャネルと時間にわたってサービス全体を設計し、ユーザーはチームの境界がどこにあるかを気にしないことを忘れないでください。
フロントステージとバックステージは一つのシステムです。すばらしい体験は、その背後の運用が支えられる分だけ良いのです。
サービスブループリントは中核の成果物です。フロントステージのタッチポイントを、それを届けるバックステージの人々、システム、引き継ぎに結びつけます。
組織図はサービスに現れる(コンウェイの法則)ので、サービスデザインとチームデザインは一緒に動かなければなりません。
スタッフ向けのツールとチーム間の引き継ぎを、サービスの第一級の部分として扱います。その摩擦が顧客に届くからです。
最初の意図から本当の成果までサービスをエンドツーエンドで測定し、部門ではなくユーザーの目標やライフイベントを軸に組織します。

参考文献とさらなる読み物

Marc Stickdorn and Jakob Schneider, This Is Service Design Thinking
Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider, This Is Service Design Doing
Andy Polaine, Lavrans Lovlie, and Ben Reason, Service Design: From Insight to Implementation
Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review
Matthew Skelton and Manuel Pais, Team Topologies
Melvin Conway, “How Do Committees Invent?“, Datamation
UK Government Digital Service, Service Manual and the Service Standard
U.S. General Services Administration, 18F Methods and the U.S. Digital Service Playbook
Nielsen Norman Group, articles on service blueprinting and customer journey mapping