[rt-users] New state - Developer resolved
Kenneth Crocker
kfcrocker at lbl.gov
Tue Oct 11 19:00:35 EDT 2011
Yep.
On Tue, Oct 11, 2011 at 1:47 PM, Ruslan Zakirov <ruz at bestpractical.com>wrote:
> On Mon, Oct 10, 2011 at 8:44 PM, Kenneth Crocker <kfcrocker at lbl.gov>
> 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 <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
> >
>
>
>
> --
> Best regards, Ruslan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20111011/a4d9c9a1/attachment.htm>
More information about the rt-users
mailing list