ユーザ操作体系の導出と思考

システムとは、ある範囲内の類似の物事が秩序正しく接続され組み合わされて構成される全体です。ユーザーオペレーションシステムは、ユーザーのニーズと企業のニーズを組み合わせたものであり、双方にとってのソリューションです。

ユーザー運用体制を計画する目的は、ビジネス運用モデルを明確にし、その後の製品企画を円滑に進めるために、事前にキャパシティの余裕を準備することです。

最近、システム計画について考える際に、論理的かつより一般的なアプローチをまとめてみることも試みました。

本稿では、インターネット保険を例に、運用モデルの設計、コアパスの描画、需要分析と分解、運用境界の整理という4つの側面から導出思考プロセスを説明します。

01 運用モデルの設計

運用モデルは製品目標とユーザーの行動から導き出され、製品目標の優先順位を評価し、それに応じて運用と製品計画を実施するのに役立ちます。

1. モデルの選択

運用モデルはユーザー運用システムの出発点であり、対象範囲が広く、企業のほとんどの業務部門をカバーします。理解にかかるコストを削減するために、モデルはできる限り一般化され、単純化される必要があります。

第二に、細分化された運用次元を抽象化し、実行中にさらに細分化する必要があります。

選択できる参照モデルは、業界ライフサイクル、成長モデル AARRR、ユーザージャーニー UJM など多数あります。ただし、使用時には実際の状況に応じて調整する必要があります。

2. モデルの調整

モデルの調整は、参照モデルが抽象的または細分化されすぎていて、製品自体の目標に直接一致しない可能性があるために行われます。

モデルの選択には、AARRR モデルを採用しました。ライフサイクルは抽象的すぎるため、定義と説明に余分な労力が必要です。

「活動」に関して言えば、保険は本来、低頻度かつ非必須の商品であり、実際の運用では活動期間よりも活動人数を追求することになります。そのため、「アクティブ」は削除され、アクティブユーザー数は「リテンション」に組み込まれました。

しかし、保険を購入するユーザーの共有行動は比較的弱く、ほとんどは1人で家族全員の保険を購入するために購入しています。共有行動はユーザーの行動とあまり一致せず、製品の核心目標ではないため、「共有」は削除されました。

保険商品は顧客獲得コストが高いため、ユーザーの離脱を防ぎ、ユーザーに保険の再購入と更新を促すことが重要であり、これも「離脱」のリンクに追加されます。

02 コアパスを描く

運用モデルは製品目標の具体化であり、コアパスはユーザーが目標を達成するための主要な動作であり、設計された運用モデルと高い一貫性が求められます。コアパスのフローは、より大きなフローとより少ない損失で流れるようにし、異常なパスの場合はその逆を行う必要があります。コアパスに基づいて、次の質問にも答えることができます。

• ユーザーの実際の行動はどうでしょうか?
• コアパスからのオフセットはどこですか?どのリンクで損失が発生しましたか?
• 損失後の実際の傾向はどうですか?
• トラフィックを回復するチャンスはありますか?

これらの問題は、一般に「成長」として知られる業務の焦点となる可能性があります。

03 需要分析と解体

ユーザーが製品を使用する理由は、ユーザーと価値を交換することができるためです。ユーザーに製品の目的を達成してもらいたい場合は、ユーザーに何を提供できるかという答えを出す必要があります。ユーザーは何を必要としていますか?

このセクションにおける「需要」は、製品指標とユーザーニーズに分かれています。前者は製品目標を定量的に内訳したもので、後者は前者を向上させるための重要な要素です。

1. 製品指標

上図は、コアパスに基づいて製品指標をさまざまな運用段階に分解したものです。この 2 つを考慮せずに指標を分解しても意味がありません。

分解にあたっては指標分類法を採用し、企業の戦略目標、組織体制における分業体制、実際の業務遂行レベルに応じて上から下へ分類します。これは、運用モデルの導出と非常によく一致しています。

企業戦略レベルの指標は、企業の全体的な目標の達成度を測定するために使用され、意思決定に向けられます。経営戦略指標とは、企業指標を下位の事業部門に分割し、その改善に基づいて業務戦略を立て、企業目標を達成する手法です。ビジネス実行レイヤーは、ビジネス戦略レイヤーの完了プロセスに属し、ビジネスの実行プロセスをガイドするために使用されます。

総取引金額を例にとると、分解プロセスは次のようになります。

コアパスの初回注文とリピート購入を合わせて、合計取引金額を初回取引金額とリピート購入取引金額に分割します。

このうち、買戻しには、非更新契約の発生と、元の契約の更新および保険料の更新が含まれます。非更新契約の発生は転換リンクに設定され、更新および保険料更新率の向上は主に損失の削減に依存し、損失リンクに配置されます。

未取引ユーザーは、それぞれ新規ステージと維持ステージに対応する新規ユーザーと既存ユーザーに分類されます。

