@@ -15,7 +15,7 @@ This applies to all paying GitLab.com SaaS customers on [Premium or Ultimate](ht
## Who is involved in this process?
Customer Success Managers (CSMs) and GitLab Support are our customers' main contacts at GitLab. These teams will ensure that the communication with the customer takes place as efficiently as possible, will provide status updates regarding the log request, and ultimately hand out any artefacts that might result from the request to the customer.
Customer Success Managers (CSMs) and GitLab Support are our customers' main contacts at GitLab. These teams will ensure that the communication with the customer takes place as efficiently as possible, will provide status updates regarding the log request, and ultimately hand out any artifacts that might result from the request to the customer.
GitLab Support handles non-complex application log requests that are within a 7-day time window from the time of the request, and which don't disclose
Personal Data, such as user names and IP addresses.
1. GitLab Support or CSM verifies that the requesting customer complies with our [conditions and requirements](#conditions-and-requirements) for the request.
1. The relevant team (either GitLab Support or GitLab Security) starts working on the case, depending on the type of requests. The issue is updated with every new finding.
1. GitLab Support or CSM provides status updates to the customer based on the updates captured in the issue on a 12-hour/business day best-effort cadence.
1. Once the requested artefacts (i.e. log entries) are collected, GitLab Security and GitLab Legal review them.
1. Once reviewed and approved, GitLab Support or CSM [share the artefacts](/handbook/support/workflows/log_requests/#sending-logs-and-other-personal-data) with the requesting customer.
1. Once the requested artifacts (i.e. log entries) are collected, GitLab Security and GitLab Legal review them.
1. Once reviewed and approved, GitLab Support or CSM [share the artifacts](/handbook/support/workflows/log_requests/#sending-logs-and-other-personal-data) with the requesting customer.
1. The team that performed the log-dive [creates an issue](https://gitlab.com/gitlab-org/gitlab/-/issues) with ~"Category:Audit Events" and ~"Enterprise Edition" labels to document the gap in [Audit Events](https://docs.gitlab.com/ee/administration/audit_event_reports.html) that forced the customer to request our assistance. This is to ensure that the missing functionality in the product is added in the future.
@@ -106,7 +106,7 @@ also refer to insights around the demonstration purpose and area of product walk
-**Guided Trial** - This activity type is used in case a prospect or existing customer needs support from an SA during their self-evaluation by using the GitLab Free trial offering.
-**Security Questionnaire / RFP** - The SA should use this activity type to record actions related to completing security assessments or progressing opportunities through tender processes. Examples of activities that fit into this category are;
- Security Assessment: Although technically speaking part of the tendering process, Security Assessment generally involve the SA to interact with GitLab governing divisions ensuring accuracy and legal responses. As such, the SA engages with a GitLab division internally to address those Security specific requirements but ahead of the process, the SAs have a responsibility to attempt in the form of a first attempt to the queries.
- Procurement / Tender process (RFx - RFP, RFQ, RFI, FRB, RFT - Request for Anything): The SA is engaged with the client and an indication has been given that their organisation will be undergoing a public tendering process. Tendering processes could be requesting a proposal, quote, information, expressions of interest and generally result in the SA responding to functional and/or non-functional queries of the GitLab platform as part of a request. Often tendering processes are indicated early, shared fairly with the approaches to take it to market and require a formal process involving the SA addressing technicalities required in form of written artefacts.
- Procurement / Tender process (RFx - RFP, RFQ, RFI, FRB, RFT - Request for Anything): The SA is engaged with the client and an indication has been given that their organisation will be undergoing a public tendering process. Tendering processes could be requesting a proposal, quote, information, expressions of interest and generally result in the SA responding to functional and/or non-functional queries of the GitLab platform as part of a request. Often tendering processes are indicated early, shared fairly with the approaches to take it to market and require a formal process involving the SA addressing technicalities required in form of written artifacts.
-**Technical Deep Dive** - SA should record client sessions on in-depth review of technology and GitLab capabilities, and creating the client solutions.
-**Technical Support** - SA conducts the technical support sessions as the account team and with GitLab Support to troubleshoot and address specific technical issues and challenges.
-**Positioned Professional Services** - This activity type should be used when positioned Professional services as part of the [Solution Architects Processes](/handbook/solutions-architects/processes/#positioning-professional-services)
