We aim to hire smart people, and let them be smart. This means we try to offer sensible guidelines that will help, but avoid “scripts” or rigidity. Speak in your natural voice as you would to a peer at a conference. Obviously avoid unprofessional language, but you’ll want to match the customer’s tone. There is often a desire to “unify” by everyone speaking in a robotic tone:
“Thank you for contacting support. We can help you with this. It looks like you are asking for help with resetting your password…”
This dehumanizes us and we lose our best asset: Support from a human. When you speak more naturally it anchors that we are also real people and not “support minds as a service:”
“Ah, sorry to hear that you lost your password. I’ve issued a password reset and you are good to go. In the future, you can use this link:
Let us know if there is anything else we can help with. “
At GitLab, we consider the elements of our responses carefully. If you find yourself wanting to use canned responses, or are saying the same things over and over, it's probably an opportunity to improve our process. That is, instead of creating a text expander asking for logs, take a step back. Is there something earlier in the experience of opening a support ticket that we could do to reduce the need for repetitive text? There are times when it's appropriate to use formal language and canned replies, but those will be rare. Whenever we can we push towards empathy and humanity and automate and preload the process.
Consider this spectrum:
Request requires -- v Pure process |--------------------|----------------------| Higher level thinking Robotic Support Voice |--------------------|----------------------| Empathy and Humanity Tone is -- ^
Be empowered: at GitLab Support we want humans with agency, not agents. If something feels broken, ask. If something feels inefficient, fix it. Everyone can and should contribute.
When it comes to actually answering tickets, the sandwich method is a great 3 point guideline that will help you elevate your responses. A great customer reply will contain the following 3 things:
For example, a customer might ask:
“ My GitLab server appears to be slowing down. Can you help me?”
An okay response is:
“ Please send us over your production logs and we can use that to troubleshoot some more. “
Notice we asked for what we needed, and we’ll be able to help. Let’s make it great using the sandwich method:
“It will be helpful to get as many logs as possible during the slowness to help us isolate the problem. You can find them in /var/log/gitlab (This is our ask)
Usually when we see slowness, it’s isolated to a specific part of the application. Can you help us narrow down the issue by outlining when you see things slow down? (This is our premise for them to reenforce our expertise.)
Once you send these over and help us understand how you are getting to the slow state we’ll be happy to help you dive in some more.” (This is us reassuring them we’ll help.)
We’ve asked for what we need early. Hit them with it, so they can start thinking on it and if they stop reading right there, they didn’t miss the ask. We’ve given a hypothesis which is something for them to chew on and understand our vantage. We don’t want to serve our customers we want to partner with them. This is one way for them to see us as a peer vs. “support minds as a service.”
We then make sure to let them know we are still here and will be when they come back.
There will be times where you might need to add more or even apologize for something, but this method should be applicable to the majority of tickets and help us deliver excellence.