Ticket Queue

[Support Team]

Re: Ticket Queue

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

[lpopejoy]

Re: Ticket Queue

Ah, really? Great news!! :)

[Support Team]

Re: Ticket Queue

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

[raymond]

Re: Ticket Queue


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

[raymond]

Re: Ticket Queue


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

[Support Team]

Re: Ticket Queue

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

[AN-Tech]

Re: Ticket Queue

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

[raymond]

Re: Ticket Queue

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

[AN-Tech]

Re: Ticket Queue

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

[hayden]

Re: Ticket Queue

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

[raymond]

Re: Ticket Queue

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

[Support Team]

Re: Ticket Queue

Thanks, Ray. Your suggestions will be reviewed.

[lpopejoy]

Re: Ticket Queue

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!

[Support Team]

Re: Ticket Queue

Noted. Thanks.

[lpopejoy]

Re: Ticket Queue


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