Add DAP bonus trial credit provisioning process to Fulfillment Guide

| Ultimate (including Duo Core) | Dedicated | Sales team | Customizable end date | Yes with $0 quote | NA |

| Ultimate with Duo Pro or Duo Enterprise | Dedicated | Sales team | Customizable end date | Yes with $0 quote | NA |

## DAP bonus trial credits

This section describes how Solution Architect (SA) managers and the Fulfillment team process GitLab Duo Agent Platform (DAP) bonus trial credit requests, and how the credits are provisioned, topped up, or extended from CustomersDot Admin. Use it as the reference when processing a [trial credit request](https://gitlab.com/gitlab-org/fulfillment/meta/-/blob/master/.gitlab/issue_templates/trial_credit_requests.md) for an existing Premium or Ultimate customer evaluating DAP.

Bonus trial credits are added to a subscription-level `bonus_trial` wallet in CustomersDot. They are consumed first (highest burndown priority), do not reset monthly, cannot go negative, and expire 30 days from the day they are provisioned by default.

### Eligibility prerequisites

Before provisioning, confirm the request meets the prerequisites captured in the request issue:

- The customer has an active paid **Premium or Ultimate** subscription (for example `A-S00330622`).

- Self-Managed customers must be on cloud licensing, and Self-Managed or Dedicated customers must be on version 18.9 or higher for usage billing and bonus trial credits to work in the usage dashboards.

CustomersDot validates eligibility at provisioning time: the subscription must be current (not cancelled or expired) and must have an eligible Premium or Ultimate usage-billing base charge. Provisioning is skipped if these checks fail.

> Bonus trial credits are **not applicable for offline customers**. Offline customers cannot consume usage-billed bonus trial credits, so DAP trials for them are handled as a **$0 order** that must be set up and approved through Deal Desk instead. See the [trial credit request template](https://gitlab.com/gitlab-org/fulfillment/meta/-/blob/master/.gitlab/issue_templates/trial_credit_requests.md) for the distinction between a bonus trial credit request and a $0 order.

### Approval matrix

The approval required depends on the request type and credit amount. The GitLab issue link itself serves as approval at the lowest tier, so we provision on the day of the request. For any tier that requires approver sign-off, a screenshot of the Slack approval must be added to the GitLab issue. If the requestor has not already added it, the provisioner adds it before provisioning.

#### First-time trial requests

| Max credits per customer | Approval required | Reporting |

| ------------------------ | ----------------- | --------- |

| Up to 1,000 | None (the GitLab issue is the approval) | Notify in the dedicated Slack channel once the issue is created |

| 1,001 to 10,000 | Deal Strategy (Carli Nodari, Guru Kannan, Alessandra Pianti) | Tag approvers, then add a screenshot of the Slack approval to the issue |

| Greater than 10,000 | CPMO (Manav Khurana) | Tag for approval, then add a screenshot of the Slack approval to the issue |

| Greater than 100,000 | CEO/CFO/CPMO (Bill Staples, Jessica Ross, Manav Khurana) | Tag one approver, then add a screenshot of the Slack approval to the issue |

#### Retrial and extension requests

All retrial and expiration-extension requests require **SA leadership approval** (SA Manager, SA Director, or VP of Solutions Architecture), regardless of credit amount. A Solution Architect must first validate that a legitimate issue (DAP bug, outage, or customer-side blocker) prevented proper evaluation, and the previous trial's post-evaluation must be complete. The standard extension duration is 30 days.

### Provisioning bonus trial credits (first-time and top-up)

Use this workflow for first-time trial credit requests and for top-up requests that add new credits to an existing wallet. Adding new credits automatically extends the expiration date of any existing non-expired credits in the wallet.

1. Confirm the eligibility prerequisites and the approval requirements above are met (GitLab issue link present, and Slack approval screenshot attached when the tier requires approver sign-off).

1. Log in to [CustomersDot Admin](https://customers.gitlab.com/admin/).

1. Navigate to **Sales** > **Bonus Trial Wallets**.

1. Select the **Add Credits** tab to open the provisioning form and complete the required fields:

   - **Subscription name**: the subscription to provision credits for (for example `A-S00330622`).

   - **Approval link**: the GitLab.com trial credit request issue link. The form validates this is a GitLab.com issue URL.

   - **Credit amount**: a whole number greater than 0.

   - **Expiration date**: choose the expiration option (see below).

   - **Additional notes** (optional, up to 500 characters).

1. Select **Save**. CustomersDot creates the credits in the `bonus_trial` wallet, records an audit event tied to your admin user and the approval link, and sends a `bonus trial credits provision notification` email to the subscription's `SoldTo` contact.

#### Choosing the expiration date for a top-up

The provisioning form offers two expiration options, which determine the effective expiration for both the new credits and any existing non-expired credits:

1. **Default (30 days)**: new credits expire 30 days from today. If the wallet already has active credits with a later expiration date, both the new and existing credits use that later date. This is the standard option and is how a top-up **with an extended date** works.

1. **Use existing expiration**: new credits adopt the existing active credits' expiration date, so the expiration is unchanged. Use this for a top-up on the **same date** when the customer only needs more credits within the current trial window. This option is only available when active credits already exist.

In both cases the system never shortens an existing expiration. The effective expiration is the later of the requested date and the latest existing active expiration.

> If the provisioning happens during the monthly billing-cycle transition window (the 1st of the month, 00:00-06:00 UTC), CustomersDot automatically schedules the provisioning to run after the previous month's consumption completes rather than provisioning immediately.

### Extending credit expiration by days only (no new credits)

Use this workflow when the customer needs more time but no additional credits. This is processed directly on the Bonus Trial Wallets page without adding credits, and still requires SA leadership approval per the retrial and extension rules above.

1. Confirm SA leadership approval is recorded in the issue (screenshot of Slack approval attached).

1. Log in to [CustomersDot Admin](https://customers.gitlab.com/admin/) and navigate to **Sales** > **Bonus Trial Wallets**.

1. Select the **Extend Credits** tab to open the extension form and complete the required fields:

   - **Subscription name**: the subscription to extend credits for (for example `A-S00330622`).

   - **Approval link**: the GitLab.com extension request issue link. The form validates this is a GitLab.com issue URL.

   - **Add days**: select an extension of **7, 14, or 30 days** (7 days is the default).

1. Select **Save**. The existing credit balance remains unchanged; only the expiration date of the active credits is moved out. The system only extends expiration and will not shorten it.

### After provisioning

1. Tag the requestor in the GitLab issue to confirm the credits or extension have been processed.

1. Close the GitLab issue.

1. Notify in the Slack thread that the credits have been provisioned.

## Storage Enforcement

> You can access the [internal handbook page](https://internal.gitlab.com/handbook/engineering/fulfillment/namespace-storage-enforcement/) for more details about the storage enforcement.