Conflicts between working-on-tickets and meeting-frt-sla workflows
@lbot and I went through:
- https://about.gitlab.com/handbook/support/workflows/working-on-tickets.html
- https://about.gitlab.com/handbook/support/workflows/meeting-frt-sla.html
And discovered a few confusing and sometimes conflicting points, as well as a couple of areas that would benefit from an iteration or two.
My intent here is not to insult, blame or bring fire to the room. I've contributed to these workflows as much as anyone and my aim is to simplify and harmonize while retaining the same meaning. Thank you to everyone who contributed towards these.
Working On Tickets
-
We consistently ask engineers to prioritize My Assigned Tickets over FRT. - https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/18fc2c7c465d3378e1221f8c1ef4a68dbf20485d/sites/handbook/source/handbook/support/workflows/working-on-tickets.html.md#L40-46
- https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/18fc2c7c465d3378e1221f8c1ef4a68dbf20485d/sites/handbook/source/handbook/support/workflows/working-on-tickets.html.md#L57-59
-
We implicitly assume "My Tickets first" in the Zendesk views section (I don't think we can move "My assigned tickets" so we should note they're presented in order or change the descriptions) -
If folks haven't looked "in an hour", we ask them to look at the regional view rather than FRT
Meeting FRT SLA
-
No need to repeat ourselves if the differences are minimal: - https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/18fc2c7c465d3378e1221f8c1ef4a68dbf20485d/sites/handbook/source/handbook/support/workflows/meeting-frt-sla.html.md#L46-57
- https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/18fc2c7c465d3378e1221f8c1ef4a68dbf20485d/sites/handbook/source/handbook/support/workflows/meeting-frt-sla.html.md#L67-79
-
I have the sense that "balance" is less important that urgency. -
Needs-org being everyone's responsibility means that it's not often done: -
Manager responsibilities need to be fleshed out a bit:
I really tried to start with an MR, but these pages are a bit challenging to work with and I didn't want to rip-and-replace without making sure I had the right sense.
Super simple version (as I understand it):
- Contribute to meeting our first reply time target by taking ownership of new tickets before they breach.
- Ensure tickets don't languish by pulling tickets from
needs-handover
- Resolve assigned tickets through troubleshooting and collaboration.
The main complexity comes from handling regional / priority tickets. In all cases but below, we assign:
- If a ticket is not in your region: needs-handover it.
- If a ticket is HPAR: needs-handover it.
A successful engineer working on tickets:
- Contributes to FRT
- Meets ticket baselines for assignment
- Collaborates with others
- Resolves tickets and makes customers happy
Are there any other simplified points I'm missing?
Related MRs
Working On Tickets Workflow
- Remove "assignment" justification section: gitlab-com/www-gitlab-com!94476 (merged)
- Add FRT as shaped KPI for "Working on Tickets" workflow: gitlab-com/www-gitlab-com!94483 (merged)
- Simplify process description and remove flow chart: gitlab-com/www-gitlab-com!94484 (merged)
- Update Main views section to highlight presentation order isn't priority order: gitlab-com/www-gitlab-com!94485 (merged)
- Condense ZD Housekeeping section: