Ticketing and support

Go back to Integria IMS Documentation Index

Integria IMS proposes a vision of support management adaptable to different needs: a ticket can be understood as a generic incident for a support team, a question to report a problem, a software bug or a planned intervention with a worksheet attached. Integria IMS can be used in a call center for operators to enter incidents into the system, or it can be offered online, hooked to a form on its website so that customers can create queries directly from the internet. Integria IMS has many possible uses.

Tickets have a series of basic features such as the urgency or criticality of the issue, a title, a description, the assigned group, and the users involved in it and their status. Then there are many other optional fields and of course, all those that the administrator defines for the type of ticket (custom fields).

When we talk about users we have to understand that each user has a specific role, so we have:

1. User who created the ticket. It is the person who identifies the problem or who raises the question. They will be the person to help in the incident management process.
2. User who owns the ticket . He is the person in charge of solving the problem. There can only be one as the issue can be escalated (pass ownership of the ticket) to someone else, but the owner can only be one person. That owner is the only person who can close a ticket.
3. User who edits the ticket. It may be different from the creator, someone simply in charge of adding the ticket to the system. Remember that if the system is managed through a line of operators, the person who picks up the call and enters the ticket is neither the creator of the ticket nor the person who is going to solve it.
4. User with access the ticket , and who provides information, but who is neither the one who created it, nor the one who is going to solve it: it may simply be a technician who provides some information.
5. User associated with a ticket : any person who has participated at some point during the life of the ticket, making modifications or adding comments. You will also receive notifications with the updates included on the ticket.

In the Contacts tab, you may see the full list of the people who participate in a ticket and their role.

Users in turn belong to companies and groups, and ticket visibility is defined based on the permissions assigned to those users. There are access bits that define who can VIEW, EDIT or MANAGE Tickets. Thus, the EDIT permission is needed 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.

Through an example, ticket management operation will be shown. Our support team is made up of three people (Tomás, Javi, Luis) and a team “leader” (Ramón).

We different types of clients. Those who work as a team and those who work independently. Those who operate as a team will have several people working simultaneously who will be able to view the Tickets of their colleagues, either to contribute with something, or to take charge of them. Independent customers or users can only view 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 in this group will be “grouped”, and their privileges will be based on the profile they have associated with their work group. While the second type of client will act individually and their user will be “independent”, so that they will only view their own content.

In our environment, when a grouped client opens a ticket, it is assigned to a user named “Ramón”. 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 will be seen later, with the workflows you may develop much more complex actions, such as sending a message to Telegram every time you receive a high priority incident, being able to assign a ticket to certain types of users depending on certain criteria and many other actions.

A mail message will be received by both the creator of the ticket as well as the ticket receiver, something like this email:

You may reply to the email and the reply will be added to the ticket's comment “thread”. Another option is to continue your management through the Integria IMS web interface, which will allow you to do much more than simply post a comment.

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

By clicking on the ticket number or its description, you enter the main ticket management screen. You may change its status, or browse the ticket tabs to see its history, notes associated with the ticket (workunits), files, and so on.

The status of a ticket starts in a NEW status (New) and from there the time counter starts. SLA (Service Level Agreement) management counts the time from when a ticket is opened until it begins to be managed and changes its status from NEW to ASSIGNED (Assigned). Also the time that passes since the ticket creator writes and receives a response and the total time it takes to solve an issue. Only the owner of a ticket can change the ticket statuses.

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

There are also two special states: PENDING TO BE CLOSED and UNCONFIRMED which are temporary states by which to mark a ticket that is pending to be closed or has been received but has not yet been classified. They mainly identify the ticket in a state that can then be processed with workflow rules, but it has no other purpose related to its incidence with SLA management.

The status CLOSED refers expressly to the lifespand end and allows adding a resolution epilogue and a specific field to indicate its resolution (solved, rejected, missing data, expired, etc.). A CLOSED ticket can be locked to prevent its reopening. The REOPENED state is similar to the ASSIGNED state, but indicates that it has been revived from the CLOSED state.

The team of people who work on the ticket (the client, the operator, second-level technicians, etc.) interact with each other by adding text notes (or workunits in Integria IMS terminology). Each user with access to the ticket provides information for its resolution. To do this, just answer one of the emails on the ticket or it can be entered manually through the interface using the tab marked with a speech bubble:

