Executive Business Reviews (EBRs)

View the CSM Handbook homepage for additional CSM-related handbook pages.

Overview

An Executive Business Review (EBR) is a strategic meeting with stakeholders from both GitLab and the customer. It is an extension of the account planning process and part of the CSM’s regular business rhythm. The EBR aims to demonstrate to the Economic Buyer the value they are getting in their partnership with GitLab. It is interactive from both sides, discussing the customer’s desired business outcomes and related metrics, progress against these metrics and desired outcomes, and aligning on strategic next steps. The most crucial element in all EBRs is giving the customer stakeholders the time to speak about what matters to them, and creating a framework to enable them to do so.

CSMs should have 1 EBR per customer per year at minimum.

What constitutes an EBR?

An Executive Business Review’s purpose is to align on strategy and discuss progress to date. It is a conversation focused on outcomes. Often, the Executive Business Review follows a standard format and prep process outlined below and uses the standard slide deck template. However, any meeting with the appropriate stakeholders & leadership on both sides in which details about outcomes and value-based initiatives and a clear path forward on high-level areas of focus to achieve those outcomes are agreed upon, can be considered an Executive Business Review.

The key ingredients for an EBR are alignment and outcomes pertaining to business value.

EBR management for a CSM’s book of business

As a key strategic engagement with customers, EBRs should be forecasted and planned with a long time horizon. CSMs should plan out their intended EBR delivery schedule for the full fiscal year, based on the target of conducting an EBR halfway through a customer’s renewal cycle (6 months from the renewal date).

Intended participants

As the EBR is meant to provide high-level alignment on progress & success, as well as objectives and strategy for the future, we aim to have senior leaders and stakeholders from both GitLab and the customer present.

From the customer side, these may include:

From GitLab, in addition to the account team this may include:

Decisions about who to invite to an EBR are made collectively by the account team with input from their respective managers.

Lifecycle and timetable

This section outlines the typical flow of an EBR covering preparation, delivery, and follow-ups. As noted above, not every EBR necessarily follows the standard flow and format - but many do, and for those situations this information provides the guide.

Stage DRI Completion date Details
Internal kickoff CSM 3-4 months prior to intended EBR date Align with account team members on target timing for the EBR, goals & objectives, topics/focus areas, and intended participants.
Initial discussion with customer CSM 3-4 months prior to intended EBR date Discussion occurs several months out to provide time for all subsequent steps, and to get the right attendees included.
Scheduling CSM, collaborating with customer contacts 2-3 months prior to intended EBR date An EBR is considered “scheduled” when a specific date & time has been picked and customer invites accepted, based on confirmed availability of intended attendees. Once scheduled, reach out to GitLab leaders you would like to have participate.
Planning & assembly CSM, collaborating with customer contacts and account team 1 month prior to scheduled EBR date Build the EBR using our EBR template as a starting point, and in collaboration with the GitLab account team, customer participants/contacts, and anyone else who will be involved. The Success Plan is used to frame strategic alignment and objectives.
Semi-final internal review CSM leading, with GitLab presenters and attendees 3-4 weeks prior to scheduled EBR date Align with all members of the account team and other GitLab participants on EBR plan, and iterate based on collective feedback. The slide deck and talk track should be mostly complete by this meeting.
Final review with customer CSM leading, meeting with customer contacts and account team members 2-3 weeks prior to scheduled EBR date Validate that the content and intended messaging is aligned with their org’s expectations, and that we have accurate details regarding their objectives.
Final internal review & prep CSM leading, all GitLab attendees & presenters 2 weeks prior to scheduled EBR date This meeting needs to include all GitLab team members who will be present for the EBR and ensure that everyone is aligned on the plan and objectives. The slide deck and talk track is complete by this meeting, except for any minor adjustments done during this review.
Send agenda & event details CSM 1 week prior to scheduled EBR date Email all participants with the agenda for the meeting, and other relevant details to ensure everyone is prepared for the EBR.
Delivery CSM leading, in collaboration with SAE/AE and leadership 6 months before upcoming renewal This is the main event! Everyone involved is clear on their role and the goals for the EBR.
Follow-ups CSM managing; others specified for each follow-up 0-7 days after EBR delivery Follow-ups that have rapid turnaround should be completed within a few days of the EBR, and no later than one week. Examples include product feature information and scheduling of subsequent meetings.
Success planning CSM 0-3 days after EBR delivery Success planning is a critical part of a successful EBR, since the information learned from and discussed during the EBR feeds directly into our strategic roadmap for the customer and is documented in the success plan.

