Add ticket status to subject of emails

[thnilsen]

We're looking at setting up OTRS to replace another less functional helpdesk package.

We have a desire to add the current status of the ticket to the subject/title of the email being sent to the customer. I've searched for a solution to this but have so far come up empty handed. Has anyone else implemented the status field in the subject field of outgoing emails?

I've started to play with /Kernel/System/Tickets.pm and the TicketSubjectBuild() function where I would expect the ticket stauts to be available in $Param{Type}, but this does not appear to be the case. I'll play some more with it to see if I can figure out a way to get the status. But it would be nice to know if someone already has a solution for this.

Regards,
Thomas

[crythias]

Think about the process that would require notification of different states.

The customer doesn't need to know anything about the status ... it's open until it closes, and at that time, you can use a reply or notification (Event) on ticket close with a different subject that includes the word "closed" manually. Even the transition from new-to-open is not of interest to anyone. A state change is not of consequence to the forward progression of the ticket; it is merely a different bucket in which the ticket sits.

If the ticket is pending, the customer doesn't need to know this, but the agent will get pending notifications.

If the ticket is closed, the agent probably knows this already (Usually the agent-owner is going to close the ticket) and, generally, no other agent needs to really know about it. They won't be notified unless a notification (Event) is applied.

[thnilsen]

It's only on replies to customers I would like to use this. I guess it more a matter of courtesy rather than what's "needed". Many servicedesk solutions will include the current state of a ticket when the customer gets a reply. Manually adding the current status to a ticket works - but should not be needed on an advanced system like OTRS and will easily be forgotten in a hectic day's work.

I would expect to see status notice when replies are sent to customers on the following states:

-> Open / In Progress
-> Awaiting customer feedback
-> Awaiting 3rd Party
-> Closed

New to Open would be of interest to the customer as it would indicate that the ticket has been actioned in some way.

One way to do it would be to use the Event Notification, but that would add a second email to every reply an agent makes to the customer and should not be needed. I'll dvelve into the code a bit more to see if a solution can be found.

Regards,
Thomas

[crythias]

You want to spam your user with internal changes?

If an agent replies to a ticket, the ticket could be assumed to be open/in progress. Notifying the user of that is redundant.
It would be assumed that the body of the ticket is indicative of awaiting customer feedback... The agent asked a question in the body. Changing the status to "Awaiting customer feedback" doesn't need to generate a separate email (Notification Event) but even if the state is currently "Awaiting customer feedback", why do you need to tell the customer that when you just asked the customer a question? And why tell the customer this by a notification email? An agent should ask again...
Awaiting 3rd party ... Again, why does the customer need to know this by automated email? Or why is it necessary to indicate this state in the subject? The only way that a customer should be informed about this is if the agent creates a response that tells the customer this, if it's necessary to do so. "Hey, we're waiting on a part..." But the status of the ticket is an internal flag.

Closed: The only time when this makes sense. The proper way to handle this is the same as above: Reply with next state closed.
But if you must.

The mere act of changing anything on the agent side should not spam the customer.

[crythias]

One other thing ... the subject line does not get pruned of the status upon reply. The customer will be replying with a subject line that includes the status (or other non-title related trivia). This also hurts a customer when s/he's grouping by subject in her/his email account.

[thnilsen]

It clear that we don't share the same view on this issue. My idea is that the status will primarily only be included in agent generated emails to customer - as when hitting "reply" on a ticket. It is exactly to prevent spamming the customer that I do not want to set up notification events for this purpose.

I've managed to do what I needed to do and currently the ticket status is appended to the subject field when an agent updates the Next Ticket State in the AgentTicketComposeReply module. It is implemented as a javascript event on change of the Next State ID. Simple and effective.

Your last point about grouping of tickets is valid - which is why the status is not appended to the beginning of the subject line.

Case closed.

Regards,
Thomas

[crythias]

Your last point about grouping of tickets is valid - which is why the status is not appended to the beginning of the subject line.

so then what? a customer has, instead of one subject, multiple subjects for every appended status?
My group by conversation relies on a static subject. If you keep changing that on me as a customer, I'll possibly lose the thread.
Don't forget, you can still include this information in the body of the message...