The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
The Admin Tooling group exists to provide internal teams with tooling and automation that allow them to provide support to our customers. Our group strives to build tools that are intuitive, easy to use, and optimise team workflows.
When our teams lack the appropriate tools to solve customer problems it leads to massive inefficiencies and, in some scenarios, leads to problems such as customers temporarily losing access to critical paid plan functionality.
Inefficiencies can present in the following ways:
The Fulfillment Admin Tooling team works with internal teams to build robust systems that enable our internal, customer-facing teams better support our customers.
Key responsibilities
Provide internal teams at GitLab with the tooling they need to serve customers efficiently and in a way that minimizes repeat issues.
Our internal teams have access to relevant customer and account information, they are able to effectively diagnose and troubleshoot issues and errors, and they are able to efficiently complete tasks and resolve issues and errors with the appropriate tooling and automation.
Our audience are GitLab internal team members, with a focus on team members that help support our commercial operations. In particular:
We work in collaboration with the Support Operations and Field Operations teams to achieve internal team efficiency goals.
Our internal teams don't always have the visibility they need to quickly serve a customer. The longer it takes to find information, troubleshoot, and then resolve an issue, the more likely customer dissatisfaction becomes. Our internal systems should provide our teams with access to all the relevant information they need (preferably in one location) to resolve problems or complete a request.
Where there are long-standing bugs or missing customer-facing features, the Support team has built the Mechanizer tool as a temporary work-around to address required functionality for troubleshooting and resolving customer issues and tasks. Since Mechanizer is not built or maintained by a GitLab engineering team and it leads to data integrity issues, it is important that this tool is deprecated in favour of intuitive tooling and automation that can provide needed functionality.
Projects to tackle this challenge:
What does an efficient L&R Support team look like?
What does an efficient Sales team look like?
How we will tackle this:
Over the next 12 months, the Admin Tooling team has the following primary objectives:
For a list of upcoming and ongoing projects, see our GitLab epic roadmap. The roadmap view is colour-coded to show: blue for feature work, green for ongoing/evergreen initiatives, and orange for sales-specific feature work.
Our performance indicator dashboard gives us visibility into data relating to tickets.
From the dashboard we can see that internal requests are increasing month over month. The types of internal requests include extending a trial, modifying a subscription, creating or troubleshooting a license issue, and investigating seat count or provisioning discrepancies. Internal requests often require the use of Mechanizer when admin actions fail with our current internal tools, known bugs hamper the ability to self-serve or there is a gap in our feature offering that is filled with manual Support assistance.
Mechanizer is a tool that uses rails console functions to create and modify SaaS subscriptions, orders, and namespaces.
Since we know that internal requests and the use of Mechanizer is linked, our long-term goal, together with other Fulfillment and internal teams, is to decrease the total volume of internal requests. In the shorter term, we recognise that Mechanizer is a burden to the Support team, who have created and maintain a tool that should not have existed and that continues to be a sunken cost.
The cost of mechanizer, since the first commit in May 2020, is summarized below:
Please see this thread for a more detailed description.