Internal kickoff

The first step in preparing any EBR is aligning internally with the account team. This discussion covers:

  • Target timeframe for the EBR to be scheduled
  • General review of the customer’s current state and roadmap
  • Goals & objectives for the EBR
  • Topics and focus areas
  • Intended participants & attendees, both from GitLab and from the customer

This meeting can optionally include other GitLab team members that the account team has previously agreed they would like to have participate in the EBR.

Initial discussion with the customer

During the next cadence call, the CSM discusses the EBR with the customer contacts. If this is the customer’s first EBR with GitLab, explain to them what it is and what value it brings. Ensure they know key stakeholders should attend and ask them to help with scheduling for those participants. After the cadence call, follow up with a written summary of the EBR and reiterate your ask for help in scheduling. Finding availability on all calendars can often require weeks or months of lead time, which is why this conversation should happen no less than 3 months ahead of the target timeframe for the EBR.

Resources to help you with this discussion are available.

It may be beneficial, or even necessary, to follow up on this discussion in other mediums. In addition to the follow-up email after the cadence call, a separate email specifically for the EBR can help keep focus on planning. If there is customer communication via other platforms like Slack or the collaboration project those are also good vectors for this discussion.

Scheduling

Getting an EBR scheduled can be one of the more challenging aspects of EBR prep since it requires coordination of schedules for several people across both GitLab and the customer’s organization. As such, it is imperative to start this process as early as possible and keep focus on it until a date & time are agreed on.

The EBR is not considered scheduled until calendar invites are sent & confirmed by at least the key participants. The CSM keeps track of scheduling efforts and drives this until participant attendance is confirmed. {: .alert .alert-gitlab-purple}

EBR length

The recommended length of an EBR is typically 90 minutes, however this is flexible based on customer need and content.

Any EBR should be structured to provide time for key focus areas, with plenty of discussion on customer objectives and roadmap. If key personas cannot participate for the full session, arrange the EBR agenda to cover the topic(s) most relevant to these personas at the beginning to ensure maximum benefit to all involved.

If you need to condense an EBR based on available time, review the guidance on how best to do that.

GitLab participant alignment

Once the EBR is scheduled, the CSM (or others if agreed during the meeting) will reach out to GitLab team members and leadership that they would like to have on the EBR with details such as:

  • Date and time for the EBR
  • Whether the EBR is intended to be in-person or virtual
  • What involvement/role you would like the person to have in the EBR
  • Next steps & timeline for EBR prep the person should be aware of, including subsequent planning meetings

As you move into planning the EBR, ensure that every GitLab participant has an active, clearly defined role in delivery. Take advantage of the opportunity to align leaders on both sides and strengthen the partnership by asking them to drive certain parts of the discussion. {: .alert .alert-gitlab-purple}

In-person considerations

An in-person EBR is ideal to maximize the interaction and discussion between participants. To ensure maximum value for all involved, additional sessions should be scheduled around the EBR itself. These include:

  • Enablement sessions, aligned with either ongoing adoption efforts or future adoption agreed upon as part of the EBR
  • Meetings with customer stakeholders for GitLab use cases to align and enable on use case adoption & value

Sessions should be planned and scheduled in advance, with proactively prepared topics, and managed or coordinated by the CSM. Open-ended or unstructured sessions (e.g. “office hours”) should be avoided.

Travel & Accommodations