WUs (Workunits) allow write a text but and also to add attachments, specify the time spent on that action (in hours), whether you have worked together with another member of the team, if cost calculation based on the imputed profile is included, etc.

All of this information will then be used for support reports that include all of these metrics (and many others). The purpose is to be able to do a detailed follow-up of the processing of each issue in order to evaluate the quality of the support from all possible angles: costs, quality, time, effort, personal profiles, customer profiles, among others.

Clicking on tab will lead to the following dialog:

Time used

Time spent, in hours, on the message.

Cost

To indicate what should be taken into account for service cost calculations.

Internal

If the comment will not be visible to the issue creator.

Public

Whether the message can be seen for everyone or only for Super Administrator or same company users.

Perfil

Displays additional information about the profile of the person writing the message.

Workunit shared with

Share the WU with another user from the same company; type two or more letters to search for users.

Description

The message itself. You will be able to format, web links, etc.

To finish, add the WU with the button ♦Add.

See also “Ticket configuration” and “Ticket creation limits”.

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 , each with its own custom fields.

In addition to the administrator-defined fields, a number of special fields, which can be seen in the edit view, in the box Advanced parameters:

The editor is the user of the application that creates the ticket, and for auditing and registration purposes, it cannot be changed. The same is true of the creation group. They are “fixed” fields that you may then use as filters in the workflow rules.

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

In the same way, you may link one or more inventory objects to an issue, so that later you may have a 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 make aware of the flow of life of a ticket to a group of third parties of which we only have their email address, who do not even have access to Integria IMS. That way, they will receive copies of everything that happens via email. It is an easy way to include third parties and keep them updated.

You may define Tickets of different types, so that each type of ticket has its own fields. These fields can be text, dates, 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.

In addition, it is possible to configure that certain types of Tickets are available only for certain groups: for example, if you have a technical support group and a user support group, the ticket types “Technical incident” that require filling in many detailed fields, would only be available to the “technicians” group, while other ticket types that do not require technical knowledge are available to everyone.

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

When defining a ticket type, you may set one or more custom fields. You may need to define a common field for all types of custom Tickets (and thus not have enter it one by one) and for that is the “global field” (Global field).

There are different fields like text (one line), extended text (a multiline free text box), date data (that will show a calendar), numeric (and that the system will validate that it is a number) or “true False”.

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

Just separate the possible values 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, you will first need to choose the type of element:

• Laptop.
• PC.
• Keyboard.
• Mouse.
• Monitor.
• Other

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

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

The second field linked, in this case the brand, will have as parent “Hardware type” field and linked values will have a special format:

value_type1|value_brand1,[value_type2|value_brand2],[value_type3|value_brand3]...

That 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

This is seen in the ticket creation interface as follows:

There is a tab within the ticket details that will show all the details, as a summary. You may expand this information with the detailed ticket reports (see reports), but overall everything you need to know is here. Depending on the history of that incidence, you will see more or less data. If, for example, the issue has not yet been closed, you will have less information. Example:

If in the process of the incident 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, a work order must be generated. You may define your own work items using a template and then have it filled out automatically using macros.

To create a working orde, go to Support → Tickets Types → Work order templates and click Create:

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

This is an example of what the PDF generated by that work order looks like:

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

Different work report templates can be assigned depending on the type of ticket . There is a set of macros that you may use to replace them with the ticket data. We recommend you to edit the default template to understand how it works. In the following example, the macros are indicated by red boxes:

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

• _sitename_ : Name of the page, as defined in the configuration.
• _incident_title_ : Incident title.
• _username_ : User name.
• _fullname_ : Full user name.
• _incident_id_ : Incident identifier.
• _url_ : Incident URL.
• _creation_timestamp_: Date and time the incident was created.
• _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_ : Incident priority.
• _status_ : Incident status.
• _resolution_ : Resolution of the incident.
• _time_used_ : Total time spent on the incident.
• _incident_main_text_ : Description of the incident.
• Custom fields: This allows that when creating an object type, the name of the fields that are added can be included as a macro which will show the value of said field: _custom field name_ .

