[rt-users] New state - Developer resolved

[Kenneth Crocker]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20111010/1a25f221/attachment.htm>