Customer Support Department Performance Indicators

1. You are here:
2. Handbook
3. Support Team Handbook
4. Customer Support Department Performance Indicators

On this page

• Executive Summary
• Key Performance Indicators
  • Support Hiring Actual vs Plan
  • Support Non-Headcount Plan vs Actuals
  • Support Average Location Factor
  • Support Recruiting Average Top-of-Funnel Location Factor
  • Support Handbook Update Frequency
  • Support Department Member MR Rate
  • Support Satisfaction (SSAT)
  • Service Level Agreement (SLA)
  • ARR per support team member
  • Average daily tickets closed per Support team member
  • Manager to customer support rep ratio
• Regular Performance Indicators
  • Support Discretionary Bonus Rate
• Other PI Pages
• Legends
  • Health
  • Instrumentation
• How to work with pages like this
  • Pages
    • Helper Functions
  • Data
  • Guidelines

Executive Summary

KPI	Health	Status
Support Hiring Actual vs Plan	Okay	Engineering is on plan. But we are lending some of our recruiters to sales for this quarter. And we just put in place a new "one star minimum" rule that might decrease offer volume. Health: Monitor health closely
Support Non-Headcount Plan vs Actuals	Unknown	Currently finance tells me when there is a problem, I’m not self-service. Get the budget captured in a system Chart budget vs. actual over time in periscope
Support Average Location Factor	Attention	We are at our target of 0.58 exactly overall, but trending upward. We need to get the target location factors in the charts. It will probably be cleaner if we get this in periscope. We need to set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
Support Recruiting Average Top-of-Funnel Location Factor	Unknown	We need to get this as a chart in periscope. We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
Support Handbook Update Frequency	Unknown	Unknown.
Support Department Member MR Rate	Problem	TBD
Support Satisfaction (SSAT)	Attention	SSAT is good (above 91%) but target is 95%. Collecting feedback from dissatisfied customers to identify trends. Support Managers review trends to create changes to workflows and/or training.
Service Level Agreement (SLA)	Attention	Inconsistent performance to a 95% target achievement. Focused staffing to key time gaps with higher level of ticket SLA breaches. Adjusting workflow to enable working with customers in their preferred timezone. Working with the data team on understanding the inconsistent we see between our ZenDesk SLA data and Periscope via 2857
ARR per support team member	Okay	Determine the need to continue to track this as a KPI versus a Support Gearing Ratio to ARR for modelling hiring plans.
Average daily tickets closed per Support team member	Attention	We are continuing to onboard new support agents and engineers so this average will be relatively dynamic as new people onboard. Still, we are in a healthy place for solving tickets and keeping pace. Determine appropriate team metrics to continue to drive individual contribution to solving tickets. Identify ways to match complexity to time to solve to differentiate expectations per support role.
Manager to customer support rep ratio	Okay	While we have an overall ratio of less than 10:1 as a department at time of this evaluation, we have re-balanced the larger imbalance in EMEA with new management in place, and have plans for 3 additional managers to hire to accommodate growth in other teams. Hire to plan for new managers. Re-align ICs to new managers to restore balance.

Key Performance Indicators

Support Hiring Actual vs Plan

This is a subset of an existing KPI. Please see the definition for the parent KPI.

Employees are in the division "Engineering" and department is "Support".

Target: 112 Support members by Jan 31, 2021

URL(s)

• /handbook/hiring/charts/support-department/

Chart (Sisense↗)

Status: Okay

• Engineering is on plan. But we are lending some of our recruiters to sales for this quarter. And we just put in place a new "one star minimum" rule that might decrease offer volume.
• Health: Monitor health closely

Support Non-Headcount Plan vs Actuals

This is a subset of an existing KPI. Please see the definition for the parent KPI.

We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.

Target: Unknown until FY21 planning process

URL(s)

• https://app.periscopedata.com/app/gitlab/633248/Support-Non-Headcount-BvAs

Status: Unknown

• Currently finance tells me when there is a problem, I’m not self-service.
• Get the budget captured in a system
• Chart budget vs. actual over time in periscope

Support Average Location Factor

We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas.

Target: 0.6

URL(s)

• /handbook/hiring/charts/support-department/

Chart (Sisense↗)

Status: Attention

• We are at our target of 0.58 exactly overall, but trending upward.
• We need to get the target location factors in the charts.
• It will probably be cleaner if we get this in periscope.
• We need to set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.

Support Recruiting Average Top-of-Funnel Location Factor

We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.

Target: 0.58

URL(s)

• /handbook/hiring/charts/support-department/

Chart (Sisense↗)

Status: Unknown

• We need to get this as a chart in periscope.
• We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.

Support Handbook Update Frequency

