Practical Examples... Locking?

Kris Jacobs

26 Nov 2007 26 Nov '07

9:24 p.m.

I have read and re-read the documentation available for OTRS @ http://doc.otrs.org I still do not understand what is meant by "locking" a ticket. I do not understand why a ticket would be locked, unlocked, or what either of those terms mean in the context of an OTRS ticket. Could someone explain it to me clearly and concisely please? Thank you!

Show replies by date

Marc Redeker

26 Nov 26 Nov

11:44 p.m.

quite easy, a ticked will be locked if someone is working on the ticket. that means that nobody else is able to work on this ticket. If you stop working on the ticket, you have to unlock it so that someone else can answer this ticket. It will protect you from multiple agents working on one ticket. Best, Marc Am 26.11.2007 um 22:24 schrieb Kris Jacobs:

...

I have read and re-read the documentation available for OTRS @ http://doc.otrs.org

I still do not understand what is meant by "locking" a ticket.

I do not understand why a ticket would be locked, unlocked, or what either of those terms mean in the context of an OTRS ticket.

Could someone explain it to me clearly and concisely please?

Thank you!

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Shawn Beasley

27 Nov 27 Nov

7:10 a.m.

Dear Kris,

...

I still do not understand what is meant by "locking" a ticket.

I do not understand why a ticket would be locked, unlocked, or what either of those terms mean in the context of an OTRS ticket.

A ticket lock is there to remove a ticket from the main queue (make it invisible) so that two agents are not busy working on the same ticket. As well a ticket will be locked when an answer is sent per email. It makes sense because the agent who was working on the ticket (send the email) is sometimes waiting on an answer. This prevents doubled efforts on one ticket. When the ticket is locked it is visible in the locked tickets section (uppper right hand section of the agent screen) The ticket is unlocked when it is visible in the queue structure. This alarms all agents who have this queue selected, or who navigate to this queue, that the ticket is free and needs to be attended I hope I have helped you. If you need detailed training in OTRS, feel free to contact us. ((enjoy)) Shawn Beasley -- ((otrs)) :: OTRS AG :: Europaring 4 :: 94315 Straubing Fon: +49 (0)9421 56818 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success! Geschäftssitz: Bad Homburg Amtsgericht Bad Homburg, HRB 10751 Steuernummer: 003/240/97505 Aufsichtsratsvorsitzender: Burchard Steinbild Vorstandsvorsitzender: André Mindermann

Kris Jacobs

1:14 p.m.

OK, I understand the reasoning behind that, but it leads me to another question: In OTRS, isn't it plainly visible to all Agents when a ticket has been assigned to an individual? Here is what we have in mind at my organization: Support requests come in. The department manager either assigns tickets to individuals, or individuals take ownership of tickets in a proactive fashion. Anyone can look at all tickets - and when they look at a ticket that has been assigned or that someone has taken ownership of, it is obvious who is working on that ticket. I think of agents as resources - each ticket in the database structure should have an assigned resource, and ideally an owning resource. Meaning, those are two separate fields. Ticket table -Ticket # -Owning Resource (person who 'owns' this issue) -Assigned Reesource (person who is actively working this issue) Does this make sense? Does OTRS have functionality that supports this principle? Thanks! Kris Jacobs

...

...
...
Shawn Beasley 11/27/2007 02:10 >>> Dear Kris,

...

I still do not understand what is meant by "locking" a ticket.

I do not understand why a ticket would be locked, unlocked, or what either of those terms mean in the context of an OTRS ticket.

Nils Breunese (Lemonbit)

1:20 p.m.

Kris Jacobs wrote:

...

OK, I understand the reasoning behind that, but it leads me to another question:

In OTRS, isn't it plainly visible to all Agents when a ticket has been assigned to an individual?

It is, when a ticket is locked. :o)

...

Here is what we have in mind at my organization:

Support requests come in. The department manager either assigns tickets to individuals, or individuals take ownership of tickets in a proactive fashion.

Anyone can look at all tickets - and when they look at a ticket that has been assigned or that someone has taken ownership of, it is obvious who is working on that ticket.

It is obvious when that ticket is locked. When an agent decides to work on a ticket, that agent locks the ticket. When someone assigns a ticket to an agent, the ticket is locked by that agent.

...

I think of agents as resources - each ticket in the database structure should have an assigned resource, and ideally an owning resource. Meaning, those are two separate fields.

Ticket table -Ticket # -Owning Resource (person who 'owns' this issue) -Assigned Reesource (person who is actively working this issue)

Does this make sense? Does OTRS have functionality that supports this principle?

The 'assigned resource' in your setup is the agent that has locked the ticket. I don't know what you mean exactly by 'owning' an issue. Nils Breunese.

Obee, Daniel

