OTRS (Open Technology Real Services)

OTRS is one of the most flexible web-based ticketing systems used for Customer Service, Help Desk, IT Service Management. As the name suggests, OTRS is a "ticketing system" which provides users with an application that can create, distribute, answer, manage, and archive trouble tickets received from customers via telephone or e-mail.

By default, user roles in the system are configured as Agents who respond to requests, and Users who receive services. Both types of users interface with OTRS through its fully customizable web interface. After the appropriate installation, setup, and configuration, user can access tickets and ticket histories, as well as create new tickets if appropriate to their role in the system. Additional roles can also be created, and out of the box roles can be customized to fit any specification or requirement.

Tickets enter the system and are subsequently managed by assignment or movement between queues. All tickets issued for individual customers and companies have unique, customizable numerical identifiers. Actions are stored in the database and can be accessed through the ticket history. Tickets can have different status characteristics, escalation times, and email addresses depending upon the queue in which they reside. This is also preserved in the history and archive.

Statistical analysis is also possible. Tickets can be answered with predetermined e-mail responses that can also contain attachments. Automation of responses and notification evens is possible.

Since its beginnings OTRS has been implemented in the programming language Perl. The web interface is made more user-friendly by using JavaScript (which can be switched off for security reasons). Different functionalities are implemented as reusable backend modules, making it possible to create custom modules to extend the functionality of the OTRS system.

The web interface itself uses its own templating mechanism called DTL (Dynamic Template Language) to facilitate the display of the systems output data.

Originally, OTRS worked only on MySQL databases. Support has since been added for PostgreSQL, Oracle, DB2 and Microsoft SQL Server. OTRS may be used on many UNIXor UNIX-like platforms (e.g. Linux, Mac OS X, FreeBSD, etc.) as well as on Microsoft Windows.

INSTALLATION

1) Download install files “otrs-4.0.10.tar.gz”.

2)Extract “otrs-4.0.10.tar.gz” to “/opt” directory

3) Rename “otrs-4.0.10″ directory to “otrs”.

4)1) Install MySQL server.

5) Install Apache Web server.

6) Install Perl modules.

7) Update source list.

8) Upgrade all installed packages.

9) Check and make sure that all required Perl modules are installed.

10)Create new user for running OTRS, because OTRS should not be run with root user rights.

11) Add created OTRS user in step above to Web server group.

12) Activate OTRS config files by copying them without .dist filename extension.

13) Run syntax check to see if your Perl is properly set up. After every command you should see message “syntax OK”.

14)Set Web server user permissions for OTRS user.

15)Set up working Apache configuration by copying OTRS conf file “apache2-httpd.include.conf” to “etc/apache2/sites-available/” directory.

16) For installing additional packages, like for example ITSM bundle it is required to set MySQL database to accept packages larger than 16 MB which is set by default.OTRS message: Please make sure your database accepts packages over 20 MB in size (it currently only accepts packages up to 16 MB). Please adapt the max_allowed_packet setting of your database in order to avoid errors.“Change following line from: “max_allowed_packet = 16M” to “max_allowed_packet = 50M”

and add the following line “innodb_log_file_size = 512M”

17) Copy Cron jobs scripts without suffix “.dist”.

18) Configure Cron Jobs with “Cron.sh” script.

Note: do not run Cron.sh script as root user, run it as OTRS user.

19) Change how often will PostMaster fetch email (by default it is set to fetch emails very 10 minutes

20)Run OTRS web based installer and finish installation steps.

http://localhost/otrs/installer.pl

21)Improve Web server GUI speed activate mod-headers.

22)Restart your Ubuntu server, and start using OTRS system via following links:

· Agent Web interface… http://localhost/otrs/index.pl

· Customer web interface… http:// localhost /otrs/customer.pl

Now, we login to system as admin.

After login, helpdesk dashboard page is opened.

"Don't use the Superuser account to work with OTRS! Create new Agents and work with these accounts instead." error is displaying. Optionally, we can create agents in settings page.