This is a subset of an existing KPI. Please see the definition for the parent KPI.

The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence. This data is retrieved by querying the API with a python script for merge requests that have files matching `/source/handbook/support/**` over time.

Target: 50

Chart (Sisense↗)

Status: Unknown

• Unknown.

Support Department Member MR Rate

Support Department MR Rate is a key indicator showing how productive our team members are based on the average MR merged per team member. We currently count all members of the Support Department (Director, EMs, ICs) in the denominator because this is a team effort. The projects included contributes to the overall product development efforts.

Target: 10 MRs per Month

URL(s)

• https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/534

Chart (Sisense↗)

Status: Problem

• TBD

Support Satisfaction (SSAT)

A measure of how satisfied our customers' are with their interaction with the GitLab Support team. This is based on survey responses from customers after each ticket is solved by the Support team using a Good or Bad rating.

Target: 95%

Chart (Sisense↗)

Status: Attention

• SSAT is good (above 91%) but target is 95%.
• Collecting feedback from dissatisfied customers to identify trends.
• Support Managers review trends to create changes to workflows and/or training.

Service Level Agreement (SLA)

GitLab Support commits to an initial substantive response in a specified amount of time from the time the customer submits a ticket. The SLA for this first reply is based on each customer's Support Plan.

Target: 95% to Priority Support SLAs

URL(s)

• https://about.gitlab.com/support/#service-level-agreement-sla-details
• https://gitlab.com/gitlab-data/analytics/-/issues/2857

Chart (Sisense↗)

Status: Attention

• Inconsistent performance to a 95% target achievement.
• Focused staffing to key time gaps with higher level of ticket SLA breaches.
• Adjusting workflow to enable working with customers in their preferred timezone.
• Working with the data team on understanding the inconsistent we see between our ZenDesk SLA data and Periscope via 2857

ARR per support team member

This is a function of modeling for staffing to a ratio of ARR and not directly influenced by Support staff performance but more to our hiring which is managed through other performance indicators.

Target: Greater than $1.175M

This KPI cannot be public.

URL(s)

• https://app.periscopedata.com/app/gitlab/421422/Support-KPIs?widget=6032352&udv=0
• https://about.gitlab.com/handbook/sales/#annual-recurring-revenue-arr
• https://about.gitlab.com/handbook/support/

Status: Okay

• Determine the need to continue to track this as a KPI versus a Support Gearing Ratio to ARR for modelling hiring plans.

Average daily tickets closed per Support team member

The Gitlab support team aims to staff the team based on weighted average of both self-managed and GitLab.com tickets closed in a given month by an individual support team member. Total number of tickets closed / Total number of support staff involved in customer tickets. (Total number of tickets closed comes from Zendesk / Total number of support staff involved in customer tickets we collect from bamboohr data for the monthly number of employees minus manager and operation)

Target: 65 tickets closed per support staff per month

Chart (Sisense↗)

Status: Attention

• We are continuing to onboard new support agents and engineers so this average will be relatively dynamic as new people onboard. Still, we are in a healthy place for solving tickets and keeping pace.
• Determine appropriate team metrics to continue to drive individual contribution to solving tickets.
• Identify ways to match complexity to time to solve to differentiate expectations per support role.

Manager to customer support rep ratio

The Manager to IC Ratio is the ratio of individual contributors to one manager. This data comes from Bamboo HR.

Target: The long term target for this metric is 10:1

Chart (Sisense↗)

Status: Okay

• While we have an overall ratio of less than 10:1 as a department at time of this evaluation, we have re-balanced the larger imbalance in EMEA with new management in place, and have plans for 3 additional managers to hire to accommodate growth in other teams.
• Hire to plan for new managers.
• Re-align ICs to new managers to restore balance.

Regular Performance Indicators

Support Discretionary Bonus Rate

Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLab team members in the Customer Support department every month.

Target: 10%

URL(s)

Status: Unknown

• We currently track bonus percentages in aggregate, but there is no easy way to see the percentage for each individual department.

Other PI Pages

• Performance Indicator Maturity Table
• Engineering Function Performance Indicators
  • Customer Support Department Performance Indicators
  • Development Department Performance Indicators
    • Growth Section Performance Indicators
  • Infrastructure Department Performance Indicators
  • Quality Department Performance Indicators
  • Security Department Performance Indicators
  • UX Department Performance Indicators
• Product Performance Indicators
  • Dev Section Performance Indicators
  • Ops Section Performance Indicators
  • Secure & Defend Section Performance Indicators
  • Enablement Section Performance Indicators
• Corporate Finance Performance Indicators
• Recruiting Performance Indicators
• People Success Indicators
• Data Team KPI Index

Legends

Health

