View the CSM Handbook homepage for additional CSM-related handbook pages.
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 conduct EBRs with their customers as follows:
| Segment | Cadence |
|---|---|
| Commercial | 20% of book of business is offered an EBR per year, in line with the goal of having 20% of the book of business be PR1 |
| Enterprise | 1 EBR per customer per year minimum |
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).
CSMs can use the EBR FY Scheduling spreadsheet 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.
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.
Below is an overview of the EBR process from start to finish. Timelines are listed relative to the EBR delivery date to provide a roadmap.
| 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. |
The first step in preparing any EBR is aligning internally with the account team. This discussion covers:
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.
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 availabilty 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.
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.
The recommended length of an EBR depends on the customer's segment:
| Segment | Length |
|---|---|
| Commercial | 60 minutes |
| Enterprise | 90 minutes |
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.
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:
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.
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:
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.
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.
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.
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.
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:
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.
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.
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:
Once this meeting is over, the EBR content is locked in and should not be changed.
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:
This information is sent no less than one week prior to the date of EBR 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:
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.
Here are some questions that may be helpful to guide the conversation and discover business objectives:
After the EBR session is complete, there are steps to take on the takeaways from the session.
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.
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.
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.
October 19, 2022: with the revised guidance on EBR timeline added to this page, the timing of when the EBR CTA in Gainsight is created is currently under discussion and may change to align with the information contained in this page. For details please look at the issue (GitLab internal only).
A CTA in Gainsight will automatically open seven months before renewal, with a due date of 45 days later to give time to schedule, prepare for and conduct the EBR. In most cases the EBR process should have already started ahead of this CTA, particularly if we're delivering an EBR to a customer for the first time. If doing a more frequent business review, please manually open a CTA, and within this CTA, open the "EBR" playbook. The CTA is where you will track the completion of tasks necessary for a successful EBR.
If you do not plan to conduct the EBR within a reasonable timeframe (discuss this with your manager, but typically within 30 days of the target timeframe) close the CTA with details added for why it's closed, and then open a new EBR CTA when you start working on it again.
Please also view our EBR Playbook (internal to GitLab) for more details on how to propose, prepare, and present an EBR. This internal playbook also includes a link to EBR Fact Sheets, which CSMs can copy and edit to send to their customers to help demonstrate what the customer will get out of the EBR, as well as an "EBR in a Box" presentation which contains several pointers on the logistics of preparing, such as a suggested timeline, how to prepare and tips on presenting.
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:
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?
Depending on the available time & delivery method of your EBR, you may need to shorten the program. Here are some tips for doing that:
