Product Catalog Guide
Change Management and SDLC Process
For SOX/audit purposes, all changes to the Zuora Billing product catalog must be properly tested, adhering to Business Technology Change Management policies and the Software Development Lifecycle Process for Finance Systems.
How to request the creation or modification of a SKU
Before submitting a SKU request issue, please read and complete all steps of the Product Launch Process. This will help ensure that the product launch is done efficiently and effectively. A business sponsor or program manager should be assigned and have the business requirements clearly defined before creating an issue for SKU creation or modification.
There are 3 issue templates in this directory that the Business Sponsor can choose from to help log their SKU request.
- To create or update a Professional Services SKU:
- Open an issue in this directory using the
CM: Add_New_PS_SKU
template - Follow the steps from the How to Create New or Update a SKU section of this handbook page
- Open an issue in this directory using the
- To create or update a Non-Professional Services SKU:
- Open an issue in this directory using the
CM: Add_New_SKU
template - Follow the steps from the How to Create New or Update a SKU section of this handbook page.
- Open an issue in this directory using the
- To retire an existing SKU:
- Open an issue in this directory using the
CM: Retire_SKU
template - Follow the steps from the How to Retire a SKU section of this handbook page
- Open an issue in this directory using the
How to Create New or Update a SKU
It is the Business Sponsor’s responsibility to provide information and obtain required approvals for the SKU changes being requested. Steps 1-4 of the SKU issue template must be completed and have required approvals obtained before the SKU can be configured. Please assign the SKU Request issue to yourself by clicking on the Edit
button on the right-hand panel of the issue.
Generally, it takes 6-8 weeks for a new SKU to be created. This timing includes 4 major steps. This flow outlines the steps to create the SKU in our Enterprise Applications (Salesforce, Zuora) & CDOt (webstore). This does not include the time it takes to provision customer access to features in GitLab.
- SKU requirements gathering and cross-functional approvals
- Enterprise Apps SKU build & test data generation
- User acceptance testing and cross-functional approvals
- SKU deployment
Step 1. SKU Requirements Gathering & Cross Functional Approvals
Owner: Business Sponsor or TPM if assigned
Expected Timing: 2-3 weeks
Step 1a. Product Information
This section covers business and technical requirements for product offerings. Most of these questions will have been answered if all steps of the Product Launch Process were completed. Please answer these to the best of your ability in the SKU issue.
General Overview/Business Requirements
Overview of Product/Service
- Provide a general overview of the SKU and the value provided to the Customer.
Desired Go-Live Date
- Provide a specific date of when the new SKU is expected to be used.
- Please note the date helps with intake and prioritization of the request and does not necessarily mean the SKU will be ready for sale by this date
- Remember that from requirements to deployment, a SKU takes 6-8 weeks to create.
Product/Service Type for Quoting
- Identify whether the SKU is a base product (i.e. Premium, Ultimate, Dedicated, etc.) or an add-on product (i.e. Storage, Professional Services, etc.)
How will the SKU be sold to Customers?
- Identify whether customers can purchase the SKU without assistance from the sales team or will customers purchase with assistance from a sales rep
- Cross-functional Approval from Fulfillment required for Self-servce
- If required, the SKU can be sold both Self-serve and Sales-assisted
What GitLab product features should this SKU enable?
- Identify which GitLab product feature(s) need to be enabled for this SKU
- Cross-functional Approval from Fulfillment required for any product features
What type of GitLab instance will this SKU support? Please check any applicable boxes below:
- Identify which GitLab instance(s) can purchase this SKU.
- If required, multiple options can be selected
Will we have restrictions on the type of subscriptions (i.e. SaaS, Self-Managed, Premium, Ultimate, etc.) this product offering can be added to?
- Identify whether only specific types of customers can purchase this SKU
- Cross-functional Approval from SalesOps required for any restrictions
- Please note this will increase time for a SKU to be available for quoting as additional development work outside of configuring the SKU will be required
Are there restrictions to the minimum or maximum quantity of this SKU?
- Identify whether customers can only purchase this SKU if they meet a minimum or maximum requirement (i.e. number of seats, storage, licenses, etc.)
- Cross-functional Approval from SalesOps required for any restrictions
- Please note this will increase time for a SKU to be available for quoting as additional development work outside of configuring the SKU will be required
Will renewals be handled via the webstore (self-service) or only by a sales rep (sales-assisted)?
- This only applies to recurring products as subscriptions renew with recurring SKUs if it is not removed prior to renewal
- Identify whether customers can renew their subscription without assistance from the sales team or if the customer must go through a sales rep
- If required, both options can be selected
Should we allow customers to automatically renew with this SKU?
- This only applies to recurring products as subscriptions renew with recurring SKUs if it is not removed prior to renewal
- Identify whether customers should be allowed to automatically renew their subscription with this SKU
Will this SKU replace any of GitLab's current product offerings?
- Identify whether this SKU will be replacing a current SKU being sold to customers
- If this new SKU replaces a current SKU, please follow open an issue in this directory to retire the current SKU using the
CM: Retire_SKU
template (see How to Retire a SKU
SKU Configuration Requirements
Rate Plan Name
- This is the customer facing name of the SKU. The
Rate Plan Name
should be in the format ofDeployment type - Name
. Some examples:
Self Managed - Ultimate
SaaS - Ultimate
Dedicated - Ultimate
- This is the customer facing name of the SKU. The
Rate Plan Charge Description
- For webstore checkout, this is a short description displayed to customers
- For sales-assisted, this is a short description of the product displayed when quoting
- A URL to the service description is typically included here for professional services SKUs
Charge Type:
- There are 3 charge types. Select the correct one for your use case based on the explanation below:
- Recurring Charges: a charge that is billed on a regular basis until removed from a Subscription.
- One-Time Charges: a charge that is only billed once.
- Usage Charges: a charge that is billed in arrears based on consumption.
- Please note that if
Usage
is selected, fill out theAny Included Units?
section to identify if there will be any units included in the charge, for example: phone plan with 1000 included minutes with overage fees after.
Charge Model:
- There are 4 charge models. Select the correct one for your use case based on the explanation below:
- With
Per Unit Pricing
the product/service is priced per unit of measure (UOM). - With
Flat Fee
the product/service is a single fixed price per purchase. - With
Tiered
the product/service is progressively priced as volume changes. - With
Volume
the product/service is priced based on the volume purchased.
Unit of Measure (UOM):
- Select an existing UOM to be used for this SKU; the most common unit of measure is
Seat
- Select
Other
if your need is related to a different UOM and name it - If your product will be a
Flat Fee
Charge Model, this section is not applicable
- Select an existing UOM to be used for this SKU; the most common unit of measure is
Charge Timing:
How is the Customer expected to pay?- Select how the Customer is expected to pay for this SKU
List Price:
- Add the dollar amount price of the SKU. If a unit of measure is associated to this SKU, explain the dollar amount per UOM (Example: $250/seat/quarter)
Revenue Recognition Requirements
- Assign Makesh Subramanian
@msubramanian
for input on the Invoicing, Revenue, and Custom Fields sections - This is required to configure the SKU and properly recognize revenue
Taxation Requirements
- Assign Sally Tian
@stian13
for input on the Taxation section and include a service description to help them identify the correct tax code to use - This is required to configure the SKU and properly collect sales tax
Data Requirements
- Assign Israel Weeks
@iweeks
for input on the Product Tier, Delivery, and Deployment fields for this offering based on the definitions in the GitLab Handbook - This is required to configure the SKU and ensure data integrity
Step 1b. Cross-functional Approval For Pricing and Non-Standard Requests
Pricing approval ALWAYS required:
- Provide a link to the Cost of Goods Sold (COGS) spreadsheet (Make a copy of this template)
- Provide a justification if project margins are below 55% for internally delivered services
- Obtain approval from @justinfarrris in the SKU issue
Fulfillment approval required if:
- Proposed SKU (meant to be) sold to Customers:
Self-serve
- Subscription with the proposed SKU (meant to) have specific behavior for self-service subscription modifications (for example, no self-service renewal)
- Any non-standard (***) Charge Type, Charge Model, Charge Timing requests
- Proposed SKU (meant to) provision specific product features to the customer (SaaS or SM)
- Obtain approval from the
Fulfillment Product Managers
Sales Operations approval required if:
- If SKU has limited quoting availability (only available to sell by certain groups)
- Any non-standard (***) Charge Type, Charge Model, Charge Timing requests
- Obtain approval from the
Senior Manager of Deal Desk
Step 1c. Finance
Finance Approval is required for any non-standard revenue recognition approach. The Business Sponsor should communicate with the directly responsible individual (DRI) for input in Step 3.
Step 1d. Management Approvals
Assign the Issue to the management approvers in Step 4. It is the Business Sponsor’s responsibility to ensure all prior requirements and approvals are obtained before progressing to Step 5.
- After all above steps are complete and required approval have been obtained, remove the ~“SKU - Gathering Requirements” label and tag
@gitlab-com/business-technology/enterprise-apps/financeops
for intake and prioritization of the SKU request so that it can be configured in the Zuora Billing product catalog and made quotable in Salesforce. Please note that all changes must follow the Business Technology Change Management for SOX/Audit purposes. - If the SKU will be sold through the channel, assign the issue to the
Sales Operations Analyst
listed in Step 6 to add the SKU to the quarterly update issue, the upcoming Pricebook and any other necessary information - If the SKU requires a service description, it is the Business Sponsor’s responsibility to complete step 7
Step 2: SKU Build & Test Generation Data
Owner: Enterprise Applications
Expected Timing: 2-3 weeks
Enterprise Applications and systems team build the SKU in test1 staging.
Enterprise Applications generates test data to be utilized during user acceptance testing based on the approved test cases.
Step 3: User Acceptance Testing & Cross Functional Approvals
Owner: Business Sponsor or TPM if assigned
Expected Timing: 1 week for test case generation and approvals (can be done in parallel with SKU Build). 2 weeks for testing and sign-off
Step 3a. Create the UAT issue
There is a UAT issue template in
this directory. Open an issue in and use the SKU UAT template
.
UAT Type: This section is to determine whether this user acceptance testing is for an existing SKU or a new SKU.
Pre-Testing Checklist:
- Stakeholder & Timeline Alignment
- This section is used to outline the [timeline] for UAT testing
- Test Case Readiness
- This section is used to:
- Create a copy of the master spreadsheet and link this spreadsheet in this section of the issue
- Check that all DRIs have approved the test cases
- This section is used to:
- System Readiness
- This section to be completed by Enterprise Apps & Fulfillment
Testing DRIs
These teams are typically involved in SKU testing:
- Deal Desk
- Billing & AR
- Fulfillment
- Data
- Revenue
- Finance
Each team will need to confirm:
- The expected DRI for that team’s testing
- The team can test during the testing availability dates for that team established in the timeline alignment above
- That they approve the test cases to be tested
Test Scenarios
Use this section to link to the test cases
Bugs Identified
This section will be used to track bugs during the user acceptance testing.
Final Testing Sign Off
This section will be used to receive final sign off across the cross-functional teams involved in testing
Step 3b: Estimate the UAT Timeline
Several key dates and timing need to be established and approved by the [Testing DRIs]:
- Date when Ent Apps will complete their SKU build in staging/test environment
- Date when UAT test cases should be finalized and approved by all Testing DRIs
- Date when Ent Apps will have test data generated
- Date when Cross-functional Testing DRIs will conduct their testing
- 2-3 biz days: Q2C & Deal Desk
- 2-3 biz days: Billing & AR
- 2-3 biz days: Fulfillment, Data, Revenue, FP&A
- Date when User acceptance final sign off/approval
Outline the estimated dates above and then ensure that these teams approve the timeline:
- All [Testing DRIs]
- Caroline Swanson from Enterprise Applications
Step 3c: Create Draft of UAT Test Cases
- Create a copy of the master spreadsheet
- Populate columns A through J in the spreadsheet
- Column A: test case #. Use this format for test case numbering:
- TC (test case)
- Short-hand for the SKU. For example Duo Enterprise would be DE
- 01 (test case number)
- So for Duo Enterprise test case #1 would be: TC-DE-01
- Column B: Purchase method
- This would be either sales-assisted or self-service
- Column C: Deal Type
- This would be new, upgrade, downgrade, renewal, cancellation
- Column D: Purchase Path:
- This would be either Direct or Partnership
- Column E: Term
- Term is the length of the contract (12 months, 24 months, 36 months)
- Columen F: Ramp?
- This would be Yes or No whether the price ramps over multi-year terms
- Column G: Ramp Segments
- Column H: Product Type
- This is the instance type: SaaS, Self-Managed, or Dedicated
- Column: I: Product Tier
- This is the product tier: Free, Premium, Ultimate
- Column J: Use Case Summary
- Describe what this test case is trying to test
- Columns K through AN will be populated during testing by the Testing DRIs
Test cases will vary depending on the SKU. However, most test cases will likely include scenarios such as:
- New deals that include a product
- Deals that have multi-year terms and need to ramp
- Deals that are an upgrade or downgrade from one product to another
- Deals renewals or cancellations
- Contract terms that need to be tested: Examples might include: ensuring minimums or maximums are tested, ensuring mandatory attach rules are tested
Not every single transaction scenario needs to be tested. Jesse Rabbits can help validate and add initial test cases.
Step 3d: Assign Business Ownership and Get Timing & Test Case Approval
Assign the folks outlined in the [Testing DRIs] section of the issue
Each team will need to confirm:
- The expected DRI for that team’s testing
- The team can test during the testing availability dates for that team established in the timeline alignment above
- That they approve the test cases to be tested
Step 3e: Conduct UAT and Track Bugs/Issues
On the approved timing dates, the outlined [Testing DRIs] will conduct the test cases from the approved test cases
Testing DRIs will use the UAT issue to report any buys or issues identified. Those bugs & issues will be tracked in the [Bugs Identified] section of the issue
Most bug resolution will be executed between the Testing DRI and Enterprise Applications.
Step 3f: Complete UAT and Cross Functional Approvals
All [Testing DRIs] need to give their final sign-off and approval in the issue.
Once completed, UAT is can be considered done
Step 4: SKU Deployment to Enterprise Applications
Owner: Enterprise Applications
Expected Timing: 2-3 days
Enterprise Applications will deploy the SKU to production Enterprise Applications SKUs are always deployed on Wednesdays [Add deployment schedules]
Post Go Live SKU Modifications
This section outlines what information can or cannot be modified after the SKU has been configured in Zuora Billing.
Modifiable Information
- Price
- Name (Product, Product Rate Plan, Product Rate Plan Charge)
- Revenue recognition rules: can be modified in conjunction with the Revenue Team
- Zuora Revenue fields
- Unit Of Measure
- Tax Code
Information that Cannot Be Modified
- Zuora IDs (used by Fulfillment and Data)
- Charge Type (One-Time, Recurring, Usage)
- Charge Model (Flat Fee, Per Unit)
Information Advised Not to Change
- The number of charges per Rate Plan.
- For example, if we have 2 charges per rate plan (license and service), we would not advise adding an additional charge (for storage, for example) to this Rate Plan
- Existing customers would not receive the additional “charge”, although all customers on a go-forward basis would
How to Retire a SKU
Edit
button on the right-hand panel of the issue.
Step 1. Product Information
Identify Rate Plans to be retired
- In this section, list all the rate plan IDs that need to be retired.
When is the SKU expected to be retired
- Provide a specific date of when the new SKU is expected to be retired.
- Please note that helps with intake and prioritization of the request and does not necessarily mean the SKU will be ready for sale by this date.
Step 2. Stakeholder Approval for SKU Retiring
Approval Required Based on Request Type
- If retiring Professional Services SKUs, tag the
Senior Director of Education Services
orDirector of Professional Services
- If retiring Non-Professional Services SKUs, tag the Fulfillment Product Managers
@gitlab-org/fulfillment/product-managers
Approval Required for ALL SKU Retirement Requests
- For Sales, tag the
Senior Director of Sales Operations
- For Sales Operations, tag the
Senior Manager of Deal Desk
- For Finance, tag the
Senior Director of Revenue Accounting
Step 3. Business Technology to Retire SKU in Zuora & Salesforce
Once all of the above steps are complete and required approval are obtained, please remove the ~“SKU - Gathering Requirements” label and tag @gitlab-com/business-technology/enterprise-apps/financeops
for intake and prioritization of the SKU retirement request so that it can be deprecated in the Zuora Billing product catalog and no longer quotable in Salesforce.
FAQ
- How long does it take to create a SKU?
- Several factors influence the length of time for a SKU to be created and made quotable
- Unclear business requirements will significantly increase the length of time and why all steps of the Product Launch Process needs to be completed prior to requesting a new or updated SKU issue.
- The complexity of the SKU (the charge type, how it is sold, guided selling rules/restrictions, etc.), the Business Sponsor’s ability to obtain approvals from stakeholders, and any other development work required to support the SKU are additional influences on the delivery time.
- What are Non-Standard Requests?
- They are SKU configurations that GitLab typically does not support/has not supported in the past and are marked by three asterisks (***) in Step 1 Product Information of the SKU process.
- Who is responsible for obtaining approvals for my new SKU request?
- It is the Business Sponsor’s responsibility to ensure all required information and appropriate approvals are obtained for each Step prior in the SKU process.
- Where can I find the issue templates described in this handbook page?
- There are 3 issue templates in this directory that the user can choose from to help log their request.
- What information can be changed after the SKU goes live?
- Please refer to Post Go Live SKU Modifications section of this handbook page
- Can we just configure the SKU in production and skip the sandbox?
- Unfortunately, no. For SOX/audit purposes, all changes to the Zuora Billing product catalog must be properly tested, adhering to Business Technology Change Management policies and the Software Development Lifecycle Process for Finance Systems.
- I only want to update the name/description of an existing SKU, do I need to go through this entire process?
- If you are not changing the charge type, unit of measure, charge model, charge timing or list price then you can simply submit an issue in this directory using the template
CM: Configuration Change [Generic]
and fill out theRequestor
section.
- If you are not changing the charge type, unit of measure, charge model, charge timing or list price then you can simply submit an issue in this directory using the template
a942533f
)