I want to set my system up so that when a ticket is assigned due to Claim on Response, an email is sent to let other agents know who has claimed the ticket.

At the moment I have a Support department and a Level 1 Support team. All agents are in both the department and the team, but no email is being sent.

Claim on Response is enabled

All team and department members have the Alerts checkbox checked on the relevant screens (Agents > Teams > Members / Agents > Departments > Access)

I am using version v1.10 (901e5ea) of osTickets

Any help would be appreciated

There is no email alert to the User when an Agent claims a ticket.  They would need to update the ticket thread (like using a canned response).

There is no setting for that, mostly because if they can see the ticket, they can act on it.

I needed my agents to see most tickets, but not act on some, didn't want sales processing orders twice etc.

So I wrote a plugin that achieves that goal, without email, https://github.com/clonemeagain/osticket-not-yours-plugin

The not yours plugin tells agents "This ticket is not yours!" Combined with lock-on-view, it works well.

I need to add that to the readme.

If that's what you are trying to achieve, good. Otherwise, maybe tell me what you're trying to do, and I don't mean "trying to send agents email on every claim", why? So they can tell? They can see the other agents message right?

Thanks Grizly, much appreciated. However your plugin, though very useful-looking, doesn't address my issue.

I just need all the agents to be aware of who is responsible for what ticket. We're all working in a shared office, with people leaving for meetings, being out half a day or a full day and we all know the clients who will be submitting the tickets. Some tickets will be important to act on quickly by *someone* (just based on the submitter and the type of ticket), and if the agent who claims it then has to leave for the afternoon, everyone else will know that there is an important ticket not being addressed and can take over.

I know that tickets can be transferred, but that may not be the correct course of action. If someone has to leave in a hurry it may not be possible either. It's just much better for us if there is general awareness when tickets get claimed.

Sounds like you've got the opposite problem then, might make sense for your department manager to unassign tickets for people who are leaving for the day, I'm under the impression that they'd be letting someone know when they go.

The problem with getting an email every time someone claims a ticket would be that you'd rapidly learn to ignore them.

It would just happen all day, who would want to remember all of them?.. when it could do it for you!

We'd have to change it to email on claim anyway, so maybe a more efficient change would be better.

Maybe you mark tickets that are claimed but the agent who had claimed it is no longer active in a different colour? Let the system keep track, but with a gap long enough for lunch etc.

For instance, if you've made no actions or page loads for 30m, the system could simply drop your claims, it could increase the priority, change the SLA, assign someone else or the whole team.. likely a simple change of colour would be enough though.

It may be a little naive to do just that though, it would drop all claims overnight or weekend etc.. hmm.

Maybe we detect the number of concurrent sessions, if more than one, we can assume it's work time and then start changing things for assigned tickets with an agent who isn't signed in..

Have a think mate, if you're still sure getting an email every time someone claims a ticket is the way your team would work best, I'll have a look and tell you what you'd need to change to get that to happen.

I appreciate your efforts, Grizly :-)

Maybe some context will help:

1. I'm just starting out with this system - it's being tested at the moment to see if it will do what we want.

2. We're a web-development business and we are looking to use osTickets to streamline how clients submit requests for support after projects go live. We get a lot of requests for small changes to presentation, content, functionality etc., as well as some bug reports, but not so many that there would be a constant stream of alerts.

3. We were hoping generally to only have to log into osTickets under one of two conditions: A - an alert is sent that needs action; B - we need to communicate back to the client on a ticket.

4. Related to 3, we didn't plan on having someone/everyone logged into the system to manage tickets - we're a small office with a fairly flat authority structure and the idea was that awareness of who was doing what would be enough to ensure that everything got done.

That initial info - that someone has responded to a ticket - would go a long way for us. We're going to use a very short SLA time (4 hours) so that tickets can't go unclaimed for too long without a warning. That way notifications arrive of a new ticket, everyone sees when someone responds to it, and if nobody responds within half a day, an alert goes out to say it's overdue. At that point someone in a more managerial role can decide to actually assign it.

In most cases, just the name of the ticket-submitter and the help topic would be enough for people in the office to know who should respond most of the time, but if there is no system to let everyone know that a ticket has been claimed, then we're in limbo - an alert comes through to say that a new ticket has arrived and we have to sit around talking about it to make sure it's dealt with. Otherwise everyone has to log in individually to see if the ticket was claimed or not.

everyone has to log in individually to see if the ticket was claimed or not.

Yup.

What's wrong with that? They have to do that with email anyway, so your moving the problem, while adding accountability and metrics.. which is what we use a ticketing system for.

You're a web development company? Sweet, you've probably got a team of people to help you!

Write a Reply...