プロジェクトについて
クライアントの製品は、サブスクリプション料金形式で動作するB2B領域のSaaSです。ユーザーは登録し、承認を渡し、アカウントを補充してサービスを使用します。
私たちの仕事は、クライアントが分析を「収集」するのを支援することです。これを行うには、コールセンターのプロセスを構築し、CRMを実装し、主要な指標によるエンドツーエンドの分析を「まとめる」必要がありました。
プロセス構造
分析を行う前に、それを収集するためのランドスケープを準備する必要があります。販売プロセスを構造化し、サービスとの統合を設定します。プロセスでいくつかの問題が見つかりました。
- マネージャーはセールスファネルの不要な段階に気を取られ、彼らの仕事はまったく監視されていませんでした。
- 売上レポートは、管理パネルから毎日手動でダウンロードされました。
- 分析を収集するための変換イベントはほとんどありませんでした。
次に、すべてのシステムの相互作用の構造を含むマップを作成しました。
これは、イベントが従うべきロジックと、アナリストがどの段階で進むかを示しています。CRMから主要なデータを取得し、それを広告とコンバージョンに関するデータと関連付けます。myBIにまとめ、PowerBIでレンダリングします。
セールスファネル
顧客の販売はEnyboxCRMで行われ、統合を容易にするためにamoCRMに転送しました。セールスロジックを3つのファネルに集めることができました。
3つの連続した漏斗
最初の漏斗は相談です。プラットフォームに登録するためにクライアントを連れてくる必要がありました。2番目の目標到達プロセスは、最初の支払いを修正することです。次に、ユーザーは自分の登録を確認しました。そして、私たちは今度は、支払いの瞬間とそれぞれの新しい補充を祝いました。
分析がどのように機能するか
| 最初の「イベント」 | 最終的な「イベント」 |
|---|---|
| フィードバックフォーム | フィードバックフォーム |
| サービスへの登録 | サービスへの登録 |
| 初回入金 | |
| テスト（少量の補充でオプション） | |
| 繰り返しの補充 | |
| 使用拒否（OPによるウォーミングアップ） |
分析システムが正常に機能するには、すべてのイベントを収集する=変換アクションをマークする必要があります。イベントはすでに分析システムに入っていますが、最初は2種類しかなく、レポートには不十分です。
データの表示
ダッシュボードの例
コンバージョンに関するデータを収集した後、それらからレポートを作成する必要がありました。主なデータ視覚化ツールはMicrosoftPowerBIです。
変換時に、広告システムとCRMを同期するために別のIDがサイトで生成されました。このIDで、費用と収入のデータをリンクしました。そのため、データを相互に関連付けて、レポートを作成することができました。
ユニット経済学。保持
1か月から12か月の
保持期間にわたるサービスのローリング保持グラフは、ユーザーがアプリケーションに関与している量と、アプリケーションに戻る頻度を示します。しかし、サービスが補充の形で機能するという事実のために、私はこのインジケーターをローリングリテンションに変更する必要がありました。保持と同じように表示されますが、ユーザーがアカウントを補充しなかったときは常に、サービスも使用したことを意味します。
最初の預金への変換
コンバージョンは、新規顧客の数と支払いの開始に大きく依存していました。最初の9か月間、毎月約430件の新規登録と90件の支払いを新規ユーザーから受け取りました。12か月のデータによると、登録月の購入への変換は20％でした。
標準の指標に加えて
サイトへの単純な移行の瞬間と、登録および追加の支払いの両方の時点で、クライアントのタッチに関する分析を確認する機会がありました。最も多くのコンバージョンチェーンを見つけるためにデータを蓄積しました：
ユーザーは広告を見た→サイトに行った→しばらくしてコンテキストを調べた→登録したが、支払わなかった→手紙でウォームアップした→試乗を提供した→テストした→OP「最初の支払いをした」→3年安定した支払い。
何かがうまくいかなかった
プロジェクトの開始者は当初、開始を秋まで延期しました（彼らは春に申請しました）。このような作業の「ギャップ」は複数回発生しました。しかし、私たちはそれについて考えず、当然のことと考えました。主な問題は、クライアントのプロセスにおけるコミュニケーションと官僚主義でした。これは、プロジェクトの作業期間全体を表す方法です。
開発が遅い
開発のギャップは、クライアントの作業の構造によるものでした。私たちはクライアントのチームと協力しましたが、プロセスのセキュリティが高いため、一部のタスクはクライアントの側でしか実行できませんでした。
2つのスプリントを逃した-1か月を失った
彼らの側のすべてのマネージャーと開発者は2週間の反復で働きました。しかし、彼らは常に私たちのプロジェクトを最優先し、私たちのタスクは「スプリント」に分類されないことがよくありました。
コミュニケーション不足と専門知識の欠如
プロジェクト中に、クライアントのマネージャー（利害関係者）は5回変更されました。おそらく、あなたが取り組んでいるプロジェクトが突然クライアントにとって面白くなくなったときの気持ちは誰もが知っているでしょう。しかし、それでも解決できます。
利害関係者の無能さに対処することはより困難でした。そのうちの一人は、彼の製品をよく知っている偉大な幹部でした。しかし、彼は販売プロセスを構築するための基本原則さえ理解していませんでした。セールスファネルから「お元気ですか？」というステータスのステージを削除するように彼を説得するために、私たちはいくつかの会議を費やしました。
上の写真のようなセールスファネルを想像してみてください。ある段階で、マネージャーは「クライアントがどのように行っているか」を知る必要があります。この目標到達プロセスのコンバージョン分析はどうなると思いますか？
マネージャーは、クライアントを目標到達プロセスに移動させる代わりに、クライアントから「お元気ですか」を確認します。ステータスは簡単ではありません。いつ置くかは明らかではありません：最初の接触後または資格取得後。その結果、シーケンシャルな動きではなく、ファンネルに沿って前後に「ジャンプ」するか、単に立つだけです。
販売プロセス中に、取引が蓄積される中間段階を設定することは不可能です。そうしないと、すべての分析が混乱し、マネージャーは多くの連絡先を失うことになります。
私たちの側からのファカパス
システムの帯域幅は考慮していません。ピーク時の1つのプラットフォームイベントに対して、ビジネスプロセスのロジックを実行するために最大10件のリクエストをamoCRMに送信しました。
1日あたり100,000イベント* amoCRMへの10リクエスト= 1日あたり1,000,000リクエスト/ 1日あたり
1,000,000リクエスト/ 10秒あたり10リクエスト（AMO制限）= 100,000秒=±27時間
結果：同期は終了しません
最初に選択されたamoCRM、システムへの要求の制限を「渡す」として。しかし、プロジェクトの開発の過程で、要件と機能が増加し、制限に「遭遇」しました。
間違ったツールを選択しました。AmoCRMは、多数の要求を処理するのに物理的に適していません。また、間違いは私たちがGOですべてを開発したことであり、1人の専門家がこれを担当しました。彼が去ったとき、誰も理解できないレガシーコードの山がありました。しかし、残念ながら、または幸いなことに、これは必要ありませんでした。
すべてが再び壊れています
このケースは、承認と不要な管理の山に埋もれているプロジェクトの別の例です。
技術的な専門知識が不足していました。クライアントへ-管理の安定性とプロジェクトを完了させたいという願望。
しかし、これは経験です。彼のおかげで、そのようなタスクは可能な限り簡単に見えるようになり、別のプロジェクトで同様のソリューションをすでに再現しました。
どうすれば失敗を回避できますか
今後このようなケースを繰り返さないために、エンタープライズクライアントと連携する際に遵守しなければならない側面を強調しました。
- : ; . , .
- . — . — . . .
- . KPI — .
- 先を考えてください。MVPを開発する場合でも、将来発生する可能性のあるボトルネックを確認する必要があります。プロジェクトは常に拡大しており、すべてのコードを最初から書き直さないように構造を提供することが重要です。
記事の著者は、LANDPROマーケターのFyodorAnisimovです。