Travel should be booked & planned two weeks prior to the EBR to ensure all client stakeholders and attendees are still confirmed for the day of. Travel and expenses are to be booked through Navan. Do a suggested review of the travel & expense handbook pages prior to planning.

Cadence call mini-EBR

Although we strive to include senior leadership from the customer in an EBR, that may not always be possible. If after two attempts to request an EBR with the decision makers and influencers the CSM is still unsuccessful, extend an upcoming cadence call to one hour and use this session to show the value of the EBR conversation.

The important thing is to conduct an EBR with a focus on strategy and objectives, both to align with our current contacts and to position a future EBR with stakeholders and leadership.

Review the guidance on shortening an EBR to consolidate your program for a cadence call EBR.

While an EBR is a specific motion, we should naturally treat all cadence calls as a “mini EBR” to enthrall our key contacts, continue demonstrating GitLab’s value, and entice the customer to learn more and engage more readily with a full EBR. {: .alert .alert-gitlab-purple}

Planning & assembly

This is the longest phase of the EBR process, since this is when the EBR actually comes together. Leveraging all of the details we know about the customer across different sources, and collaborating with customer contacts, the content & discussion points for the EBR are assembled.

Use the GitLab EBR template to create your slide deck. Please ensure you are using the most current template, rather than copying a previous EBR deck, by starting from the template linked here.

The customer’s success plan forms the basis of the EBR. Think of the success plan as the blueprint for the EBR content. A well-formed success plan provides the key information you need to discuss customer strategy, objectives & goals, accomplishments, progress on current initiatives, and roadmap for the future.

Throughout the process we should align with the customer on discussion points and details, and ensure we are highlighting their accomplishments as part of the messaging. While the CSM is the DRI for the EBR, it is a collaborative effort between the CSM, the other account team members, and the customer. There should be no surprises in the content of the EBR for anyone involved. {: .alert .alert-gitlab-purple}

If you plan to discuss product information, ensure you align with the right GitLab team members for that discussion as early as possible. This may include a Product Manager, Customer Success Engineer, Solutions Architect, or other subject matter experts. Give these team members ample time to align on the plan and prepare their portion of the EBR program.

The CSM and their manager will periodically review the EBR as this stage progresses. The CSM Manager ensures that the focus areas are appropriate for the participants and in line with expectations for an EBR.

Structuring the agenda

The agenda should be optimized for the participants, and prioritize discussion on strategic objectives and customer journey. Here are some points to consider when building the EBR agenda:

  • Highlight recent successes of your primary team and champions upfront in the call (e.g. during introductions)
  • The business objectives & goals portion should be the majority of the meeting and should begin as early in the conversation as possible
  • Avoid tactical conversation topics such as feature requests, support tickets, etc., as these can be discussed during cadence calls and are not strategic or relevant for the Economic Buyer
  • Be very selective of if you want to have a product update or overview. It’s recommended to use the EBR to get buy-in on further product adoption that are most aligned with the customer’s needs and using the opportunity to secure agreement on a follow up session. However, if a product overview during the EBR would help drive buy-in and ROI, ensure it is extremely relevant, succinct, and tied directly to their business objectives.
  • Define next steps that are both actionable and accountable, and ensure that any next steps that formed throughout the EBR itself are captured and shared with the customer afterwards

Semi-final internal review

Several weeks before the EBR, the account team and other GitLab presenters meet to go over the content and plan for the EBR, and make revisions based on collective feedback. By this point the EBR’s slide deck and talk track are mostly complete, and changes from this point forward are iterative. All presenters should come away from this meeting feeling confident in the EBR’s readiness to be reviewed with customer contacts.

This meeting can optionally include GitLab leaders that will be present, to get their feedback and align on the plan for EBR delivery.

Final review with customer

Throughout the development of the EBR the CSM & account team collaborate with their customer contacts. Ahead of the EBR delivery a final review of the EBR is conducted with the account team and customer contacts, to validate that the content & talk track is in line with expectations and properly structured.

If any portion of the EBR is to be delivered by a person on the customer side, they should be present at this meeting and leave with alignment on this delivery.