1:22 p.m.

There's the option to differentiate between owner and responsible. Maybe that's what you're looking for. I have no experience with that one whatsoever, just know the feature exists: Switch on the ticket responsible feature in Config Options: Ticket -> Core::Ticket Ticket::Responsible: Greetz, Daniel -----Original Message----- From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Kris Jacobs Sent: Dienstag, 27. November 2007 14:14 To: User questions and discussions about OTRS.org Subject: Re: [otrs] Practical Examples... Locking? OK, I understand the reasoning behind that, but it leads me to another question: In OTRS, isn't it plainly visible to all Agents when a ticket has been assigned to an individual? Here is what we have in mind at my organization: Support requests come in. The department manager either assigns tickets to individuals, or individuals take ownership of tickets in a proactive fashion. Anyone can look at all tickets - and when they look at a ticket that has been assigned or that someone has taken ownership of, it is obvious who is working on that ticket. I think of agents as resources - each ticket in the database structure should have an assigned resource, and ideally an owning resource. Meaning, those are two separate fields. Ticket table -Ticket # -Owning Resource (person who 'owns' this issue) -Assigned Reesource (person who is actively working this issue) Does this make sense? Does OTRS have functionality that supports this principle? Thanks! Kris Jacobs

...

...
...
Shawn Beasley 11/27/2007 02:10 >>> Dear Kris,

...

I still do not understand what is meant by "locking" a ticket.

I do not understand why a ticket would be locked, unlocked, or what either of those terms mean in the context of an OTRS ticket.

Kris Jacobs

1:22 p.m.

Ah, I just formulated some further thought: Could I simply create 1 queue per agent? That way, in this IT department, there would be one 'main' queue, and when a ticket is assigned or when someone takes ownership of the ticket, it is moved to an agent's individual queue. The department manager should always be able to view ALL tickets in ALL queues. I have a 4 person + 1 contractor Information Technology Department here. This would probably be pretty simple to implement and manage I think. Would OTRS support this sort of scenario? I think the main thing I'm missing or not understanding from the documentation is Practical Working Examples. Are there any Configuration or Structure Examples, some Practical Working Scenarios documented somewhere? Thanks! -Kris Jacobs PS: Oh wow, Bad Homburg! I spent a few years, from '89 to '93, in Babenhausen. I *loved* the country and the people! :)

...

...
...
Shawn Beasley 11/27/2007 02:10 >>> Dear Kris,

...

I still do not understand what is meant by "locking" a ticket.

I do not understand why a ticket would be locked, unlocked, or what either of those terms mean in the context of an OTRS ticket.

Peter van Beugen

1:25 p.m.

Yes, you can Make a Group for each person -----Oorspronkelijk bericht----- Van: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Namens Kris Jacobs Verzonden: dinsdag 27 november 2007 14:23 Aan: User questions and discussions about OTRS.org Onderwerp: Re: [otrs] Practical Examples... Locking? Ah, I just formulated some further thought: Could I simply create 1 queue per agent? That way, in this IT department, there would be one 'main' queue, and when a ticket is assigned or when someone takes ownership of the ticket, it is moved to an agent's individual queue. The department manager should always be able to view ALL tickets in ALL queues. I have a 4 person + 1 contractor Information Technology Department here. This would probably be pretty simple to implement and manage I think. Would OTRS support this sort of scenario? I think the main thing I'm missing or not understanding from the documentation is Practical Working Examples. Are there any Configuration or Structure Examples, some Practical Working Scenarios documented somewhere? Thanks! -Kris Jacobs PS: Oh wow, Bad Homburg! I spent a few years, from '89 to '93, in Babenhausen. I *loved* the country and the people! :)

...

...
...
Shawn Beasley 11/27/2007 02:10 >>> Dear Kris,

...

I still do not understand what is meant by "locking" a ticket.

I do not understand why a ticket would be locked, unlocked, or what either of those terms mean in the context of an OTRS ticket.

Nils Breunese (Lemonbit)

1:55 p.m.

Kris Jacobs wrote:

...

Ah, I just formulated some further thought:

Could I simply create 1 queue per agent?

That way, in this IT department, there would be one 'main' queue, and when a ticket is assigned or when someone takes ownership of the ticket, it is moved to an agent's individual queue. The department manager should always be able to view ALL tickets in ALL queues.

