Feature Request - Reopen Tickets

JosephWithCOR

The difference between On Hold and Closed is a line. If you miss and hit Respond before your eyes catch up, you can't go back.

I fielded a phone call. Entered the ticket, went and did the work, and closed it before tagging the asset.

Because I can't reopen the ticket, I can't fix my mistake.

johnny

@wrongecho and I discussed this before, but it may be worth taking a second look

wrongecho

Maybe like an extra confirmation popup when you hit respond when close is selected?

JosephWithCOR

I know it was discussed before and the reasoning is valid.

But, there are those times when you have a valid reason to reopen a ticket.

wrongecho

JosephWithCOR

Do you recall where we discussed this / what the reasoning at the time was? The only bits I can think of relate to tracking closed tickets but we do that properly via the timestamp now so it shouldn't be an issue?

i7phillip

Hey again, nice find with this thread. Blockers aside, what does the workflow look like to you if you could reopen tickets? Should this be configurable as some people want it and others don't? Do we only allow agents to do that? Do we allow clients / any email to do it? Should there be a time limit or should users be able to reopen tickets from a year ago, potentially even if the agent no longer exists. Should this ticket then be excluded from stats because your time to resolve stat would go through the roof?

How should we account for users reopening tickets with a "Thanks" and then getting annoyed they have yet another "Ticket closed" email.

These are genuine questions I'd like to think about before we change this.

johnny

Maybe we could give admins only the ability to reopen a ticket? or maybe the ability to just modify certain aspects of the ticket.

JosephWithCOR

If you would please put some thought to it.

In this case everything is entered, I just missed the asset.

I had another this past weekend doing updates, thought I put the ticket on hold and sent note because I had to come back to it, ended up closing it before the job was done. I had to make a second ticket to finish the work.

Granted, it does bump my ticket count and helps to justify my meager existence.

johnny

love ticket bumps hahaha

I think the real problem here is selecting closed when replying,

Maybe lets start by removing closed from the status dropdown below ticket reply and just use the button the right for closed.

adestrella1027

I do have polite customers that on occasion thank me for resolving their problem though email. I presume that would generate a new ticket where the solution would be to reply and delete?

wrongecho

adestrella1027

No, replies to an existing ticket get an auto response telling the user that the ticket has been closed and their reply will not be read. The email remains in the inbox for manual review.

i7phillip

This seems to be a common request. Most ticketing systems I have worked with, both as a tech and as a user, allow for tickets to be reopened. Why can't this be done with ITFLOW? We currently use WHMCS, however, we like the idea of being able to assign assets to tickets, which WHMCS does not do. But, with WHMCS, we can easily reopen a ticket or if a customer replies to a closed ticket, it will reopen it. Why does ITFLOW refuse to allow this option?

i7phillip

wrongecho The way it currently works in WHMCS is a technician can reopen a ticket or a reply by the customer can reopen the ticket. To prevent the customer from receiving another "Ticket closed" email, there could be an option that would allow the technician to say "uncheck" a box that could say "notify customer of closed status" or something to that effect. These settings could also be configurable based on company policy in the admin center by an admin. A simple "Allow closed tickets to be reopened" option would, IMHO, make everyone happy. You could either use it or not, but the option is there to do so if that company wanted to.

JosephWithCOR

@wrongecho This was the last time I brought it up https://forum.itflow.org/d/879-working-with-tickets-sanity-check.

It was a hard no here https://forum.itflow.org/d/549-ability-to-re-open-a-ticket

I believe this is where this particular post started https://forum.itflow.org/d/218-working-with-tickets

This morning my google-fu seems to be lacking. There have been several older discussions on this board which I believe have been consolidated into future threads which might be breaking the search.

You guys have valid arguments to not reopen tickets. Completed work. Every issue should be a new ticket. I agree.

I also, just like everyone, have muscle memory that acts faster than my eye is capable and have closed tickets prematurely. But, the more tickets I have, the more productive I look! (Even if they are not completely accurate.)

I am sure everyone here can make a valid business case (bingo) or justification for reopening tickets. When I make a request, I try to justify it. Sometimes I am successful. Sometimes I am not.

If you are asking, my vote would be to make it configurable for every reason given. If so, I would also suggest by supervisor approval. Gotta make them earn their money too!. This should help to prevent the reopening of tickets with "Thanks". As the supervisor I would be responsible for reopening tickets with justification for my techs johnny or wrongechot.

In my opinion "time limit" should also be configurable from the date of the first close because it might be based on an arbitrary warranty period. Sometimes they just don't want to stay fixed.

How is the "time to resolve stat" computed? Is it arbitrary based on start date to closed date? Or is it based on ticket time? Some combination of the two? If it is based on start to closed date, that would blow your stats. If it is based on entered ticket time it would give a more accurate time to resolve because extra time was invested to resolve the issue.

For what it is worth, my two cents.

alphaTECH

I just accidentally closed a ticket I shouldn't have. What's stopping me from re-opening it is someone else's personal preference. That's not right.

wrongecho

Appreciate all input on this thread, specifically your detailed message @JosephWithCOR

For now, I've proposed to @johnny that we just change the flow of closing a ticket instead. Reusing the existing system status of "Autoclose" (renaming to "Resolved") we'll just have a process whereby a ticket has to first be resolved and is then closed. Whilst a ticket is in a Resolved state, it can be re-opened. After 72 hrs, it will move to a closed state and cannot be reopened (via cron). (TODO: Reporting needs to be adjusted to work off the resolved_at too).

I think this accomodates for closing issues accidently / too early, but prevents silly things like a year old ticket being reopened with an unrelated issue. Whilst I like the idea of a supervisor approval, we'd still have the outstanding request that users be able to reopen tickets.

Fully appreciate we can't make everyone happy here (or ever!), but appreciate your input nonetheless.

This issue isn't really a personal preference of mine, but a limitation of how complicated we want to make ITFlow; our methodology has always been to keep things as simple as possible. You only need to look at the Bug tag on the forum to see how every new feature/function will eventually break something else. If you really wanted, you could probably use the API to re-open tickets (or just edit the database direct). ITFlow is open source which means that you can always fork it (or get someone on Fiverr) to adjust it to your specific needs (just don't expect support from us! 🙂).