🔃 From Tickets to ‣

This page is destined to ticket handlers and team managers, ie the person in each team the relevant ticket is assigned to, and outlines standards in managing incoming tickets.

👷 For Ticket Handlers

🤹‍♀️ Handling and resolving a ticket

All tickets should be reviewed within 1 business day. This means that the ticket should be moved away from 0 - Pending Workforce within 1 business day. The ticket can either be moved to:

• Done, if all the issues described by the ticket creator have been done. The ticket handler must have described the output in the body of the ticket and tagged the ticket creator in the comments for them to review. The ticket handler should not wait for confirmation from the ticket requester to move the ticket to Done, as the ticket can always be reopened if both parties are not aligned on whether the ticket is resolved.

• Started, if work on the ticket has begun, including if the ticket handler has asked the ticket requester to minor clarifications to their request.

• On Hold, if work on the ticket is blocked at this time, and by outlining the reasons why (same as ‣ except that prerequisite work is a valid On Hold reason).

  Frequent reason may be:

  • Pending validations from other members
  • More information is required from ticket creator

  <aside> ✋

  Don’t set the Status to On Hold if the ticket could be worked on if there was available workforce.

  ⇒ Set it to 0 - Pending Workforce or Started instead.

  </aside>

• -1 - Dropped, the ticket handler should move the ticket to -1 - Dropped only if the requested issues is either no longer needed of the request is not doable by the assigned team. For a ticket to be dropped, it must be validated by the Team Manager.

🔃 From Tickets to ‣

If your team uses ‣ then tickets taking more than 2 hours of work should be moved to ‣. When you move a ticket:

• If it’s a issue report, first check if there’s no existing ‣ for fixing it. If there is, instead drop the ticket then go on the existing ‣ to mention the ticket and optionally adjust the ‣.
• Fill in the Internal Characteristics, when setting the ‣ please check if there’s one suggested in the ticket.
• Tag the ticket followers if any to indicate them the ticket was moved so that they may challenge the characteristics.

👁️ For Team Managers

💠 Keeping a Ticket Database Up to date

When having a ticket database you don't have to set an owner for each template to check they're still up to date with [Shared] Inter Team Communication. You set the owner on the page containing the database and do a full review on next review. When reviewing a ticket database you must check compliance with all the pages of Structure of a Ticketing System on all aspects and notably Fields, Templates and Views .

🔜 Making sure Tickets are moving forward

Team managers must make sure their tickets are correctly handled. This means that at all time the 🆙 Stales should be empty. To ensure this team managers must review once a week their ticket database and ping Assignee to make sure no tickets get lost.

🗣️ Communicate on the Team’s SLAs

Give visibility be adding at the top of your ticket table the classic SLAs of the team.

Exemple in ‣

Owner: @Elrendio - ‣

Next Review: See [Shared] Inter Team Communication