I don't see a need to create a queue for every agent, I'd say locking would be enough. I would enable StatusView (Frontend::Module###AgentTicketStatusView under Frontend::Agent::ModuleRegistration), which adds the StatusView button to the OTRS toolbar and the department manager could use that to get a quick overview of all tickets. Nils Breunese.

Kris Jacobs

2:14 p.m.

Perhaps this is a lot simpler in practice, but this whole Locking concept concerns me a bit. Here is a scenario: Agent A takes a call in the morning from a User. Agent A opens new ticket#101001, and begins troubleshooting. Agent A takes a few more calls - and while Agent A is on the phone with some other user, Agent B fields a call. This call is the same user as ticket#101001 - the user has some new information. Can Agent B simply open ticket#101001 and add the new information without worrying about "Locking"?

...

...
...
"Nils Breunese (Lemonbit)" 11/27/2007 08:55 >>> Kris Jacobs wrote:

...

Ah, I just formulated some further thought:

Could I simply create 1 queue per agent?

That way, in this IT department, there would be one 'main' queue, and when a ticket is assigned or when someone takes ownership of the ticket, it is moved to an agent's individual queue. The department manager should always be able to view ALL tickets in ALL queues.

Nils Breunese (Lemonbit)

2:18 p.m.

Kris Jacobs wrote:

...

Perhaps this is a lot simpler in practice, but this whole Locking concept concerns me a bit.

Here is a scenario:

Agent A takes a call in the morning from a User. Agent A opens new ticket#101001, and begins troubleshooting.

Agent A takes a few more calls - and while Agent A is on the phone with some other user, Agent B fields a call. This call is the same user as ticket#101001 - the user has some new information.

Can Agent B simply open ticket#101001 and add the new information without worrying about "Locking"?

Agent B could add a note to the ticket and agent A could get a notification about that (and see it added to the ticket). Maybe you just need to setup an OTRS system to play with and see how it works for you. Nils Breunese.

Kris Jacobs

2:33 p.m.

Thanks Nils. I have had it setup for days. I am opening and closing and manipulating test tickets now. The default Locking is a problem that I will have to work around if I am going to use OTRS. It looks like I can simply set Automatic Unlocking to something low like 2 minutes.

...

...
...
"Nils Breunese (Lemonbit)" 11/27/2007 09:18 >>> Kris Jacobs wrote:

...

Perhaps this is a lot simpler in practice, but this whole Locking concept concerns me a bit.

Here is a scenario:

Agent A takes a call in the morning from a User. Agent A opens new ticket#101001, and begins troubleshooting.

Agent A takes a few more calls - and while Agent A is on the phone with some other user, Agent B fields a call. This call is the same user as ticket#101001 - the user has some new information.

Can Agent B simply open ticket#101001 and add the new information without worrying about "Locking"?

Nils Breunese (Lemonbit)

2:53 p.m.

Kris Jacobs wrote:

...

The default Locking is a problem that I will have to work around if I am going to use OTRS.

It looks like I can simply set Automatic Unlocking to something low like 2 minutes.

Locking is a key principle in any ticketing system I believe, and most people don't seem to have any problems with it. It is there to prevent problems actually. Why would your tickets have to be unlocked all the time? Nils Breunese.

Kris Jacobs

3:05 p.m.

Please describe then the exact work flow in OTRS for this scenario: Agent A takes a telephone call, and records the support request as new ticket #42. Agent A continues to take telephone calls, and records new support requests as new tickets #43, #44, #45, #46. While Agent A is on a phone call and in the process of recording another support request as new ticket #47, Agent B looks at the queue. Agent B decides to work on tickets #42, 45, and 46. Those 3 tickets are locked right? Even though Agent A has recorded the requests, and moved on - they are locked and must be unlocked before Agent B can work on them? What step by step actions must Agent B take in OTRS when he wants to work those 3 tickets? If Agent B must manually unlock them himself before assuming responsibility for them, that is unacceptable.

...

...
...
"Nils Breunese (Lemonbit)" 11/27/2007 09:53 >>> Kris Jacobs wrote:

...

The default Locking is a problem that I will have to work around if I am going to use OTRS.

It looks like I can simply set Automatic Unlocking to something low like 2 minutes.

Nils Breunese (Lemonbit)

3:15 p.m.

Kris Jacobs wrote:

...

Please describe then the exact work flow in OTRS for this scenario:

Agent A takes a telephone call, and records the support request as new ticket #42.

Agent A continues to take telephone calls, and records new support requests as new tickets #43, #44, #45, #46.

While Agent A is on a phone call and in the process of recording another support request as new ticket #47, Agent B looks at the queue.

Agent B decides to work on tickets #42, 45, and 46.

Those 3 tickets are locked right? Even though Agent A has recorded the requests, and moved on - they are locked and must be unlocked before Agent B can work on them?

What step by step actions must Agent B take in OTRS when he wants to work those 3 tickets? If Agent B must manually unlock them himself before assuming responsibility for them, that is unacceptable.

If agent A creates the tickets from the phonecalls, but doesn't intend to work on them, he should make sure they are not locked after creating them (either A should unlock the tickets or you could probably setup OTRS to not create phone tickets in a locked state). Then agent B can find them in the queue and decide to lock them if he intends to handle them. Agent B shouldn't normally even be allowed to unlock agent A's locked tickets, unless he has explicit rights assigned to do so. Nils Breunese.

Kris Jacobs

3:35 p.m.

Hmmm... thank you Nils. I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp This concept of locking tickets seems very foreign and counter-intuitive to me. -Kris

...

...
...
"Nils Breunese (Lemonbit)" 11/27/2007 10:15 >>> Kris Jacobs wrote:

...

Please describe then the exact work flow in OTRS for this scenario:

Agent A takes a telephone call, and records the support request as new ticket #42.

Agent A continues to take telephone calls, and records new support requests as new tickets #43, #44, #45, #46.

While Agent A is on a phone call and in the process of recording another support request as new ticket #47, Agent B looks at the queue.

Agent B decides to work on tickets #42, 45, and 46.

Those 3 tickets are locked right? Even though Agent A has recorded the requests, and moved on - they are locked and must be unlocked before Agent B can work on them?

What step by step actions must Agent B take in OTRS when he wants to work those 3 tickets? If Agent B must manually unlock them himself before assuming responsibility for them, that is unacceptable.

Nils Breunese (Lemonbit)

3:44 p.m.

Kris Jacobs wrote:

...

Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking? Nils Breunese.

Andy Lubel

3:46 p.m.

Smells like 1 man helpdesk? On 11/27/07 10:44 AM, "Nils Breunese (Lemonbit)" wrote:

...

Kris Jacobs wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking?

Nils Breunese. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Kris Jacobs

3:53 p.m.

Smells like you're arrogant? I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

...

...
...
Andy Lubel 11/27/2007 10:46 >>> Smells like 1 man helpdesk?

On 11/27/07 10:44 AM, "Nils Breunese (Lemonbit)" wrote:

...

Kris Jacobs wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking?

Nils Breunese. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Richard Hinkamp - BeSite

4:04 p.m.

...

Smells like you're arrogant?

Please be polite to people responding to your questions...

...

I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

You are not the first one to ask this question and most of the time it's a small helpdesk where locking is too much hassle with not much profit because of the small helpdesk.

...

So what do I do when someone in my department has a ticket locked, is out to lunch, and a user calls with more info or requests an update?

I should be able to grab that ticket and run with the ball. Period.

You can see the ticket including the history. You could add a note to the locked ticket. If you have the permissions, you may break the lock and convert to your own lock. It all depends on the configuration. We have one install were tickets are only locked when an e-mail is being written. After sending it will auto close (and unlock). This is because there are lots of people on this helpdesk and lot's of parttimers and this way they prevent agents working on the same ticket at the same time, but don't lock tickets for a long time. Richard

Adriano Amaral

7:19 p.m.

Look the answer and the commentary he got from Andy.. I would probably do the same... but in privatly ... Richard Hinkamp - BeSite a écrit:

...

...
Smells like you're arrogant?

Please be polite to people responding to your questions...

...
I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

You are not the first one to ask this question and most of the time it's a small helpdesk where locking is too much hassle with not much profit because of the small helpdesk.

...
So what do I do when someone in my department has a ticket locked, is out to lunch, and a user calls with more info or requests an update?

I should be able to grab that ticket and run with the ball. Period.

You can see the ticket including the history. You could add a note to the locked ticket. If you have the permissions, you may break the lock and convert to your own lock. It all depends on the configuration. We have one install were tickets are only locked when an e-mail is being written. After sending it will auto close (and unlock). This is because there are lots of people on this helpdesk and lot's of parttimers and this way they prevent agents working on the same ticket at the same time, but don't lock tickets for a long time.

Richard _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Andy Lubel

4:39 p.m.

It's just that we tend to revisit things that are asked pretty regularly! Go to sysconfig and enable the "status view" and I think you will see what "power" it gives within OTRS. We just talked about it I think 2 weeks ago. There is no software that exists today that meets (or conforms to) 100% of every process that a company has. OTRS is 90% configuration and 10% internal process adjustment. -Andy On 11/27/07 10:53 AM, "Kris Jacobs" wrote:

...

Smells like you're arrogant?

I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

...
...
...
Andy Lubel 11/27/2007 10:46 >>> Smells like 1 man helpdesk?

On 11/27/07 10:44 AM, "Nils Breunese (Lemonbit)" wrote:

...
Kris Jacobs wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking?

Nils Breunese. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Andy Lubel Application Administrator / IT Department GTSI Corp. 3901 Stonecroft Boulevard Chantilly, VA 20151 Tel: 1.800.999.GTSI ext.2309 Dir: 703.502.2309 Andy.Lubel@gtsi.com --

Kris Jacobs

4:44 p.m.

Issues raised regularly are usually indications of real problems. ;)

