This page presents the workflows to be used in Support Engineering to schedule, prepare for, manage and follow-up on customer calls.
We hire smart humans to provide smart support. Humans have feelings. It is important to recognize that there are emotional headwinds that can make it harder to schedule or be in calls. During a call you're putting yourself into a situation where you have to manage:
Calls can be a vulnerable experience that hit on core human fears:
Ignored (Opposite of Significant)
Humiliated (Opposite of Competent)
Rejected (Opposite of Likeable)
If you're feeling the results of any of these headwinds it can be easy to rationalize why you shouldn't move the ticket to a call. The feelings you're having shouldn't be ignored. Before judging whether or not to move to a call:
Customers are subject to the same fears Support Engineers are. To understand more about core fears of all people, consider watching this Introduction to Core Human Needs video and the follow-up video, Triggering Fears. Try to be mindful that your actions in a call can calm or trigger the customer's fears.
Be mindful as well that customers likely have pressures from their business or from their users who rely on GitLab. And, they may feel nervous or scared about appearing ignorant in front of a GitLab expert. It can be very helpful to seek to understand these forces acting upon a customer, as is discussed in these two videos:
Feelings aside, it can be difficult to sort out how to balance the demands of asynchronous ticket work and real-time support. There's a cost to customer calls in terms of preparation, running the call and doing the post-call work summarizing any findings and passing along next steps.
Various pieces of the Handbook can be used to justify a range of behaviors:
Use video calls if you find yourself going back and forth in an issue/via email or over chat. Guideline: if you have gone back and forth 3 times, it's time for a video call.
Take initiative to operate asynchronously whenever possible.
Consider the time investment you are asking others to make with meetings… Try to avoid meetings.
At GitLab Support we use two operating principles to help us interpret the sometimes conflicting guidance:
Our customer-facing Statement of Support section on video calls supports this:
At times it may be useful and important to conduct a call, video call, or screensharing session with you to improve the progress of a ticket…the support engineer… will determine:
- whether a call is necessary; and
- whether we have sufficient information for a successful call.
As a Support Engineer you are charged to act in the best interest of the customer. Customer calls are a tool in your toolbox. When used well, customer calls will allow you to be more efficient, build relationships and resolve tickets faster.
Feel free to adjust the length, timing and agenda of your calls to suit the needs of the ticket and customer. The following are examples of call types that Support Engineers have found useful in the past.
To the extent you can, try not to exceed the length of call you've arranged with the customer as this can set up unrealistic expectations for future Support Engineers working with the customer. If you feel that you're close to a resolution or need more time to collect info always pause and verify with the customer that they have the time to continue and note how much time you have left to continue.
A Discovery call is a short call with the sole purpose of learning enough to start troubleshooting asynchronously again.
15-30 minutes
A Troubleshooting call is a longer call where you'll work real-time with the customer to guide them through a series of troubleshooting steps you've crafted to gather additional information or make progress towards resolution of the issue.
30-60 minutes
A Reset & Review call is an opportunity for an engineer to connect with a customer on a long-running or high priority ticket to review the troubleshooting that's taken place so far and explain the next steps to be taken towards resolution. For high priority tickets that aren't quite emergencies in particular, establishing a cadence of Reset & Review calls early can help avoid (or ease the transition into) an account escalation.
15-30 minutes
Premium Support customers may request a call as a part of upgrade assistance. Read more about this in the dedicated Upgrade Assistance workflow.
30 minutes
When you know a ticket is ready for a call, start by determining who will lead the call:
Start by using the
General::Invite customer call
macro in Zendesk. Be sure to change PERSONAL_CALENDLY_LINK
to be your own personal
Calendly link.
When sending a customer a call link:
Support
(case insensitive). This is necessary for the event to appear in the
GitLab Support
Calendar.It's important to remember that customers also don't want to waste time on calls. The primary reason most customers want a call is because they believe it's the best use of time for them in making progress towards the resolution of their issue. In the interval between offering a call and hosting the call you have an opportunity to deflect the need for the call completely. It's prudent to shift into a more rapid response mode as you center in towards a call.
Having a customer engaged in forming the agenda for the call will help you do research and be well prepared. Ask the customer for (or prepare your own set of) questions that will need to be answered during the call. Once you have a list, (to the extent that time allows) answer them prior to the call within the ticket or provide instructions for how the customer can answer them for you.
For each item on your call agenda, seek to find a way to shift towards an async workflow to complete it prior to the call. For example, if the customer wants a call to demonstrate an issue: ask them to record their screen while reproducing the issue and tailing logs, and then attach the recording and relevant logs.
This will (potentially):
Remember: you don't have to solve everything while you're on the call. It is okay to schedule a follow-up if you hit time or knowledge constraints. Here are some phrases that could be helpful in moving back to async:
Please consider sending a pre-call email. This helps set expectations to the call regarding goals, duration, and
the people required to be on the call for effective troubleshooting. You can use the Support::Self-Managed::Pre customer call
macro in Zendesk
for that, please modify it as you see fit.
Example:
Today we're going to be looking at the configuration of your object storage for attachments. In the ticket you were able to provide the
values.yaml
for the deployment and we were able to capture some errors for viewing attachments. We were also able to verify that attachments were correctly being stored in S3. We haven't been able to verify if the IAM roles you're using have appropriate permissions to retrieve objects. We're going to spend 30 min. today running through a few scenarios that I've detailed in the ticket.
Setting context and expectations before you start the call is the best way to a graceful exit. Review tips to keep calls within the scheduled time for some tips on handling the overall call flow.
Some calls can be difficult to exit though:
Depending on the specifics of the situation you may need to get manager help, but often careful handling can be enough to reassure the customer of your commitment to seeing a timely resolution to their problem. It can be helpful to remember: you are responsible for coordinating the ticket and finding subject matter expertise to guide it to resolution. You are not responsible for directly reproducing and solving everything.
Overall: communicate that the customer can trust you and that you are proactively managing the situation.
A customer who has an understanding of what work will happen next and has secured commitments from you (that you will fulfill) for how you'll engage in the future will feel taken care of.
Managers can be called in by paging the on-call manager or tagging them in Slack if:
There are many reasons that a customer may not be able to join a call. If a customer doesn't join the call and you've waited for over 10 minutes, end the call, update the ticket and resend your Calendly link to schedule a new call. Your response on the ticket should just state that you're sorry you didn't get a chance to meet and that you invite them to use the link to schedule a new call.
Congratulations! You made it through the call. Unfortunately, your work is not yet over (even if the issue was solved).
The call summary is important for confirming with the customer what was said and done during the call, and documenting for them and for us the agreed-upon action plan.
Immediately following your call you should construct the call summary in
the Zendesk ticket using the macro
Support::Self-Managed::Post Customer Call
.
The macro provides a template to structure the summary and applies ticket tags
used to track work involving customer calls.
Why should the summary be written immediately? First, your ability to remember the details of the call will fade quickly, especially if the call was at the end of your day. Second, follow-up action may be required from others, and they will only be able to act appropriately if they have the call summary available.
When writing the call summary, keep in mind that your summary will be a source of valuable information for support engineers looking for resolution guidance from tickets similar to their own.
For some customers, only Cisco systems are allowed and in those cases, WebEx will be the best tool for calls. To start a call/session, use the GitLab Support
WebEx account. Go to our WebEx Portal, click on the login button on the top right and use the credentials found in the Support Vault on 1Password.
Once logged in, click the Enter Room
button to start the WebEx meeting and send the following link to the customer and ask them to join the call.
https://gitlabmeetings.webex.com/meet/gitlabsupport
Note: Make sure you lock the meeting so that you (as the presenter) have to allow people in. Otherwise others may attempt to use the room.
WebEx allows you to see the customer's desktop and to control it on request. It also gives the customer the possibility to join via phone and us the possibility to use our computer audio connection.
Frequently during screenshare sessions plaintext secrets or other sensitive information can be displayed. To ensure sure that any recordings that inadvertantly contain this information stay within customer's security boundary, you should ask that customers initiate and store any recordings.
If a customer wishes to record the session, then transfer the ownership of the call to the customer or ask the customer to invite you to a new call to make sure recording is done by the customer.
If you're not comfortable having the call recorded, please involve your manager in the discussion with the customer.
You're not required to turn your camera on, and some clients may elect not to. At GitLab we try to have our video on at all times because it's much more engaging for participants.
See more tips about video, environment and dress on our communication page and our all-remote meetings page.
You're strongly encouraged to use a headset with a microphone, but avoid AirPods because of audio quality and battery life issues.
See more tips on our All Remote Workspace page
Krisp.ai will mute background noise when you're in a noisy environment so you can hear and be heard more easily on calls. You may consider installing this app for your calls. GitLab Support team has a Teams Pro license. If you are interested in getting one, kindly leave a comment at this issue. Currently, it is unavailable for Linux.