[rt-users] New state - Developer resolved

[Laura Grella]

Thanks Kenn,

This is another good idea. I would have to go one further and not only
change the queue to support but also change the owner to the requestor since
we want the support staff the have the responsibility of handling the
ticket.

Thanks!


Kenneth Crocker 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.
> 
> Kenn
> LBNL
> 
> On Mon, Oct 10, 2011 at 9:24 AM, Laura Grella
> <lgrella at acquiremedia.com>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
>> <lgrella at acquiremedia.com>
>> > 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
> 

-- 
View this message in context: http://old.nabble.com/New-state---Developer-resolved-tp32625025p32625849.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.