上図において、業務実行層の指標は実際にはさらに細分化されており、以下で説明します。

2. ユーザーのニーズ

このセクションのユーザーニーズは、コアパスプロセス中にユーザーによって生成され、製品指標を改善するための重要な要素です。

コア パスは、製品がユーザーに実行してほしい動作であり、ユーザー パスはユーザーが実際に実行する動作です。

ユーザーの行動がコアパスから外れている場合、それは製品がユーザーのニーズを満たせていないか、ニーズを満たす方法が間違っていることを意味します。逸脱が大きすぎる場合は、製品の位置付けとターゲットグループに誤りがないか注意する必要があります。

上の図の説明は主にプラス思考です。なかなか始められない場合は、ユーザーの各ブレークポイントの理由を逆に考えてみるのもよいでしょう。

3. 解決策

運用モデルとコアパスに基づいて、製品指標とユーザーニーズを分析・細分化し、最後のステップとしてソリューションを提案しました。

同じソリューションを異なる運用部門と組み合わせると、さまざまなソリューションが生まれます。

04 運用境界の整理

運用段階、コアパス、対応するコア指標とソリューションを使用して、次のステップは、さまざまな段階でさまざまな問題を誰が解決するかを答えるために使用される運用境界を整理することです。

1. 運用境界

イギリスでは 1769 年にはすでに工場で分業が行われていました。分業と境界の目的は、運営資源を効率的に利用することでした。

使用率とは、運用リソースがアイドル状態または競合状態にあるかどうか、ユーザー フローが適切かどうか、トラフィック損失があるかどうかを指します。境界を整理する際によくある誤解は、業務内容の区分のみを行い、指標の割り当てや業務の流れを無視してしまうことです。

2. 運用方法

セクション 03 では、製品の指標、ユーザーのニーズ、ソリューションを紹介し、セクション 04 では、指標の責任者とそれぞれのソリューションについて説明します。

新しい運営段階では、広告部門は主に配信方法を使用し、コンテンツ運営はショートビデオ、知識コミュニティ、草の根コミュニティなど、トラフィックを転換するためのセルフメディアのマトリックスを確立します。保持段階では、ほぼすべての運用チームが努力する必要があります。

イベント運営においては、訪問頻度を高めるために高頻度アクティビティを設計する必要があります。製品の動作では、ポリシーのライフ サイクルとコア パスに基づいてトラフィックが分散されます。変換段階で言及される保険の推奨は、コミュニティ運営のためのユーザー教育、製品運営のためのパーソナライズされた推奨、アフターセールス部門のためのサービス変換です。

3. セグメンテーション指標

上記の図は、事業部門の境界と運用方法に基づいて、事業部門が一致できる製品指標を示しています。

マッチングする際には、自社のビジネスモデルに留意する必要があります。例えば、コンバージョンの観点では、コンテンツやコミュニティの運営はより長期的であり、平均獲得数の向上に重点を置きます。活動の運営はより短期的であり、最初の注文の変換率に重点を置いています。

ただし、詳細な指標は一般的には業務システムに反映されるのではなく、事業そのものの企画に重点が置かれる傾向があります。指標をセグメント化する場合は、OSM モデルを使用することをお勧めします。

O は運用目標、S は目標を改善するための運用戦略、M は戦略の品質を測定する指標を指します。目標を設定する際には、定性的な説明を定量的な指標に変換する必要があります。

更新インジケーターを例にとると、更新時期は保険購入時期からかなり離れているため、ユーザーに保険の更新を通知する必要があります。

最初のステップは、リコール成功率を評価することです。成功率が低い場合は、他のリコールチャネルの追加を検討する必要があります。

訪問コンバージョン戦略の第 2 段階は、パーソナライズされたコピーライティングと興味の刺激であり、メッセージのクリックスルー率を使用して、パーソナライズされたコピーライティングの品質と興味の促進効果を評価します。

第3段階では、支払いクリック率を使用してインタラクションの合理性と支払いの利便性を評価し、支払い率を使用して全体的なコンバージョン状況を評価します。

この方法に基づいて、自社の運用能力と組み合わせて、独自のソリューションを考え出してください。 (結局のところ、すべての部門が ROI を検討します。

05 システムの全体像

最後に、上記 4 つのステップから導き出された結果を組み合わせることで、シンプルな操作体系図を出力できます。

06 結論

この記事を書くきっかけは、偶然UJMのユーザージャーニーマップを読んだことでした。その時、ユーザーオペレーションシステムをこのモデルに置き換えることができるのではないかと考えていました。

しかし、私は深い穴にはまってしまったのです。話題が大きすぎて、集中できませんでした。長い間書き続けた結果、基本的な論理的一貫性しか得られませんでした。ここでいくつかのアイデアを出し、友人と議論したり、アイデアを交換したりしたいと思いました。

著者: ワイズ・ウォン

出典: Becomewiser (becomewiser)