Better guidance for customer calls + training module
Request for comments
README FIRST
I recognize that this has the potential to be a contentious issue. Customer calls touch on two specific areas of support sensitivity:
- As a Support Engineer, I have a lot to do: this feels like more.
- As a Support Engineer, customer calls touch on one or more of my core fears:
- Being wrong
- Providing the best service I can, but being rejected by a customer or my peers
- Appearing incompetent
- Being inadequate to the challenge
- Being thought incapable or ignorant by a customer or my peers
- Being drained of energy and unable to contribute elsewhere
- Being without support or guidance
- Being trapped and missing out on an opportunity where I can contribute better
- Being in conflict or tension
If this issue causes an emotional response:
- stop, don't comment (yet).
- be curious about your feelings.
- come back and look at the last sections and see if we've captured the piece of resistance you're feeling or benefits you want to highlight.
The contributions I'm looking for are:
- points of resistance (feel free to add directly to the section): this will help me make sure future training addresses these
- benefits (feel free to add directly to the section): this will help me make sure the Handbook does a good job of substantiating things
- small iterations / boring solutions / other ideas to help support engineers feel more supported and empowered to take needed situations to calls
Even though this issue body is prodigous, I'd like to avoid lengthy comments to the extent we can.
Context
In #4572 (closed) I spent some time gathering data on customer calls. There was some interesting data, some inconclusive data and some data that needs more capture or analysis. Overall though, what was interesting was:
Over the time period in the data set:
- 2% of tickets got calls.
- Normal priority tickets were the ones most likely to get calls.
- Most engineers had 1 or fewer calls in those two months.
More anecdotally, a frequent piece of feedback that I receive from CSMs and Sales folks is "it's too hard to get on a call with Support".
Need
It might be better to start with what this issue isn't:
- I'm not trying to turn us into an inbound call center
- I'm not trying to establish on-demand calls
- I'm not trying to set call targets
- I'm not looking for immediate change or a rapid shift
My biases are that I think that:
- customer calls are generally an underutlized tool in the GitLab Support toolbelt.
- denying a customer call is one of the surest ways to get negative SSAT.
This issue is to discern how we as a team can better approach customer calls, make sure engineers are prepared with the soft-skills required for taking on customer calls and develop engineer awareness for how to manage customer expectations for calls.
Approach
-
Substantiate the benefits and points of resistence in moving to a call -
Update Customer Calls workflow with better guidelines for why and when you should consider going to a call: https://about.gitlab.com/handbook/support/workflows/customer_calls.html -
Create Customer Calls training -
Introduce a feedback loop to document soft-skills best practices as they're discovered -
Update language in Statement of Support to soften the "the decision to conduct a call always rests with the support engineer" language: https://about.gitlab.com/support/#phone-and-video-call-support
Benefit
There are a few issues that show engineer comfort with / promotion of calls. #4649 (closed) and #4305 (closed) have some. I've sketched out some of my own thoughts as well.
Please feel free to edit the issue to contribute to this section rather than making a comment.
Calls are efficient
- During a live call relevant data and reproduction can be gathered quickly with fewer days of back and forth
- Calls give engineers the opportunity to do customer education which reduces the number of tickets that customer may raise
Calls improve our ability to deliver quality support
- During a call a Support Engineer can explain why we work primarily asynchronously and set expectations for future
- A proactive call will reduce the liklihood of a STAR or escalation
Calls increase customer perception of support / GitLab
- Having a call with a customer gives them a chance to see and interact with a human
- Tickets with calls are more likely to receive an SSAT response
- Calls are more inclusive because they treat customers as they want to be treated, rather than forcing customers to treat us how we want to be treated.
Calls increase support perception of customers / build customer empathy
- Talking to a human customer and understanding the personal or business impact of a problem helps support engineers empathize with customers
Calls are consistent with our Values / Operating Principles
- Kindness - customer calls are a kind and understanding gesture that recognizes the impact GitLab tool problems have on our customers as humans
- Get to know each other - customer calls help us to get to know our customers
- Don't let each other fail - when a customer is struggling to articulate themselves, is under business pressure to have something resolved quickly calls help us show our attention and care in a tangible way.
- Customer Results - We should take responsibility for what the customer experiences, even when it isn’t entirely in our control.
- Sense of Urgency / Bias for Action - moving to calls quickly demonstrates our sense of urgency in resolving customer issues
- Efficiency for the right group - in some cases customer calls may be less efficient for Support, but are more efficient for the customer
- Embracing Uncomfortable Ideas and Conversations - When we are willing to embrace being uncomfortable, we can focus on actually fixing the issues at hand rather than simply "appearing to care".
- Reduce cycle time - instead of one response every 24 hours, many responses in 15m - 1hr.
- Low Level of Shame
Resistance
There are multiple issues that show engineer discomfort and resistance to calls. #4649 (closed) is a recent example.
I've paraphrased and grouped here.
Please feel free to edit the issue to contribute to this section rather than making a comment.
Calls are inefficient
- Sometimes customers who want calls immediately don't actually need them: within one or two replies we can resolve the issue with no synchronous communication.
- If a customer wants to live present an issue, a screen-recording would be more efficient
- After a call, a significant amount of work has to be done to capture all information from that call on the ticket in written form as well
Calls will negatively affect our ability to deliver Support
- We couldn't handle the additional amount of work that this would lead to / Support costs will balloon.
- Customer calls are hard to get off of once they've started
Calls will negatively affect customer expectations
- With easier access to calls we abdicate the "We expect for non-emergency tickets that GitLab administrators will take 20-30 minutes to formulate the support ticket with relevant information." guideline from our current Statement of Support: customers will get lazy and default to sync workflows.
- Freer access to customer calls will invite / encourage less technical users administering GitLab servers
- Once you give one call customers will expect subsequent calls: both in individual ticket interactions as well as their expectation of support in general.
- Customer calls don't stay on topic and can expose additional problems with the "While I have you..."
Calls will negatively affect me personally or one of my colleagues
- If I were taking more regular customers calls, even a single 15 minute call a day, I would very likely see a dip in performance due to the stress and anxiety of taking the call.
- Calls require time to prep for and post-call time to document and respond: more calls will affect engineer ability to work tickets.
- Some people just are better with calls than others
Calls run run against our Values / Operating Principles
- Customer calls run contra to our DIB operating principle of Bias towards asynchronous communication
- Embrace Neurodiversity is an operating principle, for some individuals customer calls simply aren't possible.