On an account view in Salesforce, there is a Customer Success section, with the following fields:
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 is in need of completion.
The Onboarding object is a way for the Customer Success team to track and manage the customer onboarding experience.
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.
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:
Onboarding Finish Date Onboarding Status Not Started Scheduled In Progress Completed
if >5000 users OR Ultimate AND >2000 users 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 else = quartz
Please visit this page for more information on Gemstones.
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:
Executive Business Review Nameis the name that you give this EBR. Select the
EBR Datethat 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
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.
EBR Successto the appropriate value. This will automatically create the next EBR for the account 90 days after the
EBR Datefor the current EBR (ensuring that there is one EBR per quarter).
A number of fields will also auto populate making the creation process of new EBR's much more efficient.
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).
Cancelled- The main difference between a Declined EBR and a Cancelled EBR is dependent on how it is handled.
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:
EBR Dateis changed and is still planned to occur within the same fiscal quarter that it was originally planned to take place, simply update the
EBR Datefield to the new scheduled date.
EBR Dateis changed to a date that is in the next fiscal quarter please treat it as if that EBR was declined. Update the
EBR Statusand the
EBR Successfield to
Declinedand save the EBR. Please review the section above on creating successive EBR's for an account.
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).
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.
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 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.
Please visit this page for POC documentation.
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.
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:
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 account which is linked to your GitLab email address and your Salesforce account, your emails will automatically sync with Salesforce.