Ticket Queue

I feel like we need a better way of organizing tickets by "queues" and reporting on those "queues".

For instance, I want to know if In-shop service queue time is greater than average... I also need a place so that employees all doing the same service type can work tickets as a group - instead of only the tickets that are assigned to them.

Does that make sense?

I know I can do ticket types - and maybe get sort of close, but I feel like that is a work around instead of an ideal implementation. Has this come up before? Any thoughts on this?

Lovejoy, I got around this issue by using employees as queues
I have employee's named "repairs", "new tickets", "job bookings" and "system prep" then assign them as the ticket manager. This effectively gives you a queue although it does cost money to purchase a licence so I can see how this would be an issue for smaller businesses.

Ignore the auto correct on your name there :-)

Yes, we see what you mean. You may also use the Ticket Type field for classification and filter by it, though it is probably not as easy-to-use as with BDTECHRob suggestion.
Thanks. Feedback noted.

lol@lovejoy!

We also use employees for grouping. Costs more but makes our lives much easier.

@CommitCRM - hint-hint - it would be nice to not have to buy/waste employee licenses for this.

Lol, I've been called worse names I'm sure!

It would be great to see a feature like ticket queuing - we use GFIMax integration, and it would be nice to easily filter out tickets that were opened by GFI, vs email or helpdesk vs project work.

Noted with thanks.

Suggested this ages ago: here

They really need this feature. Ours overflows. Wouldn't be so bad if you could add more status's (I know you can rename).

I would love to see some traction on this. If tickets were in queues, then employees could monitor their queues - instead of just seeing tickets that were directly assigned to them.

Alerting & SLA's could be managed by queue as well.

Noted with thanks.

We use a 'new tickets' 'queue' and it works a treat.

We don't associate any email address with it so it keeps it simple.

You just do that with an extra employee license?

We also just purchased another license and named it 'Queue' which has made things immensely easier to work with. Now, all new tickets get auto assigned to Queue and we know at that point that it needs to be assigned to a tech or that action needs to be taken.

Austin

It would also be awesome to see queues implemented. I would like to have a queue for the auto-created tickets from GFIMax, vs tickets emailed to our help desk etc...

Thanks. We're working on something in this direction that will probably be included in a following release (not the coming 6.2).

Ah, really? Great news!! :)

Yes, something in this lines. It's too early to discuss though :-)

We use status and status updates to keep our stuff in order. By reassigning the master status template to:
1-QUEUED
2-Assigned
3-Work in Progress
4-Completed Pending Approval

(literally with the numbers at the front) we are able to use the status for our workflow. All new tickets automatically come in as "1-QUEUED" and all the techs keep an eye on this status (kind of queue if you will). If they are able to, they then grab the ticket and "2-Assign" it to themselves. Managers and also assign tickets as they need. We then use the status extension for more granular communication. For instance, when a ticket is assigned (given to a tech with "2-Assigned" as the status), they then change the status extension to "ACK" as in acknowledgement that they have indeed taken on the ticket. When they start work the then kick it to "3-Work in Progress".

This method does a really good job for us in keeping new tickets flushed out and techs accountable for their tickets.

Let me know if folks are interested in hearing more...

cheers --

//ray

One thing that I've talked about before with this type of workflow processing is the addition of a "Lead Tech", similar to the "Account Manager" -- this would make workflow that much better. These two would be very similar in behavior but the functions and usage would be different. Basically it would allow two different people to be able to track what is going on at an account level -- the Account Manager is interested in seeing more of the big picture while the Lead Tech is interested in taking care of the IT infrastructure... having both types of accounts would help dramatically in keeping track of what is happening at the client level.

//ray

This is all good feedback and we appreciate you sharing it. Thanks!

raymond,

Interesting use of the Status Extension field. I actually never noticed that it was there, so thanks for pointing that out. Since you brought up how you are using the Status and Status Ext fields would you mind sharing all of the ones you have configured?

Thanks in advance

The key for us is that we think of Status as "workflow" and Status Extension as, well... the "status". This is CRITICAL to introducing workflow into CommitCRM.

On the status fields, we have:
1-QUEUED (new tickets, unassigned)
2-Assigned
3-Work in Progress
4-Completed Pending Approval

That's it for the majority of our workflow. Tickets come in and are automatically assigned "queued". Everyone is trained to keep an eye on tickets with this status (it's very easy to do). At that point the ticket can be assigned by a manager or picked up by a tech -- that's when it goes to "assigned". Once work begins, it then goes to "work in process".

This is where we diverge from (probably) what most CommitCRM users do and the main reason why we have been waiting about 4-years for custom contracts. ALL charges entered by a technician are to be marked "non-billable"... this is critical because our bookkeeper runs invoices periodically and anything that is marked as "billable" gets processed as an invoice. More on this in a minute...

