Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • S sales
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 80
    • Issues 80
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Insights
    • Issue
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • GitLab.comGitLab.com
  • sales
  • Issues
  • #302
Closed
Open
Issue created Oct 26, 2018 by Tom Atkins@tatkins

Identify customers and prospects to help Support align and communicate with Sales

The Support team responds to tickets in Zendesk based on the plan the customer is on. There are some customers Support can serve better if we are more closely aligned with information Sales has about them. This issue proposes a two ways to help with that.

1. Prospects that Sales wish to give temporary access to support

Occasionally there is a need for a prospect to 'try out support'. To make it easy for Support to identify these customers we are proposing two new Support Levels in SalesForce called

  1. Prospect Self-Managed (for 'self-managed' customers)
  2. Prospect dotcom (for '.com' customers

(For implementation: The 'Support Level' field already syncs to Zendesk is identified by Support_Level__c in SalesForce)

Two automations / restrictions in SalesForce will prevent too many customers being given access:

  1. Limit the total number of Prospect Self-Managed and Prospect dotcom customers at any one time so that is not abused (e.g. 25. The number could grow as GitLab grows). If the maximum limit is reached, the field in SalesForce would not be selectable until another customer is removed from the feature. It would be up to Sales to discuss internally who is eligible at any given time.
  2. Time limit Prospect Self-Managed and Prospect dotcom in SalesForce so that it disables / turns itself off after two weeks.

2. Strategic customers

The second group of customers we'd like to identify are customers who have been identified as Strategic

There is already a check-box field in SalesForce for this: Customer+ but its use is not clearly defined. The proposal is to rename Customer+ to Strategic.

  1. A SalesForce automation to restrict the maximum number of Strategic customers will be required (e.g. 40 customers as of December 2018 - can be increased by C-Level decision as GitLab grows.)
  2. A process should be documented by Sales Directors and C-Level people at GitLab as to what constitutes Strategic and who in GitLab makes the decision. This should be clear within SalesForce.

cc @gitlab-com/support/managers @pidge @teemo @Haydn @francisaquino @wzabaglio @msnow1

Edited Jan 04, 2019 by Tom Atkins
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking