Otrsguide » History » Revision 7
« Previous |
Revision 7/14
(diff)
| Next »
Michael Noren, 2016-02-19 10:23
OTRS helpdesk system - user's guide
- Table of contents
- Introduction
- Personal preferences
- Creating tickets
- Working with tickets
- Finding tickets
- Viewing a ticket
- Locking a ticket
- Marking tickets seen or unseen
- Replying to a customer ticket
- Closing a ticket
- Re-opening a ticket
- Changing ownership
- Changing the queue
- Forward a ticket to an external person
- Adding a note to a ticket
- Setting a ticket to pending
- Deleting tickets
- Linking tickets together
- Merging tickets
- Bulk & quick actions
- Configuration options
Introduction¶
OTRS is a generic trouble ticket system, which means that- Tickets are created for customer inquiries, complaints, support requests etc.
- The ticket holds all the information about the request and allows for tracking all communications on the matter.
- Agents who will solve or answer the requests record their work on the tickets and close them when done.
- Tickets can be organised into different groups of agents to serve different kinds of requests.
- To not forget any customer request, unhandled tickets will escalate after a certain time and the agents will be notified.
- Customers can follow the status of their request until it’s solved.
In OTRS the communication between customers and agents is handled through email and web based portals for customers and agents respective. For customers there is also a specific portal for browsing frequently asked questions that the agents have compiled.

- When all requests are in a system, no customer request will be lost.
- As customers can follow the state of their request, helpdesk work becomes more transparent.
- By accumulating knowledge on past requests into a FAQ section, people can help themselves to a larger extent.
- The system will collect statistics to help improve the service in the future.
- With the ability to link requests, you can work on incidents, not on single requests.
Customers & Agents¶
A customer is the one who initiates requests through email or the customer portal, and can follow the process through these two channels.
The agent is a person who is responsible for handling requests for one or more queues. The agent will use the web interface for agents, which has much more functionality then the one for customers, to work on solving the tickets.
Tickets¶
A ticket can be seen as an information card, holding all the information on the request with the conversations between the customer and the people that helps solving the case. Central properties of the ticket are the actual request details, the state of the ticket and the links to the agent assigned and the customer who submitted it. Tickets could also be linked to other entities such as FAQ articles and other tickets.
Queues¶
Queues are a mechanism to help organise the incoming requests into groups of requests. The reasons for doing this can be that all requests on a certain kind of topic should be handled by a group of agents with these special skills, some requests should be responded to with a higher service level, certain requests should be automatically responded to with a customised automatic reply, or so that tickets are categorised when doing a follow up on past requests. A queue can have unique email address for incoming requests and can be selected when creating a new ticket in the web interface.
Frequently asked questions (FAQ)¶
When there are repeating questions or other requests on a topic, the agents can compile the subject and the solution into a knowledgebase, which they can use to respond more quickly and with standardised replies for similar future requests. The customers can also browse these FAQs on the customer portal, or on the specialised FAQ portal, and possibly find the solution themselves.
Statistics¶
Almost all actions performed on a ticket are logged in the system and this data can be utilised to extract different reports to help understand the current ticket situation, or to analyse past information for drawing conclusions on how to organise future work for example. There are predefined reports already in the system available for those who have permissions to see them. Report administrators can compose additional reports when a new need is discovered. Reports can be formatted for printing or exported to MS Excel for further processing.
Personal preferences¶
Before starting any actual work in the system, it's good to set up your personal preferences. This includes for example what queues you as an agent will work in and what kind of notifications from the system that you would like to receive. To do this, click on your name displayed in the top right corner to open up the screen for changing your preferences. Unless you have the system open at all times, it's advisable to select your queues in My Queues and select "Yes" for receiving new ticket notifications for these queues. Please note that there is no general save-function for the preferences, so remember to click the Update-button next to each setting changed.

