Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Customer calls

  1. You are here:
  2. Handbook
  3. Support Team Handbook
  4. Support Workflows
  5. Customer calls

Introduction

This page presents the workflows to be used in Support Engineering to schedule, prepare for, manage and follow-up on customer calls.

Emotional Headwinds

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:

  1. Stop and experience what you're feeling without judgement.
  2. Be curious about your feelings: is any of your resistance related to a core fear?
  3. Try and separate out the facts of the case: form "steel man" arguments for resolution time, SSAT or customer experience to round things out.
  4. Empathize with the customer and try and see the case from their perspective.
  5. Talk with a peer or manager to give yourself a second / more objective opinion.

When should a ticket go 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:

At GitLab Support we use two operating principles to help us interpret the sometimes conflicting guidance:

  1. Customer Results: Our focus is to improve the results that customers achieve
  2. Freedom and Responsibility over Rigidity: we give people the responsibility to make a decision and hold them accountable for that

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.

Markers for when you should consider moving to a call

  1. The customer asks for a call: One of the fastest ways to get a negative SSAT rating is to flat out refuse a call. You don't have to immediately jump to a call. However, you should strongly consider communicating your availability and how to gather and upload any information that will make the call effective.
  2. The ticket has failed to progress after several interactions: If a customer isn't providing needed data, is having trouble describing the problem or is signalling that our urgency isn't matching their urgency in resolving the problem you should strongly consider moving to a call.
  3. The ticket has received a STAR: STARred tickets represent situations that have been highlighted where SSAT has been threatened by some factors within or outside of our control. Moving to a call may help restore the relationship. Providing quick, high quality counsel may calm customer concerns.
  4. There's a critical missing element between the customer's reported experience and your reproduction: Sometimes a customer leaves out an important contextual detail that isn't within your immediate troubleshooting tree. Moving to a call can help make sure you're both starting from the same spot.
  5. The customer's tone within the ticket has shifted negatively: Sometimes offering and initiating a call can show our commitment to solving the customer's problem. Talking with a technical peer helps build trust and empathy on both sides.
  6. The next steps in the ticket are complex or have a branching decision tree: There can be points in the troubleshooting process where it's best to switch into the more highly interactive communications mode of a call so that you can provide direction, observe results and provide real-time feedback until it makes sense to go back to async.
  7. A Support manager has recommended a call: When reviewing a ticket, a Support manager will often take the points above into consideration along with possible outside context from the customer or other GitLab team members, and recommend moving to a call.

Types of calls

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.

Discovery calls

Purpose

A Discovery call is a short call with the sole purpose of learning enough to start troubleshooting asynchronously again.

Duration

15-30 minutes

Troubleshooting calls

Purpose

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.

Duration

30-60 minutes

Reset & Review calls

Purpose

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.

Duration

15-30 minutes

Upgrade Assistance

Purpose

Premium Support customers may request a call as a part of upgrade assistance. Read more about this in the dedicated Upgrade Assistance workflow.

Duration

30 minutes

Taking Calls

Scheduling the call

When you know a ticket is ready for a call, start by determining who will lead the call:

graph TD A{Does the customer want to
meet during my work hours?} A --> |Yes| B{Am I comfortable leading the call?} A --> |No| C(Find someone in the appropriate
region of your group who is
willing to take the ticket,
preferably but not necessarily
with the needed expertise.
The new SE can pair with another
person in their region if necessary.) B --> |Yes| D("Proceed to
#quot;Providing the call link#quot;") B --> |No| E(Pair with an SE who has the right expertise) C --> H("(sync or async)" Review the ticket with
the new SE before handing it over.) E --> F{Look for an SE in your group} F --> |Found one!| D F --> |Didn't find one| G(Find an SE from the
rest of Global Support.
Get manager help if needed.) G --> D

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:

Removing the need for a call before it even starts

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:

  1. I'll need to do some additional research on that and follow-up with you in the ticket.
  2. To the best of my knowledge, the answer is X - but let me confer with a subject matter expert and get back to you.
  3. At this juncture we've made some good progress, but there are some outstanding questions that need follow-up. Let's move back to the ticket, and once I've got a bit more information I'll send that along.
  4. Homework on my side is: X, on your side: Y. Let's move async for now and schedule a follow-up for later this week.

Pre-call email

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.

Tips to keep calls within the scheduled time:

Example:

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

Tips for making calls successful

Under development in MR: www-gitlab-com!117224

Customer No Shows

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.

Post-call

Congratulations! You made it through the call. Unfortunately, your work is not yet over (even if the issue was solved).

Call summary

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.

Special Handling

WebEx

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.

WebEx Login

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

WebEx Room

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.

If a customer wants to record a support call

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.

Audio and Video Guidelines for Support Engineers on Customer Calls

Video

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 about video, environment and dress on our communication page and our all-remote meetings page.

Audio

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 License for GitLab Support Team

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.

Open in Web IDE View source