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?
Hope this is clear. Thanks.
Laura
View this message in context: http://old.nabble.com/New-state---Developer-resolved-tp32625025p32625025.html
Hello Laura,
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.
-
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.
-
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.
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,
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.
-
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.
-
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
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
LBNLOn Mon, Oct 10, 2011 at 9:24 AM, Laura Grella lgrella@acquiremedia.comwrote:
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@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.
-
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.
-
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
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
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,
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.
-
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.
-
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
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
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,
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.
-
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.
-
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.
Yep.On Tue, Oct 11, 2011 at 1:47 PM, Ruslan Zakirov ruz@bestpractical.comwrote:
On Mon, Oct 10, 2011 at 8:44 PM, Kenneth Crocker kfcrocker@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@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@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.
-
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.
-
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.