Add contact sales options within the product
Description
We'd like to identify additional opportunities within the product to include a call to action to contact sales (https://about.gitlab.com/sales/). Two opportunities to call out:
- Trial users to initiate a paid plan.
- Users of Starter to upgrade to Premium or Ultimate, and users of Premium to upgrade to Ultimate (focus of this issue).
For the latter, our objective is to promote key capabilities not available in Starter/Premium to create interest and lead to taking action to contact sales. Users should be able to:
- Learn about key features available at higher tier plans, so they're aware of the problems GitLab Premium/Ultimate can solve for them
- Have a clear and easy-to-use CTA, so they can reach out to sales for more information
Sales should be able to:
- Know which feature the lead contacted sales in regards to, so they can reference the customer's interest in that feature when reaching out
Proposal
- For selected Premium and Ultimate features, substitute where these features would normally appear in-product with a description and CTA to contact sales for more information.
- Premium features: Canary Deployments, Premium Support.
- Ultimate features: Epics, SAST.
- Promotions should only be visible to users with Developer, Owner, or Master permissions.
- CTAs should go to
about.gitlab.com/sales/
Note: if I'm on Starter, I should see all 4 promotions (Premium + Ultimate). If I'm on Premium, I should only see 2 (Epics, SAST).
Questions
- Does the Epics container clash with the existing Issue Weights promo container?
The issue weights promo container shouldn't be displayed if the epics promo is being displayed.
- Can we adjust the CTA to allow users to self-serve when possible?
- Default to self-serve for accounts that were initially provisioned self-serve or route to self-serve if below N seats?
For now, routing to the contact sales form works as a first iteration.
- Should dismissals apply to a user, or to the project?
Dismissals should be attached to a user and apply across projects. Once a banner is dismissed, the user shouldn't see it in other projects or groups.
- Where should we store the dismissal?
On the backend. Client-side isn't persistent enough, and we want to be as non-intrusive as possible. Once a user dismisses a banner, we should not present it again.
Designs
How the banners work
- The banner can be dismissed anytime.
- If a user dismiss the banner, the banner will not show up again.
- "Contact sales" button links to Contact Sales page.
- "Read more" links to the specific feature's documentation.
Upgrade Starter plan to Premium plan
- Canary Deployments:
- It has a banner without the box on the "Environment" page.
- Premium support:
- It has the banner on Support form page since it's a good chance to let users know they can upgrade plan to get more quick and complete support from GitLab.
Canary Deployments | Premium support |
---|---|
![]() |
![]() |
Upgrade Premium plan to Ultimate plan
- SAST related features:
- The SAST line always shows up since we want users to notice it and upgrade their plans.
- The "lock" icon replaces the normal icon we use for SAST.
- It has "Contact sales" button at the end of the line.
- Epics:
- Even if the plan is "Starter", it still shows "Epic" in the issuable sidebar. So "Epic" could be a touch point to upgrade the plan (contact sales).
- When clicking "Upgrade plan" text, it shows the dropdown, and then users are able to contact sales.
SAST | Epics |
---|---|
![]() |
![]() |
SVGs
You can find SVGs in gitlab-svgs
.
Lock | Lock icon in SAST |
---|---|
![]() |
|
lock_promotion |
lock |