Ticket management is important in OTRS System. So ticket components should not removed from dashboard.Some components;

· Showing new tickets

· Showing requests in queue

· Showing tickets that is increasing priority

Company or person's emails can be shown as tickets. These tickets are solved by agents. Agents can do these processes;

· Send e-mail

· Call phone

· Change priority

· Long estimation time

· Closing

All processes are stored on database

CONFIGURATION

Our scenario is;

"We are a hosting company. Groups and Roles, Agent and Customers are in this company.

Our company has IT and IK/Finance departmants. There departmants have sub depertmants. Technical request are sending to IT depertmant and Billing requests are sending to Finance depertmant. "

GROUPS

Groups in OTRS should be thought of as collections of access rights. To some extent, you can also think of Groups as collections of Queues, though that limits their scope a bit. There are a few modules, including Stats (reporting) and FAQs, that don’t have Queues associated with them by default, but you still define access rights to their functionality through Groups. For this reason, you should not get in the habit of thinking of Groups exclusively as collections of Queues.

Groups define the following rights:

· MOVE_INTO (move tickets into these queues)

· CREATE (create tickets/articles in these queues)

· NOTE (add notes to tickets in these queues)

· OWNER (change the owner of tickets in these queues)

· PRIORITY (change the priority of tickets in these queues)

· RW (read-write access to tickets/modules in this group)

· RO (read-only access to tickets/modules in this group)

You can see that the first five rights apply primarily to Queues, while the last two (RW/RO) are more closely related to modules like Stats and FAQ. Nevertheless, there is some overlap. Develop a bias toward thinking of Groups as collections of rights rather than collections of Queues.

When you associate a Queue with a Group, you are granting all the access rights defined by that Group to the selected Queue.

Groups can seen from Admin page.

These groups are already exist. We will create custom groups for our system.

Create group page;

After enter group name, define roles on users

Our all groups;

ROLES

Now that you have some Queues that allow you to classify tickets, and you have Groups that define access rights to those Queues, you need to find a way to grant those rights to an Agent. There are two ways to do this. The first is to assign Agents directly to Groups. This is not generally regarded as best practice for large implementations. Instead, I recommend setting up Roles. Using Roles instead of assigning Group rights directly to Agents offers the following advantages:

· You only have to configure the rights once, for the role.

· You can associate multiple Agents with a Role in one swoop.

· When Agents assume or discard a Role, you can add/remove rights by disassociating them from the Role—no need to update multiple rights on multiple groups.

· When the responsibilities of a Role change, you only have to update them once for everyone associated with that Role.

The trade-off of using Roles is it requires a little more work up front. You have to define your Groups and Roles clearly to make sure that Agents get the rights they need. In the long-run, though, it will simplify administration.

We created 16 Roles;

AGENTS

By clicking the link Agents, you get access to the agent management screen of OTRS (see Figure below). Administrators can add, change or deactivate agent accounts. Furthermore they can also manage agent preferences, including the language and notification settings for the individual agent's interface.

NOTE: An OTRS agent account may be deactivated but not deleted. Deactivation is done by setting the Valid flag to invalid or invalid-temporarily.

Create agent page;

After creating agent, we need add to groups this agent.

Our agents;

After creating all agents, groups and roles, move the step relations.

1) Manage Role-Agent Relations

2) Manage Role-Group Relations

Services

Services such as "standard IT workstation", "e-mail" or "web access" are IT products and should be compiled in a "IT service catalog" prior to the adoption of OTRS ITSM. Such a service catalog is usually customer or company specific and can be structured hierarchically. Furthermore, it should be formulated in a user friendly, meaning easily understood, language, as both IT personnel (agents) and IT users (customers) are among its audience.

Our services;

SLA

Service levels and the respective agreements (service level agreements, SLAs) document quality pledges for IT services. SLAs are recorded and administered in the admin interface.

OTRS:ITSM offers by default up to 99 different calendars to describe the various time zones for work or service times. The SLAs can be allocated to them ("service level window"). Various time spans can be entered (in minutes) which OTRS::ITSM uses to control notification and escalation:

