Ticketing and Support

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

Tickets have a series of basic characteristics such as the urgency or criticality of the issue, a title, the assigned group, and the users involved in it and their status, and advanced features such as 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. He/she 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 visibility of the ticket (as long as he/she is 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 can escalate (pass the ticket ownership) to another person, but the owner can only be one person. That owner is the only person who can close a ticket.
3. User ticket editor: It may be different from the originator, someone simply 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: he may simply be a technician who provides some information.
5. User associated to a ticket: any person who has participated at any time during the life of the ticket, making modifications or adding comments. You will also receive notifications with any updates to the ticket.

In the Contacts tab you can 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 can 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 view another user's ticket, he/she must have visibility over that group.

An example will show the 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 act independently.

• Team operators will have several people working simultaneously who will be able to view each other's tickets, either to contribute or to take care of them. Customers or independent users can 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 act individually and its user will be of the “independent” type, so that it will only view 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 can 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 can 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 originator and the ticket recipient.

You can answer the email and this answer will be added to the ticket's comment “thread”. Another option is to continue its management through the 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 can then change its status, or navigate through the ticket tabs to see its history, notes associated with the ticket (workunits), files, etcetera.

The status of a ticket starts in a NEW status (New) and from that point the timer starts running. SLA management (Service Level Agreement) counts the time from when a ticket is opened until it starts being managed and changes status from NEW to ASSIGNED (Assigned). It also counts the time from when the ticket creator writes and receives a reply and the total time it takes to resolve an issue.

Only the owner of a ticket can change the ticket statuses.

There are other important statuses on a ticket, such as PENDING ON A THIRD PERSON (Pending on a third person), which puts the ticket in “pause” mode with respect to the SLA, as it generally refers to a situation whereby it is necessary to wait for someone to provide some information in order to proceed with the resolution of the ticket.

There are also two special statuses: PENDING TO BE CLOSED (Pending to be closed) and UNCONFIRMED (Unconfirmed) which are temporary statuses by which to mark a ticket that is pending closure or has been received but not yet classified. They serve mainly to identify the ticket in a state that can then be processed with workflow rules, but without purpose to its incidence with SLA management.

The CLOSED status (Closed) refers expressly to the end of life and allows you to add a resolution epilogue and a specific field to indicate the resolution of the ticket (solved, rejected, missing data, expired, etc.). A CLOSED ticket can be locked to prevent it from being reopened.

The REOPENED state (Reopened) is similar to the ASSIGNED state, but indicates that it has been activated from the CLOSED state.

The team of people working on the ticket (the customer, the operator, the 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, it is enough to answer one of the emails in the ticket or it can be entered manually through the interface using the tab marked with a speech bubble:

• The WU (Workunits) allow you to write a text and additionally add attachments, specify the time spent on that action (in hours), if you have worked jointly with another member of the team, if costing is included according to the imputed profile, and so on.
• From version 103 OUM any other user can 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 the support reports that include all these metrics (and many others). The intention is to be able to track in detail the treatment of each incident in order to evaluate the quality of support from all possible angles: costs, quality, time, effort, staff profiles, customer profiles, among others.

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

• Time used: 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.
• Cost: To indicate what should be taken into account for service cost calculations.
• Internal: To check if the comment will not be visible to the issue creator.
• Profile: Displays additional information about the profile of the person writing the message.
• 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” y “Limits to ticket creation”.

A ticket has a series of fields customized by the user, which are related to the type of ticket. It is possible to create different types of tickets, and each one with its custom fields.

In addition to the fields defined by the administrator, there is a series of special fields, which can be seen in the editing view, in the “Advanced parameters” box (Advanced parameters):

Publisher is the application user who creates the ticket, and is there for auditing and logging purposes, cannot be changed. The same goes for the creator group. They are “fixed” fields that we can later use as filters in the workflow rules.

You can define nested ticket hierarchies, linking one to the other in a parent-child relationship, for that there is the “Parent ticket” field (Parent ticket). You can also link a support ticket to a project, through linking with a task (Task), since tasks are subdivisions of projects.

In the same way, one or several inventory objects can be linked to an incident, so that later you can have traceability of which elements an incident affects and also see the history of incidents that a certain inventory object has had.

It is also possible to keep a group of third parties informed of the life flow of a ticket, of whom we only have their email address, who do not even have access to Pandora ITSM. In this way, they will receive copies of everything that happens via email. It is an easy way to include third parties and keep them informed.

Tickets of different types can be defined, so that each ticket type has its own fields. These fields may be of the type text, dates, verification box (checkbox), a selector and even make it possible to chain several selectors, and depending on the user's selection some values or others are displayed.

It is also possible to configure certain types of tickets to be available only to certain groups: for example, if you have a technical support group and a user support group, the types of “Technical Incident” tickets that require filling in many detailed fields would only be available to the “technical” group, while other ticket types that do not require technical knowledge are available to anyone.

You can create or modify a custom ticket type: Support → Tickets Types → View tickets types.

When you define a ticket type you will be able to set one or more custom fields. You may need to define a common field for all custom ticket types (so you don't have to go one by one, putting it in all of them) and that's what the “global field” (Global field) is for.

There are text type fields (one line), extended text (a multi-line free text box), date type data (which will show a calendar), numeric type (and which the system will validate as a number) or type “ true False”.

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

The possible values must be separated with commas and the system will display them in a selector.

They are custom fields related to each other. For example, an IT technician needs to identify the item to be repaired. To get there, he will first need to choose the element type:

• Portable computer (Laptop).
• Desktop computer (PC).
• Keyboard (Keyboard).
• Mouse (mouse).
• Screen (Monitor).
• Other

In addition, depending on the type of element, you must choose manufacturer brands for each of them.

You must first create the custom field “Hardware type”. In this case, a parent field (Parent) is not selected because it is the first in the hierarchy. The values will be separated by commas.

The second linked field, in this case it would be the brand, will have the “Hardware Type” field as its parent and the linked values will have a special format:

type_value1|brand_value1,[type_value2|brand_value2],[type_value3|brand_value3]...

In this way, following the previous example, it should be defined like this:

Laptop|HP,Laptop|Lenovo,Laptop|Mac,PC|HP,PC|Dell,Keyboard|ES,Keyboard|UK,Keyboard|Mac,Mouse|Mac,Mouse|Logi,Mouse|HP,Mouse|Microsoft,Other| trackball

There is a tab inside the ticket details that will show all the details, as a summary. You can expand this information with the detailed ticket reports (see reports), but in general you have everything you need to know here. Depending on the history of that incident, you will see more or less data.

If in the process of the incidence it is necessary to generate a document (PDF) with all the details, in a specific format, to deliver to a client or a supplier as a delivery note or proof of execution of a job, it is necessary to carry out a part of work (Work order). You can define your own work parts using a template and then have it automatically filled in using macros.

To create a work ticket, go to the Support → Ticket Types → Work Ticket Templates menu and click the Create button.

It will be created with the system template (there is one defined by default, which can be customized). It will automatically make it accessible for download in that same location.

Some of these fields have been filled in with ticket data, others could be filled in using custom fields and others are left blank to be filled in manually by the client or operator in person. Download the document, and if you want you can validate it by uploading a version of that same document signed by the client (scanned or photographed) for the record.

Different worksheet templates can be assigned depending on the type of ticket. There is a set of macros you can use to replace them with the ticket data. We recommend that you edit the default template to understand how it works.

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

• _sitename_: Name of the page, as defined in the configuration.
• _incident_title_: Title of the incident.
• _username_: Username.
• _fullname_: Full name of the user.
• _incident_id_: Incident identifier.
• _url_: URL of the incident.
• _creation_timestamp_: Date and time of incident creation.
• _update_timestamp_: Last time the incident was updated.
• _owner_: User who manages the incident.
• _group_: Group assigned to the incident.
• _author_: Incident creator.
• _type_tickets_: Type of tickets.
• _priority_: Priority of the incident.
• _status_: Status of the incident.
• _resolution_: Resolution of the incident.
• _time_used_: Total time used in the incident.
• _incident_main_text_: Description of the incident.
• PlanCustom field templates: This allows the name of the fields to be added to be included as a macro when creating an object type which will display the value of said field: _custom field name_.

One of the most important fields in tickets is the status. Using this field, you can accurately track where the ticket is in its life. This cycle is open to the user and can be modified.

It is possible to define a controlled flow to restrict the order of states a ticket can go through using the State Mapping feature. Using state mapping you can define if a ticket should go through different phases before being closed. This is configured in Support → Workflow → Status mapping.

The SLA (Service Level Agreement) is the way to “verify” that ticket management works under specific criteria. Pandora ITSM has automatic SLA management functionalities. 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:

• SLA Base: Indicates relationship with another SLA for informational purposes.
• SLA Type:
  • Normal SLA: When calculating, tickets that are not in the “Closed” or “Third Party Pending” status will be taken into account.
  • Third party SLA: Only tickets that are in the “Third Party Pending” status will be considered.
  • Both: Tickets in any status other than “Closed” will be considered.
• Max. response time (in hours): Maximum time that can elapse 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 a 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 resolved, will SLA went off.
• Max. tickets at the same time: If it is exceeded, SLA went off. Please note that all SLAs are set at the group level.
• Max. ticket inactivity (in hours): Time that the ticket can be without an update by any user with access to the ticket.
• Start hour to compute SLA: Hour of the day from which the SLA begins to be calculated.
• Last hour to compute SLA: Hour of the day from which the SLA is no longer calculated.
• Disable SLA on weekends: Considers Saturdays and Sundays.
• Disable SLA on holidays - Days defined as holidays will not be included in SLA calculations. In settings of tickets (see below) you can define the calendar days that the SLA will consider holidays.

It means that the system will send an email notification to the ticket owner, advising that the ticket does not meet the criteria set in the SLA rule set associated with the ticket.

This will depend on the group to which the ticket is associated, since it is in the group configuration where you specify which SLA will be applied to group tickets.

Using the SLA system, in the ticket view you can see on a time scale (histogram), when the ticket has not been fulfilled (in red) and when it has been 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, etcetera).

SLA metrics can be obtained via 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.

Quality assurance ( Quality Assurance or Q/A) and feedback (feedback) of tickets may 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.

The rating can only be good or bad, and in both cases an optional explanatory text can be added. 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 can access this data.

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

At the 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 (Total ticket limit), and the total number of active tickets for a user (Open ticket limit). These are two different limits that can be configured together.

This is configured in the group definition in the People → Groups management menu in the Open ticket limit and Total ticket limit fields. It is also possible that the limit of simultaneous open tickets can be forced and not allow to create new tickets or just warn with a message, but allow to create them. To work without limits, leave the value at 0.

A custom search can be created and stored for use in reports, the dashboard and the ticket search itself by loading the filter.

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

To do this, first use the ticket finder in Support → All tickets, set search criteria and display the results.

Click on Add custom filter. The filter name will be asked and saved with the Save custom filter button.

For future searches with custom filters, just click on the Load custom filters button and the selected results will be displayed in a few seconds.

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

Mail templates are applied to incidents and also to project management. You can 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.

Macros for e-mail templates, each introduce:

• _author_: Creator of the incident.
• _creation_timestamp_: Date and time of incident creation.
• _creatorcompany_: Company of the ticket originator.
• _epilog_: Summary of ticket closure.
• _id_group_: Identifier of the group assigned to the ticket.
• _id_priority_: Numeric value of the ticket priority.
• _id_status_: Numeric value of the ticket status.
• _incident_closed_by_: User who has closed the ticket.
• _incident_id_: Incident identifier.
• _incident_main_text_: Description of the incident (main text).
• _incident_title_: Title of the incident.
• _fullname_: User's full name.
• _group_: Group assigned to the incident.
• _owner_: User who manages the incident.
• _ownercompany_: Company of the owner of the ticket.
• Custom Field Templates: This allows when creating an object type the name of the fields you add to be included as a macro which will display the value of that field: “_custom_field_name_”.
• _priority_: Incident priority.
• _resolution_: Resolution of the incident.
• _status_: Incident status.
• _sitename_: Name of the page, as defined in the configuration.
• _time_used_: Total ticket life time.
• _ticket_satisfaction_: When a ticket is closed, this macro is replaced by a link to the ticket satisfaction screen.
• _type_tickets_: Type of ticket.
• _url_: Incident URL.
• _update_timestamp_: Last time the incident was updated.
• _username_: User's name.
• _wu_user_: In WU templates, the user who wrote the note.
• _wu_text_: In the WU templates, the text of the note.

Setup → Setup → Issue setup menu.

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 is configuring the Customization.

In the Special day section you can add and remove holidays and mark if these holidays are working days.

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

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. Personalized fields: they must previously exist in the 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 to which the fields belong and obviously reference that type in the ticket itself.

Back to Pandora ITSM Documentation Index