...

...
...
Andy Lubel 11/27/2007 11:39 >>> It's just that we tend to revisit things that are asked pretty regularly!

Go to sysconfig and enable the "status view" and I think you will see what "power" it gives within OTRS. We just talked about it I think 2 weeks ago. There is no software that exists today that meets (or conforms to) 100% of every process that a company has. OTRS is 90% configuration and 10% internal process adjustment. -Andy On 11/27/07 10:53 AM, "Kris Jacobs" wrote:

...

Smells like you're arrogant?

I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

...
...
...
Andy Lubel 11/27/2007 10:46 >>> Smells like 1 man helpdesk?

On 11/27/07 10:44 AM, "Nils Breunese (Lemonbit)" wrote:

...
Kris Jacobs wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking?

Nils Breunese. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Andy Lubel Application Administrator / IT Department GTSI Corp. 3901 Stonecroft Boulevard Chantilly, VA 20151 Tel: 1.800.999.GTSI ext.2309 Dir: 703.502.2309 Andy.Lubel@gtsi.com -- _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Andy Lubel

5:22 p.m.

People only ask because they assume that their processes will just conform to OTRS and they don't have to change the way they work. Sometimes I think its harder to change human processes than it is changing a system process. If ticket locking is make/break for your project, then maybe OTRS isn't the right package for your needs. You could just file a bug report @ http://bugs.otrs.org and maybe something could be done about it. -Andy On 11/27/07 11:44 AM, "Kris Jacobs" wrote:

