Duo Agent Platform の POV とトライアル

1. DAP トライアル

DAP トライアルは、使用量を考慮した POV の取り組みです。標準的な機能トライアルよりも、適格性の確認、準備、活用支援、クレジットのガバナンス、使用量の監視、トライアル後の意思決定の管理を綿密に行う必要があります。

DAP の「トライアル」と DAP の「POV」は、営業ステージのフローと同じように区別します。適格性の確認とディスカバリー（Stage 0/1、AE 主導でビジネスケースを探る）→ スコープの設定（Stage 2、AE + SA が協力してソリューションのディスカバリー、成功基準、初期の Customer Success Plan に取り組む）→ 評価（Stage 3）と進み、評価でトライアル（機能重視、3-in-30 は不要）または POV（ソリューション重視、3-in-30 を適用）に分かれます。スコープ設定と評価の間に AI Strategy Workshop を行うかどうかは任意ですが、顧客のユースケース、規模、成功基準がまだ明確でない場合は実施を推奨します。

flowchart LR
  A["Qualification & Discovery (Stage 0/1) - AE"] --> B["Scoping (Stage 2) - AE + SA"]
  B --> C{"AI Strategy Workshop needed?"}
  C -->|Yes| D["AI Strategy Workshop"]
  C -->|No| E["Evaluation (Stage 3)"]
  D --> E
  E --> F["Trial (features-oriented)"]
  E --> G["POV (solution-oriented, 3-in-30)"]

1.1 DAP トライアルの利用資格と開始条件

1.2 DAP トライアルの開始条件

評価クレジットを申請する前に、AE と SA は次を確認する必要があります。

• 顧客に有効な有料 Premium または Ultimate サブスクリプションがあり、そのサブスクリプション識別子を申請に記載すること。
• 評価と商業上の成果を追跡する進行中の商談があること。
• SA によるスコープ設定の話し合いを実施済みであること。
• 顧客が評価者、チーム、責任者、意思決定者を明確にしていること。
• 顧客が明確なユースケースと成功指標を選定していること。
• 顧客がトライアル期間内に実行できる状態であること。
• 評価計画を顧客フォルダーに保存し、申請からリンクしていること。
• デプロイモデルとバージョンが対象要件を満たしていること。
• 評価クレジットのみを使用量の充当元とする予定の場合、それと競合する月額コミットメントや、有効になっているオンデマンド課金がないこと。
• Self-Managed の顧客が、現在のバージョン、クラウドライセンス、接続性、Runner、DAP の前提条件を満たしていること。
• セルフホストまたはオフラインの DAP について、別途アーキテクチャ、モデル、ライセンス、ネットワーク、サポートの計画があること。

既存のクレジット、または準備が整っていると検証済みの方法で、顧客が代表的な DAP フローを少なくとも 1 つ正常に実行できるようになるまで、DAP の評価期間を開始しないでください。

1.3 AE と営業担当者による DAP トライアルの申請方法

flowchart LR
  A["AE + SA scoping call - confirm users, use cases, dates"] --> B["Complete DAP evaluation plan + trial checks"]
  B --> C["Create Fulfillment issue - trial_credit_requests template"]
  C --> D["Post issue link via Slack workflow"]
  D --> E["SA Manager reviews and approves"]
  E --> F["Fulfillment / CDot provisions credits"]
  F --> G["Customer notified; trial clock starts"]

AE / 営業担当者は申請に責任を持ち、SA は技術計画に責任を持ちます。

1. 顧客と SA によるスコープ設定の話し合いを完了します。
2. 顧客固有の目標、ユースケース、参加者、日付、前提条件、成功基準を盛り込んだ DAP 評価計画を作成または更新します。汎用テンプレートを変更せずに顧客向けの計画として送付しないでください。
3. 次を検証します。有効な有料 Ultimate/Premium サブスクリプション（A-S###### ID）、月額コミットメント SKU や有効なオンデマンド課金がないこと、クラウドライセンスの確認済み（セルフマネージド）、バージョンが 18.9+（セルフマネージド）または 18.8.4+（Dedicated）であること。
4. 現行の Fulfillment テンプレートを使用してトライアルクレジット申請を作成します。
5. gitlab-org/fulfillment/meta の trial_credit_requests テンプレートから GitLab の Issue を作成し、タイトルを [A-XXXXXX] [Subscription Name], [Customer Name], [Total Credits Requested], [Date Requested For] として、次を含めます。
   • サブスクリプション名と ID、顧客名、AE と SA、Salesforce の Account へのリンク、Salesforce の DAP の Opportunity へのリンク、販売先担当者のメールアドレス、サブスクリプションの種類、合計シート数、申請クレジット総数、オフラインフラグ、顧客固有の評価文書。
   • 再トライアルまたは延長の場合: 前回のトライアル Issue へのリンク、理由コード、残りのクレジット、妥当性を検証した SA の氏名。
   • ユーザー、ユースケース、期間、デプロイモデル、GitLab のバージョン、前提条件、成功基準、開始 / 終了日、申請クレジット数で十分な理由。
