Contents
Purpose
Triage Meeting
Review Process
Product Issue Accepted
Product Issue Rejected
Purpose
This document covers the product issue case review and acceptance process for cases that have been submitted to the Triage queue. The Triage queue is the first step in review for suspected product issues. The queue is monitored by a team of product resources to ensure that requests in the queue meet the criteria for a product issue before being accepted. Any case that does not meet the criteria may be rejected or transferred to a different department for further follow up.
The Product Issue Flow outlines how a case will be moved between resources/departments throughout the process. It also highlights the automated customer messaging that is sent at each stage.
Throughout the flow of a case moving through Triage, Development, QA and into the future release, automated messaging will be generated as the case owner and status changes. For this process to work effectively, please be aware of the following requirements and details and properly populate all fields as noted:
- Two groups of emails will be sent:
- To Contact and any CC email addresses identified in the case
- The email will be logged to the case
- To the Case Owner and Secondary Case Owner
- These emails will NOT be logged to the case
- To Contact and any CC email addresses identified in the case
Important Note: The Case Owner and Secondary Case Owner fields must be populated for any of the emails above to be sent. Triage Meeting
The Triage team meets daily to review all issues based on the following schedule:
- Business Management cases: Monday/Wednesday/Friday
- Alarm Monitoring cases: Tuesday/Thursday
The team consists of, but is not limited to, resources from the following departments:
- Development
- Product Management
- Support
- LMS
The goal of the meeting is to status each case listed in the Dev-Triage Open Cases with Rank report for the following:
During the review the team will:
- Confirm there is enough information to agree there is a possible product issue (at a high level)
- Confirm priority of the case
- Transfer non product issues to another more appropriate department. Examples:
- Product Management - product enhancement requests
- Professional Services - implementation issues
The desired state is that no cases remain in the queue at the end of each session.
Review Process
The following steps are taken to review each case assigned to the Triage queue
- Open the Dev-Triage Open Cases with Rank report and select the appropriate filters for the cases to review
- Accept or reject the case using the steps below:
Product Issue Accepted
After the review is completed, cases accepted to move to the Development queue for scheduling will require the following steps:
- Set the Priority field for the case
- Is the case a duplicate report?
- Yes
- Confirm the Parent Case field is populated with the original reporting case
- In the QW Connector section, click the Update Dev button and locate the existing Dev Ops record
- No - Create the Dev Ops request
- In the QW Connector section, click the Send to DEV button to create and link a new Dev Ops request
- In the QW Connector section, click the Send to DEV button to create and link a new Dev Ops request
- Yes
- Confirm the Product/Sub Product/Functional Area fields are populated correctly
- Click Edit Case Category to adjust if necessary
- Confirm the Category field = Possible Issue
- If this field is not set to Possible Issue, the customer will not receive status notifications
- This prevents other Dev Ops types from sending notifications unnecessarily. Example: Development questions
- Click the Transfer button
- Transfer To field: Development
- Click Save
- An automated message will be sent to the customer contacts and Secondary Case Owner that the case is now with Development, status is New, and awaiting scheduling. The following field criteria is required for triggering the message:
- Account = is not blank
- Case Status = Transferred
- Case Owner = Development
- Category = Possible Issue
- Work Item/Issue Number = is not blank
- Work Item/Issue Status = New
Product Issue Rejected
There are two main reasons a case could be rejected during the Triage process:
- Not enough data was provided to gain acceptance
- The Triage team will add their findings to the case activity and @mention the submitting party or other knowledgeable resources to provide the missing information directly within the case activity.
- The Triage team will change the owner of the case back to the original submitter to add the additional information
- The Triage team will add their findings to the case activity and @mention the submitting party or other knowledgeable resources to provide the missing information directly within the case activity.
- The issue is not a product issue, but it is an issue for another department
- The Triage team will add their findings to the case activity notes and transfer the case to the appropriate department for further action
To move a case to another department:
- Update the Category to reflect the appropriate type of case
- Click the Transfer button
- In the Transfer To field select the appropriate department
- For support, select the Support Manager option based upon the product
- BM Support Managers - for the financial products
- AM Support Managers - for the alarm products
- For support, select the Support Manager option based upon the product
- Enter the reason for the transfer in the Transfer Details box