...

Issues raised regularly are usually indications of real problems. ;)

...
...
...
Andy Lubel 11/27/2007 11:39 >>> It's just that we tend to revisit things that are asked pretty regularly!

Go to sysconfig and enable the "status view" and I think you will see what "power" it gives within OTRS. We just talked about it I think 2 weeks ago.

There is no software that exists today that meets (or conforms to) 100% of every process that a company has. OTRS is 90% configuration and 10% internal process adjustment.

-Andy

On 11/27/07 10:53 AM, "Kris Jacobs" wrote:

...
Smells like you're arrogant?

I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

...
...
...
Andy Lubel 11/27/2007 10:46 >>> Smells like 1 man helpdesk?

On 11/27/07 10:44 AM, "Nils Breunese (Lemonbit)" wrote:

...
Kris Jacobs wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking?

Nils Breunese. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Kris Jacobs

7:08 p.m.

unsubscribe

...

...
...
Andy Lubel 11/27/2007 12:22 >>> People only ask because they assume that their processes will just conform to OTRS and they don't have to change the way they work. Sometimes I think its harder to change human processes than it is changing a system process.

If ticket locking is make/break for your project, then maybe OTRS isn't the right package for your needs. You could just file a bug report @ http://bugs.otrs.org and maybe something could be done about it. -Andy On 11/27/07 11:44 AM, "Kris Jacobs" wrote:

...

Issues raised regularly are usually indications of real problems. ;)

...
...
...
Andy Lubel 11/27/2007 11:39 >>> It's just that we tend to revisit things that are asked pretty regularly!

Go to sysconfig and enable the "status view" and I think you will see what "power" it gives within OTRS. We just talked about it I think 2 weeks ago.

There is no software that exists today that meets (or conforms to) 100% of every process that a company has. OTRS is 90% configuration and 10% internal process adjustment.

-Andy

On 11/27/07 10:53 AM, "Kris Jacobs" wrote:

...
Smells like you're arrogant?

I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

...
...
...
Andy Lubel 11/27/2007 10:46 >>> Smells like 1 man helpdesk?

On 11/27/07 10:44 AM, "Nils Breunese (Lemonbit)" wrote:

...
Kris Jacobs wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking?

Nils Breunese. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Adriano Amaral

7:18 p.m.

It's sad guys... A flaming war about a feature that he thought was usefull... The point on open source, is to be open to the opinions, and try to understand sometimes those who don't have the same vision as us. Instead of having another user that maybe would be an asset in the future, we give him crap because on his experience the feature is not usefull. Well donne !!! I wonder how other folks that look for answers on this forum will act after reading all this. Adriano Kris Jacobs a écrit:

...

unsubscribe

...
...
...
Andy Lubel 11/27/2007 12:22 >>>

People only ask because they assume that their processes will just conform to OTRS and they don't have to change the way they work. Sometimes I think its harder to change human processes than it is changing a system process.

If ticket locking is make/break for your project, then maybe OTRS isn't the right package for your needs.

You could just file a bug report @ http://bugs.otrs.org and maybe something could be done about it.

-Andy

On 11/27/07 11:44 AM, "Kris Jacobs" wrote:

