Your thoughts on ticket statuses

1. Yes
2. Currently using
3. Some of our shared inboxes just don’t need that level of granularity. They only need open/closed due to lower volume.
4. No

I was very excited when I heard about ticketing when it was announced. I’m a company admin and we manage some complex workspaces. The inability to customize statuses then having customizations only at the company level were early blockers to usage. We recently had a new team switch to Front and they will be testing out ticketing with custom tickets for their workspace.

I don’t really like that a company admin has to configure the ticket statuses since I'm the only company admin outside of IT. I think workspace admins should be able to manage their own ticket statuses and that makes me hesitate to try to scale this company wide - each team is a little different. 

At this point, I have at least one team that may be able to benefit a great deal from ticketing, but we’re having bandwidth issues and other priority issues that make any new transitions feel impossible. While the feature may actually work as we may need it right now, it’s not likely to happen without addressing other priorities first. 

1. Yes
2. Our conversations are very, very multifaceted. It’s pretty rare that there’s only action that needs to be taken on a Front convo
3. We’re not using them
4. Since there are so many different action items (or a combination of action items) that a Front convo could require, there isn’t really a viable way to contain all of that within a simple status line. There could be 10-15 things that need to be actioned on for any given conversation, and if we were to group them into a “Needs action” status, it wouldn’t be helpful because it’d be too generic. 

Were you aware of ticket statuses before today? Yes

If you’re not using ticket statuses in shared inboxes today, why not? We are using them across most inboxes 

If you’re using ticket statuses in only some of your shared inboxes and not others, why is that? Some are low volume 

Based on the information in this post, are there any reasons preventing you from using ticket statuses in the future? It would be very useful to configure more custom tickets, and be able to apply them to multiple inboxes easier. An extra plus, is being able to configure task templates that auto apply to ticket statuses within each inbox.

We have custom statuses enabled and find them very useful HOWEVER, I very much dislike that even though these ticket statuses were created in the “Waiting” stage, if they are used they archive the ticket, which causes all the automations we’ve built for the archive stage to kick in.

Waiting statuses always require follow up from our team at some point, depending on what they are waiting for. My team has been trained to close using >Snooze>Status During Snooze, but I would strongly prefer these status only be available when a ticket is snoozed OR that the tickets remain OPEN and not archive themselves.

Were you aware of ticket statuses before today?
Yes.

If you’re not using ticket statuses in shared inboxes today, why not?
I honestly wish this had been available when we first implemented Front. At this stage, migrating our current process into Front’s ticketing system would require a significant operational overhaul, and we’re not prepared to take that on right now.

If you’re using ticket statuses in only some shared inboxes and not others, why is that?
If we were to use ticket statuses, I could see us intentionally not enabling them on backend administrative shared inboxes that aren’t actively managed.

Based on the information in this post, are there any reasons preventing you from using ticket statuses in the future?
The main blocker would still be the operational lift. Adopting ticket statuses would require us to rework workflows, retrain the team, and migrate existing processes. Because of that, we wouldn’t be considering a move to the ticketing feature in the near term.

We use ticket statuses and they work well for us! The biggest pain right now, though, is how they interplay with rules. 

What I’d love to see is rules that are status-aware.

Right now, we use internal “nudge” comments when a ticket has been in a Waiting status for X days. The problem is that if the ticket moves back to Open before that timer runs out, the nudge still fires. That means unnecessary internal comments and a bit of noise in the queue.

In an ideal world, when a ticket transitions from Waiting to Open, any rule tied to that original Waiting state would automatically cancel and the status change should invalidate the timer.

The same issue shows up with external reminders. I’d love to automatically follow up with customers after a set amount of time if we’re waiting on them to reply, but if they reply before that timer is up, the reminder should not go out. There doesn’t seem to be a way to conditionally cancel that scheduled action today.

In short, we need rules that respect state changes and stop themselves when the underlying condition no longer applies. Right now, automation is technically working but operationally noisy.