[ Response Time ]

· = reaction time with incidents

· = start of service request procession ("service request lead time")

[ Update Time ]

· = notification time

[ Solution Time ]

· = time elapsed until incidents are resolved ("maximum time to repair", "MTTR")

· = delivery time for service requests ("delivery time")

[ Min. Time Between Incidents ]

· = "MTBI": minimal time between closure of the last incident ticket and recurrence of an incident for which the same SLA applies.

Our SLA;

CUSTOMERS;

Customers can be added two ways. Firstly, we can add unregistered users with only ID and name. Secondly users can be created tickets after login. We will use second option in our scenario

Our customer list;

Queues likes stats, miscs, postmaster are exist as default in OTRS. When create tickets, we can reach agents. Specific people can administer these queues. We should organize these queues for using First Level Support, Second Level Support and Third Level Support. Firstly users tickets should display on Helpdesk group. Helpdesk group decide, this ticket should send to Second Level Support. Second Level decide, this ticket should send to Third Level Support. For this, we must create different queue for three group.

We will use Helpdesk group for First Level Support. We need to Second and Third Level group.

After creating Second Level Support and Third Level Support, we need to define role permission.

Second level Agent-Group Relations selected all permission because they have same role.

QUEUE;

Help Center is for First Level and Second Support is Second Level, Third Support is Third Level.

Our queues;

Finally, We should give permission for creating tickets to Helpdesk group and we should define services for using customers.For this, we should allow.

After settings, our customers;

Services must be defined for using customers;

All settings finished. Let's go now to our scenario.

SCENARIO

Sample scenario has 4 users.

1.user; sCustomer (Sample Customer) [Customer]

2.user; Hazel Turan [Helpdesk]

3.user; Cansu Alkan [Second Level Support]

4.user; Selin Beyaz [Third Level Support]

Customer will contact with HelpCenter for Database problem. HelpCenter will not solve this problem and ticket will be forwarded to Database department. At first stage, There is not a waiting ticket in HelpCenter and Second Level Support. These users can login with https://itmsystem.managed-otrs.com/otrs/index.pl link.

Hazel Turan - HelpDesk Dashboard (No Tickets)

Cansu Alkan - Second Level Support (No Tickets)

Selin Beyaz - Third Level Support (No Tickets)

Customer login with https://itmsystem.managed-otrs.com/otrs/customer.pl? link.

Lets go now to create ticket!

Our first ticket that coming from customer.

Software ticket;

Service level aggrement(SLA) and Service can be selected.

Hardware Ticket;

We can only "Help Center" on "To". If we want, customer can see more than Help Center. But now it is enough.

Customer's ticket list;

After creating tickets, tickets transmit to Help Desk. Two tickets are seen in Help Desk Dashboard.

After moving ticket, Help Desk can not see this tickets.

This ticket is shown Second Support.

Second Level Support can not solve this problem. The support transmit to Third Level Support.

Third Level Support Dashboard;

Third Level Support solved this problem. Need to return this ticket.

After answer ticket, customer will receive an e-mail.

And close ticket;

KDB (Knowledge DataBase)

We use knowledge database (kdb) for system’s problems. For example ;

0.Level : Customer based problem.

1.Level - 2.Level : Software problem.

3.Level : Solution Types.

OTRS- SURVEY

1) As can be seen on the screen "Questionnaire" section to come we will prepare for customer satisfaction survey. "Survey" option from the "new" we choose. And against our "Create New Survey" screen appears. We fill in the complete way of the information contained herein. Poll title, content, information will be sent by whom, is located here.

2) Then we will make the process "Questions Editor" option will come publish our questions. We will post three questions.

3) Our question above "Survey Questions Editor" is seen on the screen. And also we add the percentages for the questions can be seen in the side.

4) "roundcube" is called, is to show their own account with a simple e-mail accounts on the server where the setup in advance by the administrator web interface. That allows us to read our e-mail via the Internet. We survey our customers are sending out to roundcube.