Creating tickets¶
Creating new tickets can be done in multiple ways, where to most common are- Sending an email to one of the email addresses assigned to one of the queues.
- Creating a ticket through the “New ticket”-forms in the agent web interface.
- Creating a ticket through the “New ticket”-form in the customer web interface.
By email¶
When a queue is created at least one email address has to be assigned to that queue and any email sent to this address will generate a new ticket in that queue.
Using the agent web interface¶
- Log on to the agent web interface and select “Tickets” from the menu.
- In the “Tickets” menu select the type of ticket you want to create – “New phone ticket” or “New email ticket”. See below for the differences between these two ticket types.
- Depending on the type chosen, the form will look slightly different, although the fields are basically the same. What needs to be filled out is
- Who the customer is, which has to be in the form of an email address (suggestions from the accounts in the system will show up as you start typing). If the type “New email ticket” is chosen you can notify other people of the new ticket by using the “Cc” and “Bcc”-fields.
- The queue to which the new ticket go into.
- The subject and body text of the request.
- Setting the owner is not necessary, but if it’s done there will be no notifications sent to the other agents in the selected queue and the ticket will be locked by the owning agent.
- When finished, submit the form and a notification will show up below the menu bar that the ticket was created.
The phone ticket is similar to when the user is creating a ticket by sending an email to the system, and it will respond with an email message using the auto-reply template from the selected queue, adding a “Re: “ before the subject in the message. The email ticket will also send a message to the customer, but only adding the signature selected for the queue instead of any auto-response message. Additional people can be notified of the ticket when creating an email ticket by adding them to the Cc and Bcc-fields.
Working with tickets¶
Actually handling the tickets opens up for a lot of different actions provided by the system, this section will try to cover the main part of these.
Finding tickets¶
Unlike a supermarket where for example a can of coconut milk only can exist in the special Thai section or among other usual canned products at the same time, an IT-system can show the same items presented from different perspectives at the same time. In OTRS there are many ways of looking at the same tickets, based on queues, status, and escalation for example and in different levels of detail.
The main views of tickets are the Dashboard, Queue view, Status view, Escalation view and the Search view; these will be presented here in more detail.
Dashboard¶
The dashboard is the default view available to agents when logging on to the web interface.

The dashboard contents can be customised by the agent, selecting what items to show on screen from the settings menu (normally in the upper right of the screen).

The items can further be customised by clicking the cogwheel showing up when hovering with the mouse pointer over the top right corner of each section.

This opens up for selecting how many items and which columns to show in the section. All these sections selected for the dashboard view can finally be arranged by dragging them to the desired position with the mouse.
Queue view¶
Select Tickets -> Queue view. The queue view is a personal view over the tickets that are of concern to the agent logged in. When setting up personal preferences the agent can select which queues are of interest and these will show up here as My Queues, listing tickets that are open to work with. This means that any tickets locked by another agent, queues that the agent does have write-permissions for tickets on, or empty queues will not show up in this view. Queues not selected as for my queues can be selected also.

Status view¶
Select Tickets -> Status view. Compared to the Queue view this is a more generic view, where tickets locked by other agents also will be visible, and the focus lies on the state of the tickets.

Escalation view¶
Select Tickets -> Escalation view. This view will aid in getting an overview of which tickets have escalated or are about to escalate.
Search view¶
Select Tickets -> Search. A new window will pop up where you could either just enter a string to search for in the tickets or specify the query more by selecting more attributes to search on from the drop down menu (click the plus-sign after selecting an item from the list). If it’s a recurring search, it is possible to save it as a template by clicking the “Create new”-button, entering a name for the template, clicking the “Add”-button and then specifying the search criteria. When performing the same search next time, only the template has to be selected.
Finding pending tickets¶
When the ticket state is set to pending, it means that the ticket is not active currently and therefore it won’t show up in the regular queue lists any more. Though there are multiple ways to find it, for instance one of the following methods can be used:
- If the ticket is locked by you, it will still show up under your locked tickets by clicking the “lock”-icon in the top left screen. When the reminder is reached it will be indicated by a lock with a clock symbol on top.

- In the dashboard, under the
Ticket Queue Overview-section, clicking the number under the columnPending reminderwill show pending tickets.
- Searching for tickets will also return pending tickets.
Set the ticket detail level in lists¶
The amount of detail to show for each ticket can be altered by selecting between S, M or L in the upper right corner of the list of tickets. This is valid for the most of the ticket views - Queue view, Status view, Escalation view and the Search view.

Viewing a ticket¶
When opening the detailed view on a ticket, for example by clicking on the ticket in any of the ticket views or via a link in an email, the screen is divided into multiple sections, grouping the ticket information as follows (see the image below for reference):
- A) These are the controls for actions on the ticket as a whole, for example locking the ticket or moving it to another queue.
- B) All the correspondence between people working with the ticket (agents, external experts etc), the customer and also information sent automatically by the system, such as automatic replies, is shown here in chronological order.
- C) For each item in the correspondence a few actions can be performed on the individual item, for instance replying to a response from an external expert and not the initial customer request.
- D) This is the information on the ticket itself, with the current state of the ticket, what queue it belongs to etc. Something that can be unclear here is the information on if the ticket is locked or not, where “unlock” means it is not locked, while “lock” means the ticket is locked.
- E) The information on the customer of the ticket. Since all customers must have an email address as their identity in the system, a request history for each customer can be kept and here the customers’ eventual other open tickets can be reached.
- F) When the ticket is linked to other tickets (displayed as T:<ticket number>) or FAQ items (displayed as F:<faq number>) this is shown here as links to these other items.

