Ticketing and Support

A ticket may be understood as a generic incident to a support team, a question, to report a problem, etc.

Tickets have a series of basic features such as the urgency or criticality of the issue, a title, the assigned group, and the users involved in it and their status, as well as advanced features such as SLA or the Description field that supports HTML elements, such as rich text, web links and images or the File upload field to be able to store and share files related to the incident.

Then there are many other optional fields and, of course, all those that the administrator defines for the type of ticket (custom fields).

In a ticket each user has a specific role:

1. User who created the ticket: This is the person who identifies the problem and initiates the management. They will be the person to help in the incident management process. Even if the ticket creator has a group defined and then the ticket group is changed, the ticket creator will always have ticket visibility (as long as they are not changed as the creator), this is designed that way and the rest of the ACL continue to work the same.
2. User owner of the ticket: This is the person in charge of solving the problem. There can only be one person as the problem may escalate (pass the ticket ownership) to another person, but the owner can only be one person. That owner is the only person who may close a ticket.
3. User ticket editor: It may be different from the source, someone just in charge of entering the ticket into the system. If the system is handled through an operator line, the person who picks up the call and enters the ticket is neither the ticket originator nor the person who will resolve the ticket.
4. User with access to the ticket, and who provides information, but who is neither the one who created it, nor the one who will solve it: they may simply be a technician who provides some information.
5. User associated to a ticket: Any person who participated at any time during the life-cycle of the ticket, making modifications or adding comments. You will also receive notifications with any updates to the ticket.

In the Contacts tab, you may see the complete list of people involved in a ticket and their role.

Users in turn belong to companies and groups, and ticket visibility is defined according to the permissions assigned to those users. There are access bits that define who may VIEW, EDIT or MANAGE tickets. Thus, the EDIT permission is required to be able to create tickets, and for a user to be able to see another user's ticket, they must have visibility over that group.

An example will show ticket management operation. This support team consists of three people and a team leader.

There are several types of customers: Those who work in teams and those who work separately.

• Team operators will have several people working simultaneously who will be able to see each other's tickets, either to contribute or to take care of them.
• Customers or independent users may only see their own tickets, and no one else has access to them.
• The first type of client will have its own group and several users assigned to that group, the users of this group will be of type “grouped”, and their privileges will be based on the profile they have associated to their working group.
• The second type of client will work individually and its user will “independent”, so that it will only see its own content.

In this environment, when a grouped type customer opens a ticket, it is assigned to a team leader. That user will be the one who receives the ticket and may then escalate it, if appropriate, to other users.

It could also be sent to a generic user acting as a mailing list. As we will see later, workflows may be used to elaborate much more complex actions, such as sending a message to Telegram every time a high priority incident is received or assigning a ticket to certain types of users depending on certain criteria. An e-mail message will then be sent to both the ticket sender and the ticket recipient.

You may answer the email and this answer will be added to the ticket's comment “thread”. Another option is to continue its management through Pandora ITSM web interface, which will allow you to do much more than just post a comment.

When a user creates a ticket and it remains in NEW status, it will be displayed with a slightly reddish background, similar to the following:

Clicking on the ticket number or its description takes you to the main ticket management screen. You may then change its status, or navigate through ticket tabs to see its history, notes associated with the ticket (Workunits), files, etc.

Possible ticket statuses:

• New: Ticket opening status. While in this state, the ticket's first response SLA will be counted until the user who owns the ticket replies for the first time. Once there is an initial response, the user must decide which status the ticket will be switched to. If the user who owns the ticket provides this initial response, the ticket should be changed to status Pending customer.

• Pending Customer: When the user who owns the ticket was the last one to reply and a response is expected from the user who created it. This should be the status set on the ticket for correct SLA interpretation and correct status flow. When the ticket owner replies again, this is the status that will be set by default when adding it.
• Pending Support: Status that the ticket should be in when a response is expected from the user who owns it. In this status, the response SLA will be counting down until the response is effective, and will be executed if the limit is exceeded. When the user who created the ticket responds, this will be the status it defaults to.
• Reopened: Custom status, it will have the same impact as the Pending Support status at SLA level.
• Pending to be Closed: Custom status, it will have the same impact as the Pending Support status at SLA level.
• Pending on a third person: Custom status, in this status the SLA is not counted except for resolution time. SLA inactivity or response are paused.
• Closed: Ticket closed, it works in a similar fashion to previous versions.

