Ticket management

Tickets move to this state when additional information was requested to the customer.

Ticket SLA is stopped. When the customer replies with the information the ticket, jumps to ‘New’ or ‘In Progress’ state, and SLA is restarted (note it is not resumed).

This state doesn´t necessarily means that this ticket analysis has stopped. If there is enough information to meanwhile continue with the ticket troubleshooting, this will continue until no further work can be accomplished or the ticket is solved.

If the requested information is or becomes crucial, customer will be informed/reminded about its importance and that no further processing can be accomplished without this information.

When a ticket relates to an unknown issue for which there is no fix still available, but there will be a fix to it in the future, the ticket shall change to this state until a fix is provided\available. When that happens the ticket will change to ‘Pending to Close’ state.

Note that tickets that refer to feature enhancements or new functionality ARE NOT set to this state. They will be overflowed to Product Management for evaluation.

This is a prelude of an ending state, where all problems with a fix are (either internal or external).

Pending to Close is a temporary state for ‘Closed’. The reason is to allow customers to apply the provided solution. If the customer does not get back with additional information, the ticket is closed after a time period.

Tickets in this state no longer count to SLA.

This is an ending state.

Tickets jump to this state after Pending to Close.

This is an ending state.

A case is discarded when the raised problem is not really a problem, but rather a feature or a customer’s misperception.

This is an ending state for support, but not for the issue.

When the problem reported is related with the product or the company, but it isn’t a bug or defect that is part of Support context.

Tickets changed into this state, will always have a forward mail reply to the destination party with customer included, with the reason of the ticket transfer.

Examples of these are Feature Requests that should be sent to Product Management, or integration issues developed by Collab service team.

This is an ending state.

Tickets that are open or suspended for a long time will be changed to this state. Note that it’s natural for tickets to move from suspended states to expired, but only in very few and well justified cases can a ticket jump from Open\In Progress to Expired.

Merged is not a state by itself, is a unification of existing tickets that report identical problems from the same customer that were registered separately.

After this operation there is an active ticket (that follows the normal state flow), and another that is classified as duplicated.

Indicates what group is responsible to handle the problem.

It is almost always assigned to Support, only when it goes to a 2nd line (R&D, Q&A or external) is this field changed.

Indicates the impact of the problem on operations:

Critical (P1) – Critical Errors severely affect service, capacity/ traffic, Product functionality or maintenance capabilities.

High (P2) – Major Errors causes conditions that seriously affect system operation, maintenance and administration, etc. and require immediate attention. The urgency is less than in Critical situations because of a lesser immediate or impending effect on system performance, End-users, and End-user’s operation and revenue.

Medium (P3) – Affect system operation, maintenance, administration, etc., but don't require immediate attention.

Low (P4) - Do not significantly impair the functioning of the system and do not significantly affect service.

Refers to the ticket ID that is identical to this one.

This field is only used when a ticket is changed to a Duplicated state, otherwise is must be empty.