Locking a ticket¶
In terms of the system all tickets that are open and not locked by any agent can be seen as available for all the agents in the corresponding queues to work on. Therefore, by locking a ticket the agent signals to all the other agents that he or she is working on this request. When a ticket is locked, only the agent who locked it can perform central actions (replying etc.) on the ticket, while the other agents can still view it. To lock the ticket, the agent can explicitly click on the “Lock”-item on the top of the ticket details view. The implicit way is when forwarding or replying to a ticket and changing the ownership, the system will automatically lock the ticket for the current and the new agent respectively.
If the agent who locked the ticket forgets to finish the work on the ticket and close it, the system will unlock the ticket automatically after a certain time (depending on the settings for the queue in which the tickets belongs). If the time for escalation of the ticket is reached before the ticket is closed and while it is still being locked, the escalation notification will be sent to the agent who locked it, otherwise to all the agents who receives notifications for that queue.
Marking tickets seen or unseen¶
Like in your email client it is possible to mark either complete tickets or just individual articles in a ticket as read or unread, making it possible to mark things in order to come back to them later on. This is done using the menu items "Mark seen" & "Mark unseen" when viewing a ticket, and marking individual articles unread is done using the menu item "Mark unseen" on the little menu on top of the article. Marking many tickets read or unread can also been done from the bulk action, see Bulk & quick actions.

Replying to a customer ticket¶
From the ticket details view, start by selecting of the items in the list of correspondence (normally it would be the first item, which is the original customer request), then from the reply-dropdown menu, choose the template you would like to use for the reply. In the new window that opened the recipient will be selected already in the To-field, but others can be added also. After entering the response message, the next state for the ticket can be selected, so if the answer is expected to solve the issue, one of the closed states can be selected. Ticket can also be replied to by using the bulk-action feature.

Replying with a FAQ answer¶
Apart from replying with a template answer, a FAQ item can also be used for the reply. To do this, click on the FAQ link above the reply text area, navigate through eventual categories to the article of choice and click on it. When the FAQ article opens, at the bottom there will be a button for inserting the FAQ article into the reply. For public FAQ articles there will also be a button to just insert the link to the article on the FAQ portal, or a combination of both.

Closing a ticket¶
When the request is handled and no further action will be taken (as the request cannot always be solved) the ticket should be closed. Then the ticket will not show up among the tickets that need to be handled, or escalate again. The most common way to close a ticket is likely to set the next ticket state to one of the "Closed"-states when replying to a ticket. When the ticket can be closed without further customer interaction, a click on the "Close"-item on the top of the ticket details view will also do the job.
Re-opening a ticket¶
The typical workflow would be that the agent sets the next ticket state to one of the “Closed”-states when replying with a solution to the customer request. If the customer is not satisfied with the answer or the problem occurs again later, he or she can respond to one of the emails regarding the case and when the system then receives a new email with a ticket number in the subject referring to a closed ticket, the system will then re-open this ticket (this can be configured).
If an agent would like to re-open a closed ticket, first the ticket needs to be found using the status view or by searching for the ticket. When the ticket is found and opened, there is no option to just open the ticket again, so an action the allows for setting a new ticket state (replying, forwarding, registering a phone call) needs to be performed and thereby changing the next ticket state to “Open”.
Changing ownership¶
Being the owner of a ticket in the system actually entitles less than one would think, and can be seen more or less as an indicator of which agent who last worked with the ticket, as the agent who locks a ticket also will become the owner. The ownership has a practical implication when update- or escalation notifications are sent for tickets, but otherwise, as mentioned before, it can be seen as mostly information on who last worked with the ticket, or who should work with the ticket.
To change the ownership (and thereby letting someone know he or she should pay attention to the ticket), click on “Owner” on the top of the ticket details view and select the new owner from the list.
Changing the queue¶
If the ticket does not fit within the current queue for some reason (wrong topic, wrong service level etc.), it can be moved to another queue, alerting the agents for that queue. Moving tickets is done by choosing a new queue from the “Move”-dropdown list on the top of the details view for a ticket. Only the queues the current agent has permissions to move tickets into will be selectable.
Forward a ticket to an external person¶
Sometimes the agent working with a ticket might request help solving the request from a person that does not have access to the helpdesk system. One way of doing this and still keep a history inside the ticket, is to select an article from the list of correspondence in the ticket details view and then click on the “Forward”-link. Apart from entering the email and message for the external person in the new window that opens up, there is also the choice of the next ticket state and the article type this forwarded email should be handled as.
When expecting the external person not only to provide information, but to actually solve the case the next ticket state can be set to one of the “Close”-states, otherwise the agent has to observe when a reply comes back from the external person, through notifications or inside the system.
The article type is about the visibility of the communication between the external person and the agent, where “email-external” means that the customer can potentially see the messages in the customer portal, and “email-internal” will hide the messages from the customer completely.
Adding a note to a ticket¶
Notes allows agents to add extra information to the tickets that for example can be important for solving the request, helping out for future requests where the agent looks for the answer among the old tickets or as instructions for people in another queue when moving the ticket. To add a note to a ticket, click on Note on the top of the ticket details view and input the information. As with forwarding a ticket, the article type option should be considered regarding the visibility of the note to the customer of the ticket. Setting it to email-external means that the customer can potentially see the note in the customer portal, and email-internal will hide the note from the customer completely.
Setting a ticket to pending¶
When the work on a ticket cannot proceed for some reason (new information or software will soon be released, other work needs to be done first etc.) or in order to separate tickets between 2 agents working on the same queue while replying to them, a reminder can be set to alert the agent(s) when this event has occurred and it’s expected to be possible resume working on the ticket again. This will lock tickets to yourself (during the whole pending time, not only during the default unlock time for a locked ticket), which means the ticket will disappear from other agents’ "ToDo"-list. Worth noting is that there is no relation between escalations and the pending states, so tickets will still escalate if the escalation time is lower than the reminder.

