How to track tickets the right way

[kibet]

Hi,

we have been using OTRS for some time as a support tool for internal as external issues. I created different queues for every department within the company. Then I created groups for each department. In each group I gave full (rw) permissions for members of the department and read/note/create for the rest of the company. Each department group is assigned to its respective queue. So the dashboard only shows the relevant issues for the department and everybody can create/view/add notes/search in that queue.

The person that is registering an issue should be able to track the progress of the problem even when assistance of another department is needed. Currently we try to avoid the owner to be changed and use the responsible function to request help of a person of a different department. We change the queue and make somebody of the queue responsible. Therefore I also disabled the locking mechanism since this locking automatically changes the owner. How can you still track the ticket progress?

1) Are we using OTRS in the right way?

2) How can you track the progress of an issue/ticket? The problem is that on the dashboard the owner cannot see all the tickets he owns when a ticket is assigned to a queue where the owner does not have rw permissions. How can you see all tickets you own on the dashboard regardless permissions?

3) Why is OTRS changing the owner when locking a ticket?

Really appreciate your reaction.

[tdeklein]

2) How can you track the progress of an issue/ticket? The problem is that on the dashboard the owner cannot see all the tickets he owns when a ticket is assigned to a queue where the owner does not have rw permissions. How can you see all tickets you own on the dashboard regardless permissions?

Hi,

Did you consider subscriptions? With that every agent who is interested could subscribe to a ticket before passing it to another department and keep track of its progress. You will not see those tickets in the dashboard either, but there will be a new icon in the top left corner (an eye) which will show you the tickets you are watching.

Cheers
Thomas

[kibet]

Thanks for your reaction and suggestion for using watch/subscribe function.
This seems to be a manual action. I didn't find an automatic way to do this. So that every created ticket is automatically watched by the creator/owner.

How do you track issues? Do you use the dashboard or search or something else? I like to have a list that shows the tickets that needs to be monitored (f.e. created by me) or I need to work on (ticked assigned to me or my queue). The most obvious place seems to be the dashboard.
How is your implementation? Do you use different groups for queues or assign the same group to each queue? Do your queues reflect departments or something else? Do you use different permissions for members of a group? Currently we use different permissions in order to show only relevant tickets for each department and not all tickets in the organization on the dashboard.

I feel like we are overlooking something since I made a lot adjustments. Maybe we are not using OTRS the way it suppose to be. Hope you can help me.

[crythias]

Things for *you* are under "Tickets", generally, though you can also use a saved search.
The beauty of OTRS is that the "right way" is "your way", and you seem to be doing ok.

If you want more "automatic", I suggest looking at "Responsible" as an option. In this manner, you can "own" the ticket. Also, if you check that setting, you get assigned as "Responsible", but you then can change that to the "real" worker. It's a nice feature and I used it for a dispatcher to have ownership of tickets, (so she could close them), and yet be able to assign a responsible to handle tickets. Meanwhile, the ticket is always under her.

What I suggest for OTRS usage is that Queues are ways to assign Agents to tickets they are able to and have permission to handle.
Rudimentary Queues: Printing, Email, Web, Plumbing, Lighting
Advanced Queues (based upon department): Maintenance, which has subqueues of Lighting, Plumbing, Repair, Cleanup; and Technology, which has subqueues of Printing, Email, Web, Computer Replacement

A Queue is a folder. A Group tells who has access to the folder.

[tdeklein]

This seems to be a manual action. I didn't find an automatic way to do this. So that every created ticket is automatically watched by the creator/owner.

Well, I have no solution for this but the responsibility-feature that crythias mentioned might come in handy. I myself did not activate it because I thought that it might complicate matters. My own setup is not productive yet. We are about two weeks away from switching from an inhouse written solution to OTRS. So nothing I am talking about here has stood the test of real use yet. We will see about that soon .

How do you track issues? Do you use the dashboard or search or something else? I like to have a list that shows the tickets that needs to be monitored (f.e. created by me) or I need to work on (ticked assigned to me or my queue). The most obvious place seems to be the dashboard.

The dashboard does not seem to be that usefull to me. I myself prefer to check my locked and my subscribed to tickets via the icons in the top left corner (and I like that they indicate it when something new happend on any of them) and the queue and escalation view. Maybe I will get used to the dashboard in the future, but at the moment I prefer the other views, even if it means switching between them.

