[REQ] Closing a ticket via e-mail

[AdamVocks]

We have some operators that work via e-mail and don't log into the ttx web interface except when they get a free moment to close hundreds of tickets.

A few questions:

I was wondering if anyone has considered the ability to close a ticket via e-mail.

and

If there isn't a way to close tickets via e-mail, then do your operators reply to an ticket in e-mail and then log into the web interface to close the ticket?  OR  Do most operators use the web interface?

Thanks!

Adam

[Sparky]

TTX is a great system but if people refuse to properly use it, your options are limited.

For me, the whole purpose of installing and using TTX was to get away from email.  To have all projects and jobs organized in a nice centrally located interface.  I don't even want my customers responding via email so I won't even install the optional mail module.

To be honest, I don't understand the point of TTX if your operators respond to everything via email.  So customers don't use tickets online, & operators don't use tickets online... just go back and forth with customers via email, no?  Most modern email clients like Outlook allow you to organize conversations into projects.

Getting back to your original request:  No, there is no practical way I know about to close out tickets via email.  If any modifications were possible, they'd have to be done within the optional mail module.

Perhaps, others can also respond with their ideas.

[AdamVocks]

For me, the whole purpose of installing and using TTX was to get away from email.  To have all projects and jobs organized in a nice centrally located interface.

Let me be clear.  I love TTX and think its great and it has saved us a lot of grief over problems that used to slip though the cracks.

There are key differences how we use TTX and just simply using e-mail.  If we were using only e-mail, we would have our customers send to a support@ e-mail that gets distributed to all of our operator.  No central place to look it up.  I agree with you on that.

I don't even want my customers responding via email so I won't even install the optional mail module.

We purchased the mail module because customers were replying to the e-mails anyway, so we figured why fight it.  Why would you not want customers to respond via e-mail?

To be honest, I don't understand the point of TTX if your operators respond to everything via email.  So customers don't use tickets online, & operators don't use tickets online... just go back and forth with customers via email, no?  Most modern email clients like Outlook allow you to organize conversations into projects.

That option works fine if your talking about one operator talking to many customers.  We needed a place to centrally manage our tickets, and see which ones are not finished, etc. etc.  Again, love the program and it's benefits.

What we've found is that when we get notified of a problem, it is quite a bit faster to simply click reply and give the customer a solution as opposed to clicking the link, typing in your username and password and typing your reply that way.

Is that the procedure your operators use when they receive a request?  (I'm assuming since you stated you don't install the mail module.)  If so, are saying it is not easier to simply reply?

Maybe we're just doing it wrong so, I suppose we are looking for efficiencies using TTX as well.

Take care,

Adam

[Sparky]

I understand your point.  I just don't understand why your operators aren't mandated to use TTX as intended.

I agree, getting customers to properly use the system can be difficult.  I personally tell mine that any response made outside of the TTX system might get lost.  It's important to use the link in the email and post the response online.  I've placed footers in my email templates that remind people to use the link, do not hit reply, etc....  If the situation ever gets worse, my notice will say that any email reply will not be read.

As to your question about why I do not want to install the email module.  That's simple... I want my customers to see the full ticket as they make their answer.  Many times I get nonsensical answers to my questions and must quote contradictory statements they've made in previous replies.  Forcing them to reply inside the ticket, hopefully forces them to actually read the ticket.  If they don't read it, fine... but I still need documentation of what they're asking me to do.

Secondly, I don't believe operators should have the luxury of the email module.  If you're paying them to do a job, then they should do the job exactly as you specify.  On my end that would mean posting all responses within TTX... for the same reasons as customers... to better understand the history of the ticket which leads to a higher quality response.

I also added a "quote" function to my BB-code editor which easily allows me to quote any text on the page when I type my follow-ups.

With strictly email, the tickets look like a mess and are more difficult to follow.

[AdamVocks]

Valid points...  Thank You

If it isn't inteded for customers to reply to the messages via e-mail, then maybe it would be better to take our the message in the e-mail leaving them no choice but to click on the link.

But I do think the e-mail module provides a layer of simplicity and comfort to end users.  And yes, I agree that operators should and will do what you tell them to do, but I still think it is faster and easier to reply to the e-mail.  Many of our questsions are solved with a single answer so the point about reading the entire ticket while valid for muilti conversation tickets may not be valid for 80% of our tickets.

We're just trying to be efficient.

Adam

[Sparky]

Valid points...  Thank You

If it isn't inteded for customers to reply to the messages via e-mail, then maybe it would be better to take our the message in the e-mail leaving them no choice but to click on the link.

I good way to force it... I've considered it more than once.

And yes, I agree that operators should and will do what you tell them to do, but I still think it is faster and easier to reply to the e-mail.

Sure but then you can't do any of the other stuff at all... like editing or closing the ticket.   

I'm still hesitant to agree that replying to an email is easier.  I think it has way more to do with poor habits than "ease of use".

• Keep a browser window open.
• In that window is a ticket browser list sorted by "updated".
• The 'auto-update" feature is set to 1 minute.

New tickets and tickets with new responses are always floating to the top of the list... an email would never have to be touched by the operator.  Same typing and less clicking.

comparing email response to browser response:

email client => browser
click on email => click on ticket
hit reply (oops - 1 extra step for email)
type message in box => type message in box
hit send => hit submit

[AdamVocks]

It's pretty clear that your operators are in front of a computer all day.

I probably should have stated this earlier on, but my operators are also on-site computer techs who are not in the office most of the day.  They use TTX to take care of our service contract customers and to make sure that requests are not forgotten.  25% of trouble tickets they respond to are from a smartphone when they are not at the office...

And I can open up the TTX web interface from our smartphones but it's not easier than replying to the e-mail.