So, the tech works on the ticket and decides it's completed. Then then mark it "completed pending approval". This then triggers the "true" account manager (and the reason why we keep asking for the ability to add Lead Tech along with the Account Manager for accounts/tickets) to review the ticket to make sure the problem was resolved, a good resolution as been entered, charges make sense and that everything just looks good. At that point, they then mark all the items as "billable" and change the ticket to "closed"

This process is what helps us make sure that the client is taken care of and everything gets billed. The key to this is that EVERYTHING in our systems eventually gets marked "billable" and "billed". I can elaborate on this more if folks wish.

From there we have:
4-Do Not use (reserved for future use)
5-Internal (internal tasks that we wish to track)
6-On Hold
7-REC-TASK
8-REC-BILL
9-Completed Closed

The special ones above are the 7-REC-TASK and 7-REC-BILL. We use the first for recurring tasks (e.g. weekly/monthly/quarterly maintenance, etc.) and the second for recurring billing (e.g. monthly items). The one bummer is that CommitCRM does not let us re-assign the status “slots” between open or closed (the status groupings) so slot “8” shows up in the [Closed] group for tickets... it would be nice if we could modify this.

The status extension is what we then use to communicate internally about what's going on with the ticket. We have:
ACK (acknowledged)
CA1 (contact attempt #1 -- all contact attempts are documented in history notes...)
CA2 (contact attempt #2)
CA3 (contact attempt #3)
CA4 (contact attempt #4)
FCI (final check in... a state the techs use just before they mark a ticket “completed pending approval” – this is them trying to check with the client to make sure everything is good)
SCH (scheduled)
WFC (waiting for client)
WFR (waiting for results, as in testing)
WFV (waiting for vendor)

One cool feature of CommitCRM is that the status extension automatically shows up in the Status column when looking at lists!

Commit: one thing that would be very helpful here would be to move the Status Extension to the general tab for tickets -- that way Status Extension can be right next to Status (which makes sense to me!).

Hope this helps -- if others start using CommitCRM in this way (for workflow) then maybe it will be easier to get CommitCRM to think this way as well... :-)

//ray

Ray,

That has to be the single most useful tip I have gotten from the forums. I look forward to implementing some type of similar setup here.

I agree that being able to reclassify the customized status's as open or closed would be very helpful. Also having the Status Ext field in the same area as the Status field only makes sense. This is probably the reason that I never really noticed that field in the first place.

Finally the custom contracts are a MUST, MUST, MUST for us. We have never been able to create a contract that matches what we have for our customers. And since what we have with them is simple enough to explain without being overly complicated or with a lot of exceptions it should also be able to be created as a contract inCommitCRM.

Thanks again,
Ed

This topic has been mentioned many times, a lot by myself. imo, this is the biggest missing feature inCommitCRM.

I just noticed that the numbers are off... it actually starts off as "0-QUEUED" then "1-Assigned"... this allows everything to flow alphabetically when sorting on status.

Let me know if anyone needs more information on the above process. This shift in thinking (using status as workflow and having all charges eventually be marked as billable/billed) has allowed us to really get the program to mimic our business processes, allows us to make sure everything gets billed and helps us keep an eye on quality assurance.

Commit, the only items that need to be added/tweaked to make this REALLY viable are:

1) Move the Status Extension field to the general tab = this is what allows us to have both workflow and ticket status front and center.

2) Give us the ability to assign the various Status Values to "[Open]" or "[Closed]" = this is minor but does allow us to customize the workflow better.

3) Add a Lead Tech field to the account/ticket (treat this exactly like the Account Manger field, just with a different name) = this allows us to have a technical manager (the person responsible for the ticket) and an account manager (the person responsible for the client) and each can plug into the ticket as needed. I understand that this isn't necessarliy trivial to implement but would allow the program to support firms with multiple levels of support/managment.

4) Add custom contracts...

Thanks!

//ray

Thanks, Ray. Your suggestions will be reviewed.

Ray,
I had no idea that the Status: Ext would show up in the same column as the status. That's pretty cool - thanks for that tip!

Commit,
Now that I've been playing with this - I really wish you could see "Status: Ext" changes in the audit trail. It would be really nice to be able to see when something went from "P2-Part Quoted" to "P3-Part Ordered".

Thanks!

Noted. Thanks.

On a side note, is there any reason that the Status & Status Ext fields are on two different tabs? They both show on the new ticket creation screen - which is nice. After that, though, they kind of get lost.

lol, just looked above and see that is something Ray already suggested. I'll post anyway for the +1 effect. thxn

Two reasons mainly: Most people do not use it and it would have created more 'noise' for them. The other reason is lack of native space to put it there.
Anyway, we get the point here and we will consider how to make it better. Thanks.

