<chapter id="basics-about-tt">
<title>Basics about a Trouble Ticket System</title>

<sect1 id="simple-example-for-a-tt">
<title>A simple example for a small Trouble Ticket System</title>

<para>
What is a typical scenario for using OTRS?
</para>
<para>
Example: Bob is a manufacturer of VCRs and his customers often have problems to program the VCRs. So they send Bob an e-mail. Sometimes they send a second e-mail to show Bob how important their request is. They are wondering if Bob is alive and how fast he will answer. Bob is using a normal INBOX and reads his e-mails with pine, mutt or what ever e-mail client. Sometimes his two brothers Tim and Joe help him to answer the e-mails. They all use the same INBOX. Of course they have no clue that one customer wrote two e-mails and maybe Tim gives a different answer to the first e-mail than his brother Joe does for the second. So the client gets different information. Of course Bob has no client-history and no clue how much support he is offering. For the next VCR he is producing he has no feedback from his support. That is bad!
</para>
<para>
But Bob is a smart cookie so he installs OTRS. The e-mail from his customers are not anymore going to his personal INBOX but are routed to the OTRS account (normaly called otrs). The OTRS account has some nifty procmail rules which pipe this e-mail messages to the system. The system answers the client a standard text which says that they received the e-mail and gives the client a Trouble Ticket Number (which is very important to trace the customers request). The client is happy because he knows that his valuable e-mail was received by Bob and his team. Anybody from Bob's team can open a webbrowser with the URL of the OTRS to have a look at the amount of received e-mails and to answer them. In case the customer Mr. Smith sent a question, Bob can answer it. Maybe Mr. Smith does not understand the question and sends a reply. But Bob is ill. Now even Tim can open this ticket and has access to the history of the ticket. He can read Bob's answer(s) and the original e-mail of Mr. Smith. Tim can answer to Mr. Smith and Mr. Smith even does not realize that he was handled by two different persons.
</para>
<para>
Of course this is just a very rough overview of the benefits of OTRS. Probably Bob receives some 100 e-mail messages a day which could be handled even without a Trouble Ticket System. But by the time you receive some 100000 or even just some 500 e-mails a day you will be happy to have a system which handles all the e-mails.
</para>
</sect1>

<sect1 id="what-is-a-trouble-ticket">
<title>What is a trouble ticket in the OTRS?</title>
<para>
Within the OTRS all trouble tickets are handled as normal e-mails. In case you want to attach something (e.g. a fax) it will be attached as an e-mail attachment. All tickets are stored on the harddrive in clear text format. The headers are stored in a databasei too. The database is used to sort the tickets and to give quick access to them. For detailed information about this mechanism have a look in the source code.
</para>
</sect1>

<sect1 id="what-is-a-queue">
<title>What is a ticket queue?</title>
<para>
For native english speaking folks this might be a bit funny but for non native speakers the term QUEUE does not make any sense at all. So we use this section to describe the idea and concept.
</para>
<para>
Normally an e-mail (and as described above a trouble ticket is stored as an e-mail) is stored in an INBOX. An INBOX is a large file and every new e-mail is just appended to the end of the INBOX. The e-mail client is parsing this file and sorts it as you want it (typically by date of receiving). 
</para>
<para>
A queue is a mechanism to store many tickets within. As a user you do not know where the tickets are stored. You just know that a new ticket is e.g. in the RAW queue. A user (agent) can move a ticket from one queue to another. Why should he/she do this? You can use different queues to get more order and a better overview to your tickets. Let's assume you receive 200 e-mail messages (tickets) a day. And you have 3 teams of specialists. It doesn't make any sense to ask every specialist to read every ticket. It is a waste of time. So you have to create a fourth team which dispaches all the tickets in the INCOMING-QUEUE (or how ever you call this queue). The dispatch instance will have a quick (quick!) look at every ticket and move it then to a special queue. The 3 teams of specialists read their special queues only. 
</para>
</sect1>


</chapter>