...
Issues raised regularly are usually indications of real problems. ;)

...
...
...
Andy Lubel 11/27/2007 11:39 >>>

It's just that we tend to revisit things that are asked pretty regularly!

Go to sysconfig and enable the "status view" and I think you will see what "power" it gives within OTRS. We just talked about it I think 2 weeks ago.

There is no software that exists today that meets (or conforms to) 100% of every process that a company has. OTRS is 90% configuration and 10% internal process adjustment.

-Andy

On 11/27/07 10:53 AM, "Kris Jacobs" wrote:

...
Smells like you're arrogant?

I've worked in plenty of complex multi-user support request systems - I'm having trouble drawing parallels from them to OTRS though.

...
...
...
Andy Lubel 11/27/2007 10:46 >>>

Smells like 1 man helpdesk?

On 11/27/07 10:44 AM, "Nils Breunese (Lemonbit)" wrote:

...
Kris Jacobs wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking?

Nils Breunese. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system?

Kris Jacobs

4:14 p.m.

Incident Monitor example: A support request is opened by Agent A. Agent A is the owning resource. Agent A does whatever to work the request - removes it from the HelpDesk Queue to his personal queue. He probably takes ownership and assignment of the request. In IM those are two separate properties of any given request. Agent A works the request, and comes to a logical stopping point - perhaps he solicited the user for some more information, that's very common. The user calls in the next morning, and gets Agent B. Agent B asks the user for her request #, Agent B pulls the request, sees that Agent A has assumed responsibility for the request and has done some work on it, and that Agent A has solicited some more info from the customer. The customer communicates the more info to Agent B, and Agent B can do two different things at this point: 1. Record the additional info in the request & move on - as soon as Agent A returns to the system he'll see that entry by Agent B. Agent A picks up where he left off when he returns to the system, armed with the additional info recorded by Agent b. 2. Record the additional info in the request and assume assignment, working the request to resolution. Agent A retains ownership, but Agent B has assumed assignment. The system will continue to notify Agent A (because he owns the request) of progress made to the request, up to and including the point where Agent B resolves and closes it. Number Two happened a lot: it was very important to maintain a smooth transition in the customer-facing aspect of the request management system. Agent B was able to easily pickup the ball and carry the request to completion, and Agent A still had visibility of the request from the point he asked for more info from the customer/user. I feel like I'm talking a completely foreign language here - the terms and processes between OTRS and what I'm used to I think accomplish the same things in very similar ways, but I am having trouble drawing the parallels.

...

...
...
"Nils Breunese (Lemonbit)" 11/27/2007 10:44 >>> Kris Jacobs wrote:

