Using Front as an Internal IT Ticketing system

It's nothing special for ticketing, but it sure beats free Spiceworks. We migrated last summer as the first adopter for Front at our company. We have a team of four, and three of us needed licenses for support purposes, so paying for one user to have a better ticketing system for the whole team made sense, but otherwise I wouldn't necessarily say it's the best value.

I like what @alexo had to say, so I won't repeat that.

Because we're a small team with a daily average of only like three tickets, there's not much to it. I look at most tickets as soon as they come in and end up handling a large portion of them right away. We've created subtags for a few different categories like department, facility, hardware, software, type, etc. We don't go crazy on metrics because we don't need to, but that gives us a little bit of data for noticing trends. So when a ticket comes in I typically tag it right away and either handle it or assign it to someone else. This helps the rest of my team spend less time in Front.

If there's anything notable about a particular ticket, we can leave it in a comment. Collaboration in comments feels very natural as well. We reply as needed, but have opted to use send as our default instead of send and archive, which screws up the metrics but keeps the tickets in front of us until they're resolved. This works because we never have more than 3-5 open at once. However, the snooze feature is great and if we had a lot of tickets I could see us taking advantage of that more. Resolved tickets are simply archived, but if we wanted to get more serious about tagging, it's possible to make a rule that unarchives tickets if they don't have tags yet.

One other nifty thing is the ability to apply tags based on sender and message content. That does a lot of work for us. If we had a specific person assigned by keyword or sender, that could work super well.

One thing Front really sucks at is groups. If you want to assign a ticket to a group of people, you have to choose between load balancing and round robin. You can't just pawn it off to a group and let the first available agent nab it. I suppose the solution would be routing it to a different inbox (or perhaps a tag and view) for that specific group and leaving it unassigned.

It is possible to add multiple teammates as subscribers to a ticket via rules (including making a fake @group function by text parsing), and that will add anyone who isn't currently marked as out of office. That works alright, but if you use this as a way to inform multiple agents about a specific ticket, each of them are permanently subscribed to it unless they remove themselves. I really don't like this approach because in most cases, if a ticket gets archived, the other agents really don't need it sitting in their shared with me view. That's just creating extra work for them to sift through.

So, if you have super well defined teams for very specific areas of support, you might want an inbox for each, but otherwise it's nice to keep it all in one. You'll want to think through the downsides of each approach before you commit to it.

In all, I've found Front to be a really good makeshift ticketing system for small teams, but if I walked into a new job tomorrow and was told we needed a new ticketing system, I'd shop around before suggesting Front. We're in it though, so any future experience you have to share I'd definitely read if you post here.

It looks like I can’t edit my reply, but I forgot to mention that-- at least for M365 channels-- it takes 1-3 minutes to sync inbound messages from Outlook to Front. While that’s hardly a big deal, it’s an objective disadvantage towards providing the fastest customer service experience. In IT, sometimes that matters.

Hi @evan_zaske ! I am Front's Director of Corporate IT, and of course, we use Front for IT Support at Front, and for us it works great! For context, we get a fairly low volume of tickets (~120 this month) and are a team of four.

My first piece of advice to you is to not get too hung up on what you may know from experience with more traditional ticketing systems like Zendesk — while some of the things you may be used to (i.e. ticket numbers, statuses, etc.) are helpful, in the last two years I've realized they don't really matter and Front's way of doing things has worked great for me.

1. Ticket Numbers — I think as IT practitioners, we're all used to tickets having a ticket number and referencing that everywhere ("Hey, can you please go look at INC-34238"). Because Front's shared inboxes are so collaborative, I never find myself sharing ticket numbers with other people when I ask them to look at a ticket. Instead, I just mention them into the conversation, and we collaborate directly there. If you ever need a "ticket number", you can grab the conversation ID from the kebab menu in a Front conversation (top right).
2. Statuses — Having come from traditional ITSMs, I thought purely in the mindset of ticket statuses and thought that Front wouldn't be able to do what I wanted without them. So, I initially added a ton of tags (New, Open, Pending Customer Response, Resolved, etc.) and tried to force Front into being a traditional ITSM. What I've found is that they didn't really add much value, and in fact, made handling a ticket more cumbersome. What I've found FAR more valuable than status tags (category tags are great) is the ability to snooze a conversation for later. Additionally, within the next few weeks, I'll be moving our team completely away from status tags and to conversation stages, which is built-in to Front, provides out-of-the-box reporting, and takes away a lot of the pains of manually tagging statuses. Two reasons why I think snoozing and conversation stages are way better than using tags for statuses:
   1. We tried to use a "Pending Customer Response" tag to auto-trigger reminders that we're waiting on the user using on a workflow in Front, but found that to never be perfect. Not because of Front, but because life happens. Maybe a user is out sick, on PTO, busy with other things. I'd much rather just snooze a ticket until I know we can handle it (or just close it), than have to tag and continually rehandle a ticket when a user needs a few more days.
   2. We have a tag "Resolved" that we use when a ticket is resolved, and that triggers an email to notify the user we closed it and a link to a CSAT survey. The problem is, and I am SURE you've run into this as well, often times users reply to say thank you, which reopens the ticket, then you have to solve it again. By moving to conversation stages, Front will determine that a ticket is resolved if the message is archived and I am the last responder, and then we can create a rule that sends a CSAT survey X hours after a message is considered resolved. In my opinion, that's a much better workflow than I've seen in ANY ITSM tool ever.