Only minor changes should happen at this stage, and the result of this meeting should be alignment between GitLab & the customer on how the EBR will be delivered. {: .alert .alert-warning}

Final internal review & prep

All GitLab participants in the EBR meet for a final review of the EBR’s content, talk track, and delivery plan. Ideally no changes are made at this phase, but any that are should be very minor and subsequently communicated to the customer contacts. All participants should come away with this meeting aligned on the following:

  • Each person’s role during the EBR, including the specific sections they are responsible for presenting or speaking to, and the key points & goals for those sections
  • Overall goals for the EBR
  • Customer participants and their expectations

Once this meeting is over, the EBR content is locked in and should not be changed. {: .alert .alert-gitlab-orange}

Send agenda & event details

Before the actual EBR delivery, the CSM sends an email to all participants (both at GitLab and on the customer side) with details for the day of the EBR, including:

  • The agenda for the EBR
  • Logistical details (location, timing, etc.)
  • Additional relevant details (areas of focus for discussion, follow-on sessions planned for the day if applicable, etc.)

This information is sent no less than one week prior to the date of EBR delivery. {: .alert .alert-danger}

Delivery

The main event! This is the actual Executive Business Review presentation and discussion, where everyone comes together. During the EBR session, the CSM is responsible for leading the meeting. This means:

  • Start with the agenda & introductions: this should be brief, but take a few minutes to refresh on what the plan for the meeting is and who the participants are. Do not spend too much time on this though, so it doesn’t eat into time for the rest of the EBR.
  • Focus on customer objectives and perspective: throughout the meeting, ask questions and open the discussion to customer personas to share their thoughts.
  • Pace the meeting appropriately: keep an eye on time and move the discussion along based on how the conversation is going. Don’t rush the customer or cut off good discussion, but keep things moving at a comfortable pace.
  • Hand off sections to the designated presenter: know the plan well, and who is covering each section, in order to cleanly transition to each person & topic.

The CSM should ensure that notes are taken throughout the meeting, and explicitly ask team members to aid in note-taking. If appropriate based on the EBR program, the CSM can ask one or more team members to act as primary note-takers. Notes do not have to be verbatim, but the more detailed the better. Key information to document includes customer insights, success criteria & metrics, strategic objectives, experiences with GitLab, Q&A, and any action items on both sides.

A successful EBR results in a clear understanding of customer objectives (along with any available success criteria & metrics), and alignment on next steps to keep things moving forward following the EBR.

Discussion guidance & questions

Here are some questions that may be helpful to guide the conversation and discover business objectives:

  1. Tell us about your largest initiatives right now - where are you focused?
  2. As you look at the year ahead, what are your key 2-3 initiatives?
  3. What has changed since last year?
  4. What would you like things to look like in the next couple years - where do you want to be?
  5. On the security front, we see customers struggling with the triage process. When you have a security issue, what does the resolution process look like? Who is involved?
  6. How do security vulnerabilities affect your cycle time?
  7. Can you spend some time on your overall cloud and app modernization strategy?
  8. What visibility or insights does your leadership have? How are you collecting this information today?
  9. (If customer describes an objective with no metrics) Would you please describe what ‘good’ will look like for this initiative? How are you thinking about/measuring progress against this effort? What are your success criteria?

Follow-ups

After the EBR session is complete, there are steps to take on the takeaways from the session.

Summary email

Within 1 business day of the EBR, the CSM sends an email to all participants. In it, they will thank everyone for their participation and partnership, and summarize key takeaways & next steps, with timelines and persons responsible for each item. Attached to this message is a copy of the slide deck, and any other materials that were agreed on to be shared.

Log in the Gainsight Timeline

Once an EBR is finished, add a Gainsight Timeline entry to catalog it. When adding a timeline entry type of either Customer Call Or In-Person Meeting, select the option Executive Business Review from the Meeting Type dropdown menu. Provide details about who was in attendance in the appropriate fields, as well as some summary details in the description.

Timeline entries added as described above drive our EBR reporting & metrics.

