Skip to main content
Top
Review meshIQ Products (G2.com)

Ticket support flow

The overall flow of a ticket submitted to the Support System is shown in this diagram:

mceclip1.png

 
NOTE:  If you have not registered for the Support System, click HERE. 

Your involvement

While there are a variety of stages, there are 3 that you are involved in:

  1. New – This status is defined when an issue is initially open. At this point, it has not yet been assigned for review. There are several key pieces of data that we need a ticket is opened:
    • Category:  The product or component associated with the problem
    • Reproducibility:  How often the product occurs
    • Severity:  What is the severity of the impact on you 
    • Priority:  How urgent is the issue (see notes below)
    • Profile:  The version of the associated product or component
    • Summary: A meaningful summary of the issue. Avoid being too general, such as “getting an error” or “please help”.
    • Description: Detailed notes about the issue being reported
    • Upload files:  Any pertinent logs, documents, files, images
  2. Feedback – Additional information is needed to continue. This could be responses to questions about the environment. Other examples include traces or logs to analyze the cause of a problem either as files or streamed to the support portal.
    • Once the information has been provided, the customer can respond with a note and/or change the status to assigned
  3. Verification – A solution, response, or permanent fix to a problem has been provided. The support representative is waiting for the customer to verify this addresses the problem.
    • If the verification confirms the issue is addressed, the customer responds with a note and/or changes the status to resolved
    • If the verification fails, the customer responds with a note and/or changes the status to assigned

Ticket priority

Priority determines the urgency of a ticket and response times to address it. Priority can be Immediate (P1), Urgent or High (P2), Normal (P3), or Low (P4). As indicated, a P1 Immediate ticket needs to be serviced right away. It will be escalated as needed within the support organization. It is important that your company resources are available to work on these tickets as required. P2 Urgent and High tickets are just a step lower than P1, but have a less critical impact.

Using an analogy, P1: my fire alarm is going off; P2: my fire alarm is broken; P3: my fire alarm battery needs to be replaced; P4: my fire alarm documentation has a typo. Severity is related to priority but is not a measure of urgency, but how the issue is affecting you.

Note that the development teams work off a different set of issues. These “internal” tickets are the ones we assign to releases and work on. They exist because there could be multiple internal tickets created from one customer request or multiple customers might have the same issue related to a single internal ticket. When the issue is addressed and is marked to be resolved, the fixing release will be indicated. It is not always possible to directly identify the specifically related fixes in the release notes since the internal ticket(s) may have different summary information. 

Enhancement requests

An area we get frequent questions around are enhancement requests. These are cases where the product does not work the way you would like it to, or you want something new that you believe would be beneficial to your company. In this case, the issue severity is assigned to the feature. Like all developers of software solutions, we get a lot of feature requests and we review and discuss them all, and try to satisfy as many as possible. The general criteria as to when that happens are based on value to you and other customers. Some enhancements may take longer than others to get to and some are determined to not make sense to be added to the product (for a number of reasons). When an enhancement request moves from an acknowledged status to confirmed, this means that it has been targeted for a release. 

There is still no guarantee a "confirmed" enhancement request will make the next release as, with any agile development effort, it may not end up in scope. One thing to consider when opening an enhancement request is to describe what you are trying to do, not how. That is, using the analogy above, consider an enhancement request to make the smoke detector reset button bigger. But the real issue is that the smoke detector is going off too frequently and you want the button bigger to make it easier to reset. What we want to know is the real requirement, to improve the smoke detector alarming frequency.

If there is something you want quickly, one option to consider is having the professional services team implement it for you. Since our products are designed to be extensible, in many cases, there are ways to do things without waiting for the feature to be implemented in code. For example, if there is data that is needed, we can use one of the many data collectors to augment the core data that is needed. An example of this was recent changes for RDQM, which were adding new commands and data via the CD releases.  

In the Resource Center, you will find several related articles and how-to videos on using the support system.