All these changes were made in order to improve ticket status tracking and statistics. In the statistics tab, you may track how long the ticket was on the Support and Customer side, so that ticket resolution times may be better accounted for on the support team side. Some of these times were added to the incident view so that they may be tracked in the ticket view itself:

The team of people working on the ticket (the customer, the operator, second level technicians, etc.) interact with each other by adding text notes (or Workunits, in Pandora ITSM terminology). Each user with access to the ticket provides information for its resolution. To do so, just answer one of the emails in the ticket or it may be entered manually through the interface using the tab marked with a speech bubble :

• WU (Workunits) allow you to type a text and additionally add attachments, specify the time spent on that action (in hours), if you worked jointly with another team member, if costs are included according to the imputed profile, and so on.
• From version 103 OUM, any other user may be mentioned, according to the ACL visibility the user has when interacting with a Workunit, and the mentioned user(s) will receive an e-mail message for their information.
• All this information will then be used for support reports that include all these metrics (and many others). The intention is to be able to track in detail the processing of each issue in order to evaluate the support quality from all possible angles: costs, quality, time, effort, staff profiles, customer profiles, among others.

Clicking on the speech bubble icon will lead to a dialog box with the following fields:

• Time dedicated (hours): Time spent, in hours, on the message.
• Private workunit: Appears if the token New WU are always public is active in the configuration of working units, and allows private comments to be shown only to administrators and the user who added the comment.
• Add to project`s cost: To indicate what should be taken into account for service cost calculations(projects).
• Internal workunit: To check if the comment will not be visible to the issue creator.
• Description: It features an HTML editor that allows you to add rich text, links and images.
• Workunit shared with: Share the WU with another user from the same company; type two or more letters to search for users.

Finally, the WU is added with the Add button.

See also “Ticket configuration” and “Limits to ticket creation”.

Tickets have an amount of user-customized fields, which are related to the ticket type. It is possible to create different types of tickets and each of them have their own custom fields.

In addition to the fields defined by administrators, there are some special fields, which appear in the edit view, within the Advanced parameters box:

The Editor is the user of the application who creates the ticket and is always on record for auditing and logging purposes (it cannot be changed). The same applies to the Creator group. These are “fixed” fields that may then be used as filters in workflow rules.

Nested ticket hierarchies may be defined, linking one to another in a parent-child relationship, for this purpose there is the Parent ticket field.

Support tickets may be linked to projects by linking them to a task (Project Task), since tasks are project subdivisions. You may also link a ticket to a change in Change. In order for the advanced details section to be displayed and include a link to a task, it must be selected in Change Task:

Similarly, one or more inventory items may be linked to an incident, so that you may then trace which items are affected by an incident and also view the incident history for a specific inventory item.

It is also possible to keep a group of third parties informed about ticket status, even if we only have their email address and they do not have access to Pandora ITSM. They will receive copies of everything that happens through email. This is a simple way to include third parties and keep them informed.

Tickets of different types can be defined, so that each type of ticket has its own fields. These fields can be of text type, dates, checkbox or a list selector. You can even link several selectors and, depending on the user's selection, display some values or others.

It is possible to configure certain ticket types to be available only to certain groups: If you have a technical support group and a user support group, the “Technical Incident” ticket types (which require filling in many detailed fields) would be available to the “technical” group. So other ticket types that are non-technical would be available to anyone.

When defining a ticket type you will be able to set one or several custom fields. You may need to define a common field for all custom ticket types (to save work editing all at once): For that there is the Global field.

Other options allow the custom field to be displayed in the incident list and whether or not its value needs to be specified.

Text type fields (one line), extended text (a multi-line free text box), date type data (which will display a calendar), numeric type data (which the system will validate as a number) or “true/false” type data are available.

There are two more complex types, such as the value selector called Combo and the related fields called Linked.

A custom field must be added and the Combo option must be chosen. The possible values must be separated with commas and the system will display them in a selector.

They are linked fields, a main field and a secondary field. Depending on the choice in the main field, the secondary field will show different values.

If you need to address hardware issues in the keyboard and mouse peripheral accessories you can create a main field with those two options and then a secondary field with the types of connection to the computer of those peripherals.

Creation of the main field:

1. Add a custom field.
2. Field name ingress Peripherals.
3. In Type select Linked.
4. In Parent, as it is the main field, leave it with the default value Select parent.
5. In Linked value insert ,Keyboard,Mouse.
6. Press the Create button to save the main field.

Creation of the secondary field:

1. Field name ingress Peripheral connection type.
2. In Type select Linked.
3. In Parent, as it is the secondary field, select Peripherals.
4. In Linked value insert ,Keyboard|USB,Keyboard|Bluetooth,Keyboard|PS/2,Mouse|USB,Mouse|Bluetooth.
5. Press Create button to save secondary field.

Creating a new ticket and choosing its type will look something similar to this:

There is a tab within ticket details that will show them all as a summary. You may broaden this information through detailed ticket reports and overall here is everything you need to know. Depending on the history of that ticket, you will see more or less data. These statistics are grouped into six sections:

1. General: Time since opened, closed, last update, time spent, and time not assigned to third parties.
2. Work Units: Time elapsed since the last job performed, number of work units, etc.
3. Activity by user according to Workunits.
4. By status (time in last status).
5. By group to which the incident belongs.
6. For each user who has owned the ticket.
7. By company.
8. By SLA time. In this case, starting with version 107, percentage calculations were removed and the following times are used:

First response (FRT)

Total SLA time calculated since the ticket was opened, until the moment the first response was received:

• Used: Time elapsed between the creation of the ticket and the agent's first response. If there is no initial response yet, this time will be updated on a steady basis. Times will be counted within the SLA time frame .
• Limit: First response SLA limit defined in the SLA associated with the ticket.
• Deviation: If the value used is less than the limit, deviation is the time remaining within the SLA (positive value). If the value used is greater than the limit, deviation represents non-compliance time (i.e., delay). In the latter case, an SLA alert will be triggered.Response time

It measures the time between subsequent responses after the initial one between the ticket creator and the agent. For it to be counted correctly, ticket status must be “Pending Support”.

• Used: Time elapsed since the customer's last response, within the SLA time frame.
• Limit: Maximum response time configured in the SLA associated with the ticket.
• Deviation: If the value used is lower than the limit, deviation is the time remaining within the SLA (positive value). If the value used is greater than the limit, deviation represents non-compliance time (i.e., delay). In the latter case, an SLA alert will be triggered.

Inactivity time

It measures the time since the last ticket update.

• Used: Time elapsed since the last ticket update within the SLA time frame.
• Limit: Inactivity time limit established in the SLA associated to the ticket.
• Deviation: If the value used is lower than the limit, deviation is the time remaining within the SLA (positive value). If the value used is greater than the limit, deviation represents non-compliance time (i.e., delay). In the latter case, an SLA alert will be triggered.

Resolution (TTR).

It measures the total time from ticket creation to resolution. It ensures that incidents are solved within an acceptable timeframe.

• Used: Time elapsed since the ticket was created until the last ticket update.
• Limit: Downtime limit set in the SLA associated with the ticket.
• Deviation: If the value used is lower than the limit, deviation is the time remaining within the SLA (positive value). If the value used is greater than the limit, deviation represents non-compliance time (i.e., delay). In the latter case, an SLA alert will be triggered.

If in the ticket process you need to generate a document (PDF) with all the details, in a specific format, to deliver to a customer or a supplier as a delivery note or proof of execution of a job, you need to make a Work order. Work orders can be created by defining a template and then having it automatically filled in for each issue using macros.

Some of these fields are filled with data from the ticket (macros), others could be filled using custom fields (macro with the name of the field) and others are left blank to be filled manually by the customer or operator in person.

Then access the ticket edition, option Work order and click on New Work order:

Once the work report has been created from the corresponding template, the document can be downloaded:

You can also validate (Validate work order) by uploading a version of the same document signed by the customer (scanned or photographed) for the record.

The following macros will be replaced by the actual value in templates that use them:

One of the most important fields of the tickets is the status. By means of this field it is possible to keep track of the ticket's current status.

By default this cycle is free to the user and can be modified without prior requirement.

It is possible to define a controlled flow to restrict the order of the states a ticket can go through using the State Mapping feature. By using state mapping, you can define whether a ticket must necessarily pass through different phases before it is closed.

The combinations between the different statuses are many, one of the simplest cases is shown: A new ticket (initial status) can only be assigned. After being worked it can only be pending to be closed and after review it can be closed with two options: solved or incomplete. In case of being incomplete it has the possibility to be reopened and from there more conditions can be added.

The SLA (Service Level Agreement) is the way to “verify” that ticket management works under specific criteria. Pandora ITSM has automatic SLA management features. The SLA is processed according to some parameters and is configured in Support → View SLA menu.

Some of the fields that require explanation are the following:

• First response SLA (in hours): Maximum time in hours that can elapse between the creation of a ticket and the first response from the ticket owner.
• SLA Base: It indicates the relationship with another SLA for informational purposes.
• SLA Type:

1. Normal SLA: When calculating, tickets that are not in “Closed” or “Third Party Pending” status will be taken into account.
2. Third party SLA: Only tickets that are in “Third Party Pending” status will be considered.
3. Both: Tickets in any status other than “Closed” will be considered. Version 106 or later: When selecting both, the option Max. ticket inactivity (in hours) for Third party SLA will appear in order to configure some parameters for Normal SLA and other parameters for Third party SLA and will be applied depending on the ticket status, in one way or another.

• Max. response time (in hours): Maximum time elapsed between a ticket creator's Workunit and another response. For example, if this time is 4 hours, and a new ticket has 4 hours and 6 minutes to live, the SLA will be triggered. If a ticket is already several days old and the last work unit is from the ticket creator, after 4 hours without response, the SLA will also trigger.
• Max. resolution time (in hours): The maximum lifetime of a ticket. If a ticket is older than that time and is not closed or solved, the SLA will go off.
• Max. tickets at the same time: If it is exceeded, the SLA will go off. Please note that all SLA are set at group level.
• Max. ticket inactivity (in hours): Time that the ticket can stay without updates by any user with access to the ticket.
• Disable SLA on holidays: Days defined as holidays will not be included in SLA calculations. In ticket settings (see below) you may define the calendar days that the SLA will consider as holidays.

Starting with version 107, Scheduled was introduced with its simple and detailed options for configuring, even down to the minute (the cron must be configured minute by minute for this), the time periods when the SLA will be calculated:

It means that the system will send an email notification to the ticket owner, warning about the ticket not meeting the criteria set in the SLA rule set associated with the ticket. This will depend on the group the ticket is associated to, since it is in group configuration, where it is specified which SLA will be applied to group tickets.

Using the SLA system, in the ticket view you may see on a time scale (histogram), when the ticket was not fulfilled (in red) and when it was fulfilled (in green). In addition to an indicator of the percentage of compliance of the ticket throughout its life or by date ranges (last 15 days, today, et cetera).

SLA metrics may be obtained through API for each incident, for each group, for each operator. They are also used in reports. These are the most important metrics to measure service quality.

Ticket Quality Assurance or Q/A and feedback may as well be configured.

By default the system will ask the ticket creator, when the ticket is closed (regardless of who closes it), how the ticket was closed. An email will be sent to access a rating screen.

These ratings are associated with the ticket and the person who owns it. Only users with Q/A permissions and the user who created the ticket may access this data.

The default support ticket rating is enabled at general level in the Setup → Setup → Issue setup → Ticket behavior → Disable ticket score menu.

At group level, in the People → Groups management menu, the token Send customer satisfaction email is enabled by default.

You can limit, for each group, the total number of tickets created per user, and the total number of active tickets for a user. These are two different limits that can be configured together:

• Total ticket limit: If it is a grouped user, it shows the maximum number of tickets for the group that a user can have in total (open or closed). If this is an independent user, it shows the maximum number of tickets for a user, for that group, that a user can have in total (open or closed).
• Open ticket limit: If it is a grouped user, it shows a maximum number of tickets for this group that a user can have opened at the same time. If it is an independent user, it shows the maximum number of tickets for this group and for one user that a user can have opened at the same time.

It is also possible that the limit of simultaneous open tickets can be “forced” and not allow the creation of new tickets or simply “warn” with a message and allow the creation of new tickets. To work without limits, the value should be set to 0.

Starting with version 107, SLA calculations using percentages have been removed and the following filtering times have been introduced:

All saved custom searches can be reused in the ticket overview as well as being the base data for standard ticket reports.

Once the filtering criteria have been established, save by pressing the Add custom filter option. The name of the filter will be asked and saved with the Save custom filter button.

For future searches with custom filters, simply click on the Load custom filters button and click on the corresponding Load preset. In this dialog box you can also select one or more filters and delete them with Delete selected presets.

The columns to be displayed in the incident list can be customized at a general level by the general configuration. These columns will be displayed to each and every user when using the Support → All tickets menu.

Then you can set the necessary columns using the Set custom columns option and then save that selection in a custom filter.

In Available fields, you can select multiple fields and add them to Selected fields using the > button, and vice versa. When you are finished, you can save your selection by clicking the Save changes button.

You may customize all emails that are sent, changing their appearance. That is done using a set of macros inserted into the template. The templates are HTML files that may be edited from the tool itself in menu Setup → Setup → Email templates setup.

Mail templates are applied to incidents and also to project management. You may even assign different templates, depending on the group. Editing is simple and intuitive, and minor changes (logo, texts) can be made from the editor itself without any HTML knowledge.

• In each of the Status and Resolution sections there are a series of fields that can be modified according to need and language. In the case of languages, right next to the two sections, there is a button to reload default values in the language used by the user who configures Customization.
• In the Special day section you may add and remove holidays and check whether these holidays are working days.
• The list of fields to be displayed in the incident list is preconfigured and can be modified in section Default custom columns.

Each item has an individual selector or a selector of all items displayed in order to perform the same operation on the selection made. The interface is displayed to all users, however, when ordering change execution, permissions will be checked and, if necessary, the requested modifications will be saved.

You may massively modify the status of each ticket, priority, resolution status, task label, group, assign a ticket as parent of the selected ones, or change its owner. Finally, and to be used with care, there is the option to delete the selected items.

The fields will be the following according to the logical order established by the tool (the names have been numbered to make work easier):

1. Start.
2. Close.
3. Qualification.
4. Description.
5. User ID.
6. State.
7. Priority.
8. Group ID.
9. Update.
10. Identifier of the creator.
11. Task identifier.
12. Resolution.
13. Epilogue.
14. Father's identifier.
15. SLA disabled.
16. Identifier of the affected SLA.
17. Incident type identifier.
18. Punctuation.
19. Emails in copy.
20. Publisher.
21. Identifier of the creator group.
22. Last state.
23. Closed by (name).
24. Extra data.
25. Extra data 2.
26. Locked.
27. Old state.
28. Old resolution.
29. Old state 2.
30. Old resolution 2.
31. Extra data 3.
32. Extra data 4.
33. Do not show a notice to assess the resolution of the ticket.
34. Hash.
35. Evaluation (positive or negative).
36. Valuation comment.
37. Custom fields: They must previously exist in Pandora ITSM system and must be indicated in order, being able to choose a value, or in case of not wanting to give them a value, blank space (,,). In the case of tickets, it will be necessary to create the type the fields belong to and obviously reference that type in the ticket itself.

Back to Pandora ITSM documentation index