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.

We are using ticket statuses since months now and it is working well for us and all inboxes but it would be great to increase the number of customized tickets statuses as so far there is a limitation in Front.

1. Yes, but not familiar with the intricacies.
2. A couple reasons:
   1. We’ve considered using ticket statuses to connect emails in front to records in our CRM (Sugar), but since there’s no connector from Front to Sugar, it would really just increase our workload.
   2. Honestly it would be a pretty big learning curve for some staffers, especially because it would only really be useful in some inboxes.
   3. When it’s been discussed before, there’s a feeling that adding a ticketing system brings an increasingly corporate energy to our team and our work that we don’t love.
3. We’re not using ticketing in any, but some inboxes just see such low volume that ticketing feels like it would be a lateral change.
4. Two reasons:
   1. Lack of an easy connection between Front and SugarCRM is a big hurdle in making tickets useful (if there’s a workaround for this, though, I’d definitely be interested in it).
   2. We have very limited staff time for making big changes like this, and even if we decided it would be good to try ticketing, right now we’re putting that staff time toward changes that reduce the number of emails we get in the first place.

​@allenk For inboxes that don’t need the granularity of ticket statuses, would you mind sharing what kinds of conversations are in these inboxes generally? Is it fair to say that, for these inboxes, ticket statuses simply provide no additional benefit beyond Open/Archived? Thanks!

​@caitlin.crouse Thanks for sharing your feedback on the permissions piece. It sounds like the biggest blocker for wider adoption is the fact that you or IT needs to go in on behalf of each workspace admin to configure the right ticket statuses and groups. Is this an issue primarily because of the upfront setup cost for you, or do these workspace admins end up needing to make additional adjustments to their ticket statuses down the line, which you then need to administer?

I hear you on the competing priorities being a blocker for further adoption today. It’s important feedback for me that the transition to using ticketing feels like a big lift! With that being said, I’m curious if you’ve considered using the default Open, Waiting, and Resolved statuses with no custom statuses for this team?

​@dtos That makes sense knowing your use case. Coming at this from another angle, do you see any harm in a “Waiting” status to bridge the gap between Open and Archived?

​@david_vien You said you don’t use ticket statuses on low volume inboxes. Can you say more about why you only see a need for ticket statuses on higher volume inboxes? If these low volume inboxes had ticket statuses, would that be a detriment?

About task templates that apply to ticket statuses: can you give an example of what you are trying to accomplish?

I’m just not sure what that would really convey to our users.

They’re very, very used to the concept of Open/Archived/Snoozed already. If we’re going to swap over to ticket statuses, it’d need to be for a pretty compelling reason. A Waiting status wouldn’t really give enough information on what it’s waiting on for us to swap to something like that, in my view.

It’s just not something we currently see as a problem that we feel we need to push to change.

For the first question, it’s primarily understanding the nuance of the processes and what statuses are actually needed versus what’s requested plus seeing if any teams have similar flows or process steps that would be able to use the same status groupings. Then I would want to monitor implementation to see if any statuses are being misused or not used at all to tweak the process. 

The main team that I would want to transition was the first I discussed ticketing with when it was first announced. We decided that we wouldn’t be able to do anything until we had custom statuses, unfortunately. 

​@conniechen These are smaller support inboxes with lower volume, but shared among multiple people. One of the top 3 reasons we went with Front is that it didn’t force all shared inboxes into “ticketing” systems and you could just have a shared inbox where people can easily reply to emails, assign them, and archive them.

We would not want statuses for this inbox as they are very straight forward messages where an action needs to be taken and then replied.