How is your implementation? Do you use different groups for queues or assign the same group to each queue? Do your queues reflect departments or something else? Do you use different permissions for members of a group? Currently we use different permissions in order to show only relevant tickets for each department and not all tickets in the organization on the dashboard.

I have a root queue that branches out to subqueues for different departments (support, sales, backoffice, ...). We might create more subqueues for some of the departments in the future, but at the moment we are only one level deep. Each department has its own group/role and has rw rights on its own queue and mostly read/comment/create/set priority on the others as far as it makes sense (i.e. only backoffice and sales may give tickets to the purchasing department). Everybody has rw on the root queue, so if tickets land there everyone will notice. Mail gets to OTRS via SMTP and is presorted to the correct queues with procmail according the the address that it was sendt to. Anything that did not get to a specific queue gets to the root queue and has to be matched to the right queue manually. All queues have a timelimit of 2 hours for first reaction and differing update times. I did not use solution times and I did not use unlock times (although I would like to unlock a ticket an certain conditions, but I dont want to impose a solution time).

Our current troubleticket system has one pool of free tickets for everyone and escalations are seen by everybody. One of our goals with OTRS was to limit exposure to escalations and such to those who are actually concerned by it. One thing I still have no solution for is how to handle this: If a ticket escalates, only those who have rw rights to its queue get notified and see it in there views. Thats what I want. But if a ticket escalates more often that might indicate that nobody from that department is there and it needs attention from anyone regardless from which department. So I would like to move a ticket that escalated multiple times, or is unattended after escalation for more than i.e. an hour to the root queue where it will (hopefully) get everyones attention. I have not been able to come up with the right GenericAgent-Fu for that yet.

I feel like we are overlooking something since I made a lot adjustments. Maybe we are not using OTRS the way it suppose to be. Hope you can help me.

I think that it needs to fit your needs. But it might help to see how others use it and get some ideas from that. So in that sense I hope my post is helpfull and I would like to hear any comments you or anybody else has on my description.

Cheers
Thomas

[kibet]

Things for *you* are under "Tickets", generally, though you can also use a saved search.

Because of need of rw permissions on queues I thought the queue view and status view under Tickets where not useful. But digging in sysconfig I found this setting: Ticket::Frontend::AgentTicketQueue###ViewAllPossibleTickets : No --> Yes where also ro queues are shown.
Thanks this really helps!

If you want more "automatic", I suggest looking at "Responsible" as an option. In this manner, you can "own" the ticket. Also, if you check that setting, you get assigned as "Responsible", but you then can change that to the "real" worker. It's a nice feature and I used it for a dispatcher to have ownership of tickets, (so she could close them), and yet be able to assign a responsible to handle tickets. Meanwhile, the ticket is always under her.

The responsible function is helpful. We like to use it as a dispatcher. To be clear how I understand this: the person that registers and wants to track the ticket is referred as owner. The person(s) that perform action to solve the problem are referred as responsible. Or do you mean the reverse?
- How do I need to understand the responsible?

I thought this is working fine, but I came accross the problem that tickets are
locked by some actions (RequiredLock) by the person working on the problem and the owner is automatically changed to that person.
- How do you deal with that?

- Even more general: Why do you lock a ticket? Is it to make sure other agents cannot work on it or is it also to ensure database integrity?
- Why does locking automatically involve change the owner?
- Is there a way to prevent changing the owner while locking a ticket?

[crythias]

I thought this is working fine, but I came accross the problem that tickets are
locked by some actions (RequiredLock) by the person working on the problem and the owner is automatically changed to that person.
- How do you deal with that?

I let it happen. The person who works on the ticket owns the ticket. The person who takes ownership of the ticket locks the ticket.

Even more general: Why do you lock a ticket? Is it to make sure other agents cannot work on it or is it also to ensure database integrity?
- Why does locking automatically involve change the owner?
- Is there a way to prevent changing the owner while locking a ticket?

You lock a ticket so other agents cannot work on it. (Responsible does not apply here).
There is no real owner until the ticket is locked.
Locking the ticket generally prevents change of ownership. (prevention of others from unlocking a ticket to change ownership may require a bit extra work.)