From CSS Wiki

About Ticketing

When people say "ticketing," they're talking about buying a stub of paper that gets them into an event. Our type of ticketing is a way for organizations to keep track of their to-do lists, who is working on which tasks, what's already been done, and when tasks were completed. You will also hear the phrase "trouble ticketing" bandied about, though there does not have to be a problem for ticketing to be useful.

Ticketing can make life easier for many people and departments in an organization — basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs and answering customer service requests.

Since tickets are detailed records, you might not want to bother using it for one-off events ("Buy Bob in HR a going-away present.") You also shouldn't use it for tasks that are too broad ("Save world") or too granular ("Go to phone." "Pick up phone" "Lift finger." "Dial '9.'")

About RT

RT is about ticketing system for small- to medium-sized organizations. It is available under the terms of the GNU General Public License (GPL), so it doesn't cost anything to set up and use. We'll get into the technical features later, but for now, let's look at how RT might work:

• Billy has a problem with his Bananamaster 3000, so he sends email to help@example.com
• RT records the new issue in its database and sends Billy an electronic "ticket stub" containing the new ticket's ID number and, ideally, some helpful information. He can refer to the ticket stub if he needs to send another email later.
• RT forwards Billy's email to a set of staff members.
• One of the staff members, Jane, is the company's Bananamaster expert. So Jane takes over Billy's issue and drafts a reply to Billy, which RT automatically records and forwards to him.
• Billy is a happy customer; Jane resolves the issue and heads down to the pub for a pint.

RT concepts

There are some words and phrases you should understand in the context of RT before you begin.

A Ticket is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.

A Queue is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue, but only the right to comment on tickets in the Bar queue.

A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed, so be aware that any comments you make about a ticket are permanent.

Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff not visible to the requestor. This is useful when you want to be tactful but still convey important information, like, "This requestor is an investor, so be nice" or "This user's request mentioned his 'PC' but he really has a Mac."

Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer.

The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:

• NEW: the ticket has just been created and hasn't been touched yet.
• OPEN: the ticket has been assigned and it is being worked on.
• STALLED: due to circumstances beyond your control (waiting for the requestor to respond, waiting for the owner to return from Sri Lanka), the ticket isn't getting worked on right now. It will open again when someone adds a comment or reply.
• RESOLVED: hooray! Work on the ticket has been completed and is out of everyone's hair.
• REJECTED: the ticket is not the staff's problem and is not going to be resolved, but is, for some reason, worth recording in the system. For instance, if an employee asks approval for something ridiculous, you can reject the ticket, but it will stay in the database as evidence that the employee makes silly requests.
• DELETED: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) — and is now being zapped for good.

A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

• OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner.
• REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
• CC: someone (or someones) who should get copies of any replies that go to the requestor. This might be the requestor's boss, sales rep, etc. This person will see the email but doesn't necessarily have the right to work on the ticket.
• ADMINCC: a Cc or Ccs that also gets copies of comments and generally are allowed to work on the ticket.

We're hedging with words like "generally" and "necessarily" because any role can be assigned any right.

Relationships in RT can be ticket-to-ticket, but can also link tickets to external items like URLs or FedEx shipping numbers. For the sake of simplicity, we'll refer only to tickets in the following explanation of relationship types:

• DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
• REFERS TO: the ticket doesn't need the other ticket, but it would sure be useful for you to look at it. The converse is referred to by.
• PARENT: a big, general ticket ("Move house.")
• CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")

Now that you're clear on the concepts, you're ready to start using RT.