GitLab defines Commercial Sales as worldwide sales for the mid-market and small/medium business segments. Sales segmentation is defined by the total employee count of the global account. The Commercial Sales segment consists of two sales teams, Small Business (SMB) and Mid-Market (MM). The Commercial Sales segment is supported by a dedicated team of Solutions Architects (SA) and Technical Account Managers (TAM).
Solutions Architects are aligned to the Commercial Sales Account Executives by a pooled model. Requests for an SA will be pulled from the triage board by an SA based on multiple factors including availability, applicable subject matter expertise, and workload.
Technical Account Managers that support Commercial Sales are aligned by region (Americas East, Americas West, EMEA, and APAC). Not all accounts will have a dedicated TAM. Account qualification is required.
To request SA assistance, create an issue on the Americas Commercial SA Triage board or the EMEA Commercial SA Triage board using the relevant issue template. For more detail on creating an issue, please reference the Solutions Architect Handbook page.
Typically, once an SA pulls the work from the Triage board, that SA will consistently service that customer after that first meeting. Additional triage requests should not be required for follow-on meetings or other customer outreach so as to create a consistent customer experience via a singular technical contact. SA's may always call on each other for assistance as needed. Typical conditions where other SA's will get involved in an account include:
Once a customer enters or completes a technical evaluation of GitLab, it is the responsibility of the Account Executive to transition the opportunity stage within Salesforce from Stage 3 to the next logical stage. It is the responsibility of the SA to ensure that Stage 3 transition data (such as win/loss reasons) have been properly entered, the migration from stage 3 has happened in a timely manner once SA activity is complete, and any POV data and status is correct in Salesforce.
There is also a detailed walkthrough of SA activity and metrics during the Commercial Sales Buyer's Journey.
As a best practice, an SA should not attend discovery calls as it does not lend itself to scaling the SA team efficiently. However, there are times when SA attendance on a discovery call is the right activity. This will be left to the discretion of the Account Executive, but may include reasons such as:
Avoid direct messaging an SA for general questions. Technical questions should be posted in the #cs_commercial Slack channel.
Avoid last-minute meeting requests. SA's cannot commit to these with any consistency. SA's will do their best to accommodate as schedules allow, but it does not allow the SA sufficient prep time for customer context and frequently results in a sub-optimal experience for the customer.
SA's help with guided POV's, but as a general guideline they do not provide real-time help for free trials. For product evaluations with IACV greater than $10K USD, existing trials should be converted to a Proof of Value so the SA can better assist the customer.
Any time IACV or services revenue is involved, the SA should be involved.
SA’s can partner with customers but should not be doing the work for customers - this requires Professional Services.
SA’s should never have hands on customer keyboards or give real-time coaching on production systems - this requires Professional Services.
SA’s can advise on implementations but should not formally design production implementations - this is a paid Professional Service.
SA’s can provide best practices, usage direction and documentation guidance, but do not provide specific directions on non-standard use of GitLab.
SA’s can provide a set of getting started links and resources around GitLab features and functions based on customer need.
SA’s should be able to leverage existing resources as much as possible vs creating custom content for specific customers.
SA’s should be part of proposing or committing to any workshops, POV’s, on-sites or other time-intense engagements.
Since the SMB team does not currently have dedicated Solutions Architects, the SMB team may engage the Mid-Market CS team for pre-sales or post-sales support using the following guidelines:
SMB Customer Advocates may request asynchronous technical pre-sales assistance for any SMB prospect using the Commercial SA Triage Board via the process documented on the Solutions Architects page, or they can request asynchronous technical post-sales assistance for current SMB customers using the Commercial TAM Triage Board.
The SMB Customer Advocate should obtain as much detail as possible and post the technical questions from the client into an issue on the relevant Commercial Triage board.
The relevant Mid-Market CS team will respond in the issue with answers within 48 hours unless otherwise noted by the CS team.
SMB Customer Advocates may request synchronous technical assistance when opportunity threshold criteria are met. The request for real-time pre-sales assistance should utilize the Commercial SA Triage Board via the process documented on the Solutions Architects page; for real-time post-sales assistance, the SMB Customer Advocates should utilize the Commercial TAM Triage Board. If the prospect does not meet the criteria below, the request will be handled asynchronously, as outlined above, but SMB Customer Advocates may still inquire about surplus bandwidth and/or availability of the Mid-Market CS team using the #cs-commercial channel in Slack.
Criteria for Synchronous Engagement:
Engagement Limitations:
For commercial accounts, we do not currently offer our customers Slack channels unless they meet specific criteria and it would be highly beneficial to both the customer and GitLab teams. Prior to creating the channel and provisioning access, the TAM for the account must approve its creation and use. To qualify, the customer should be at minimum:
Collaborative projects should be suggested first with few possible exceptions (such as reference customers, early adopters or strategic partnerships). If the customer is evaluating GitLab or doing a POV for an upgrade, SAs or TAMs can request an ephemeral Slack channel, but the channel should be closed within 90 days if it does not meet the criteria shown above. Slack is simply too intensive to scale for Mid-Market and SMB.
Meanwhile, it is not scalable for every customer to have a collaboration project, and the CS team will determine the need for a project on a per-customer basis.
A seamless customer journey requires a continuous flow of relevant information between the roles at GitLab with customer outcomes in focus. Below are some examples of the transfer of information between roles that may be required.
