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 Satisfaction (SSAT)
  • Service Level Agreement (SLA)
  • Customer Wait Times
  • Customer Support Margin
  • Support Overall Handbook Update Frequency Rate
  • Support Department Narrow MR Rate
  • Manager to customer support rep ratio
• Regular Performance Indicators
  • Support Hiring Actual vs Plan
  • Support Non-Headcount Plan vs Actuals
  • Support Average Location Factor
  • Support Discretionary Bonus Rate
  • Customer Support Department New Hire Average Location Factor
• Other PI Pages
• Legends
  • Health
• How to work with pages like this
  • Pages
    • Helper Functions
  • Data
  • Guidelines

Executive Summary

KPI	Health	Status
Support Satisfaction (SSAT)	Attention	SSAT is very good (above 93%) 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
Customer Wait Times	Okay	TBD
Customer Support Margin	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.
Support Overall Handbook Update Frequency Rate	Unknown	Unknown.
Support Department Narrow MR Rate	Problem	TBD
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 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: At or above 95%

Chart (Sisense↗)

Health: Attention

• SSAT is very good (above 93%) 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: At or above 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

Customer Wait Times

The following KPI tracks the ratio between the median "Resolution Time" and the total median "Customer Wait Time" per ticket. "Resolution Time" is defined as the amount of time between the ticket creation and the last ticket communication. "Customer Wait Time" is defined as the total amount of time the ticket spends in the "Open" state over the tickets life cycle.

Target: 10% less than the median "Customer Wait Time" over a 6 months rolling average.

Health: Okay

• TBD

Customer Support Margin

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

Target: Headcount and non-headcount expenses to be at or below 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.

Support Overall Handbook Update Frequency Rate

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

Chart (Sisense↗)

Health: Unknown

• Unknown.

Support Department Narrow MR Rate

Support Department MR Rate is not directly a key performance indicator used to indicate productivity of our Support team members. Nonetheless, we want to track the average MR merged per team member to encourage updates to Documentation and Support 'fixes'. We currently count all members of the Support Department (Director, EMs, ICs) in the denominator because this is a team effort. The projects that are part of the product contributes to the overall product development efforts.

Target: At or above 5 MRs per Month

URL(s)

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

Chart (Sisense↗)

Health: Problem

• TBD

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 target for this metric is at or below 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.

Regular 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: At 136 Support members by Jan 31, 2022

URL(s)

• /handbook/hiring/charts/customer-support/

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

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: Actuals below Plan

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

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: At or below 0.6

URL(s)

• /handbook/hiring/charts/customer-support/

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.

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

Customer Support Department New Hire Average Location Factor

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

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 for team members hired within the past 3 months so hiring 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 more efficient location factor areas with another hire. The historical average location factor represents the average location factor for only new hires in the last three months, excluding internal hires and promotions. The calculation for the three-month rolling average location factor is the location factor of all new hires in the last three months divided by the number of new hires in the last three months for a given hire month. The data source is BambooHR data.

Target: Below 0.61

Chart (Sisense↗)

Health: Okay

• We are under our target

Other PI Pages

• Performance Indicator Maturity Table
• Engineering Function Performance Indicators
  • Customer Support Department Performance Indicators
  • Development Department Performance Indicators
    • Dev Sub-Department Performance Indicators
    • Ops Sub-Department Performance Indicators
    • Secure Sub-Department Performance Indicators
    • Threat Management Sub-Department Performance Indicators
    • Growth Sub-Department Performance Indicators
    • Enablement Sub-Department 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
  • Sec Section Performance Indicators
  • Enablement Section Performance Indicators
  • Stage and Group Performance Indicators
• Corporate Finance Performance Indicators
• Talent Acquisition Performance Indicators
• People Success Indicators
• 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

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 corresponding 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 corresponding 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_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 Performance Indicators data files and returns a signed chart URL for embedding a Sisense chart into the handbook.

Data