A reminder can be set clicking on Pending-link in the ticket details view and in the new window the desired pending option is selected under “Next state” and by setting the pending date and time below the choice of pending state (the default pending time is 7 days). Setting a ticket to pending can also be done in combination with various other actions like forwarding, replying, registering a phone call or splitting a ticket.
- Pending reminder
A basic reminder that will alert owner of the ticket if it is locked, or all the agents watching he queue if the ticket is unlocked. The ticket status will be pending until the status of the ticket is changed by an agent.
- Pending auto close-
The “auto close-“-reminder is similar to the basic one; apart from that the ticket will be set to "Closed Unsuccessful" when the pending time has expired.
- Pending auto close+
The “auto close+“-reminder is similar to the basic one; apart from that the ticket will be set to "Closed Successful" when the pending time has expired.
Deleting tickets¶
In general tickets should not be deleted from the system since preserving a history is important for the functionality of the system. For example when a new follow-up email enter the system on an existing, but closed case, the old case should re-open, the details of old requests can be searched by agents looking for information on how to solve a re-occurring issue, and in the end the ticket information is used to produce statistics. Therefore the system lacks all kinds of delete buttons.
Still there can be spam emails sent into the system that should be there, so to get rid of these the agents have the option to move them into the “Junk”-queue. This is a special queue designed for this use case, and it has a job running that closes all tickets entering the queue and later on also deletes them from the system.
Linking tickets together¶
Tickets that have a relation to each other as seen from the agent’s perspective, for example when they describe the same issue, can be linked together. This ticket relation can be seen by other agents and be navigated on from the menu placed on the bottom right on the details view of any of the linked tickets. Relations between linked tickets can be either “Normal” or “Parent”/”Child”.

In the default installation of OTRS though there is no special logical meaning to these different types of relations, so it is mostly for helping the agents understand the relationship. If needed the system can also be configured to cater for more advanced linking scenarios, ranging from that a parent ticket cannot be closed until all child tickets are closed, to a master/slave scenario where all changes on a master ticket are reflected on the child tickets (e.g. add note, send e-mail, pending state, close).
Linking tickets is usually done by clicking on the Link-item on the top of the ticket details view. In the next window, select whether the ticket should be linked with other tickets or other FAQ items, search for the ticket(s) or FAQ item(s) that should be linked. In the search results, tick the results of choice, choose the kind of link appropriate (Normal, Parent or Child), select Add links and finally, close the window.

Merging tickets¶
If linked tickets are useful when there are multiple tickets on the same issue from multiple customers, merging tickets are more targeted at the case when multiple request come in from the same customer on the same issue, or if there is no need to get back to each customer individually. When merging tickets start by finding the ticket number of the ticket to which all the content should be merged (the target ticket), then open the source ticket with the content to that should be merged into the target ticket, and select the “Merge”-link on the top of the ticket details view. Input the target ticket number in the window that opens.