If it helps, I never used it because I didn't notice it since it was on a different tab :-)

Guys you are aware you can add a custom Tickets Tab and arrange all these fields however you like aren't you?

I know this is an old thread

we use almost exactly the same method and Raymond minus the Status extensions.

I cannot seem to copy or move this filed to the General Tab. Has anyone done this? Do I need to build a custom tab.

Commit Guys. Can we ditch the Priority field and just replace it with the colored labels. it would be easier on the eyes and we would gain the field for the Status Extension

icle

Version 7 kinda solves this with labels. One of the best changes we've seen in some time.

Would still like some way of added more statuses though.

@PC MedEvac,

Unfortunately currently there is no option to add/move Status extension to the General tab or remove Priority field. We are aware of this request so it will be considered for a future release. Thanks.

@Hayden, you are right and thanks for your feedback, it's great to hear that you like this new feature :-)
The new labels feature introduced in RangerMSP 7.0 can be used instead of Status Extension.

As for adding more statuses - currently there is no such option, we'll see.

At first, we did not like labels all that much but we are now warming up to them. Please note that labels do NOT replace the function of Status, Status Ext., Priority or Type... each one of these serves a very specific purpose and function:

Status is used to track workflow on a high level. We have customized this so that it tells us if a ticket is Assigned, Work in Progress, Completed Pending Approval, On-hold, etc.
Status Extension is used to track what is happening at a more granular level. We have created lists (codes) that tell everyone if "something is being tested", "we are waiting on someone to do something" (e.g. the client or vendor), or if we have attempted to contact the client, etc. -- these are sub sets of the Status... (!)
Priority seems pretty self explanatory...
Type is used to tell us what "kind" of ticket this is. Is it's purpose to order PRODUCT, work on a PROJECT, is it a recurring TASK or perhaps a recurring BILL(able) item, etc.

Where we see labels fitting in (and where we are implementing them) is to flag the type of client and contract that a ticket came in on. This is kind of like "importance" but is more general than that. For instance, we are now using labels to indicate which managed services level they are on (L1, L2, L3, etc.) or if for some reason, we temporarily need to pay special attention to them (VIP). We are also using the labels to flag tickets that are assigned to certain "project contracts" so that we can treat them differently, etc.

So, we certainly don't want to see any of these fields go away or hide. In fact, what we would like to see is:
1) Status Extension be moved to the general tab.
2) The ability to assign (the same) colors to the Priority, Status and Type fields as well!
3) A bit more flexibility with the Status field, including the ability to add more and assign them to the open/closed categories accordingly.

cheers!

//ray

Absolutely brilliant posts. I apologise in advance if I am hijacking this post, however we are in big trouble with our customers since moving to CommitCRM. What are you guys doing to notify/alert customers on charges/changes to tickets while they are being worked between opening & closing the ticket.

CommitCRM only sends customer alerts on opening & closing tickets.

Thanking all of you for this post once more.

Well Kevin I find the best way to update clients is picking up the phone and speaking to them. Good customer service revolves around good communication, you won't ever achieve this by using auto responders and status change updates.

Hi BDTECHRob

Thanx for responding and agreed that customer service is paramount. Unfortunately our previous antiquated ticketing system had update notification by email and our customers are used to this feature. The other problem in South Africa is that local calls are not free and the costs would quickly add up. We will continue trying to invent a workaround.

We have added custom email templates which might be of use (they are easy to send from the ticket drop down in he toolbar and get attached to the ticket as a history note). Create a "Ticket Status Update" template and have the tech manually kick off a notification when they think it is a good idea to update the client (they should add a short note in there before sending). We have quite a few of these template emails and use them often.

On this, we would definitely NOT want clients getting notifications every time we made a change or charge on a ticket... we don't want them knowing everything we do and they would be inundated with spam!

//ray

Kevin; we have template emails that we can right click and send... here's an example

http://iforce.co.nz/i/5i4eowk5.ldf.jpg

24 hour example

http://iforce.co.nz/i/jdacyhxa.wfl.jpg

Just need to train your staff...

You don't want to spam the crap out of your customers :)

+1 for an excellent thread and +1 for the Status extension

Coincidentally enough we have literally implemented a very similar process to this in the last few months or so (have been using CommitCRM 2+ years/long story why hadn't done earlier but really see this as THE way a helpdesk should 'work')

Equally didn't really see the importance of Labels (considering how many other pressing matters there are to get sorted with CommitCRM listed throughout these forums - but all credit to Commit they are definitely listening and moving in the right direction!) but we too are warming to them and it's most definitely good to have a bit of colour going on as trivial as it may seem!

(and yes email templates are VERY handy...)