Action items

There will be several action items, follow-ups, and next steps defined both from the content prepared ahead of time and as a result of the discussion during the EBR. These are captured in the EBR slide deck, and in the notes taken collaboratively during the session.

The CSM is responsible for ensuring that all follow-ups are completed by the person responsible for each item. These should be completed in a timely manner, as soon as possible after the EBR.

Initial steps on follow-up items should be completed no more than one week following the EBR. {: .alert .alert-danger}

Success planning

No EBR is complete without updating the success plan.

Within a few days of the EBR, while the information is still fresh, the CSM updates the customer’s success plan. The EBR will have generated a lot of new information that will drive our strategy and actions with the customer for the coming months. All sections of the success plan should be updated, and objectives created and/or updated based on the EBR discussion & takeaways.

The CSM Manager will discuss the EBR with the CSM in their next 1:1 after the EBR, which will include reviewing the success plan.

EBR Enablement

  • A SAE/AE can be a great partner in positioning EBRs. For more on the value of EBRs, with customer examples, please watch this internal EBR enablement session.
  • Follow this link to access the EBR eLearning on Level Up.
  • Chorus Playlist gives you access to the recordings of the best CSM calls. The recordings are continuously updated, so keep this playlist bookmarked for best practices.

Resources & materials

  • EBR slide deck template: this is the standard template for Executive Business Reviews, aligned to the success plan format and focused on business objectives & results.
  • EBR FY Scheduling: This spreadsheet is used to help with the FY planning process. This helps get forward-looking visibility into when EBRs should be scheduled, and make adjustments to manage workload across the year.

Please also view our EBR Playbook (internal to GitLab) for more details on how to propose, prepare, and present an EBR.

Sample EBR proposal talk track

As we are reaching the halfway point through our current year of partnership, I wanted to schedule some time for us to meet and discuss progress against your business objectives and key initiatives. The goal of this time together is to:

  1. Amplify your accomplishments
  2. Show the progress against your key initiatives that you and the team have made
  3. Ensure we are aligned on (company name)’s upcoming key business initiatives

We’d like to invite xxx (influencers, decision-makers) to join also, and we’ll have some of our leadership team join. Would you suggest that my leadership or I reach out to them directly, or what is the best way to get time on everyone’s calendar?

Tips for shortening an EBR

Depending on the available time & delivery method of your EBR, you may need to shorten the program. Here are some tips for doing that:

  • Highlight recent successes of your primary team and champions upfront in the call (e.g. during introductions), just in case you run out of time at the end.
  • No matter the length of the EBR, the business objectives & goals portion should be at least 75% of the call and should begin as early in the conversation as possible, as this is the reason we’re here.
  • To help break it up even further, consider 50% of the call to be focused on existing objectives (validation, review of progress, how GitLab will help achieve those goals, questions from both sides on those objectives, etc.), and 25% to be open-ended conversation on future or additional objectives not already discussed. Depending on your familiarity of the account, those percentages may be swapped, as you’ll focus more time on learning about their objectives than discussing what you already know.
  • Avoid tactical conversation topics such as feature requests, support tickets, etc., as these can be discussed during cadence calls and are not strategic or relevant for the Economic Buyer.
  • Be very selective of if you want to have a product update or overview. It’s recommended to use the EBR to get buy-in on further product adoption that are most aligned with the customer’s needs and using the opportunity to secure agreement on a follow up session. However, if a product overview during the EBR would help drive buy-in and ROI, ensure it is extremely relevant, succinct, and tied directly to their business objectives.
  • As always, prepare your next steps to be both actionable and accountable, and ensure that any next steps that formed throughout the EBR itself are captured and shared with the customer afterwards.
  • If you only have 30 minutes, forgo the slides and presentation, but still come prepared with everything that would have been in the slides documented in a clear format that can be shared with the customer afterwards.
Last modified March 28, 2024: Resolve "Move Solutions Architecture outside of Customer Success" (1b1a8189)
View page source - Edit this page - please contribute. Creative Commons License