6. 現行のトライアル申請ワークフローに申請を提出し、指定の Slack チャンネルにリンクを投稿します：#dap-trial-request。
7. 承認のエビデンスを申請に添付または記録します。
8. 承認とクレジット付与の状況が確認されるまで、開始日を約束しないでください。

1.5 SA manager による評価と承認のガイドライン

クレジットまたは延長を処理する前に、SA Leadership の承認が必要です。すべてを確認するか、適切な承認者が例外を明示的に文書化する必要があります。

• サブスクリプションが有効な有料の Premium または Ultimate であり、競合するオンデマンド課金が有効になっていないこと。
• セルフマネージドの顧客はクラウドライセンスを使用し、Dedicated の顧客は 18.8.4+ を使用していること。
• SA が評価計画（ユースケースと成功基準）を顧客の Drive フォルダーに保存し、その実行を確約していること。
• AE と SA が、提出前にユーザー数を 50 ユーザー未満に設定していること。
• オフライン / エアギャップの顧客は、クレジット申請ではなく $0 注文のために Deal Desk に案内していること。

再トライアルまたは延長では、クレジット数にかかわらず SA Manager（または SA Director/VP）の承認が必要です。承認前に、SA は、DAP のバグ、障害、顧客側の阻害要因、評価時間の不足といった正当な理由を検証し、前回のトライアルの評価後アンケートとフィードバックフォームが完了していることを確認する必要があります。

SA manager は、単に無料利用を求める申請ではなく、信頼でき、実行可能な評価を表す申請のみを承認してください。以下の必須行はすべて Yes であるか、例外が明示的に文書化され、適切なリーダーの承認を受けている必要があります。

1.5.1 SA manager の承認チェックリスト

申請が、汎用デモ、ディスカバリーの代替、更新のみの取り組み、適格性未確認の評価、コピーしたテンプレート、サポート対象外の環境、重複申請、正当化されていないクレジット数、顧客の確約の欠如、合意した計画を実行しなかったことだけを理由とする延長に該当する場合は、差し戻してください。

承認経路については、2,000 クレジット以下の初回申請と、その後の再トライアルを含む 5,000 クレジット以下の申請では、SA Manager、SA Director、または VP of Solutions Architecture の承認を使用します。5,000 クレジットを超える申請には CPMO の承認が必要です。100,000 を超える申請には、Fulfillment テンプレートで定義された CEO/CFO/CPMO レベルの承認が必要です。再トライアルと延長には、数量にかかわらず SA Leadership の承認が必要です。

次の場合は差し戻しまたは却下します。

• 申請が汎用的なデモ、ディスカバリーの代替、更新、または適格性未確認の初期段階の評価である。
• POV オブジェクト、信頼できる意思決定への道筋、明確な顧客側責任者、推進者、意思決定者、意思決定日のいずれかが欠けている。
• 評価文書が未変更のテンプレートである、またはユースケースや成功基準が欠けているか、測定できない。
• 顧客が、実行に必要として記載したユーザー、環境、プロジェクト、時間、アクセス、管理者の支援を用意できない。
• 申請が重複している、正当な再トライアルの理由がない、またはチームが合意した計画を実行しなかったために延長を求めている。
• ユーザー数、計画、期間、申請対象となる利用者によってクレジット数を正当化できない。
• トライアルにより、管理されていないセキュリティ、法務、データ、オフライン、運用上のリスクが生じる。

