Customer Success Operations

1. You are here:
2. Handbook
3. Sales
4. Field Operations
5. Customer Success Operations

On this page

• On this page
• Mission
• Strategy
• What we do
• Who we work with
• CS Ops Request Process
  • Process Flow
• CS Ops Board, Groups, Projects, and Labels
  • CS Operations Board
  • Groups
  • Projects
  • Issue Weighting
  • Labels
• Peer Review

Mission

To empower GitLab and customers to mutually reach their strategic outcomes and revenue goals across aligned customer journeys.

Strategy

Develop and operationalize Customer strategies leveraging analytics and insights for key expansion and renewal initiatives, resulting in increased net ARR.

1. Refine cohesive Customer Success motion
2. Operationalize usage reporting in post-sales customer journeys
3. Expand Digital motion through multiple channels and across customer lifecycle
4. Stand up Renewal operations motion for a more predictable and scalable revenue motion
5. Operational excellence resulting in scalable vision, KPIs, operational processes, and documentation
6. Increase Sales and CS effectiveness through systems and tools

What we do

Customer Success Operations creates and updates existing processes for the Customer Success organization. CS Operations oversees:

• Systems implementation and maintenance
• Operational reporting
• Systems enablement
• Product analytics and renewal strategies
• Fiscal Year planning and strategy
• Operationalizing Customer Success Journeys

The CS Ops team also provides support for customer programs, renewals, and Gainsight.

Who we work with

Customer Success Operations provides support, content, and data analysis for all Customer Success teams.

CS Ops Request Process

Process Flow

Instructions for new request intake and execution for following along with the flowchart above (definitions further down on the page). Once assigned, the Issue Assignee moves the issue through each label.

• Workstream Lead: the individual who has oversight for a given topic, product, or section (e.g., Digital, Gainsight, Scale, ROPS)
• Issue Assignee: the assignee for the issue who will execute and will own the issue through to completion

1. New Request only has ~CSOps label - The Workstream Lead (Gainsight, Scale, Digital, ROPS, etc.) will review requests on a weekly basis to assign, mark as Need more info, mark as won't do, transfer them to a different team, or defer to a later date
2. CSOps::Triage - The Workstream Lead will move the issue here when after review and ready for prioritization
3. CSOps::Need_More_Info - Issue Assignee to apply label if additional information or clarity is needed from the business stakeholder
4. CSOps::Unassigned - Workstream Lead to apply the label when we've agreed the work should be done, but lack prioritization and/or capacity
5. CSOps::In Process - Issue Assignee is actively working the issue; if you are working an issue, it must have this label
6. CSOps::Awaiting Feedback - Issue Assignee to add Peer Reviewer and add label
7. CSOps::Blocked - Issue Assignee applies the label when the issue cannot be worked (technical problem or decision to be made)
8. CSOps::Won’t Do - Workstream Lead selects this when the decision has been made that it will not be worked, then close the issue
9. CSOps::Backlog - Workstream Lead applies label when we've agreed it's helpful and reasonable, but is either a lower priority or cannot achieve in the next 90 days
10. Issue closing - Issue Assignee to:
    1. Ensure any handbook sections have been updated
    2. Add to the Gainsight changelog
    3. Ensure the peer review process has been followed
    4. Communicate with stakeholders (in the issue, and possibly using other mediums such as Slack or a team call) as the last step, ensuring awareness and follow-through of the completion of the request
    5. Ensure the Workstream Lead is made aware, along with a summary of the work and any next steps
    6. Issue Assignee to remove CSOps::In Process label
    7. Close the issue!

CS Ops Board, Groups, Projects, and Labels

CS Operations Board

The CS Ops team uses issues and issue boards to track our projects and tasks. If you need help with a project, please open an issue and add the ~CSOps label anywhere within the GitLab repo.

CS Operations uses a global issue board to capture and track issues in any group or sub-group in the repo.

See the global issue board for CS Ops Technical Writing.

Groups

• Use the gitlab.com group for epics that may include issues within and outside the Sales Team group.
• Use the GitLab Sales Team group for epics that may include issues within and outside the Field Operations group.

