AWS パートナーセントラル API リファレンスが再構築されました。サポートされている API オペレーションの詳細については、 [AWS パートナーセントラル API リファレンス](https://docs.aws.amazon.com/partner-central/latest/APIReference/Welcome.html)を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# リードの操作
<a name="working-with-your-leads"></a>

## リードとは
<a name="what-is-a-lead"></a>

business-to-business (B2B) 販売では、リードは、企業の製品やサービスに関心を示しているが、まだ販売機会として完全に認定されていない潜在的な顧客を表します。リードは販売パイプラインの初期段階であり、アクティブな共同販売の機会に変換する前に、育成と認定が必要ですAWS。

がパートナーAWSと共有しているリードは、ウェビナーへの参加、キャンペーンへの参加、パートナーソリューションの問い合わせなどのカスタマーエンゲージメントシグナルに基づいています。これらのリードには、顧客の企業情報、ビジネス上の問題、エンゲージメントの詳細などの貴重なコンテキストが含まれており、パートナーが潜在的な機会に優先順位を付け、認定するのに役立ちます。

## リード招待の使用
<a name="working-with-lead-invitations"></a>

パートナーは、潜在的な顧客がパートナーソリューションまたはサービスに関心を示すAWSと、 からリード招待を受け取ります。リード招待プロセスにより、パートナーはエンゲージメントにコミットする前にリードを評価し、効率的なリソース割り当てと変換率の向上を実現できます。

### リード招待の受信
<a name="receiving-lead-invitations"></a>

AWSはリード招待を作成し、Selling API を通じてパートナーと共有します。新しいリード招待が利用可能になると、 はリードコンテキストを含むエンゲージメント招待を適格なパートナーAWSに送信します。

パートナーは Amazon EventBridge を使用して`Engagement Invitation Created`イベントをモニタリングする必要があります。このイベント通知には、 に設定された `payloadType`フィールドが含まれており`LeadInvitation`、パートナーはリードの招待を機会の招待と区別できます。イベントを受信すると、パートナーは招待の詳細を取得してリードを評価できます。

### リード招待の一覧表示
<a name="listing-lead-invitations"></a>

パートナーは、 `ListEngagementInvitations` API アクションを使用してすべてのリード招待を表示できます。このアクションは、呼び出し元のプリンシパルが送信者または受信者のいずれかである招待を取得します。

リードの招待を特にフィルタリングするには、パートナーは値 の`payloadType`フィルターを使用する必要があります`LeadInvitation`。このフィルターにより、結果からの機会の招待を除き、リードの招待のみが返されます。

リードの招待は、次の状態になります。
+ **保留中**: パートナーの承諾または拒否待ち
+ **承諾:** パートナーは招待を承諾し、完全なリード詳細へのアクセスを取得しました
+ **拒否:** パートナーは招待を拒否しました
+ **有効期限切れ**: 招待がアクションなしで有効期限を過ぎました

## リード招待の評価
<a name="evaluating-lead-invitations"></a>

リード招待を受け入れる前に、パートナーは `GetEngagementInvitation` API アクションを使用して詳細な招待情報を取得する必要があります。これにより、情報に基づいた承認または拒否の決定を行うための重要なコンテキストが提供されます。

リード招待ペイロードには以下が含まれます。

**顧客情報 (事前承諾可能):**
+ 会社名、業界、国
+ ウェブサイトの URL
+ 市場セグメント (エンタープライズ、ラージ、ミディアム、スモール、マイクロ)
+ AWS成熟度レベル (評価、単一アカウント、マルチアカウント)

**顧客とのやりとり:**
+ ソースタイプとキャンペーン情報
+ カスタマーアクションの実行 (フォームの完了、ウェビナーへの参加など)
+ 顧客が提供するビジネス上の問題の説明
+ ユースケースカテゴリ
+ 問い合わせタイトル (BANT 認定の権限コンテキストを提供します)

**重要**  
顧客の連絡先情報 (名前、E メール、電話番号) は、招待段階では表示されません。連絡先情報は、招待を承諾した後にのみ利用可能になり、顧客のプライバシーを確保し、リードファームの動作を防止します。

## リード招待の承諾
<a name="accepting-lead-invitations"></a>

パートナーがリードを追及することを決定した場合、`AcceptEngagementInvitation`API アクションを使用して招待を受け入れる必要があります。このアクションは、パートナーをエンゲージメントに追加し、顧客の連絡先情報を含むリードの詳細全体へのアクセスを許可します。

承諾後:
+ パートナーはエンゲージメントのメンバーとして追加されます
+ 顧客の連絡先情報がエンゲージメントリードコンテキストを通じて表示される
+ リードは、AWSシステムでパートナー認定リード (PQL) に分類されます。
+ リードがパートナーのアクティブなリードリストに表示される
+ パートナーはリードの育成と顧客からの問い合わせの確立を開始できます

パートナーは、招待`AcceptEngagementInvitation`ごとに を呼び出すことで、複数のリード招待をプログラムで受け入れることができるため、高品質のリードを効率的に一括処理できます。

## リード招待の拒否
<a name="rejecting-lead-invitations"></a>

リードがパートナーの能力、キャパシティ、またはビジネスフォーカスと一致しない場合、パートナーは `RejectEngagementInvitation` API アクションを使用して招待を拒否できます。リードの招待を拒否する場合、パートナーはリードのルーティングとマッチングAWSの改善に役立つ拒否理由を提供する必要があります。一般的な拒否理由は次のとおりです。
+ 地理的カバレッジの欠如
+ ユースケースの技術的な専門知識が不十分
+ 現在の容量の制約
+ 顧客業界の不一致
+ 予算のずれ

拒否後:
+ リードがパートナーの保留中の招待キューから削除される
+ 顧客の連絡先情報がパートナーと共有されることはありません。
+ リードは、AWSシステムでパートナー拒否リード (PRL) として分類されます。
+ 招待は、パートナーの拒否された招待リストに表示されたままになり、参照できます。

拒否されたリードは、顧客の同意要件が満たされていれば、他のパートナーへの再割り当ての対象となる場合があります。

## 承認されたリードの管理
<a name="managing-accepted-leads"></a>

リード招待を承諾すると、パートナーは完全なリード情報にアクセスし、顧客関係を育み、認定段階を通じてリードを追跡できます。

### リードの詳細の表示
<a name="viewing-lead-details"></a>

パートナーは`GetEngagement`、 API アクションを使用して完全なリードの詳細にアクセスします。エンゲージメントには、顧客とのインタラクションに関する包括的な情報を含むリードコンテキストが含まれていますAWS。

リードコンテキストには以下が含まれます。

**Customer Profile を完了する:**
+ 元の招待のすべての会社情報
+ すべての顧客とのやりとりの完全な連絡先情報 (名前、E メール、電話、役職)
+ AWS成熟度レベルと市場セグメント

**インタラクション履歴:**
+ 複数のカスタマータッチポイントを 1 つのエンゲージメントに統合
+ 各インタラクションには、ソース情報、顧客アクション、ビジネス上の問題、連絡先の詳細が含まれます。
+ インタラクションは時系列で一覧表示され、完全なカスタマージャーニービューを提供します。

**資格ステータス:**
+ リード認定の現在の状態 (非認定、認定、非認定、またはカスタムステータス)
+ パートナーは、認定プロセスを進めるにつれてこのステータスを更新できます。

この包括的なビューにより、パートナーは各やり取りを個別のリードとして扱うのではなく、複数のAWSキャンペーンやタッチポイントにわたる顧客のエンゲージメント履歴全体を把握できます。

### アクティブなリードの一覧表示
<a name="listing-active-leads"></a>

パートナーは、`contextType`フィルターを に設定して `ListEngagements` API アクションを使用して、すべてのアクティブなリードを取得できます`Lead`。これにより、パートナーがメンバーであり、エンゲージメントにリードコンテキストが含まれているエンゲージメントが返されます。

リストレスポンスには、次のような重要な情報が含まれます。
+ エンゲージメント ID とタイトル
+ 顧客の会社名
+ 現在のエンゲージメントスコア
+ 適格ステータス
+ インタラクションの数
+ 作成と変更のタイムスタンプ

パートナーはこのリストを使用して、ダッシュボードの構築、リードパイプラインの状態の追跡、注意が必要なリードの特定を行うことができます。

### Prospecting Insights によるリードの強化
<a name="prospecting-leads"></a>

パートナーは、受け入れられたリードをAWSインサイトで強化し、アウトリーチに投資する前に優先順位を付けて認定することができます。エンリッチメントは、プロスペクティングタスクを通じて非同期的に実行されます。これにより、AWS派生シグナルとのリードエンゲージメントが強化され、認定の決定をサポートします。

**プロスペクティングタスクの開始**

パートナーは `StartProspectingFromEngagementTask` API アクションを使用してエンリッチメントを開始します。このアクションは、1 回のリクエストで最大 100 個のエンゲージメント識別子を受け入れるため、パートナーはリードをバッチで強化できます。タスクは非同期的に実行され、パートナーが進行状況を追跡するために使用する `TaskId`と `TaskArn` をすぐに返します。最初の `TaskStatus`は、`PENDING`、、`IN_PROGRESS``COMPLETED`、または のいずれかです`FAILED`。

パートナーはオプションで、タスク`TaskName`にラベルを付ける と`ClientToken`、再試行全体でべき等性を確保するための を提供できます。

**結果のポーリング**

プロスペクティングは非同期であるため、パートナーは API `GetProspectingFromEngagementTask`アクションを使用して完了をポーリングし、開始時に `TaskId`が返されます。レスポンスは、送信された各識別子の全体的なタスクステータスとエンゲージメントごとの結果をレポートします。

各エンゲージメントは個別に処理されるため、個々のエンゲージメントは同じタスク内の他のエンゲージメントに影響を与えずに成功または失敗する可能性があります。エンゲージメントごとに、結果には以下が含まれます。
+ **エンゲージメント識別子**: 処理されたエンゲージメント。
+ **ステータス**: `PENDING`、`IN_PROGRESS`、`COMPLETED`、または `FAILED`。
+ **コンテキスト識別子のプロスペクティング**: エンゲージメントが正常に処理されたときに入力されます。この識別子は、エンゲージメントに追加された拡張されたプロスペクティングコンテキストを参照し、後続のオペレーションで使用できます。
+ **理由コードとメッセージ**: エンゲージメントが失敗した場合にのみ入力され、列挙された障害コードと、推奨される復旧ステップを含む人間が読める説明を提供します。

**複数のタスクのモニタリング**

多くのリードのエンリッチメントを追跡するために、パートナーは `ListProspectingFromEngagementTasks` API アクションを使用します。このアクションは、発信者のアカウントによって開始されたすべてのプロスペクティングタスクを一覧表示し、設定可能なソートを使用して、タスク識別子、タスク名、または開始時間範囲によるオプションのフィルターをサポートします。レスポンスはページ分割されます。各レスポンス`NextToken`の値を使用して後続のページを取得します。

エンリッチメントが正常に完了すると、AWSインサイトがプロスペクティングコンテキストとしてエンゲージメントに追加されます。パートナーは で強化された詳細を取得し、それ`GetEngagement`を使用してリードの資格ステータスを設定し、変換に進む原因を決定できます。

### リード情報の更新
<a name="updating-lead-information"></a>

パートナーはリードを育成し、追加情報を収集すると、 `UpdateEngagementContext` API アクションを使用してリードの詳細を更新できます。このアクションにより、パートナーはエンゲージメント内のリードコンテキストを変更できます。

パートナーは以下を更新できます。

**認定ステータス:** パートナーは、内部認定プロセスを進めるにつれて認定ステータスを更新する必要があります。
+ **非修飾**: リードを受け入れた後のデフォルトステータス。リードが評価を必要とすることを示します
+ **認定**済み: リードが認定基準を満たし、オポチュニティへの変換の可能性が高い
+ **失格**: リードが基準を満たしていないか、パートナーのソリューションに適していない
+ **カスタム状態**: パートナーは、内部プロセスに合わせて独自の認定状態を定義できます。

**リードメタデータ: **パートナーは、認定および育成プロセスに関連する追加情報を追加または更新できます。

認定ステータスを更新すると、パートナーはリードの進行状況を追跡し、正確なパイプラインレポートを生成し、オポチュニティに変換できるリードを特定するのに役立ちます。

### AWS更新のモニタリング
<a name="monitoring-aws-updates"></a>

AWSは、新しいカスタマーエンゲージメントシグナルまたは洗練されたエンゲージメントスコアに基づいてリード情報を更新する場合があります。がエンゲージメントAWSを更新すると、パートナーは Amazon EventBridge 経由で`Engagement Updated`イベントを受け取ります。

これらの更新には以下が含まれます。
+ 新しい顧客アクティビティに基づいてエンゲージメントスコアを改善
+ 新しいキャンペーンやタッチポイントからの追加のカスタマーインタラクション
+ 更新された顧客情報

パートナーはこれらのイベントをモニタリングし、 `GetEngagement`を呼び出して最新のリードの詳細を取得する必要があります。これにより、パートナーはリードの優先順位付けと育成に関する最新情報を得ることができます。

`Engagement Updated` イベントには `contextTypes`フィールドが含まれており、パートナーは特にリード (リードコンテキストを使用したエンゲージメント) をフィルタリングできます。

## リードをオポチュニティに変換する
<a name="converting-lead-to-opportunity"></a>

リードが認定され、真剣な購入の意図を示すと、パートナーはリードを正式な共同販売コラボレーションの機会に変換できますAWS。この変換は、リード育成 (主にパートナー主導) からオポチュニティ管理 (コラボレーション) への移行を示しますAWS。

### 推奨されるアプローチ: Convenience API
<a name="recommended-approach-convenience-api"></a>

パートナーは、`StartOpportunityFromEngagementTask`便利な API アクションを使用して、機会の作成とリンクプロセスを合理化できます。このタスク API は、複数のアクションを自動的にオーケストレーションします。

1. リードコンテキストからの予備情報を含むドラフトオポチュニティを作成します。

1. リソーススナップショットを介してソースエンゲージメントにオポチュニティをリンクします

1. CustomerProject コンテキストをエンゲージメントに追加します

この便利な方法により、必要な API コールの数が減少し、適切な属性追跡が保証されます。このアプローチを使用するパートナーは、引き続き以下を行う必要があります。
+ を使用してオポチュニティの詳細を入力する `UpdateOpportunity`
+ を使用したパートナーソリューションの関連付け `AssociateOpportunity`
+ 準備`StartEngagementFromOpportunityTask`ができたら、 を使用してオポチュニティを送信する

コンビニエンス API は、統合の複雑さを最小限に抑えたい、自動化されたlead-to-opportunityワークフローを持つパートナーに特に役立ちます。

### 代替アプローチ: Step-by-step API
<a name="alternative-approach-step-by-step"></a>

**ドラフトオポチュニティの作成**

リードを変換する最初のステップは、 `CreateOpportunity` API アクションを使用してドラフトオポチュニティを作成することです。これにより、 を `Lifecycle.ReviewStatus`に設定してオポチュニティが作成されます`Pending Submission`。この段階では、オポチュニティはまだ検証AWSのために に送信されていません。

パートナーは、リードの育成中に収集された情報を機会に入力する必要があります。
+ 顧客アカウントの詳細
+ プロジェクト情報とビジネス上の問題
+ 予想される顧客支出
+ ターゲット終了日
+ 認定中に収集されたその他の関連する詳細

ドラフトオポチュニティにより、パートナーは送信前に完全な情報を準備できるためAWS、承認率が高く、検証が迅速になります。

**オポチュニティをリードエンゲージメントにリンクする**

ドラフトオポチュニティを作成した後、パートナーは `CreateResourceSnapshot` API アクションを使用してソースリードエンゲージメントにリンクする必要があります。このステップは、以下にとって重要です。
+ **帰属の追跡**: リードの招待からオポチュニティクローズまでの出所チェーンを確立し、マーケティングキャンペーンとリードソースの正確な ROI 計算を可能にします。
+ **変換メトリクス**:AWSとパートナーはlead-to-opportunity変換率を測定し、成功したリードソースを特定できます。
+ **コンテキストの保存**: 元のインタラクションやエンゲージメントシグナルを含む、カスタマージャーニーの完全な履歴を維持します。

リソーススナップショットを作成するときに、パートナーは以下を指定します。
+ エンゲージメント ID (ソースリードエンゲージメント)
+ オポチュニティ識別子
+ リソースタイプ (オポチュニティ)

このアクションは、リードがアクティブなオポチュニティに変換されたことを示す CustomerProject コンテキストをエンゲージメントに自動的に追加します。エンゲージメントに、元のリードコンテキスト (保存履歴) と新しい CustomerProject コンテキスト (アクティブなオポチュニティを示す) の両方が含まれるようになりました。

**オポチュニティの詳細の完了**

オポチュニティが作成されてリンクされると、パートナーは送信前に追加のオポチュニティ要件を完了する必要があります。詳細については、 `AssociateOpportunity` API アクションを参照してください。

プロジェクトの詳細の更新: パートナーは `UpdateOpportunity` API アクションを使用して、プロジェクト情報、顧客のビジネス上の問題、予想される支出、およびリード認定中に収集されたその他の関連の詳細を絞り込むことができます。

**オポチュニティの送信**

必要な情報がすべて完了すると、パートナーは`StartEngagementFromOpportunityTask`コンビニエンス API を使用してAWS検証の機会を送信します。これにより、オポチュニティがドラフトステータスからAWSレビュープロセスに移行されます。

検証要件: エンゲージメントには、送信前に CustomerProject コンテキストが必要です。このコンテキストは、 `CreateResourceSnapshot` を使用してオポチュニティをエンゲージメントにリンクするときに自動的に作成されます。このコンテキストがない場合、送信は失敗します。

送信後:
+ オポチュニティの への`Lifecycle.ReviewStatus`変更 `Submitted`
+ リードは、AWSシステムのパートナー販売認定リード (PSQL) に分類されます。
+ AWSは、機会の詳細が正確で完全であることを確認するために検証を開始します
+ レビュープロセスが完了するまで、オポチュニティに変更を加えることはできません

その後、オポチュニティは「オポチュニティの操作」ドキュメントで説明されている標準検証ワークフローに従い、レビュー中、アクションが必要、承認済み、または失格などの状態に進みます。