Skip to content

Allow multiple Support ticket assignees

Current Status: BLOCKED.

This proposal requires Support Manager approval to move forward and Support Ops to implement.

Problem Statement

What is the problem?

ZenDesk arbitrarily limits us to one assignee per ticket. One assignee indicates one responsible individual (RI) for subsequent replies on each ticket.

Why is this a problem?

There are situations where having more than one ticket assignee could produce better results for our customers and our Support team.

There are a number of scenarios where having more than one assignee or RI per ticket would be helpful, including (but not limited to) the following:

All Regions High/Medium Priority tickets

All Regions High/Medium priority have 4/8hr SLA on a 24hrs/day timer. An individual assignee is expected to be working ~8hrs/day. This leaves a ~16 hr/day gap in coverage where the individual responsible for subsequent replies to 4/8hr SLA tickets is unavailable.

For All Regions tickets, having only individual responsible for subsequent replies may increase % of NRT SLO breaches and time between replies.

Having multiple assignees for "all regions" tickets, one per region, could ensure 24/hr coverage for these tickets.

Short-term PTO (planned/paid time off)

Without a workflow to hand-off and hand-back ticket assignment of tickets for 1-2 day absences, there is confusion about what to do in the event of a short-term planned absence.

Adding secondary ticket assignees on tickets in situations where primary assignees take 1-2 days of PTO could be a simple way to ensure temporary coverage of assigned tickets without permanently re-assigning them.

Collaborating with others

Collaborating with a subject-matter expert, Senior Support Engineer, or fellow team member is an efficient and effective way to tackle difficult tickets and tricky customer problems in GitLab Support.

Having a secondary assignee to keep an eye on tickets or leave internal notes could help our team share knowledge, build trust internally, and help team members level up skills in new or unfamiliar areas.

Unplanned absences

When a GitLab team member takes a sick day or has an unplanned absence, their tickets go without a DRI.

With multiple assignees, we could co-assign someone else to keep an eye on their tickets while they're out.

Proposal

"Opt-in to the follower and CC system" in ZenDesk.

With both followers and CCs enabled for each ticket, we could use one to indicate co-assignees and the other one to indicate we're watching the ticket without taking responsibility for next replies.

With two fields in which we can add team member names, we can use one to indicate co-assignees and the other to follow tickets in the same way we've been using CCs.

Relevant resources:

Other ideas/proposals

Other less ideal ideas and proposals I have for a boring solution revolve around using CC's in addition to another element.

  • CC's and tags - CC oneself and their name as a ZD tag, use tags to create personal ZD co-assignee views (cost of maintaining 100+ tags, co-assignee tags may be hidden)
  • CC's and text field - we add an arbitrary text input field to ZD, put names of co-assignees there (indicator only - no notifications outside being CC'd)
  • CC's + internal note - CC oneself and add an internal note to indicate who is co-assignee (indicator only - no notifications outside being CC'd)

DRI

@greg will act as the DRI for this issue and the next steps.

Required Resources

Collaboration

Collaboration is a hard requirement. To be specific this will require Team Member Feedback, Manager Approval, and a Technical Solution.

Technical Solution

@jcolyer and the Support Ops team are the experts on whether this proposal (or something similar) is feasible or not.

Team Member Feedback

This would be a global change that affects workflows for our entire team. To come up with a solution that works and benefits us all, team member feedback will be solicited and carefully considered.

Manager Approval

This would change our global ticket assignment workflows, so it'd be best to get support manager approval before beginning work on technical solutions.

Potential Roadblocks/Things to consider

Roadblocks

  • it might be technically impossible to get this working in ZenDesk. (this has been my understanding up to now)

Things to consider

  • how much time would it take to develop and implement a solution that works the way we want it?
  • how do other Support teams solve this? (I doubt we're the first ZenDesk customer that sees value in having >1 ticket assignee)
  • is there a way to make a feature request or communicate our need for this to ZenDesk? (what do we have to do to get them to implement support for >1 assignees natively?)
  • is ZenDesk the best tool for GitLab Support team? (what about dogfooding GitLab Service Desk ;) )

Desired Outcome

GitLab Support team members can add themselves or others as Secondary (and Tertiary) ticket assignees.

What does success look like?

Two (or more individuals) can share responsibility for moving tickets forward with helpful next replies.

Where would future feedback go?

  • in a feedback-gathering issue

Related Issues/MRs/Epics/Tickets

Edited by Greg Myers