通信事業向けセールス CRM のワークフロー

  • リリースバージョン: Australia
  • 更新日 2026年06月17日
  • 所要時間:6分
  • 通信事業向けセールス CRMワークフローには、最初の見込み客の識別から注文のクローズまで、販売注文を管理するためのエンドツーエンドのプロセスが表示されます。

    通信事業向けセールス CRMワークフローステージを示すフローチャート

    通信事業向けセールス CRM ライフサイクルステージ

    この図は、リードの認定、契約の作成、注文処理、履行アクティビティなど、ライフサイクルにおける次の主要なステージを示しています。
    1. 見込み客の識別:リード認定:これは、潜在的な顧客を特定し、リードとして認定する初期段階です。この段階では、アカウント情報は必須ではないため、営業チームは完全な顧客の詳細を必要とせずに見込み客を獲得できます。この時点では製品カタログはオプションですが、リード品目はカタログアイテムを参照して、製品を早期に可視化し、認定作業を支援できます。
    2. 予約注文の認定:リードが機会に変換され、特定の顧客にリンクされた正式な営業活動が確立されます。機会レコードは、顧客のニーズとコンテキストに合わせて調整された製品品目を使用して作成されます。この段階で、オポチュニティを顧客アカウントにリンクする必要があります。製品カタログはオプションのままですが、使用すると、特定のカタログアイテムと暫定的な価格見積もりを参照できます。これにより、後の段階での詳細な価格設定と構成をサポートする製品構成フレームワークが確立されます。
    3. 販売契約の作成/構成、価格設定、見積もり:このステージは、2 つの並列パスが双方向の関係で機能する重要な岐路を表し、商用条件と詳細な価格設定の間の継続的なインタラクションと調整を可能にします。これら 2 つのパスの間の双方向矢印は継続的なやり取りを示しており、契約の商業条件の更新が見積もりの価格設定に反映され、その逆も同様です。
      • 構成、価格設定、見積もり:詳細な商用構成、価格設定、および実現可能性検証を処理して、提案されたソリューションを確実に提供できるようにします。実現可能性の結果により、オファーの適格性、互換性、および価格が決定されます。アカウントは完全な構造と階層を持つ必須であり、すべてのアカウントの場所情報を指定する必要があります。サイトレベルの製品構成は各子アカウントで行われ、販売契約のグローバル SLA が自動的に適用されます。オファーは確認済みの価格設定で構成され、承認または価格設定再設定アクティビティが完了します。見積もりバージョンは、反復的な絞り込みに対応します。見積確認ではサマリードキュメントが生成され、契約の作成に進む前に法的署名が必要です。
      • 販売契約を作成:商用枠組みを確立し、後続のすべての見積と顧客関係全体を規定する契約条件を交渉します。合意は、今後の見積もりの参照です。顧客アカウントは法務レベルで必須であり、製品カタログも必須です。グローバルレベルのサービスに依存しない SLA は、すべてのサービス契約にカスケードされるネゴシエーションされます。パートナーサービスの契約条件もこのレベルで交渉されます。
        注:
        これは、既存の顧客が新しい見積もりを作成する場合に適用されます。この場合、既存の契約が参照として使用され、すぐに見積もりが生成されます。
    4. 契約管理販売契約の作成:契約は販売契約またはサービス契約にすることができます。
      • 販売契約:見積確認後の販売契約は、顧客とサービスプロバイダーの間の法務拘束力のある商業契約を表します。続行する前に見積もりの確認が必須であり、子レベルの連絡先を持つアカウントを確立する必要があります。販売契約には見積品目が直接反映され、確認済みの商用構成、価格設定、条件が取り込まれます。
      • サービス契約:エンタイトルメントとサービスレベルコミットメントを含む非営利構成を処理する、確認後の契約上の合意を表します。エンタイトルメントは必須であり、製品オファリング (PO) タイプとしてモデル化され、販売契約で確立されたグローバル SLA に従う必要があります。サービス契約は、ルーティングタイプ、アクセスタイプ、POP 冗長性要件などの特定の見積品目構成に基づいて、子アカウントまたはサイトレベルで作成されます。
    5. 注文の送信:注文により、すべての商用および非商用構成が、検証済みのすぐに履行可能なパッケージに統合されます。請求プロファイルを含むアカウント情報は必須です。注文ヘッダーと明細品目は見積もりを直接反映し、トレーサビリティを維持します。商用の変更は見積もりを再オープンする必要がありますが、非商用の変更は注文で直接行われます。注文は承認前に検証されます。
    6. 注文の承認:送信時に、履行を開始する前に、注文の財務的および運用上の検証が行われます。製品インベントリは作成されますが、非アクティブなままになり、正常に完了するのを待ってからアクティブ化されます。これにより、インベントリレコードが存在しますが、サービスが成果物として確認されるまで可用性に影響を与えません。
    7. 注文の分解:注文の分解では、注文を実行可能なコンポーネントに分割して、オーケストレーションされた履行を行います。製品オファリングと製品仕様に対して注文品目が作成されます。ドメイン固有のオーケストレーションを有効にするために、製品仕様ごとにドメイン注文が作成されます。注文分解では、注文品目とドメイン注文の子注文が生成され、並列履行と順次履行の両方をサポートする階層構造が作成されます。
    8. サブフローとタスクをインスタンス化: サブフローはすべてのドメイン注文に対してインスタンス化され、フルフィルメントのための作業ストリームが作成されます。タスクは、フロールールと分解ルールに基づいてトリガーされます。タスクは、手動、API 主導型、オンサイト作業の場合は電気通信向けフィールドサービス管理 (FSMT)、複雑なプロジェクトの場合は電気通信向け戦略的ポートフォリオ管理 (SPMT) です。処理は、適切な順序付けのために依存関係と並行して行われるか、リソースを最適化するためにずらして行われます。

      ワークフローは、複雑なシナリオと例外を専門的に処理するために 2 つの並列パスに分岐します。

      • 特別なプロジェクトのインスタンス化:このパスは、プロジェクト管理の規律を必要とする注文に特化した処理を提供します。プロジェクトは、大規模なエンタープライズ展開、マルチサイトインストール、または調整された計画、リソース管理、正式なプロジェクト追跡を必要とする注文など、複雑な履行シナリオ向けに設計されたタスクで作成されます。
      • フォールアウト管理:このパスは、例外の管理と解決を処理します。注文で問題やエラーが発生した場合、または特別な介入が必要な場合、このパスはメインの履行フローを妨げることなく、適切な追跡、エスカレーション、解決を保証します。問題のある注文は個別に管理され、成功した注文は通常どおり処理が続行されます。
    9. 注文のクローズ:最終ステージでは、サブフローからドメイン注文、完全な注文に至るまで、各レベルでタスクを段階的にクローズすることで履行を統合します。すべてのタスクが完了すると、注文がクローズされ、サービスが有効になります。構成管理データベース (CMDB) との統合が確立され、監視、変更コントロール、インシデント管理などのライフサイクル管理が可能になります。

    完了すると、 通信事業向けセールス CRM ワークフローにより、顧客が使用できるアクティブ化されたサービス、履行された注文によるトランザクションの完了、ライフサイクルの管理とモニタリングのための CMDB 統合、定義されたエンタイトルメントを含むサービス契約、コンプライアンスを確保する完全な監査証跡、およびエンドツーエンドの可視化を提供する統合システムが得られます。