13.3 KB
Newer Older
layout: handbook-page-toc
3 4 5 6 7 8
title: "Using Salesforce within Customer Success"

# Using Salesforce within Customer Success

9 10
## On this page
{:.no_toc .hidden-md .hidden-lg}

{:toc .hidden-md .hidden-lg}
14 15

- Using Salesforce within Customer Success *(Current)*
16 17 18 19 20
- [Account Onboarding](/handbook/customer-success/tam/onboarding/)
- [Technical Account Manager Summary](/handbook/customer-success/tam/)
- [Account Triage](/handbook/customer-success/tam/triage/)
- [Account Engagement](/handbook/customer-success/tam/engagement/)
- [Gemstones](/handbook/customer-success/tam/gemstones/)

22 23 24 25
On an account view in Salesforce, there is a Customer Success section, with the following fields:

* Health Score - A field to record the overall customer health (details TBD on this)
* GitLab Customer Success Project - Where you enter the URL of the project created using the template described above
* Customer Slack Channel - A field to record Slack channel(s) used for internal and external customer collaboration. If a channel is internal, make sure it follows the naming convention "#a_<customer-name>-internal" per [Communication Chat](/handbook/communication/chat/#account-channels-a_)
27 28
* Solutions Architect - The Solutions Architect aligned with the account
* Technical Account Manager	- The Technical Account Manager aligned with the account
29 30 31 32 33

## Salesforce Objects

Salesforce operates using a series of objects. Standard objects are objects that are included with Salesforce. Common business objects like Account, Contact, Lead, and Opportunity are all standard objects.

Custom objects are objects that you create to store information that’s specific to your company or industry. For GitLab, we have created four custom objects that are specific to Customer Success. These are POC's, SOW's, EBR's, and Onboarding objects. We can link these custom objects to accounts and opportunities, and create automations such as allowing us to auto-populate specific fields and notify users when a task needs to be completed.
35 36 37

### Onboarding objects

The Onboarding object is a way for the Customer Success team to track and manage the customer onboarding experience.

* When an account moved from Gemstone 5 or 6 to Gemstone 1-4 a new onboarding object is created.
* The purchase date field is auto-populated with the close date from the opportunity.
* The object and account will be automatically associated with one another.

44 45
A key purpose is measuring the three Time to Value metrics (definitions are covered under Fields). These will be used as a primary gauge for assessing the quality of customer onboarding.

46 47 48
1. [Time to Engage](#fields)
1. [Time to First Value](#fields)
1. [Time to Onboard (Days of Onboarding)](#fields)

##### Fields

* Customer Onboarding Name
* Opportunity (manually populated)
* Purchase date (date field, automatically populated, editable)
55 56 57 58
* First Reach-out (date field, manually populated, editable)
* Infrastructure Ready (date field, manually populated, editable)
* Onboarding Start Date (date field, manually populated, editable)
* Onboarding Finish Date (date field, manually populated, editable)
* First Value Date (date field, manually populated, editable) - date when a minimum of 20 users are active on Production Environment
60 61 62 63
* Onboarding Status (picklist) - Not started (default), Scheduled, In Progress, On Hold, Completed
* Time to Engage (calculation: Purchase Date - First Reach-out)
* Days of Onboarding (calculation: Onboarding Start Date - Onboarding Finish Date)
* Time to First Value (calculation: Purchase Date - First Value Date)
* Onboarding Notes (text field)
65 66
* Onboarding Challenges / Highlights (text field)
* Success Plan (manually populated link to GitLab Onboarding issue)

#### Compulsory fields after status is set to Completed
69 70 71 72

* Onboarding experience survey sent? y/N checkbox
* Onboarding experience survey results received? y/N checkbox
* Onboarding experience score (picklist of 1-5) (decided by TAM if no survey results received)
73 74 75 76 77

#### GitLab Team Fields

These are important to fill out so we can historically track who assisted with onboarding the customer. This is not pulled from the account metadata as the account metadata may change but these people should always be historically recorded.

### Creating a new Customer Onboarding object manually

1. In Salesforce, click the Customer Onboarding tab (click the ‘+’ to view all tabs if not visible on the top-right)
81 82
2. Click the New button to create a New Customer Onboarding record
3. Enter in the following information and click Save once completed:
83 84
    * Customer Onboarding Name
    * Account 
85 86 87
    * Owner (Technical Account Manager)
    * Purchase Date
    * Onboarding Start Date
    * Greenfield?

90 91
### Updating Object During Onboarding

The Customer Onboarding object shouldn't be updated _only_ at the start and completion; update it at each milestone to measure Results, Iterate for short feedback loops, and Collaborate. Small changes are easier than attempting to remember all the details at completion. It also enables reporting on early metrics without waiting for the entire Onboarding process to be finalized. 

94 95 96
### Completing the Customer Onboarding object

The TAM owner will be expected to finalize this Onboarding record through completion with the customer; this will result in a few additional values that must be populated:

98 99 100 101
* Ensure all date fields are accurately filled
* Complete any Onboarding Notes and Onboarding Challenges/Highlights
* Onboarding Finish Date
* Onboarding Status: mark `Completed`

#### Gemstone Automations

105 106
##### This is how the Gemstone for an account is calculated:

107 108
if >5000 users   
OR Ultimate AND >2000 users
110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129
OR >500k iACV
= diamond

else if >2500 users
OR Ultimate AND >1000 users
OR >250k iACV
= pearl

else if >1000 users
OR >100k in iACV
= sapphire

else if >500 users
OR >50k in iACV
= ruby

= quartz

Please visit [this page](/handbook/customer-success/tam/gemstones/) for more information on Gemstones.
131 132 133 134 135 136 137 138 139 140

### Executive Business Review (EBR) objects

EBR objects allow the Technical Account Managers to track and measure the success of Executive Business Reviews held (or not held) with customers each year.

In order to appropriately track and create Executive Business Review Objects please follow the instructions below:

#### Creating the first EBR for an account

* If it is the first EBR for an account you can navigate to the EBR Tab. This can be located on the either the 'Sales' or the 'Service' App within Salesforce
* If you would like to schedule an EBR with a GitLab E-Group member, please review and follow the [Meeting request requirements](/handbook/eba/#meeting-request-requirements) page
* On the top of the list shown, you click on the 'New' button. This will enable you to create the new EBR object where you can provide the following. `Executive Business Review Name` is the name that you give this EBR. Select the `EBR Date` that the EBR is scheduled to occur on.

Note: If the EBR Date changes, please see below for handling this situation in order relate the EBR to the appropriate account. This is done using the search functionality provided by the `Account` field. `EBR Status` should be set to either 'Not Started' or 'Scheduled' depending on the current state of the EBR. All other fields should be left alone. Please refer to the section below on if you should link the EBR to any Opportunities.
145 146 147

#### Creating any successive EBR's and handling "Declined" or "Cancelled" EBR's

* In order to create any successive EBR's (anything besides the first EBR), DO NOT us the 'New' button as this will cause errors with tracking. Instead, after the completion, cancellation or declined invite of an EBR, update the `EBR Success` to the appropriate value. This will automatically create the next EBR for the account 90 days after the `EBR Date` for the current EBR (ensuring that there is one EBR per quarter).
149 150 151 152 153 154 155 156

A number of fields will also auto populate making the creation process of new EBR's much more efficient.

#### Tracking the performance of EBR's

* There are currently two picklist fields in order to provide tracking for EBR's:
    * `EBR Status` - This field shows the scheduling status of the EBR. This should be used to help monitor workflow (Scheduled vs Not Started) and also to track cancellations and declined EBR's as well as completed EBR's that were actually held.
    * `EBR Success` - This field tracks the overall success of the EBR with the default set to `Incomplete`. This field should only be updated once the EBR is held OR after a cancellation or declined EBR. This tracks what the  Technical Account Manager believes was the outcome of the EBR (or if it was declined or Cancelled).
* `Declined` vs `Cancelled` - The main difference between a Declined EBR and a Cancelled EBR is dependent on how it is handled.
158 159 160 161 162 163 164

For example, if a customer pushes to only have two EBR's a year, then two of the EBR's each year should be labeled as Declined. If an EBR is successfully scheduled but then for whatever reason the customer or GitLab has to cancel the EBR, then this value should be chosen.

Handling EBR Date Changes:
* If the `EBR Date` is changed and is still planned to occur within the same fiscal quarter that it was originally planned to take place, simply update the `EBR Date` field to the new scheduled date.
* If the `EBR Date` is changed to a date that is in the next fiscal quarter please treat it as if that EBR was declined. Update the `EBR Status` and the `EBR Success` field to `Declined` and save the EBR. Please review the section above on creating successive EBR's for an account.  

165 166
#### Linking EBR's to Opportunities:
* Although all EBR's can be associated to an Opportunity, not all EBR's necessarily need to be associated to an opportunity. Only the four latest EBR's should be related to an upcoming opportunity.
167 168 169

For example, If there is an upcoming opportunity in Q4 2019 then the only EBR's that should be related to this Opportunity should be the following EBR's, Q1-2019-EBR, Q2-2019-EBR, Q3-2019-EBR & Q4-2019-EBR (Assuming that the Q4 EBR took place before the opportunity close date).

* To link an Opportunity to and EBR use the "New EBR-Opportunity Associations" Button that is located above the "EBR-Opportunity Associations" related list. This is done on either the Opportunity you would like to associate the EBR with, or the EBR that you want to associate with the Opportunity.

Scroll down to find the "EBR-Opportunity Associations" related list on the layout and click on "New EBR-Opportunity Associations" Button. From there, search and select the appropriate Opportunity and EBR that need to be associated with one another and save the record.
173 174 175

### Statement of Work (SOW) objects

SOW objects in Salesforce are used to track the progress of our SOW's that are agreed upon with our customers. These SOW's describe the professional services that Gitlab will deliver to our client. As this is related to a billable service that we are extending to our clients all SOW's must be related to an appropriate Opportunity and an Account.

The Opportunity that each SOW is associated with will contain information relevant to the Opportunity (Amount, IACV etc.) while the SOW itself will house notes, details and monitor the progress of the SOW (Go Live Date, Kick Off Date etc.). If a client would like to move forward with many professional services at once then all of these services would be encapsulated and related through one Opportunity and one SOW.

If an existing client, who previously purchased professional services from Gitlab, would like to purchase addition professional services, then a new Opportunity and SOW would be created in Salesforce. Review our section in the [handbook](/handbook/sales/#when-to-create-an-opportunity) about creating new opportunities if you have any questions around the Opportunity creation process.  

In order to track the contacts that are associated with a SOW, we utilize the SOW-Contact Association list. This can be accessed by navigating to the SOW page layout and locating the SOW-Contact Association related list. From there you can create a new association by looking up the contact that is associated with this SOW. Multiple contacts can be associated with a single SOW.
183 184 185

### Proof of Concept (POC) objects

Please visit [this page](/handbook/sales/POC/) for POC documentation.
187 188 189 190 191

## Salesforce - Customer Success Automations

### New Zendesk Ticket Notifications

192 193 194 195 196 197 198 199 200 201 202 203 204 205 206
For all new Zendesk tickets that are created, the Technical Account Manager and Account Owner for the account that the ticket is associated with will receive an email notification alerting them of a new ticket. This currently is a one time notification that only occurs when the Zendesk ticket is first created in Salesforce.

### Tracking Emails within Salesforce

Anyone communicating with a customer via email should ensure their emails are being tracked within Salesforce in the account's activity history. To do this:

1. Log in to [Salesforce](
1. Click your name at the top right
1. Click "My Settings"
1. Click "Email" on the left sidebar
1. Click "My Email to Salesforce"
1. Save the email address it provides next to "Your Email to Salesforce address"

Any time you email a customer, bcc your "email to Salesforce address" on the email so that it is tracked within Salesforce.

Alternatively, if you have an [Outreach](/handbook/business-ops/tech-stack/#outreachio) account which is linked to your GitLab email address and your Salesforce account, your emails will automatically sync with Salesforce.