Support Department Performance Indicators

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

On this page

• Executive Summary
• Key Performance Indicators
• Regular Performance Indicators
• Other PI Pages
• Legends
  • Maturity
  • Health
• How to work with pages like this
  • Data
  • Pages

Executive Summary

KPI	Maturity	Health	Reason(s)
Support Hiring Actual vs Plan	Level 3 of 3	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	Level 2 of 3	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	Level 3 of 3	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	Level 2 of 3	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	Level 3 of 3	Unknown	Unknown.
Support Satisfaction (SSAT)	Level 3 of 3	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)	Level 3 of 3	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
Customer Support Margin	Level 3 of 3	Okay	Tracked and reported monthly, and for the year we are under our margin target for spend. Maintain focus on spend while iterating on needs for non-headcount expense requirements.
ARR per support team member	Level 3 of 3	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	Level 3 of 3	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	Level 3 of 3	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

Are we able to hire high quality workers to build our product vision in a timely manner? Hiring information comes from BambooHR where employees are in the division `Engineering` and department is `support`. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured.

Target: 90% to plan per quarter

URL(s)

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

Chart (Sisense↗)

Health: 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

Maturity: Level 3 of 3

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

Health: 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

Maturity: Level 2 of 3

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↗)

Health: 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.

Maturity: Level 3 of 3

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/

Health: 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.

Maturity: Level 2 of 3

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↗)

Health: Unknown

• Unknown.

Maturity: Level 3 of 3

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↗)

Health: 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.

Maturity: Level 3 of 3

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↗)

Health: 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

Maturity: Level 3 of 3

Customer Support Margin

Total Support headcount and non-headcount expenses as a percent of ARR.

Target: Headcount and non-headcount expenses to be 10% of ARR

Chart (Sisense↗)

Health: Okay

• Tracked and reported monthly, and for the year we are under our margin target for spend.
• Maintain focus on spend while iterating on needs for non-headcount expense requirements.

Maturity: Level 3 of 3

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/

Health: Okay

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

Maturity: Level 3 of 3

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 involved in customer tickets. Total number of tickets closed / Total number of support staff.

Target: 65 tickets closed per support staff per month

Chart (Sisense↗)

Health: 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.

Maturity: Level 3 of 3

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↗)

Health: 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.

Maturity: Level 3 of 3

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 GitLabbers in the Customer Support department every month.

Target: 10%

URL(s)

Health: Unknown

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

Maturity: Level 2 of 3

Other PI Pages

• Performance Indicator Maturity Table
• Engineering Function Performance Indicators
  • Development Department Performance Indicators
    • Growth Section Performance Indicators
  • Infrastructure Department Performance Indicators
  • Quality Department Performance Indicators
  • Security Department Performance Indicators
  • Support Department Performance Indicators
  • UX Department Performance Indicators
• Corporate Finance Performance Indicators
• Recruiting Performance Indicators
• Data Team KPI Index

Legends

Maturity

Level	Meaning
Level 3 of 3	Has a description, target, and Sisense embed (if public) or URL (or not).
Level 2 of 3	Missing one of: description, target, or Sisense embed (if public) or URL (or not).
Level 1 of 3	Missing two of: description, target, or Sisense embed (if public) or URL (or not).
Level 0 of 3	Missing a description, a target, and Sisense embed (if public) or URL (or not).

Health

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

How to work with pages like this

Data

The heart of pages like this is a data file called /data/performance_indicators.yml which is in YAML format. Almost everything you need to do will involve edits to this file. Here are some tips:

• 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 take a number between 0 and 3 (inclusive)

Two flags to note:

• parent can be used when a PI or KPI 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.
• public can be set to false where a PI or KPI meets our not public guidelines.

Pages

Pages like /handbook/engineering/performance-indicators/ are rendered by and ERB template.

These ERB templates call the helper function performance_indicators() that is defined in /helpers/custom_helpers.rb. This helper function calls in several partial templates to do it's work.

This function takes a required argument named org in string format that limits the scope of the page to a portion of the data file. Possible valid values for this org argument are listed in the org property of each element in the array in /data/performance_indicators.yml.