Is the ball in our court?

RT Users
1

Hi All…

We have been using RT for several weeks now and its saving us time and
confusion every day! There is one small issue I would appreciate some
advice on.

We have found that it takes several exchanges with the customer to
completely resolve their issue. After we send them some correspondence, we
don’t have a good way to know if they have replied, since the TOLD column
in the search is updated upon any correspondence, whether sent or received.

We have tried resolving the ticket right after sending correspondence, and
this works in that it gets opened again by RT when the customer responds.
This is not a great solution.

Is there an easy way to know that the customer has replied, without
resolving the ticket?

Thanks!

Jim

2

Is there an easy way to know that the customer has replied, without
resolving the ticket?

Hello Jim,

I’m new to RT myself, but I get the sense that it would be fairly easy
to configure a “Scrip” for your queue that would e-mail someone (maybe
the “AdminCC” watchers) when correspondence happens. Did you try
something like that?

Mark

3

Hi Mark…

Well, we do get email from RT to the watchers list. But we’re trying to
keep email out of it. We would prefer to be able to do this all from the
web interface.–On Thursday, January 30, 2003 6:14 PM -0500 Mark Stosberg mark@summersault.com wrote:

Is there an easy way to know that the customer has replied, without
resolving the ticket?

Hello Jim,

I’m new to RT myself, but I get the sense that it would be fairly easy
to configure a “Scrip” for your queue that would e-mail someone (maybe
the “AdminCC” watchers) when correspondence happens. Did you try
something like that?

Mark

http://mark.stosberg.com/

4

Is there an easy way to know that the customer has replied, without
resolving the ticket?

If you want something similar to the behavior that makes resolved
tickets open upon correspondence, set the tickets to “stalled” –
stalled tickets also switch to open on correspondence.

(“Stalled” is essentially “awaiting response”.)

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

5

“JA” == Jim Archer jim@archer.net writes:

JA> We have found that it takes several exchanges with the customer to
JA> completely resolve their issue. After we send them some correspondence, we

someone posted here (or was it in contrib) a week or two ago some code
to make the summary page show who was the last correspondent. This
should let you know what you need. I’ve been meaning to implement
this myself…

Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

6

We have been using RT for several weeks now and its saving us time and
confusion every day! There is one small issue I would appreciate some
advice on.

We have found that it takes several exchanges with the customer to
completely resolve their issue. After we send them some correspondence, we
don’t have a good way to know if they have replied, since the TOLD column
in the search is updated upon any correspondence, whether sent or received.

We have tried resolving the ticket right after sending correspondence, and
this works in that it gets opened again by RT when the customer responds.
This is not a great solution.

Is there an easy way to know that the customer has replied, without
resolving the ticket?

You could stall the ticket…

In our organization, we established the following:

Stalled: we are waiting on an internal or external resource for
information before we can respond to the requestor.

Resolved: we have sent a response to the requestor. It doesn’t matter if
our response was a query for more information or if we think we have
closed the ticket. You see, many times, the requestor never responds to
the query therefore we would have a bunch of stalled tickets sitting there
forever.

In both cases, the ticket will be opened if the requestor replies
referencing the ticket number.

7

Hi,

The way we solved the problem here is through a scrip.
Some of our queues have only a few tickets, very few owners, and a usually
long delay before questions get an anwser (because they usually need some
research).
Users where complaining that they hd to check all tickets several times a
day for nothing, just in case someone had replied.

The scrip just send the owner a mail message when a transaction occurs on
its message. This transaction is almost always an incomming answer. The
emails contains a URL to the ticket itself so the owner just has to click on
the URL and he is back into RT on the desired ticket.

All this is just using standard features.

The proposed solutions based on status and proposed in the other replies are
interesting too, could not be applied to us. Turning the messages to
“solved” was not acceptable to us for several reasons :

  1. Really, the ticket is NOT solved. I want to know there is still some
    potential time to spend on it for the team.
  2. When solving a ticket, we send a message out. Users would beleive we
    consider that problems are solved when they can’t be sorted out in less than
    2 days. Bad for our reputation…

Blaise

-----Message d’origine-----De : Jim Archer [mailto:jim@archer.net]
Envoye : vendredi 31 janvier 2003 00:06
A : rt-users@lists.fsck.com
Objet : [rt-users] Is the ball in our court?

Hi All…

We have been using RT for several weeks now and its saving us time and
confusion every day! There is one small issue I would appreciate some
advice on.

We have found that it takes several exchanges with the customer to
completely resolve their issue. After we send them some correspondence, we
don’t have a good way to know if they have replied, since the TOLD column
in the search is updated upon any correspondence, whether sent or received.

We have tried resolving the ticket right after sending correspondence, and
this works in that it gets opened again by RT when the customer responds.
This is not a great solution.

Is there an easy way to know that the customer has replied, without
resolving the ticket?

Thanks!

Jim

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

8

Hi,On Fri, 2003-01-31 at 00:06, Jim Archer wrote:

Hi All…

Is there an easy way to know that the customer has replied, without
resolving the ticket?
In our workflow we have added a new state called “fixed”, which means we
found a solution for the problem, but it is not tested yet or the
customer has not agreed to our solution . That depends on the usage of
the queue. In the web interface ‘fixed’ tickets are shown in a light
blue in the list of the tickets one owns, so everyone has a good
overview. (we like these colored lists :slight_smile:
These tickets reopen like ‘stalled’ or ‘resolved’ tickets, if something
happens with them. Normally the customer responds next to a message.

Regards,
Harald
Dr. Harald Kolléra Professional Services
fun communications GmbH
Brauerstrasse 6 76135 Karlsruhe Germany
Tel: +49 (0)7 21-9 64 48-1 54 Fax: +49 (0) 7 21 9 64 48-2 99
email: harald.kollera@fun.de http://www.fun.de/

9

JA> We have found that it takes several exchanges with the customer to
JA> completely resolve their issue. After we send them some
correspondence, we

someone posted here (or was it in contrib) a week or two ago some code
to make the summary page show who was the last correspondent. This
should let you know what you need. I’ve been meaning to implement
this myself…

This is a really trivial thing to do…

My RT summary page currently provides:

25 highest priority tickets I own…

Subject Queue Status Last

(where Last is last person to touch the ticket)

25 highest priority tickets I requested…

Subject Owner Queue Status Last

and

25 highest priority unclaimed tickets in the 8 queue(s) I watch…

Subject User Queue Status Age

Where User shows the email of the user

To make these sorts of changes, modify My* in the Elements directory

Add these lines kind of lines in the right places:

Last (This is the header of the column) and <%$Ticket->LastUpdatedByObj->Name%> (This is the data to display)

If you wanted to display the last time, the email, etc, just change the
data line… This is just an example, since clearly, you can add most
anything you can look up… if you don’t know the RT schema, this is a
good point to start learning… if the field doesn’t display what you
want, try try again.

and i agree that using stalled makes more sense in Jim’s case. We’re
using resolved, since frequently, after the first response, the customer
doesn’t reply, as it’s been solved.