One of the most important fields on Tickets is the status. Using this field, you may accurately track the time the ticket is at in its lifespan. 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 may define whether a ticket must go through different stages before being closed. This is configured in Support → Workflow → Status mapping

Example of different statuses of a ticket:

A team of operators is responsible for managing customer incidences. To ensure that the order of resolution is respected and guarantee customer service quality, through status mapping it is indicated that:

1. A ticket with the status “New” can only go into states “Assigned” or “Pending on third person”.
2. From either of these two states it can only go into “Pending to be closed”.
3. Only if it is in “Pending to be closed” can it finally be “Closed”.
4. Furthermore, from “Closed” the only possibility will be to be “Reopened” again.

The configuration for this case would be:

For each condition insert a line with Add row and save to floppy icon. You may also delete a condition in the trash icon (Actions column) and save the changes for a condition in the Update icon next to delete.

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

Some of the fields that require explanation are the following:

• SLA Base: It indicates relationship with another SLA for informational purposes.
• SLA Type:
  • Normal SLA: When making the calculation, the Tickets that are not in “Closed” or “Pending third parties” status will be taken into account.
  • Third party SLA: Only tickets that are in “Pending on third party” status will be taken into account.
  • Both: Tickets that are in any state other than “Closed” will be taken into account.
• Max. response time (in hours: Maximum time that can elapse between the ticket creator workunit and another response. For example, if this time is 4 hours, and a new ticket is 4 hours and 6 minutes old, the SLA will be triggered. If a ticket is already several days old and the last workunit belongs to the ticket creator, after 4 hours without a response the SLA will also be triggered.
• Max. response time (in hours): The maximum lifetime of a ticket. If a ticket is older than that time and is not closed or resolved, the SLA will be triggered.
• Max. tickets at the same time (Maximum number of tickets open at the same time): If exceeded, the SLA will be triggered. Note that all SLAs are configured at group level.
• Max. ticket inactivity (in hours): Time the ticket can stay without an update by any user with access to the ticket.
• Start hour to compute SLA: Time from which the SLA starts to be calculated (e.g.: 9 in the morning).
• Last hour to compute SLA: Time from which the SLA stops being calculated (e.g.: 6 in the evening).
• Disable SLA on weekends: It considers Saturdays and Sundays.
• Disable SLA on holidays: Days defined as holidays will not be included in SLA calculations. In the ticket configuration (see below) you may define the calendar days that the SLA will consider holidays.

It means that the system will send an email notification to the ticket owner, warning that the ticket does not meet the criteria established in the set of SLA rules 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 the group tickets:

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

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

The quality assurance Q/A and feedback of tickets may be configured.

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

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 and are not visible to that person.

Only users with Q/A permissions can access that data, and also the user who created the ticket. This assessment can be seen in the ticket itself as follows:

To activate the assessment of support tickets, check that it is not deactivated globally, go to the menu Setup → Setup → Issue setup

And it is also configured at the level of each group:

You may limit, for each group, the Total ticket limit created per user, and the Open ticket limit for a user. They are two different limits that can be configured together.

This is configured in the group definition (People → Group management menu) in the Open ticket limit and Total ticket limit fields. It is also possible that the limit of simultaneous open tickets could be “forced” and that it does not allow creating new Tickets or simply “warning” with a message, but that it allows creating them. To work without limits, leave the value at 0.

You may create a custom search and store it for use in reports, in the dashboard, and the ticket search itself, loading that 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 search engine (Tickets → All my tickets) and search for results:And click Add custom filter. You will be asked the Filter name, fill it out and save with Save custom filter:

For future searches using custom filters, just click Load Custom Filter and it will display the results selected right away.

You may customize all the emails sent, changing their look. To do this, a set of macros that are entered into the template are used. Templates are HTML files that can be edited from the tool itself, in Configuration → Setup in the Mail Template tab:

Mail templates apply not only to incidences, but 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 having to have any knowledge about HTML.

Macros used in email templates:

• _sitename_ : Name of the page, as defined in the configuration.
• _incident_title_ : Incident title.
• _username_ : User name.
• _fullname_ : Full user name.
• _incident_id_ : Incident identifier.
• _incident_title_ : Incident title.
• _url_ : Incident URL.
• _creation_timestamp_ : Date and time the incident was created.
• _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_ : Ticket type.
• _priority_ : Incident priority.
• _status_ : Incident status.
• _resolution_ : Resolution of the incident.
• _time_used_ : Total time spent on the incident.
• _incident_main_text_ : Description of the incident (main text).
• Custom fields: This allows that when creating an object type, the name of the fields that are added can be included as a macro which will show the value of said field: _custom field name_.
• _creatorcompany_ : Company of the ticket creator.
• _ownercompany_ : Company owner of the ticket.
• _id_group_ : Group identifier assigned to the ticket.
• _id_priority_: numerical value of the priority of the ticket.
• _id_status_ : Numerical value of the ticket status.
• _incident_closed_by_ : User who closed the ticket.
• _time_used_ : Total lifetime of the ticket.
• _wu_user_ : In WU templates, the user who wrote the note.
• _wu_text_ : In WU templates, the text of the note.
• _ticket_satisfaction_ : When a ticket is closed, this macro is replaced by a link to the satisfaction screen of the ticket.
• _epilog_ : ticket closing epilogue (summary).

Go to the Configuration → Setup menu and access the advanced incident configuration tab:

On this screen there are several checks that define what the system performance is like:

• Show the creator of the ticket and show the owner of the ticket in ticket search list/view.
• Maximum number of Tickets per search: Limit search results for tickets to avoid performance impacts from excessively large searches. A limit between 200 and 500 is recommended.
• Enable quick edit mode: It allows you to quickly edit some elements of the ticket (user owner, criticality, status) without entering full edit mode.
• Show username instead of identifier when searching for tickets: real name instead of ID.
• Two date format options: long format yyyy/mm/dd h:m:s (default option) and approximate format; example: 1 day, 2 hours.
• Date of realization: Checking this option will display the Date of realization field in the ticket workunits. This date can be different from the creation date of the workunit.

• Disable incident assessment.
• Enable IW to change creator: Users with that access bit will be able to change the creator of the ticket .
• Editor adds WU on ticket creation: a WU is added automatically when creating a ticket.
• Allow to change the ticket type: if disabled, the type cannot be changed once created.
• Allow to define the time/date of the ticket when creating it.
• Ignore user defined by group for owner.
• Type of incidence required: forces you to choose a type of ticket.
• Ignore the default creator user: it must be specified manually.
• Allow modification of the creator user and the owner user.
• Allow external users (not grouped) to modify their Tickets.
• Ignore group template from incident creator.
• Creator user can see all users. With this you will be able to see users from other groups.
• Auto assign ticket, based on group assignment rules.
• Ticket editor is the first user to edit: if checked, the ticket editor user will always be set as the user who edited the ticket in the first place.

• Ticket auto closing: Number of hours after which a ticket will be closed automatically.
• Ticket default WU time: default value used when entering a work unit, in units of hours. 0.25 will be 15 minutes.
• Sort WU by date of completion (in the WU list of a ticket).

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. Beginning.
2. Closing.
3. Title.
4. Description.
5. User ID.
6. State.
7. Priority.
8. Group ID.
9. Update.
10. Creator identifier.
11. Task identifier.
12. Resolution.
13. Epilogue.
14. Parent identifier.
15. SLA disabled.
16. Identifier of the affected SLA.
17. Incidence type identifier.
18. Punctuation.
19. Copies of emails.
20. Editor.
21. Creator group identifier.
22. Last state.
23. Closed by (name).
24. Extra data.
25. Extra data 2.
26. Blocked.
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 notice to assess the resolution of the ticket.
34. Hash.
35. Rating (positive or negative).
36. Rating comment.
37. Custom fields: they must exist previously in Integria IMS system and they must be indicated in order, being able to choose a value, or in case of not wanting to give them a value, a 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.

“2021-01-21 19:24:19, 2021-01-21 19:47:44, Terminal broken, Needs replacement, technician_support, 7, 3, 4, 2021-01-21 19:47:44, admin, 0, 1, 0,, 0, 0, 1, 0,, support_technician, 1, 0000-00-00 00:00:00, support_technician,,, 0, 3, 0, 7, 1,,,, 0, , 0,, custom_field_value1, custom_field_value2 ”[m]

Go back to Integria IMS Documentation Index