The heart of pages like this are Performance Indicators data files which are YAML files. 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. For Product PIs, product hierarchy should be separate from name by " - " (Ex. {Stage Name}:{Group Name} - {PI Type} - {PI Name}
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. For GMAU, the target should be quarterly.
org	Required	the organizational grouping (Ex: Engineering Function or Development Department). For Product Sections, ensure you have the word section (Ex : Dev Section)
section	Optional	the product section (Ex: dev) as defined in sections.yml
stage	Optional	the product stage (Ex: release) as defined in stages.yml
group	Optional	the product group (Ex: progressive_delivery) as defined in stages.yml
category	Optional	the product group (Ex: feature_flags) as defined in categories.yml
is_key	Required	boolean value (true/false) that indicates if it is a (key) performance indicator
health	Required	indicates the (K)PI health and reasons as nested attributes. This should be updated monthly before Key Meetings by the DRI.
health.level	Optional	indicates a value between 0 and 3 (inclusive) to represent the health of the (K)PI. This should be updated monthly before Key Meetings by the DRI.
health.reasons	Optional	indicates the reasons behind the health level. This should be updated monthly before Key Meetings by the DRI. Should be an array (indented lines starting with dashes) even if you only have one reason.
urls	Optional	list of urls associated with the (K)PI. Should be an array (indented lines starting with dashes) even if you only have one url
funnel	Optional	indicates there is a handbook link for a description of the funnel for this PI. Should be a URL
sisense_data	Optional	allows a Sisense dashboard to be embeded as part of the (K)PI using chart, dashboard, and embed as neseted attributes.
sisense_data.chart	Optional	indicates the numeric Sisense chart/widget ID. For example: 9090628
sisense_data.dashboard	Optional	indicates the numeric Sisense dashboard ID. For example: 634200
sisense_data.shared_dashboard	Optional	indicates the numeric Sisense shared_dashboard ID. For example: 185b8e19-a99e-4718-9aba-96cc5d3ea88b
sisense_data.embed	Optional	indicates the Sisense embed version. For example: v2
sisense_data_secondary	Optional	allows a second Sisense dashboard to be embeded. Same as sisense data
sisense_data_secondary.chart	Optional	Same as sisense_data.chart
sisense_data_secondary.dashboard	Optional	Same as sisense_data.dashboard
sisense_data_secondary.shared_dashboard	Optional	Same as sisense_data.shared_dashboard
sisense_data_secondary.embed	Optional	Same as sisense_data.embed
public	Optional	boolean flag that can be set to false where a (K)PI does not meet the public guidelines.
pi_type	Optional	indicates the Product PI type (Ex: AMAU, GMAU, SMAU, Group PPI)
product_analytics_type	Optional	indicates if the metric is available on SaaS, SM (self-managed), or Both.
is_primary	Optional	boolean flag that indicates if this is the Primary PI for the Product Group.
implementation	Optional	indicates the implementation status and reasons as nested attributes. This should be updated monthly before Key Meetings by the DRI.
implementation.status	Optional	indicates the Implementation Status status. This should be updated monthly before Key Meetings by the DRI.
implementation.reasons	Optional	indicates the reasons behind the implementation status. This should be updated monthly before Key Meetings by the DRI. Should be an array (indented lines starting with dashes) even if you only have one reason.
lessons	Optional	indicates lessons learned from a K(PI) as a nested attribute. This should be updated monthly before Key Meetings by the DRI.
lessons.learned	Optional	learned is an attribute that can be nested under lessonsand indicates lessons learned from a K(PI). This should be updated monthly before Key Meetings by the DRI. Should be an array (indented lines starting with dashes) even if you only have one lesson learned
monthly_focus	Optional	indicates monthly focus goals from a K(PI) as a nested attribute. This should be updated monthly before Key Meetings by the DRI.
monthly_focus.goals	Optional	indicates monthly focus goals from a K(PI). This should be updated monthly before Key Meetings by the DRI. Should be an array (indented lines starting with dashes) even if you only have one goal
metric_name	Optional	indicates the name of the metric in Self-Managed implemenation. The SaaS representation of the Self-Managed implementation should use the same name.

Guidelines

• Each KPI chart should be a timeseries chart.
  • Use Purple bars to denote values.
  • Use a Red stepped-line for timeseries target.
  • Directional targets will be used:
    • Above ...
    • Below ...
    • At ...
    • At or above ...
    • At or below ...
  • Optional: Use a single Green bar for the current month (in progress). Preferred for metrics which accumulate through a month but optional due to the performance impact to render the chart.
  • Optional: Use a Black line for rolling average.
• Each Sisense dashboard for KPIs should consider the following settings to ensure timely updates:
  • Setting up auto-refresh for a frequency that fits the KPI
  • Excluding Dashboards from Auto Archive
• 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 corresponding Performance Indicators data file under the sisense_data property
• Multi-series performance indicators should consider the following guidelines:
  • If series are mutually exclusive, use stacked bars for each series with a monthly time series
  • If series are not mutually exclusive, use grouped bars for each series with a monthly time series
  • Do not graph any targets in the chart.
  • Current month styling guidelines will not apply
• 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 :