Integria IMS proposes a vision of support management adaptable to different needs: a ticket can be understood as a generic incident to a support team, a question, to report a problem, a software bug or a planned intervention with an attached worksheet. Integria IMS can be used in a call center for operators to enter incidents into the system, or it can be offered online, added to a form on your website so that customers can create queries directly from the internet. Integria IMS has many possible uses.
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 (PDF documents, text documents, etc.).
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:
In the Contacts tab you can see the complete list of people who participate in a ticket and their role.
The users in turn belong to companies and groups, and the visibility of the tickets is defined based on the permissions assigned to those users. There are access bits that define who can VIEW, EDIT or MANAGE tickets. So, 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, the 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 have various types of clients. Those who work in teams and those who act independently. Those that operate as a team will have several people working simultaneously who will be able to view the tickets of their colleagues, either to contribute something, or to take charge of them. Customers or standalone 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 of the “grouped” type, and their privileges will be based on the profile they have associated for their work group. While the second type of client will act individually and its user will be of the “independent” type, so that they will only view their own content.
In our environment, when a pool type customer opens a ticket, it is assigned to a useror called “Ramon”. That user will be the one who receives the ticket and can then escalate it if necessary to other users. It could also be sent to a generic user that acts as a mailing list. As will be seen later, with workflows you will be able to carry out 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.
An email will arrive both to the ticket creator and to the ticket receiver, something similar to this email:
You can reply to the email and said reply will be added to the ticket comment “thread”. Another option is to continue managing it 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 the “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 can change its status, or browse the ticket tabs to see its history, notes associated with the ticket (workunits), files, etc.
The status of a ticket starts in a NEW state (New) and from there the timer starts running. SLA (Service Level Agreement) management counts the time from when a ticket is opened until it starts to be managed and its status changes from NEW to ASSIGNED. It also counts the time that elapses from when the ticket creator writes and receives a response and the total time it takes to resolve an issue. Only the owner of a ticket can change 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 in which it is necessary to wait for someone provide some information to proceed with the resolution of the ticket.
There are also two special statuses: PENDING TO BE CLOSED and UNCONFIRMED, which are temporary statuses for marking a ticket that is pending closure or has been received but has not yet been classified. They are mainly used to identify the ticket in a state that can then be processed with workflow rules, but it has no other purpose in terms of its incidence with SLA management.
The CLOSED status (closed) makes express reference to the end of life 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 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, the 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, it is enough to answer one of the ticket emails or it can be entered manually through the interface using the tab marked with a speech bubble:
Clicking on the bubble icon will take you to the following dialog:
A Super Administrator type user will always be able to see all messages.
To finish add the WU with the Add button.
\\ <WRAP center round info 90%>
When a Work Item (comment) or file is added or its status is changed, an email notification is sent to all users associated with that ticket. This way the interaction is constant. You can customize the sending of emails through the configuration (see configuration options).
</WRAP>
See also “ Ticket configuration” and “limits_a_a_la_creacion_de_de of Tickets ”.
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 Integria IMS. 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 → Types of tickets → View types of tickets (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).
Just separate the possible values with commas and the system will display them in a selector:
The option string must begin with a comma, ie the first option must be empty.
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:
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
This is seen in the ticket creation interface as follows:
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, for example, the issue has not yet been closed, you will have less information. Example:
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 menu → Ticket Types → Work Ticket Templates ( Support → Tickets Types → Work order templates ) and click the Create button (Create):
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:
This is an example of what the PDF generated by that work order looks like:
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/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. In the following example the macros are marked by red boxes:
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._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 ( Support → Workflow → Status mapping )
Example of different statuses of a ticket:
A team of operators is responsible for customer incident management. To ensure that the order of resolution is respected and to guarantee a quality of service to the client, through the mapping of states it is indicated that:
The configuration for this case would be:
For each condition insert a line with Add row and save to the floppy disk icon. You can also delete a condition in the trash can icon (Actions column) and save changes to a condition in the Update icon next to delete.
The SLA (Service Level Agreement) is the way to “verify” that ticket management works under specific criteria. Integria IMS has automatic SLA management functionalities. The SLA is processed according to some parameters and is configured in Support → Ver SLA (Support → View SLA).
Some of the fields that require explanation are the following:
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, etc.).
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.
The assurance of the quality (Quality Assurance or Q/A) and the feedback (feedback) of the tickets can well be configured.
By default, the system will ask the ticket creator, when it is closed (regardless of who closed it), how the ticket was closed. An email will be sent to access a valuation 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 evaluations are associated with the ticket and the person who owns it and are not visible to said 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 evaluation of support tickets you must check that it is not deactivated globally, go to the Settings menu → Setup → Support Settings ( Setup → Setup → Issue setup )
And it is also configured at the level of each group:
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). They are two different limits that can be configured together.
This is configured in the definition of the group (menu People → Group Management) in the fields Open ticket limit and Total ticket limit. It is also possible that the limit of simultaneous open tickets can be “forced” and that it does not allow the creation of new tickets or simply “notify” with a message, but it does allow them to be created. To work without limits, leave the value at 0.
The ticket limit is calculated by counting the number of tickets in the last year from the current date.
You can create a custom search and store it for use in reports, on the dashboard and the ticket search itself, by loading said filter.
All saved custom searches will be reusable in the ticket overview as well as being the base data for standard ticket reports.
To do this, first use the ticket finder under Support → All tickets and search for results:
In the Owner field, by entering at least two characters, you can choose from a list of matching users and then search for results. However, if the Current user field is activated, the tickets belonging to the logged in user will be displayed. Filters can be saved with this field Current user active and it can be used in Dashboards, in which case the tickets belonging to the user who is logged in (and that meet the other filter conditions) will be displayed search).
And click Add custom filter. You will be asked for the name of the filter (Filter name), fill in and save with the button Save custom filter (Save custom filter):
For future searches with custom filters, just click the Load custom filters button and you will see your selected results in a fewseconds.
You can customize all the emails that are sent, changing their appearance. To do this, a set of macros are used that are introduced in the template. The templates are HTML files that can be edited from the tool itself, in Configuration → Setup in the Email Template tab:
Email templates apply not only to incidents, but also to project management. You can even assign different templates depending on the group:
Editing is simple and intuitive, and minor changes (logo, text) can be made from the editor itself without the need to know HTML.
Please note that any image included in the template must be accessible from the Internet when someone opens it from the mail.
Macros used in email templates:
_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._incident_title_
: Title of the incident._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 ticket._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 (main text)._name_of_custom_field_
._creatorcompany_
: Company of the ticket creator._ownercompany_
: Company of the ticket owner._id_group_
: Identifier of the group assigned to the ticket._id_priority_
: Numerical value of the ticket priority._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 with a link to the ticket satisfaction screen._epilog_
: Epilogue (summary) closing ticket.Go to the Settings menu → Setup and access the advanced incident settings tab:
On this screen there are numerous checks that define how the system behaves:
yyyy/mm/dd h:m:s
(default option) and approximate format; example: 1 day, 2 hours.The fields will be the following according to the logical order established by the tool (the names have been numbered to facilitate the work):
2021-01-21 19:24:19, 2021-01-21 19:47:44, Terminal broken, Needs replacement, tech_support, 7, 3, 4, 2021-01-21 19:47:44, admin, 0, 1, 0, ,0, 0, 1, 0, , support_tech, 1, 0000-00-00 00:00:00, support_tech, , , 0, 3, 0, 7, 1, , , , 0, , 0, ,custom_field_value1, custom_field_value2