Projects

Create issues in the CS Operations project.

Issue Weighting

• Weight = 1: 0-1 hours of work
• Weight = 3: 1-3 hours of work
• Weight = 5: 3-5 hours of work
• Weight = 7: 5-7 hours of work

Anything that takes longer than a day of work should be captured in an epic/multiple issues

Labels

Labels to use when creating new issues or MRs for CS Ops:

Team Specific or System Labels

• CSOps - Use to track and manage all CS Operations-related issues and MRs.
• CS Programs - For the Digital Programs team to track and manage content requests, improvements, and other means of digital customer marketing.
• CS Product Usage Reporting - Issues related to Customer Success product usage data.
• CS Analytics - Used to track Customer Success Analytics issues.
• CS RenewalOps - Label to designate issues for the Renewal Ops team to improve our customer renewal process and experience.
• CS Ops Technical Writing - Assigned to the CS Ops technical writers for review or creation of copy.
• Gainsight- Label to designate the issue is related to Gainsight.
• Gainsight: Bug- This label is used to track bugs exclusive to Gainsight.
• Gainsight: Feature Request - This label is used to track feature requests for our installation of Gainsight (not for Gainsight the product).

Scoped Labels - used for tracking SDLC progress

• CSOps::Need_More_Info - Requires additional information from the requester, or lacks information to complete the request.
• CSOps::Triage- Issue that is in the triage stage.
• CSOps::Ready_for_Assignment - Ready to be assigned and prioritized by CS Ops.
• CSOps::Awaiting Feedback - Used for peer review and when analysis is needed before closing the issue.
• CSOps::In_Process - Actively being worked on in the current week or milestone.
• CSOps::Blocked - Currently blocked by an internal or external prerequisite.
• CSOps::Backlog - Issues that are not currently being evaluated or worked on.
• CSOps - Interrupt - Issue that was submitted after the current milestone started and prioritized ahead of the original milestone scope.
• CSOps::Triage- Issue that is in the triage stage.
• CSOps::Won’t Do - Indicates that the issue is not going to be worked/completed, although scoping of solution might have already been concluded.

Segment and Team Support Labels - for tracking where the request(s) came from

• CSOps - CSM- Ops - Request opened by the CS Ops team that benefits the CSM team.
• CSOps - CSM - Request originating from the CSM team.
• CSOps - PS - Request originating from, or to benefit the PS team.
• CSOps - SA - Request originating from, or to benefit the SA team.
• CSOps - Ops - Request to benefit the CSOps team.
• CSOps - PubSec - Requests that are specific to the Pub Sec CSM Team.
• CSOps - Strategic - Requests that are specific to the Strategic CSM Team.
• CSOps - Scale - Requests the are for the Scale Segment.
• CSOps - All Segments - Request that cover all CS Segments.
• CSOps - Growth - Requests that are specific to the Growth CSM Team.
• CSOpsSlack-Questions - Indicates that the request/issue came in via Slack (#gainsight-users Slack channel being the largest contributor to it)
• CSOPs-Priority - This is for initiative/issues tied to Top Priority Initiatives.

Peer Review

The peer review process (currently for issues related to Gainsight) allows CS Ops team members to have another member of the team review their work.

The issue owner is responsible for making sure the issue is completed in timely manner, including communicating to the peer reviewer when the issue needs to be completed. The peer reviewer is responsible for completing the review in the timeframe given by the issue owner.

• Issues MUST be peer reviewed by the Gainsight Admin if it is a change, addition, or removal in a rule or data object (e.g. creating a new rule or connector job, removing fields from an object, combining multiple rules into one)
• For changes to reports or dashboards, strongly consider a peer review.

Feel free to ask for a peer review for other any updates if you feel it would be helpful to have a second opinion.

To start the peer review process:

1. Provide a Summary of the work you have completed in the Resolution section on the GitLab issue
2. Change the issue status to CS Ops::Awaiting Feedback
3. Tag the teammate completing the peer review and comment on the issue that it is ready for peer review
4. The issue owner will remain an assignee as they are ultimately responsible for the issue completion.