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:
If you're feeling one of the results of one of these headwinds it can be easy to rationalize why you shouldn't move the ticket to a call. The feelings you're feeling though shouldn't be ignored. Before judging whether or not to move to a call:
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.
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.
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.
Premium Support customers may request a call as a part of upgrade assistance. Read more about this in the dedicated Upgrade Assistance workflow.
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
When sending a customer a call link:
Support(case insensitive). This is necessary for the event to appear in the
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, then and attaching 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 knoledge 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.
Today we're going to be looking at the configuration of your object storage for attachements. In the ticket you were able to provide the
values.yamlfor 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.
Under development in MR: www-gitlab-com!117224
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 would they please 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).
Immediately following your call you should construct the call summary in
the Zendesk ticket using the macro
Support::Self-Managed::Post Customer Call.
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. And as with all ticket documentation, it is a source of
valuable information for support engineers looking for resolution guidance from
tickets similar to their own.
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.
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.
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, 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 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.