...

Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24 ( http://www.monitor24/ )-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

Nils Breunese (Lemonbit)

4:40 p.m.

Kris Jacobs wrote:

...

Incident Monitor example:

A support request is opened by Agent A.

Agent A is the owning resource.

Agent A does whatever to work the request - removes it from the HelpDesk Queue to his personal queue. He probably takes ownership and assignment of the request. In IM those are two separate properties of any given request.

In OTRS agent A would just lock the ticket, which happens by default if he creates the ticket, so there is nothing special that agent A needs to do.

...

Agent A works the request, and comes to a logical stopping point - perhaps he solicited the user for some more information, that's very common.

The user calls in the next morning, and gets Agent B. Agent B asks the user for her request #, Agent B pulls the request, sees that Agent A has assumed responsibility for the request and has done some work on it, and that Agent A has solicited some more info from the customer.

The customer communicates the more info to Agent B, and Agent B can do two different things at this point: 1. Record the additional info in the request & move on - as soon as Agent A returns to the system he'll see that entry by Agent B. Agent A picks up where he left off when he returns to the system, armed with the additional info recorded by Agent b.

2. Record the additional info in the request and assume assignment, working the request to resolution. Agent A retains ownership, but Agent B has assumed assignment. The system will continue to notify Agent A (because he owns the request) of progress made to the request, up to and including the point where Agent B resolves and closes it.

Number Two happened a lot: it was very important to maintain a smooth transition in the customer-facing aspect of the request management system. Agent B was able to easily pickup the ball and carry the request to completion, and Agent A still had visibility of the request from the point he asked for more info from the customer/user.

If agent A was not available to work on the ticket, agent A should have unlocked the ticket before going home. Or you'd have to setup OTRS so your agents have permission to change the owner of the ticket.

...

I feel like I'm talking a completely foreign language here - the terms and processes between OTRS and what I'm used to I think accomplish the same things in very similar ways, but I am having trouble drawing the parallels.

If you feel OTRS is not able to do what you need, maybe OTRS isn't for you. I'm a happy user and I think OTRS is a pretty flexible and configurable system and a lot of the default behavior can be changed to suit your needs. Be assured that we're only trying to help you get comfortable with OTRS. Nils Breunese.

Kris Jacobs

4:26 p.m.

In 4 years of working with IncidentMonitor in an environment with 20+ users in it every day, I can't think of a time where two people were duplicating effort. I'm not sure if it was because of the request owning resource / request assigned resource characteristics or what - but having two agents duplicating effort on a single request doesn't register with me at all.

...

...
...
"Nils Breunese (Lemonbit)" 11/27/2007 10:44 >>> Kris Jacobs wrote:

...

Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24 ( http://www.monitor24/ )-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter- intuitive to me.

Andy Lubel

3:46 p.m.

Oh boy, here we go again... Locking tickets is important for the enterprise, where support may not all be in one place and there may be many agents. Its also good for beancounting how much effort you spend on each request. If you don't need ticket locking, just set up a shared mailbox in exchange and work your helpdesk that way! Or search the lists for more info related to locking and get the full story on why it may be good for any helpdesk with more than a couple people acting as agents to have this. Nils, don't you think OTRS really needs to expose that "status view" so these guys don't get freaked out that they don't have a way to see what tickets each agent has locked? -Andy On 11/27/07 10:35 AM, "Kris Jacobs" wrote:

...

Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter-intuitive to me.

-Kris

...
...
...
"Nils Breunese (Lemonbit)" 11/27/2007 10:15 >>> Kris Jacobs wrote:

...
Please describe then the exact work flow in OTRS for this scenario:

Agent A takes a telephone call, and records the support request as new ticket #42.

Agent A continues to take telephone calls, and records new support requests as new tickets #43, #44, #45, #46.

While Agent A is on a phone call and in the process of recording another support request as new ticket #47, Agent B looks at the queue.

Agent B decides to work on tickets #42, 45, and 46.

Those 3 tickets are locked right? Even though Agent A has recorded the requests, and moved on - they are locked and must be unlocked before Agent B can work on them?

What step by step actions must Agent B take in OTRS when he wants to work those 3 tickets? If Agent B must manually unlock them himself before assuming responsibility for them, that is unacceptable.

If agent A creates the tickets from the phonecalls, but doesn't intend to work on them, he should make sure they are not locked after creating them (either A should unlock the tickets or you could probably setup OTRS to not create phone tickets in a locked state). Then agent B can find them in the queue and decide to lock them if he intends to handle them.

Agent B shouldn't normally even be allowed to unlock agent A's locked tickets, unless he has explicit rights assigned to do so.

Nils Breunese.

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Andy Lubel Application Administrator / IT Department GTSI Corp. 3901 Stonecroft Boulevard Chantilly, VA 20151 Tel: 1.800.999.GTSI ext.2309 Dir: 703.502.2309 Andy.Lubel@gtsi.com --

Kris Jacobs

3:55 p.m.

So what do I do when someone in my department has a ticket locked, is out to lunch, and a user calls with more info or requests an update? I should be able to grab that ticket and run with the ball. Period.

...

...
...
Andy Lubel 11/27/2007 10:46 >>> Oh boy, here we go again...

Locking tickets is important for the enterprise, where support may not all be in one place and there may be many agents. Its also good for beancounting how much effort you spend on each request. If you don't need ticket locking, just set up a shared mailbox in exchange and work your helpdesk that way! Or search the lists for more info related to locking and get the full story on why it may be good for any helpdesk with more than a couple people acting as agents to have this. Nils, don't you think OTRS really needs to expose that "status view" so these guys don't get freaked out that they don't have a way to see what tickets each agent has locked? -Andy On 11/27/07 10:35 AM, "Kris Jacobs" wrote:

...

Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter-intuitive to me.

-Kris

...
...
...
"Nils Breunese (Lemonbit)" 11/27/2007 10:15 >>> Kris Jacobs wrote:

...
Please describe then the exact work flow in OTRS for this scenario:

Agent A takes a telephone call, and records the support request as new ticket #42.

Agent A continues to take telephone calls, and records new support requests as new tickets #43, #44, #45, #46.

While Agent A is on a phone call and in the process of recording another support request as new ticket #47, Agent B looks at the queue.

Agent B decides to work on tickets #42, 45, and 46.

Those 3 tickets are locked right? Even though Agent A has recorded the requests, and moved on - they are locked and must be unlocked before Agent B can work on them?

What step by step actions must Agent B take in OTRS when he wants to work those 3 tickets? If Agent B must manually unlock them himself before assuming responsibility for them, that is unacceptable.

If agent A creates the tickets from the phonecalls, but doesn't intend to work on them, he should make sure they are not locked after creating them (either A should unlock the tickets or you could probably setup OTRS to not create phone tickets in a locked state). Then agent B can find them in the queue and decide to lock them if he intends to handle them.

Agent B shouldn't normally even be allowed to unlock agent A's locked tickets, unless he has explicit rights assigned to do so.

Nils Breunese.

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Steven Carr

4 p.m.

In this situation you can either add a note to the ticket which is already locked by the agent, or if you want to deal with the call you can take ownership of the ticket and deal with it. It is confusing if you are not used to working this way, infact we weren't and ran with the automatic unlocking of tickets every 5 minutes but then we got to the stage of not knowing who was dealing with what so we turned off the automatic unlocking and our agents lock tickets they are working on. Anything that is in an actual queue and can be seen needs dealing with, everything else is locked and being dealt with. I do agree that the StatusView should be turned on by default, after finding this gem everything became easier as we could then see at a glance who was working on what. Ste Kris Jacobs wrote:

...

So what do I do when someone in my department has a ticket locked, is out to lunch, and a user calls with more info or requests an update?

I should be able to grab that ticket and run with the ball. Period.

...
...
...
Andy Lubel 11/27/2007 10:46 >>> Oh boy, here we go again...

Locking tickets is important for the enterprise, where support may not all be in one place and there may be many agents. Its also good for beancounting how much effort you spend on each request.

If you don't need ticket locking, just set up a shared mailbox in exchange and work your helpdesk that way!

Or search the lists for more info related to locking and get the full story on why it may be good for any helpdesk with more than a couple people acting as agents to have this.

Nils, don't you think OTRS really needs to expose that "status view" so these guys don't get freaked out that they don't have a way to see what tickets each agent has locked?

-Andy

On 11/27/07 10:35 AM, "Kris Jacobs" wrote:

...
Hmmm... thank you Nils.

I'm used to working in Incident Monitor at a previous employer: http://www.monitor24-7.com/corp/prod_im_overview.asp

This concept of locking tickets seems very foreign and counter-intuitive to me.

-Kris

...
...
...
"Nils Breunese (Lemonbit)" 11/27/2007 10:15 >>> Kris Jacobs wrote:

...
Please describe then the exact work flow in OTRS for this scenario:

Agent A takes a telephone call, and records the support request as new ticket #42.

Agent A continues to take telephone calls, and records new support requests as new tickets #43, #44, #45, #46.

While Agent A is on a phone call and in the process of recording another support request as new ticket #47, Agent B looks at the queue.

Agent B decides to work on tickets #42, 45, and 46.

Those 3 tickets are locked right? Even though Agent A has recorded the requests, and moved on - they are locked and must be unlocked before Agent B can work on them?

What step by step actions must Agent B take in OTRS when he wants to work those 3 tickets? If Agent B must manually unlock them himself before assuming responsibility for them, that is unacceptable. If agent A creates the tickets from the phonecalls, but doesn't intend to work on them, he should make sure they are not locked after creating them (either A should unlock the tickets or you could probably setup OTRS to not create phone tickets in a locked state). Then agent B can find them in the queue and decide to lock them if he intends to handle them.

Agent B shouldn't normally even be allowed to unlock agent A's locked tickets, unless he has explicit rights assigned to do so.

Nils Breunese.

_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? => http://www.otrs.com/

Andy Lubel Application Administrator / IT Department

GTSI Corp. 3901 Stonecroft Boulevard Chantilly, VA 20151 Tel: 1.800.999.GTSI ext.2309 Dir: 703.502.2309 Andy.Lubel@gtsi.com

-- Steven Carr Engineer - Khipu Networks Ltd. support@khipu-networks.com - www.khipu-networks.com Secure - Compliant - Infrastructure Registered Office: Fairfax House, 15 Fulwood Place, London WC1V 6AY Registered in England. Company Number 5218573 CRN Channel Awards - Specialist reseller of the year 2007

Richard Hinkamp - BeSite

3:47 p.m.

...

This concept of locking tickets seems very foreign and counter-intuitive to me.

It's quite simple. See it as a pile of papers which need to be processed by multiple people. When you process one piece of paper you take it from the pile to your desk (lock it) and process it, maybe put some notes to it etc. When you're done, you put it back on the pile (unlock it). When you know the customer will call YOU back this afternoon, you keep it on your desk (keep it locked), this way you are sure none of your colleagues will do something with this piece of paper during that time. The mechanism is very simple but powerful and one of the strong points of a system like OTRS. Richard

6443

Age (days ago)

6444

Last active (days ago)

List overview

Download

32 comments

10 participants

participants (10)

Adriano Amaral
Andy Lubel
Kris Jacobs
Marc Redeker
Nils Breunese (Lemonbit)
Obee, Daniel
Peter van Beugen
Richard Hinkamp - BeSite
Shawn Beasley
Steven Carr