CSE Pooled

The Pooled CSE motion: on-request technical engagements for accounts without a CSM or CSA, the topics CSEs cover, and how an engagement runs.

In the Pooled motion, the account team asks for a Customer Success Engineer (CSE) when a qualifying customer without a Customer Success Manager (CSM) or Customer Success Architect (CSA) needs technical guidance on a specific topic. The request goes to a shared team queue and the next available CSE picks it up. The CSE delivers a focused, topic-scoped engagement and hands the customer back to the account team better equipped.

Pooled is one of the three CSE motions and the original one. Customers can ask their AE or RM to request a CSE engagement for them. For accounts with an assigned CSE, the account team contacts that CSE directly instead.

What CSEs can help with

The account team chooses an offering when they make the request. Offerings fall into five areas. The offerings page lists what is in and out of scope for each one.

CI/CD and DevOps

Streamline your CI workflows: CSEs review the customer’s .gitlab-ci.yml and share patterns to cut build times and improve job efficiency, caching and pipeline architecture.
Accelerate your software delivery: best practices for deployment automation, environment configuration and release management.

Security and compliance

Strengthen your application security: how to automate security scans, enforce security policies and manage vulnerabilities with GitLab’s security features.

AI: GitLab Duo and the Duo Agent Platform

Transform your workflow with AI: use-case discovery and adoption guidance for GitLab Duo and the Duo Agent Platform across planning, coding, review and security.

Migration and architecture

Optimize your migration strategy: migration approaches, prerequisites and limitations, architecture considerations and risk mitigation, whether moving from another tool, from self-managed to GitLab.com, or between GitLab instances.
Optimize your GitLab architecture: patterns for a scalable GitLab deployment, including high availability and disaster recovery.

Platform and operations

Fast-track GitLab implementation: setup recommendations covering configuration, user management and documented best practices.
Strengthen your GitLab operations: authentication and single sign-on, user management, group structure and project configuration at scale.
Optimize your platform observability: monitoring and observability for GitLab, from basic system monitoring to resource utilisation tracking.
Scale your agile planning: workflows with issues, epics and iterations, and measuring progress with value stream analytics.

What is out of scope

Break/fix and product bugs. The CSE points the customer to GitLab Support and makes sure they know how to open a ticket.
Hands-on migration or implementation work. CSEs give architectural guidance and best practices. Hands-on delivery is a Professional Services engagement, and the CSE flags the need to the account team.
Ongoing advisory, cadence calls or business reviews. These are part of Success Tiers.

How an engagement runs

The account team requests a CSE. The Account Executive (AE) or Renewals Manager (RM) submits a request from the customer’s record in our CRM, chooses an offering, and describes the customer’s challenge.
A CSE picks it up. Requests are assigned to the next available CSE on the team.
The CSE aligns with the requester. Before contacting the customer, the CSE checks with the AE or RM: do they want a warm handoff or a direct email, and what exactly is the ask?
The CSE researches the account. Product usage and adoption, license utilisation, GitLab version, recent support tickets and any earlier CSE work. The aim is to arrive with the right questions and a few candidate solutions, not a script.
The call. The CSE leads with discovery, brings resources the customer can act on straight away, and invites the AE or RM. Before closing, they confirm the next steps, who owns each and by when.
Follow-up. The CSE sends a written summary of what was discussed, the recommendations and the next steps, with the requester copied. The customer then receives a short satisfaction survey.
Close. The CSE records the outcome and their recommendation for the account team.

When a live session is not possible, the CSE can still deliver value asynchronously: a well-scoped email with tailored recommendations and resources. They agree the best approach with the requester, whether that is continued outreach, an async write-up, or a recommendation for the account team to re-engage later.

Follow-up questions

Pooled engagements are short-term: the CSE is not permanently aligned to the account, and sets that expectation on the call.

If the customer comes back with related questions soon after the engagement, the CSE picks them up. If the questions need more depth, the CSE offers a short follow-up call. After more than three follow-ups on the same topic, or once four weeks have passed, the request is treated as a new one. A new topic is always a new request. Once an engagement is closed, a new request is a new engagement and goes to the next available CSE.

Escalations

There are two kinds of escalation:

Support escalations are for an existing support ticket that is having a very high business impact on the customer. They follow the support ticket attention request process, which raises the ticket’s priority within Support.
Account escalations may or may not relate to a support ticket. They cover a highly impactful problem, for example an open bug or a missing feature that blocks a critical use case, and put the customer’s use of GitLab at risk. They follow the Customer Success Escalations Process.

Escalations are used sparingly, so that Support, Product and Engineering can prioritise where the impact is greatest.

Limits

Pooled coverage is capped at three requests per account per half year. Each request covers one topic.

When a customer needs more

If an engagement shows the customer needs more help than a CSE engagement provides, the CSE shares this with the account team so the right support can be offered.