The result of the merge is that the source ticket will be empty, except a note that the ticket has been merged into the target ticket. It will have a new status of “Merged” which in practice is similar to closed, so that the ticket will not show up in the list of current tickets. The target ticket on the other hand will contain all the correspondence from the source ticket, but the customer for the ticket will still be the target ticket’s original customer. This means that if the merged tickets have different customers, the agent will have to remember to add all the source tickets customers to any replies (or reply individually to each customer in the correspondence list).
Bulk & quick actions¶
Sometimes there is a need to perform the same action on more than one ticket and this is where the bulk action feature can be a time saver for the agents. In all the views of tickets reached from the Ticket-menu, the left most column contains a checkbox for the agent to tick individual tickets, or all of them by ticking the header checkbox. Performing a bulk action on the selected tickets is done via the Bulk-link just above the first ticket column, and it will to open up a new window where all the desired actions can be chosen.

Actions that can be performed are the most common ones, for example replying, closing or adding a note to the tickets, and also changing the owner or queue. Bulk action is not available from the Dashboard though, and the regular salutations, templates and signatures from the queues are not available for the bulk replies.
If only one ticket is selected, the agent will in addition to the bulk actions have the option to trigger common actions such as closing the ticket or moving it to another queue, directly from the list of tickets instead of opening each ticket first.

Configuration options¶
Escalations¶
In OTRS escalation is not the same thing as the typical organisational escalations, where the next level up in the organisation will be notified if the lower level has for example not completed task X in time. As there is no concept of organisational hierarchy in OTRS, what escalation means is that either the agent in charge of a ticket (the ticket is locked by this agent) or if no agent has locked the ticket, all agents monitoring the queue containing the ticket will receive an escalation notification. The intent is that the escalations will help enforce a certain service level in relation to the customers of the helpdesk.
Three things can trigger an escalation:
- If a new ticket has not been responded to within a certain time.
- When the ticket is updated with a new item in the conversations, for example customers reply, and no agent has responded to that within a certain time.
- If the ticket has not been closed within a certain time.
Apart from sending notifications to the agent(s), an escalated ticket will show up in the dashboard view of escalated tickets, and if it was locked it will be unlocked by the system, so that other agents can handle it. To stop a ticket that already has escalated from continuing to escalate an agent has to add a conversation with the customer, by a reply or by registering a phone call. Escalation is set on a per-queue basis, which means that all tickets in a queue will follow the same escalation settings. For each queue there is always a calendar with the working hours for the helpdesk service represented by that queue, and the escalations will only count the time on these working hours towards the escalation time.
Salutations, templates & signatures¶
When an agent sends messages from the system, the actual message can be made up from three different templates, all depending on the type of message to send.
- The salutation is a template set per queue that goes in the top of the message. For each queue there is just one salutation template.
- The main message template goes into the middle of the message and multiple templates can be assigned to one queue and be selected by the agent when composing the message.
- Just like the salutation, each queue can only have one signature, which goes into the bottom part of the message.
These templates can all use variables in the system to automatically insert ticket information such as the customer or agent name, ticket number etc. into the message based on the template.
Ticket follow-ups¶
When a ticket is closed and a follow-up email is sent to the system, the default behaviour is that the ticket will be re-opened, but this can be customised for different needs:
- New ticket: A new ticket will be created instead of re-opening the old ticket.
- Re-open: The closed ticket will be re-opened (default)
- Reject: It is not possible to post follow-up referencing a closed ticket number, and the email will be discarded.
Additional email contacts¶
The email addresses showing up in the auto-complete list when starting to write a new email from the system contains the Eionet users, and the current customers (i.e. people who sent in a ticket). If you have the need to add other recipients on a regular basis, it can be convenient to have them in the auto-complete list. Adding new contacts is done with the following steps:
- Select "Customers" and "Customer User Administration" from the main menu.
- Make sure that "Database backend" is selected in the drop-down menu on the left, and click the button "Add customer user".
- Fill out the fields for Firstname, Lastname, Username (e.g. firstname & lastname put together) and Email.
- Leave the Password-field blank, but select "contacts Email contacts" for "CustomerID" and save (click the "Submit"-button).
Now the new contact should show up when starting to type a recipient address or name when composing a new email.
Updated by Michael Noren over 5 years ago · 7 revisions
Go to top