Yep. On Tue, Oct 11, 2011 at 1:47 PM, Ruslan Zakirov <[email protected]>wrote:
> On Mon, Oct 10, 2011 at 8:44 PM, Kenneth Crocker <[email protected]> > wrote: > > Laura, > > > > You can also add a new Status value like 'Dev compl' or something that > > indicates that the ticket is ready to go back to Customer support. Then > > write a scrip that change the Queue for the ticket back to Custom Support > > when the status is changed to that value. Make it part of your workflow > > design. > > I don't mind at all moving tickets around. However, ticket is a sort > of channel of communication with interested parties. Yes, when you > move ticket to development you either can change requestor or tune > notifications, so original requestors are not notified. This works > when people use email, but stops working when people get access to the > web interface - they see all replies and/or comments. > > Moving is good when you have conveyor like processing, for example > order -> warehouse -> delivery. Things start in one queue and move > towards final queue, rarely return back and all parties can talk to > requestor but each figures out its own details. In development it's > also possible, for example "bugs" that are created by supporters and > q&a teams and managed by developers, then things move into q&a, then > to changes_integration queue where they tied to tickets in 'releases'. > > Good indication for conveyor type is often change of owner of ticket > not because of absence of the current owner, but because of workflow. > > > Kenn > > LBNL > > > > On Mon, Oct 10, 2011 at 9:24 AM, Laura Grella <[email protected]> > > wrote: > >> > >> Thank you so much Ruslan! This really opened my eyes to how we can > change > >> our > >> procedures for support/developer communications. I will definitely think > >> through what you have suggested and see how we can put it into use. > >> > >> > >> > >> Ruslan Zakirov-2 wrote: > >> > > >> > Hello Laura, > >> > > >> > On Mon, Oct 10, 2011 at 6:51 PM, Laura Grella < > [email protected]> > >> > wrote: > >> >> > >> >> Would this scenario be possible: > >> >> > >> >> We have customer support queue open a ticket, and then the ticket > gets > >> >> sent > >> >> to Software Development. We don't want software development to ever > >> >> resolve > >> >> a ticket if it was originated in the customer support queue. We want > it > >> >> to > >> >> always end up in customer support so the support staff can first call > >> >> customer to tell them the work was done. > >> >> > >> >> Can I remove the resolved button/option if the ticket started in > >> >> customer > >> >> support and is not currently in customer support and replace it with > a > >> >> resolved by development button/option if it is owned by development > >> >> which > >> >> will cause it to go to the customer support queue where they will > then > >> >> have > >> >> to real option to resolve the ticket? > >> > > >> > > >> > In RT 4.0 every status change can be protected with a new right and > >> > that right can be assigned to groups. > >> > > >> > However, in such setup I would recommend two alternatives ways for > >> > support to comunicate with developers. > >> > > >> > 1) Developer comment required. In support queue supporters add > >> > developers to AdminCc or Cc of a ticket when they need feedback from > >> > developers. Setup rights, so developers can only comment on tickets in > >> > support queue. For developers you setup saved search so they see > >> > tickets in support queue where they are watchers. Also, you may create > >> > additional custom field with values: "waiting for developer", "waiting > >> > for requestor", ... . This way developers never interact with > >> > customers, supporters bring in developers only when required and take > >> > care of their awareness. > >> > > >> > 2) Bug fixing and development. When real development is required, > >> > supporter creates a ticket in development queue and support request is > >> > linked to development ticket. This allows you to link multiple support > >> > requests to one development ticket, so you don't mix customers by > >> > merging tickets and still tracks one development process through one > >> > ticket. Developers can access all requests and via comments ask for > >> > more info. Developers can communicate to each other via development > >> > ticket. They can split development ticket into if problems are > >> > different and as well split linked requests accordingly. As well, such > >> > development ticket can be used to comunicate with Q&A team. > >> > > >> > For sure it needs more time to setup such thing, but it works much > >> > better than moving tickets between support and development. > >> > > >> >> Hope this is clear. Thanks. > >> >> > >> >> Laura > >> > > >> > -- > >> > Best regards, Ruslan. > >> > -------- > >> > RT Training Sessions (http://bestpractical.com/services/training.html > ) > >> > * San Francisco, CA, USA October 18 & 19, 2011 > >> > * Washington DC, USA October 31 & November 1, 2011 > >> > * Barcelona, Spain November 28 & 29, 2011 > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://old.nabble.com/New-state---Developer-resolved-tp32625025p32625677.html > >> Sent from the Request Tracker - User mailing list archive at Nabble.com. > >> > >> -------- > >> RT Training Sessions (http://bestpractical.com/services/training.html) > >> * San Francisco, CA, USA October 18 & 19, 2011 > >> * Washington DC, USA October 31 & November 1, 2011 > >> * Barcelona, Spain November 28 & 29, 2011 > > > > > > -------- > > RT Training Sessions (http://bestpractical.com/services/training.html) > > * San Francisco, CA, USA — October 18 & 19, 2011 > > * Washington DC, USA — October 31 & November 1, 2011 > > * Barcelona, Spain — November 28 & 29, 2011 > > > > > > -- > Best regards, Ruslan. >
-------- RT Training Sessions (http://bestpractical.com/services/training.html) * San Francisco, CA, USA October 18 & 19, 2011 * Washington DC, USA October 31 & November 1, 2011 * Barcelona, Spain November 28 & 29, 2011
