Introductory Meeting

Purpose, structure and goals of an introductory meeting between an ASE and their new account, and tips for how to make the meeting successful

Overview and Purpose

When a customer account signs their first contract for a GitLab Assigned Support Engineer (ASE), we need to be prepared to start delivering the service on day one of the contract. But what exactly are we delivering? Even with the terms being spelled out in the signed Statement of Work (SOW), we can’t really answer that question until we meet with the customer to tell them who we are, learn who they are, learn how and why they use GitLab, and learn their reasons for signing that contract.

With that purpose in mind, the ASE and their manager should work with the account team to schedule an hour-long introductory meeting with key members of the customer’s team to occur on the first business day of the SOW. If the ASE or the customer is not available on that day, schedule the meeting for no more than five business days later.

Goals

There are only a few goals for this meeting:

  • Gain a shared understanding of how you and the customers will and won’t work together
  • Begin the relationship building between you and the customers
  • Learn what the customers really want and need from you

Optional Pre-introductory meeting between ASE and CSM

Before your introductory call, it’s advisable to meet with the CSM you’ll be working alongside. Here are some key points you should go over to ensure you’re both aligned and can help each other succeed:

  • Brief Introduction / Chat: Discuss work styles, preferences, expectations, and how you can best support one another.

In addition, it’s also highly recommended to address the following items during the meeting, as these tips are essential for effective customer-facing interactions:

  • Avoid assigning labels to colleagues during all interactions, particularly those that are customer-facing. For instance, a CSM should refrain from making statements like, “This ASE is really good at CI/CD.”
    • Such statements can inadvertently influence the customer’s expectations and perceptions, potentially leading to misalignment between what is promised and what is delivered
    • Labeling can create preconceived notions about specific team members' roles or expertise, which may not accurately reflect their full capabilities or responsibilities.
  • Demonstrate Mutual Trust: Show a high level of trust in each other’s abilities. If any concerns arise, address them privately, away from customers, to maintain professionalism and avoid undermining confidence.
  • Coordinate Before Involving Additional Resources: Always communicate and discuss matters thoroughly before considering the need to involve other resources.

Structure

  1. Introduce yourself
    1. Tell them your name
      • be sure you say your name clearly and slowly enough for them to understand
    2. Tell them a little about your experience at and with GitLab
      • how long you’ve been at the company
      • how long you’ve been a support engineer
      • how long you’ve been using our products
      • what are your biggest strengths with GitLab and supporting technologies
    3. Tell them why you are excited about the opportunity
    4. Tell them how you work
    5. Tell them your time zone
  2. Ask them to introduce themselves
    1. Name
    2. Role
    3. Time zone
    4. GitLab expertise
  3. Review the ASE role, constraints and SOW
    1. Let them know how you’ll work with them
    2. Let them know how you’ll work with the account team
    3. Ask what questions they have for you
    4. Ask who your primary contact(s) will be
    5. Ask what their goals are for working with you
  4. Learn about their GitLab-related Plans
    1. Why did they become GitLab customers?
    2. How are they using the product right now?
    3. What’s going well and what’s not going well?
    4. What are their goals for using GitLab?
    5. Determine whether it would make sense to use a collaboration project to track any long-term plans

Tips

  1. State clearly to the account team when the meeting is being scheduled that the ASE will run the meeting and that they will use the entire meeting for their set agenda.
  2. For the meeting to be successful, all stakeholders must participate. This can include:
    1. The customer’s technical people who are expected to be the ones working with the ASE on a frequent basis
    2. The individual(s) designated by the customer to oversee and assess the success of the ASE engagement
    3. The ASE
  3. Do not let the meeting become a troubleshooting session
  4. Throughout the meeting, be sure that you speak clearly, slowly but not too slowly, and loudly enough but not too loudly - your aim is to be heard and understood the first time
  5. Be yourself, gently: let the customers get to know you a little at a time
  6. Be friendly and happy, and let the customers feel your energy and excitement around this opportunity
  7. Be early to the meeting, and welcome each person as they join
  8. This meeting is your first opportunity to set expectations with the customer, so let them see how we, and you, operate: stay on your agenda, keep the meeting flowing, be sure somebody is taking good notes, and end the meeting on time
Last modified November 5, 2024: enhanced support handbook structure (6f6080e5)