How's that for changing the scope of the conversation!!!

Let me ask another related question.

Let's assume that my operators reply by e-mail from their smartphones before they get back to my office and I end up with 50 tickets that needs to be closed.  Doesn't it seem like a waste of time to go in and close each ticket after its been completed?  Then it gets even more complicated if some are not completed and now we have to read each of those 50 tickets to make sure we don't close a ticket that's not supposed to be closed.

Thanks for your point of view.  It really is helpful to see what other people are thinking.

Adam

Adam

[Sparky]

Let's assume that my operators reply by e-mail from their smartphones before they get back to my office and I end up with 50 tickets that needs to be closed.  Doesn't it seem like a waste of time to go in and close each ticket after its been completed?  Then it gets even more complicated if some are not completed and now we have to read each of those 50 tickets to make sure we don't close a ticket that's not supposed to be closed.

Agree.

But then again, you're stretching TTX way beyond its intended usage.  It's a browser based solution... not a smart-phone based solution.  Deal with the headaches or get smart-phones with better built-in browsers.  Not trying to be a smart-ass but just stating the obvious.


- This discussion forum, SMF, requires a browser.

- The Google Groups discussion forum is Usenet based and you can also participate in threads via email.

Those are two totally different packages and if you ask me, Google Groups is more difficult to use, search, post, reply and moderate.  And if you want to use the email features, you must subject yourself to an email every time somebody responds to ANY thread.

Point being:  you can't have everything.

Of course, being that TTX is open-source, you could hire a Perl guru to write a custom module that would take the incoming emails and parse out keywords which would trigger actions such as closing the ticket...  However, security headaches such as preventing just anyone from closing your tickets, would be yet something new to overcome.

[AdamVocks]

But then again, you're stretching TTX way beyond its intended usage.  It's a browser based solution... not a smart-phone based solution.  Deal with the headaches or get smart-phones with better built-in browsers.  Not trying to be a smart-ass but just stating the obvious.

The truth hurts doesn't it!!!  We started it browser based, but now we are getting greedy...

Here's my options as I see them.

• Pay Alex to modify the code.
• Learn Perl and do it myself.
• Since my data is stored in SQL and I'm a .net programmer, I can write a windows service that will do what I need it to do.
• I can find another trouble ticketing system.
• Do nothing and live with it.

I'll probably go the route of creating a .net service that looks at the trouble tickets and closes them if there's a {CLOSE} in the body of the message.

It appears to be as simple as looking through the messages for some indicator such as {CLOSE} find the corresponding ticketid in the tickets table and mark status as CLS and fill in a closed date.  Am I missing anything?

I'll be happy to publish my code if anyone want/cares to see it.

[Sparky]

I'll probably go the route of creating a .net service that looks at the trouble tickets and closes them if there's a {CLOSE} in the body of the message.

It appears to be as simple as looking through the messages for some indicator such as {CLOSE} find the corresponding ticketid in the tickets table and mark status as CLS and fill in a closed date.  Am I missing anything?

The "updated" date also matches the closed date when the ticket is closed.  Otherwise, there's not much to it.

Yes, feel free to post any modifications or code to this thread.  Post links to externally hosted files of your creation... however do not post any modified TTX modules for download.... just the edits and locations please.  Include system requirements.

[AdamVocks]

OK, Thanks!

I enjoyed the conversation.

Adam

[AdamVocks]

As promised, if anyone is interested, here is vb.net code that will loop through all the messages in your trouble tickets looking for a close identifier and mark the ticket as closed if it finds one.

You could compile this as a service or as a command line utility and run it from a scheduled task.

Requires data to be stored stored in SQL server but could be modified to work with the text file or mysql.

Code:

    Private SQLServerName As String = "SQL"
    Private SQLServerDB As String = "TTX"
    Private SQLTablePrependName As String = ""
    Private CloseMeText As String = "{CLOSE}"

    Private Sub CloseTickets()
        Dim LastMessageID As Integer = 0
        If IO.File.Exists("LastMessageID.txt") Then
            Dim sr As New IO.StreamReader("LastMessageID.txt")
            Dim strID As String = sr.ReadLine
            sr.Close()
            If IsNumeric(strID) Then
                LastMessageID = CInt(strID)
            End If
        End If

        Dim con As New SqlClient.SqlConnection("Data Source=" & SQLServerName & ";Initial Catalog=" & SQLServerDB & ";Integrated Security=True")
        Dim cmd As New SqlClient.SqlCommand("Select MID,TID,MSG from " & SQLTablePrependName & "messages where MID > " & LastMessageID, con)
        Dim da As New SqlClient.SqlDataAdapter(cmd)
        Dim dt As New DataTable
        da.Fill(dt)

        For Each row As DataRow In dt.Rows
            If row("MSG") IsNot DBNull.Value Then
                Dim strMessage As String = row("MSG")
                If strMessage.Contains(CloseMeText) Then
                    CloseTicket(row("TID"))
                End If
            End If
            LastMessageID = row("MID")
        Next

        Dim sw As New IO.StreamWriter("LastMessageID.txt", False)
        sw.WriteLine(LastMessageID)
        sw.Close()

    End Sub

    Private Sub CloseTicket(ByVal TicketID)
        Dim con As New SqlClient.SqlConnection("Data Source=" & SQLServerName & ";Initial Catalog=" & SQLServerDB & ";Integrated Security=True")
        Dim cmd As New SqlClient.SqlCommand("update " & SQLTablePrependName & "tickets set CLOSED='" & Now.ToUniversalTime & "', STATUS='CLS' where ID = " & TicketID, con)
        con.Open()
        cmd.ExecuteNonQuery()
        con.Close()
    End Sub