Value	Level	Meaning
3	Okay	The KPI is at an acceptable level compared to the threshold
2	Attention	This is a blip, or we’re going to watch it, or we just need to enact a proven intervention
1	Problem	We'll prioritize our efforts here
0	Unknown	Unknown

Instrumentation

Value	Level	Meaning
3	Okay	We are correctly capturing and measuring data for GitLab.com and self-managed instances.
2	Attention	Missing one of: GitLab.com or self-managed data.
1	Problem	Missing both: GitLab.com and self-managed data.
0	Unknown	Unknown

How to work with pages like this

Pages

Pages, such as the Engineering Function Performance Indicators page are rendered by an ERB template that contains HTML code.

• Any changes to the Performance Indicator (PI) ERB template will cascade to all links under the Other PI Pages section
• To add, delete, or update (K)PI information (including title, description, etc), make changes to the Performance Indicators data file. See more details in the Data section below.
• To update the way each individual (K)PI displays:
  • make changes to the Performance Indicators List ERB file for how the (K)PI is displayed on the KPI Index page
  • make changes to the Performance Indicators ERB file for any other properties and its format
• When adding a new PI page,
  • create the new PI page in the business division's handbook section (like the Engineering Division page)
  • include the relative link to the PI page in the Performance Indicators List ERB file
  • add all the (K)PI information into the Performance Indicators data file

Helper Functions

These ERB templates calls custom helper functions that extract and transform data from the Performance Indicators data file.

• The kpi_list_by_org(org) helper function takes a required string argument named org (deparment or division level) that returns all the KPIs (pi.is_key == true) for a specific organization grouping (pi.org == org) from the Performance Indicators data file.
• The pi_maturity_level(performance_indicator) helper function automatically assigns a maturity level based on the availability of certain data properties for a particular PI.
• The pi_maturity_reasons(performance_indicator) helper function returns a reason for a PI maturity based on other data properties.
• The performance_indicator_target(name) helper function returns the target value from the target property for a specific PI from the Performance Indicators data file.
• The performance_indicators(org) takes a required string argument named org (deparment or division level) that returns two lists - a list of all KPIs and a list of all PIs for a specific organization grouping (department/division).
• The signed_periscope_url(data) takes in the sisense_data property information from the Performance Indicators data file and returns a signed chart URL for embedding a Sisense chart into the handbook.

Data

The heart of pages like this is the Performance Indicators data file which is in YAML file. Each - denotes a dictionary of values for a new (K)PI. The current elements (or data properties) are:

Property	Type	Description
name	Required	String value of the name of the (K)PI
base_path	Required	Relative path to the performance indicator page that this (K)PI should live on
definition	Required	refer to Parts of a KPI
parent	Optional	should be used when a (K)PI is a subset of another PI. For example, we might care about Hiring vs Plan at the company level. The child would be the division and department levels, which would have the parent flag.
target	Required	The target or cap for the (K)PI. Please use Unknown until we reach maturity level 2 if this is not yet defined.
org	Required	the organizational grouping (Ex: Engineering Function or Development Department)
is_key	Required	boolean value (true/false) that indicates if it is a (key) performance indicator
health	Required	has two additional elements/property - level (inclusive value between 0-3) and reasons. This should be updated monthly before Key Meetings by the DRI.
urls	Optional	list of urls associated with the (K)PI
sisense_data	Optional	contains elements/properties related to Sisense, including chart (numeric Sisense widget ID), dashboard (numeric Sisense dashboard ID), shared_dashboard (Sisense shared dashboard ID), embed (v2)
public	Optional	boolean flag that can be set to false where a (K)PI does not meet the public guidelines.
instrumentation	Optional	has two additional elements/property - level (inclusive value between 0-3) and reasons. This should be updated monthly before Key Meetings by the DRI.

Guidelines

• Each KPI chart should be a timeseries chart.
  • Use Purple bars to denote values.
  • Use a single Green bar for the current month (in progress).
  • Use a Red stepped-line for timeseries target.
  • Optional: Use a Black dashed-line for rolling average.
• Each KPI should have a standalone dashboard with a single chart representing the KPI and a text box with a link back to the handbook definition.
  • In Sisense, create a shared dashboard link to get the shared dashboard ID.
  • In Sisense, use the Share Link action of the chart to get the chart (widget_id) and the dashboard ID.
  • Add the shared_dashboard, chart , and the dashboard key-value pairs to the Performance Indicators data file under the sisense_data property
• Avoid : in strings as it's an important character in YAML and will confuse the data parsing process. Put the string in "quotes" if you really need to use a :
• urls: should be an array (indented lines starting with dashes) even if you only have one url
• Both maturity.level and health.level display a value between 0 and 3 (inclusive).