So now, with your mind hopefully a little more open, let me tell you some other things I'm really excited about with Front that we're rolling out internally in the next few months for IT Support (I know other teams at Front are already using it, I'm just a little behind!)

1. I've mentioned Conversation Stages a few times — I think this is not only going to make us more efficient, but it's going to mesh nicely with Front's built-in analytics, giving me better insight into my team, our capacity and how we'll we're serving our internal customers.
2. Dynamic Objects — I am very excited on Dynamic Objects, and we've already set up two that we are actively using. One of them is an integration with our asset management tool, so if a ticket comes in and we tag it as hardware-related, we automatically get information about the user's assets (make, model, serial, uptime, OS, age, etc.) directly in the conversation thread without having to go look elsewhere. The second one is an integration with our identity provider, providing us useful context such as the user's manager, title, department, location, etc. Both of these in tandem came in useful recently when a user requested a new laptop — Immediately, I could see they were eligible for a refresh, and they were remote, so I had to ship it to them, without looking anywhere else.
3. KB / Message Templates — The IT Team is going to be moving our knowledge base to Front KB, which will allow us to attach/embed knowledge articles in our responses more quickly. Likewise, we're going to build out more message templates to help us respond more quickly to our users.
4. AI Tagging — We're already using AI Tagging, but our models are getting smarter by the day, and I'd love to start using tags to help trigger some auto-responses/knowledge deflection. (i.e. if a message is tagged with a laptop refresh tag, Front could automatically send that user our guide for preparing for a new laptop — backing their files up to Google, saving bookmarks, etc.)

With all that said, I'd tell you to start small and build from there. If you try to force Front into being a traditional ITSM the way you were taught an ITSM should be, I think you're going to do a lot of unnecessary work and probably give yourself some headaches — as I did myself!

Use Front the way it is intended to be used with features like conversation stages, tagging (for the category, not status), dynamic objects, routing, etc. and over time, I think you'll find a lot of really cool ways to use Front for your IT Support needs, and I think it will serve you very, very well.

Hope this helps!

@gregkn thank you so much for the insights. We found that our users didn’t like the noise of autoresponders on ticket creation, assignment, and closing, so the only thing we added with Front is a short, templated reply when something comes in before business hours. It’s reassuring to hear that the simplicity we’ve implemented with Front still scales to a size like yours, and I trust it will only get better if we can spare the resources to integrate as you have.

Happy to help @samsheridan! I’ll be the first to admit that I definitely did not implement Front the best way when I first rolled it out for IT support because I tried to force it into being a traditional ITSM and just made it too complicated. 

My team and I are spending the next quarter backing ourselves out of that and implementing Front the way it should be done, and the way I described above! I’ll be sure to keep you all updated with all the cool things we do.

I agree, I think the autoresponders on tickets can create a lot of noise and don’t deliver the value I think we’re all trained to believe they provide (other than giving the user confirmation that their support request ended up somewhere, which I am sure some appreciate), but I think you’re using them correctly.

Another creative use of autoresponders could be for IT-related announcements. For example, we just rolled out an app request catalog internally, so I updated our “ticket received” auto-responder with an announcement about the app catalog and redirecting folks there. So far I’ve already seen a few tickets where folks see it and then reply to the ticket “nevermind, I’ll submit through the app catalog!”.

​@gregkn  Your replies in this thread are very helpful with what we were hoping to accomplish and have enlightened us to think differently in our ticketing approach.

​@DShultis Glad to hear it was helpful! If you haven’t seen it, I did an updated write up a few months ago about how our usage of Front has evolved over the last year. Definitely check it out and let me know if you have any questions!