再トライアルと延長では、SA リーダーシップの承認と、正当な DAP の問題、障害、顧客側の阻害要因、評価時間の不足が適切な評価を妨げたことを検証した文書を必須とします。再トライアルの承認前に、前回の評価後の確認を必須とします。

1.6 クレジット付与のガイドライン

1.6.1 承認のしきい値とトライアル規模の設定

承認経路については、2,000 クレジット以下の初回申請と、その後の再トライアルを含む 5,000 クレジット以下の申請では、SA Manager、SA Director、または VP of Solutions Architecture の承認を使用します。5,000 クレジットを超える申請には CPMO の承認が必要です。100,000 を超える申請には、Fulfillment テンプレートで定義された CEO/CFO/CPMO レベルの承認が必要です。再トライアルと延長には、数量にかかわらず SA Leadership の承認が必要です。

クレジット数の算定と付与

1.7 トライアルクレジット付与のための CustomersDot アクセス

クレジット付与を許可されたマネージャーには、sales ロールを持つ CustomersDot Admin へのアクセスと、Okta グループ okta-cdot-prod-sales-admins のメンバーシップが必要です。

アクセスの手順:

1. 標準のアクセス申請プロセスで、必要な Okta グループのメンバーシップを申請または確認します。
2. Okta で CustomersDot Admin にサインインします。
3. Bonus trial wallets を使用して、クレジットを追加するか有効なクレジットを延長します。
4. サブスクリプション名、承認 Issue のリンク、クレジット数または延長日数、有効期限の選択、メモを入力します。
5. 成功メッセージ、ウォレットのレコード、顧客への通知、監査イベントを確認します。

ハンドブックでは、管理者専用の実装の詳細を重複して記載するのではなく、正式なアクセス申請と CustomersDot のランブックにリンクしてください。マネージャーに必要なロールがない場合は、クレジット付与を許可された担当者または承認済みの Fulfillment ワークフローを通して申請してください。

1.8 DAP の準備状況チェックリスト

30 日間の評価期間が始まる前に、次を確認します。

• サブスクリプションとクレジット: 有効な Premium または Ultimate サブスクリプション、対象となるクレジットプール、正しい日付と残高、意図しないオンデマンド課金がないこと。
• デプロイ: GitLab.com、Self-Managed オンライン、Self-Hosted、Offline のいずれかの方法を選択済みであり、サポート対象のバージョンとパッチレベルを確認済みであること。
• ネームスペースとアクセス: 専用の評価グループまたは同等のものがあり、パイロットのユーザーとプロジェクトを特定済みで、ロールとアクセスを検証済みであり、AI ネイティブの機能が意図した場所でのみ有効になっていること。
• 実行: Runner がオンラインで DAP フロー用の適切なタグが付いており、ネットワークとイメージへのアクセスが機能し、代表的な DAP フローが少なくとも 1 つ完了すること。
• ユースケース: 3 〜 5 つのユースケースを選択済みで、顧客固有のプレイブックを作成済みであり、前提条件とエビデンスを定義済みであること。
• 測定: 基準値と目標値を定義済みで、使用量と価値のダッシュボードを特定済みであり、中間・最終アンケートを予定に設定済みであること。
• サポート: カスタマーサポート窓口、アカウントチームへの連絡経路、Request for Help のエスカレーション経路について合意済みであること。
• ガバナンス: コラボレーションプロジェクトが存在し、POV レコードを関連付けており、キックオフ、定例のやり取り、最終報告がカレンダーに登録されていること。

1.9 DAP 実行チェックリスト — 申請からスコープ設定、終了まで

次の表は、評価計画のチェックリストの順序を保持し、標準的な POV ガバナンスのフィールドを追加したものです。SA は、次の通過条件に進む前に各行を完了済みとしてマークしてください。顧客向けの計画でも、同じ日付と確約事項を使用してください。

1.10 DAP の責任分担

1.11 購買決定権を持つ経営幹部への週次メールまたは Slack 更新テンプレート

トライアル期間中にこの更新を毎週送信する責任は AE/Rep が持ちます。SA と顧客側の推進者が技術的な内容を提供しますが、購買決定権を持つ経営幹部とのコミュニケーションに説明責任を負うのは AE/Rep です。メールと Slack で同じ構成を使用し、内容を簡潔かつ事実に基づくものにし、合意した POV 計画に結び付けます。

ページのソースコードを見る - ページの編集 - please contribute.