The SLA system explained with example implementation

[Matthew]

I, too, have descended into the documentation-less snake pit that is home to SLA's, Escalations, and Ticket Statuses. I think I can now explain, more or less, how it is *supposed* to work. Note, however, that if you are still using v3.11.01 stable without the recent CVS updates to modules/tickets/functions_ticketscore.php, there are bugs that take a lot of the power out of the system. Update that file!

The basic function of an SLA is to assign an expiration time (or due time) to an incoming ticket. 'Incoming' in this sense does not only mean freshly opened tickets; it could also mean tickets that have a status of, say, 'On Hold' or 'Waiting'--or any other status you have defined. This means that you can have different due times for different parts of your work flow.

SLA's assign a due time to a ticket by filtering tickets by Department, Status and Priority. These filters form a logic statement that reads like this:

"If this ticket is for Department X AND is of Priority (A, B, OR C) AND has a Status of (D, E, OR F), THEN give it an expiration time of Y minutes AND assign it schedule Z."

In order to avoid conflicts between SLA's, you'll naturally want to make sure your defined SLAs' criteria do not overlap. For example, you would not create two SLA's each assigned to the same department, and applying to the same Statuses and Priorities, and give them different expiration times. How would the ticket 'know' which SLA it is supposed to adhere to? Automatic error checking for this would be nice, so that you don't create conflicting SLA's; but that's probably complicated to code, so it's up to you to make sure your filter rules do not conflict.

Once your ticket has entered the SLA 'room' and found a matching policy, it now has an expiration time, and it's internal 'clock' will start to count down to zero--but 'ticking' only during the hours of the schedule you have attached to the SLA. In effect, your ticket will now sit there under its current Status (Open, Waiting, On Hold, etc.) until either:

1. the ticket's 'clock' expires (shame on you!), or
2. the ticket's Status changes because (in one way or another) you or your staff are addressing the issue.

When the ticket's clock expires, you now have the option to apply an Escalation rule so that the ticket gets somebody's attention. Escalation rules apply to a specific SLA, and only when that SLA's timer reaches 'zero'. Escalation rules allow you to do 4 things, singly or in any combination:

1. move the ticket into a new department
2. assign the ticket to a specific person
3. change the Status of the ticket
4. change the Priority of the ticket

When a ticket's Status changes for whatever reason, things can get really interesting. This is where the power of the SLA system resides...

What happens next depends on two factors:

1. a setting in Tickets>Manage Statuses>StatusName for the status the ticket is moving to or from.
2. whether the ticket's timer is already at zero (or has no timer). Note that if the status has been changed by an escalation rule, then this will certainly be the case, since escalations only happen upon timer expiration.

The setting I mentioned in Tickets>Manage Statuses>StatusName is called Reset Due Time On Status Change, but I think a better label would be Reset SLA On Status Change (and I advise the developers to make this change for clarity's sake). Because the idea is not to reset the timer to what it was before, but to check to see if this changed ticket should not follow a different SLA (which could have a shorter or longer due time then the one to which it was previously attached).

Setting this option to 'yes' should cause the ticket to be 'kicked' (again) into the SLA arena, where it 'searches' about (once more) for an SLA that matches its new set of criteria. Finding one, it will start a (new) countdown. If it can't find one, it will take the default countdown time defined in Settings>Tickets. If the default SLA time is turned off, then the ticket gets no countdown time and just sits there--waiting for someone to notice it.

This is seriously powerful, because you can specify different response times according to the changed status (and department, and priority) of your ticket. You might specify a maximum of 15 minutes to assign the ticket to a help desk staff member, but then give an extra 45 minutes until that issue must be addressed.

What if Reset Due Time On Status Change is set to 'No'?

If the clock is no longer ticking, or if there never was a clock, then nothing happens. On the other hand, if the clock is still ticking on a ticket, then it will continue to count down to zero. If the timer reaches zero, an escalation rule associated with the previous SLA will kick in, if one has been defined. If one has not been defined, then nothing happens, and the ticket simply becomes overdue.

Change the Status again, and the process repeats itself. If Reset Due Time On Status Change is 'Yes', then the search begins again for a matching SLA...

Group and User SLAs. A group can be assigned any SLA; the normal 'filtering' aspect of the SLA (i.e., by department, priority, and status) is essentially ignored. An SLA assigned to an individual user works in the same way, and takes precedence over any SLA attached to the group of which that user is a member. Question: what happens the next time the Status of a ticket attached to a User or Group SLA changes and the due time must be reset? Answer: the ticket will 'grab' an SLA according to it's new Department/Status/Priority properties; it does not use the SLA previously assigned to the user/group unless that SLA also matches it's new property set.

The whole arrangement can be charted as shown here:



All of that being said, the work flow I first tried to implement with v3.11.01 stable to take advantage of these features exposed a serious bug--which has been mentioned elsewhere in these forums. The Reset Due Time option for the statuses was simply not working; the due time was just getting zeroed. But if this option doesn't work, then all the oomph is gone, because you can't kick a ticket back to attach to another SLA!

Thankfully, these issues seem to have been fixed with the 3.11.01 CVS fixes to modules/tickets/functions_ticketscore.php. (Nice going!) The update notes claim 'minor fixes' but don't let that fool you: if you want to create a multilevel SLA scheme, you'll need those fixes!

I hope this helps. But to make it clearer, I'll next provide a sample implementation of an SLA scheme for an IT help desk.

[Matthew]

Here's my go at a tutorial for setting up SLAs. I've focused only on how to apply a scheme to web-based tickets. Using email tickets may require some additional setup. Remember that the SLA implementation is (in my experience) buggy up to v3.11.01 stable. Get the CVS updates to functions_ticketcore.php!

The Scenario:

You run an IT help desk for a financial services company located on a single high-rise floor. Response times must be relatively fast, as your clients are processing stock and other time-sensitive financial transactions. You have only one support department, and your help desk office hours are always the same.

For your SLA scheme, you decide on the following:

1. You'll have 4 user-assigned Priority Levels (1-4). You'll give these descriptive text so that your non-techie clients have a better sense of the urgency implied:
   1. When you have time
   2. Soon please, if possible
   3. This is holding me up!
   4. I need this right away!
2. You'll have 2 staff-assignable Priority Levels (5-6). These follow in the same style, as they will be visible to clients (if used), but will not be selectable by clients:
   • Drop everything else!
   • Everyone! Critical!
3. You decide on 6 possible ticket statuses:
   • Open - a new ticket
   • Assigned - someone is scheduled to work on this
   • In Progress - some is actually working with the client on this
   • On Hold - resolution is pending some event
   • Closed - issue is resolved
   • Escalated - we haven't lived up to the SLA. Start fixing it now!
4. You'll divide your staff into a Level 1 Support group and a Level 2 Support group. New staff tickets always go to 'Level 1' first; your 'Level 2' people are sysadmins, often doing project work, who should not be bothered when someone's email client stops working.
5. You want a deadline for assigning a new ticket to a Level 1 support person. When the ticket is assigned, the status should change from 'Open' to 'Assigned', and this should be visible on the ticket status as seen by your highly-impatient clients. The deadline will be based on the user-assigned ticket priority. You decide that a deadline of 15 minutes will work just fine for both priorities 1-2; but for priorities 3-4 you want the ticket to be assigned within 5 minutes.
6. You want another deadline for the Level 1 support person to actually start working on the issue. Once the problem is being addressed, the deadline countdown will stop and the status should change to 'In Progress'. In this case, you decide that each priority should have its own deadline: 105, 45, 25, and 10 minutes respectively. Why the odd numbers? Adding the 'assignment' deadlines to the corresponding 'start working' deadlines gives you the following scheme for starting to work on the issue. This is what you'll publish on your internal web site:
   • Priority 1: Maximum 2 hours to begin work
   • Priority 2: Maximum 1 hour to begin work
   • Priority 3: Maximum 30 mins to begin work
   • Priority 4: Maximum 15 mins to begin work
   • For emergency issues, please call the help desk directly (but we may still assign a lower priority afte evaluating the request)
7. You want to escalate a ticket to a Level 2 support group if either of the above deadlines expires. If it's only the 'assignment' deadline, the ticket Status should not change--as that's not part of your published (client-facing) SLA. However, if the ticket has been assigned and the Level 1 staff have failed to get started on it, you want the status to show as 'Escalated', and you may want to up the priority. That should tell your clients that someone is getting on the issue right away.

You may also want a deadline for resolving 'In Progress' issues completely, but we'll leave that out for now to keep things simple.

It helps a lot to make a diagram, something like this:



To do all of this, you'll need to build the following components:

• 2 staff Departments, for your Level 1 and Level 2 people
• 1 work Schedule
• 6 ticket Priorities
• 6 ticket Statuses
• 6 SLAs, with...
• 6 corresponding Escalation rules, and...
• A par-tridge in-a pear tree

The Steps:

1. Set up your departments and assign staff, if you haven't already. We'll call them Level 1 and Level 2, although you'll want to change these names to reflect the culture of your company, keeping in mind that (by default) clients will see the department name when they go to submit a ticket on the web page.
2. Create a work schedule in SLA>Insert Schedule. (Aw gee... there's no lunch break. Why didn't Kayako think of that one?)
3. Set up priorities in Tickets>Manage Priorities. Give them pretty colors.
4. Set up ticket statuses in Tickets>Manage Statuses. For all statuses except 'Escalated', the option Reset Due Time On Status Change should be 'Yes'.
5. Now go into Settings>Tickets and make sure the option to use a default SLA is turned off.
6. Create SLAs in SLA>Insert Plan:
   • SLA 1 Name: Open Tickets (priority 1-2). Due time: 0.25 hours. Department: Level 1. Priorities: select 1 and 2. Statuses: select Open.
   • SLA 2 Name: Open Tickets (priority 3-4). Due time: 0.083 hours. Department: Level 1. Priorities: select 3 and 4. Statuses: select Open.
   • SLA 3 Name: Assigned Tickets (priority 1). Due time: 1.75 hours. Department: Level 1. Priorities: select 1. Statuses: select Assigned.
   • SLA 4 Name: Assigned Tickets (priority 2). Due time: 0.75 hours. Department: Level 1. Priorities: select 2. Statuses: select Assigned.
   • SLA 5 Name: Assigned Tickets (priority 3). Due time: 0.416 hours. Department: Level 1. Priorities: select 3. Statuses: select Assigned.
   • SLA 6 Name: Assigned Tickets (priority 4). Due time: 0.166 hours. Department: Level 1. Priorities: select 4. Statuses: select Assigned.
7. Create 6 Escalation rules in Escalations>Insert New Rule:
   • Rule 1 Name: Open Tickets (priority 1-2). SLA Plan: Open Tickets (priority 1-2). Set Move Department to Level 2.
   • Rule 2 Name: Open Tickets (priority 3-4). SLA Plan: Open Tickets (priority 3-4). Set Move Department to Level 2.
   • Rule 3 Name: Assigned Tickets (priority 1). SLA Plan: Assigned Tickets (priority 1). Set Move Department to Level 2. Set Change Ticket Status to Escalated.
   • Rule 4 Name: Assigned Tickets (priority 2). SLA Plan: Assigned Tickets (priority 2). Set Move Department to Level 2. Set Change Ticket Status to Escalated.
   • Rule 5 Name: Assigned Tickets (priority 3). SLA Plan: Assigned Tickets (priority 3). Set Move Department to Level 2. Set Change Ticket Status to Escalated.
   • Rule 6 Name: Assigned Tickets (priority 4). SLA Plan: Assigned Tickets (priority 4). Set Move Department to Level 2. Set Change Ticket Status to Escalated.

That's it, your SLA scheme is all set up! Note that during daily operations, when a ticket is assigned to a Level 1 staff person, the ticket's Status must manually be updated to 'Assigned'. I'm not aware of a way to make this happen automatically, but I'll bet some clever PHP guru could make a hack for it.

If there are errors in the way I've approached this, I'm sure someone will let me know, and I will edit accordingly. Hope it helps!

[Matthew]

In my previous post, I noted that user and group SLA's ignore the normal filtering system that assigns an SLA to a ticket based on Department, Status, and Priority. When you assign an SLA to a user or group, you are essentially saying, "I want a ticket from this user/group to have a default due time that is based on the SLA I am indicating here, and I don't care what other filter rules would normally apply to that SLA."

Developers: This needs to be clarified in the explanatory text which accompanies assigning an SLA to either a user or a group.

If you have a simple SLA structure, which only defines initial response time, or which specifies only a maximum resolution time, then assigning SLA's to users or groups lets you (theoretically) provide faster service for particular user groups or particular 'sensitive' individuals.

However, if you have a complex SLA structure, which defines different response times based on ticket status changes (as we did previously), User and Group SLA's, if assigned, will only apply to the first level of response.

Let's extend the example from my previous sample implementation. Our scenario involved a financial services company, and as it happens, there are a number of 'clients' in this company that, for 'political' reasons, absolutely must be handled by an experienced (Level 2) support technician, even though all new tickets by default go to the Level 1 support department. The Level 2 people can be relied upon to handle these sensitive clients in a timely manner. You want this process to be transparent to the client: they get the 'special touch' without having to do anything special while submitting a ticket.

We're going to use a user-assigned SLA to do this. The logic is simple enough:

1. 'Sensitive' user submits a ticket, which is assigned to an SLA which expires immediately
2. The ticket is then escalated to Level 2 support people, who can be trusted to deal with it appropriately and in a timely manner

To make this work, you'll need to make sure you have a CRON job running to force ticket escalations every 1 or 2 minutes. (Just search 'cron' on this forum if you don't understand what I mean.)

Start by creating a new priority called 'dummy'.

Then make a new SLA in SLA>Insert Plan:

• Name: Executive Ticket.
• Overdue time: .001 hours.
• SLA Schedule: your standard schedule
• Department: Level 2.
• Priorities: select 'dummy'.
• Statuses: select Open.

We'll assign a due time that expires immediately, because our sole intention is to escalate this ticket to Level 2 support. We've also filtered by department 'Level 2' rather than 'All Departments', because we don't want incoming tickets for Level 1 support to use this SLA by mistake. Using the 'dummy' priority, and making this SLA apply only to tickets with a status of 'Open', insures that this ticket will not 're-attache' to this SLA after it's escalated to Level 2 support.

Next, make an escalation rule for this SLA. This rule should change the department to Level 2 and reset the status to 'Open'. If you've followed the previous tutorial, you'll know how to do this.

Lastly, go into your staff control panel and assign this SLA to the relevant users or groups.

That's it! Your 'sensitive' clients' tickets get booted within a minute or so to Level 2 support people, who are more experienced in providing for your clients 'special needs'. The due time will appear empty, unless you've set up another SLA to handle response times of Level 2 support people.

This setup is not perfect, as there is a brief period (possibly up to 2 minutes depending on how you've set your CRON) where the 'sensitive' client's ticket appears in the Level 1 support 'Open' status (and it's 'overdue'!). How will you instruct your Level 1 people not to handle these tickets?

[Matthew]

Reading the forums, I have a sense that the push for a robust SLA implementation has languished due largely to lack of understanding of how the system is supposed to work and a number of bugs that have (until recently, at least) persisted in the system. Bugs, plus minimal documented examples, creates a vicious circle of confusion. Beset by these complexities, many folks are creating only the most basic SLA implementations, or giving up completely and wanting to turn the whole SLA/Escalation system off.

If you have been one of these people, I humbly (as a junior member of this forum) invite you to give the SLAs another try, working through my previous 'tutorials' as a guide. Be sure to upgrade the relevant files from CVS.

There is an element of selfishness in this invitation: I have discovered some things which (in my opinion) one ought to be able to do with SLAs, but can't yet as of v3.11.01. I hope that, like me, you'll find that you too really need one or two of these features, so that we can push to have them included in upcoming v3 builds without having to wait for v4. Here they are, in what I perceive as order of difficulty:

1. The Manage Users and Manage Groups widgets in Staff CP should (really... it should!) indicate whether a user/group has an individual SLA. Are we expected to open the properties for every user? This should be an easy fix.
2. In Admin CP>SLA>Insert SLA, we need the ability to select multiple Departments to which to apply an SLA. Having to create identical SLAs for different departments is, well, silly.
3. In Admin CP>SLA>Insert SLA, the ability to select multiple Schedules. This would make it easy to create an SLA for situations where your staff (all of them) get a lunch break and you don't want the clock ticking on a ticket. You could make this part of the schedules themselves by breaking each day into two segments, but it seems more flexible to allow multiple selections in the SLA.
4. The mail parser needs an additional mechanism so that an incoming support request can be matched to a user group, and that property used to (re)assign the department. This makes it possible to have one support email address for multiple departments, rather than half a dozen.
5. Holiday schedules, attachable to SLAs as well as a staff member's calendar. It's been said elsewhere by myself and others, but bears saying again in this list. As with schedules, we should be able to select multiple holiday schedules for a single SLA; for example, I live in a country where there are fixed-date national holidays, and a huge number of religious holidays whose dates vary from year to year.

I hope that others will lend their voices to get these essential features in place, and bring the SLA system into real maturity.

Jamie, I realize these feature requests might actually have a place somewhere else, but I'd like to keep them linked with the examples I've provided, if possible. That way users can get a fuller picture of what they can and can't do with SLAs. However, I will edit as per your advice.

[Emma]

Originally Posted by Matthew

Start by creating a new priority called 'dummy'.

Then make a new SLA in SLA>Insert Plan:

• Name: Executive Ticket.
• Overdue time: .001 hours.
• SLA Schedule: your standard schedule
• Department: Level 2.
• Priorities: select 'dummy'.
• Statuses: select Open.

I tried all the above, but I still can't get it to do what I need. The above walkthrough is great! However, I still think the SLAs don't work to 'normal' standards.

My issue with the above 'dummy' SLA Plan is this: What happens when you change the status of the ticket internally? I need my Critical Executive Ticket to stay on 1 hour response, no matter what department it is in, no matter whether it is 'on hold' etc. So this dummy will put the ticket into the correct SLA when the customer logs the ticket at first, which is great. But what happens when we work on it? Set the ticket to In Progress. Then On Hold. This is where SLAs start to get messed up. The dummy SLA won't keep it assigned to that SLA because it will only do it for tickets set to 'open'.

Also, I don't want my executive customers to go straight to level 2 - they need to go via 1st line support always but with a faster SLA. They are escalated to 2nd line if needed. That's just me being fussy though - I have just created 2 separate departments for my executive users and for my residential users, which is much the same as having a 'level 2' department anyway.

I tried to implement this with template groups - I have residential, and extecutive templates. This all works fine, the SLAs get assigned properly and at the customer end everything runs smoothly.

The issues here come when you try to use the staff control panel. When you create a new ticket within the staff panel on behalf of a customer, it always gets created into the default template. So long as you choose the correct priority, the correct SLA gets chosen, but it is still all a complete mess - the customer starts to see dropdowns of the priority types that should only be visible from the other template group!

All I want is to be able to create the following:

Exec Department - All status types - Critical priority
Exec Department - All status types - low priority
Residential Department - All status types - Critical priority
Residential Department - All status types - low priority

The only way I can do this is to have two sets of critical and low priorities in the template groups. I really don't want to do this as it confuses everything.

If the user SLA assignment would simply stick permanenely to the right SLA, all my problems will be solved. Until then, we can't really use it. We've had the full license for several months now, I needed to roll this out a looong long time ago. I am worried this bug won't be fixed by the time my support contract runs out.

If there is a way around it, I am all ears, but I've tried everything I can think of.

[nibb]

Wow this is very good and impressing. Did Kayako paid you to post this? Why isn't the manual like this? Now I really understand the SLA and Escalation system. Thanks

[craigbrass]

I don't think they paid him but it is very useful.

I agree, Jamie should ask permission to include this in the manual.

[Matthew]

Originally Posted by craigbrass

I don't think they paid him but it is very useful.

I agree, Jamie should ask permission to include this in the manual.

No, of course they didn't pay me. Just my little contribution to the online documentation. As I said somewhere else, there's a selfish motive: I figure if more people understand the SLA system, they will use it, and there will be more pressure from old and new customers to add a few missing (but IMHO essential) features. Like the holiday/vacation schedules, for instance. Please check out my suggestions in this post.

Jamie has not asked, but Kayako is welcome to use my tutorial in the docs, if they wish.

[michelvana]

Hi Matthew,

Your clear explanation is great, thank you very much! I am busy following your steps, but got confused at step 6, mainly because we have a rather straightforward SLA-plan I guess.

At this moment we only have three SLA-flavours:
1. On critical issues, we will respond within 4 hours (during business hours, from 9 to 5);
2. On regular requests we respond ultimately before the end of the next business day (during business hours, from 9 to 5);
3) No SLA: we respond during business hours as soon as we have time.

Your post brought us the Idea to add a 4th for Sensitive Clients, to direct them to Group Level 2, but we did not implement this yet.

Your steps seems as if we could use them within the above mentioned SLA-plans 1 to 3. Since these plans aren't as strict as your example describes, they would have a more internal 'service quality'-goal in the case that we implement them as such: although the client's SLA is not that strict, we would expect from our agents that they respond much faster. Nothing wrong with that (exceed customer expectations).

In some cases we use third party agents in our staff. We cannot force them always into these new strict service quality standards. If we apply your 6 steps, the status of ALL tickets will change, while we know beforehand that these third party agents does not have to meet the standards.

For this reason we would like to expand the time limits to prvent unnecessary and unwanted status changes.

Now the question: we got confused in the relationship of the 105/45/25/10 minutes deadline (in our case to short) and their relationship with and effect on the priorities of the starting times for the beginning of the work (2 hours, 1 hour, 30 mins, 15 mins). We have got lost at step 6, where the SLA 1 to 5 Name seem to have have odd Due-times.

Would you be so kind to explain their relationship a bit further. Is there a formula that you used to calculate this?

Thanks in advance for your reply!

Kind regards, Michel

[magic7s]

First, thanks for the post and information.
I understand that everyone uses this system a bit differently. My company does not have a help desk staff (or managers) that monitor the system all the time. We rely on email alerts for most everything.
Is there a way to kick off simple email alerts when SLAs expire? One better would be a tiered system where after X minutes of overdue it emails this person or group, then after X minutes emails more people.

[Raghav Arora]

Originally Posted by magic7s

First, thanks for the post and information.
I understand that everyone uses this system a bit differently. My company does not have a help desk staff (or managers) that monitor the system all the time. We rely on email alerts for most everything.
Is there a way to kick off simple email alerts when SLAs expire? One better would be a tiered system where after X minutes of overdue it emails this person or group, then after X minutes emails more people.

Yes, you can set the Escalations for this. And escalations have the actions like: Assign to staff, Move department, Change priority and Change ticket status. You can set the email alerts for any of them and your staff will be alerted for the same.

[Matthew]

After letting our Kayako installation languish for several months due to a frenetic company reorganization, we are finally in a place to use it, and I'm back at it--with apologies for those who addressed messages to me and never saw a response.

Since there have been many small changes to the CVS since October when I last tried, I did a complete re-install on our new web host, using a CVS from 08 Jan 2008. After putting my SLAs together again, I've seen that there is still a bug which unfortunately puts a serious dent in my ability to use the system. I reported this bug when I first came upon it, yet it seems there's been no progress on what seems on the surface a minor coding issue.

Here it is again:

When setting up a new ticket Status, there is an option to make it 'private'--that is, staff can select it, and clients should be able to see it; yet it should not appear in the drop-down list of statuses available to the client when updating his/her ticket. The actual text reads:

Private: Private statuses are selectable only by staff users. If a ticket is set to a private status the client user will see this status, but they will not be able to select this status themself (sic).

Aside from the grammatical error, the advertised function is not working: the 'private' status is NOT visible to clients (it is simply blank).

Have a look at the attached image if this is not clear.

Another bug of a similar type, maybe related:

'Private' department names are also not displaying on the client interface. Here's the way I've done it:

1. Open tickets are assigned to the Tech department. These have an SLA which requires a response within a set number of minutes.
2. Upon expiration of the timer, an escalation rule kicks in and moves the ticket to the 'private' department Systems Support. This are my 'level 2' support people.

Why doesn't the department label now show up on the client's ticket view? I don't want clients to be able to send tickets to this department, but I certainly want them to see where the ticket has been escalated to.

As these bugs impact one of the key advertised features of Kayako (the SLAs), can someone please have a closer look at this?

I located the previous ticket for the issue (LVV-197205), from Jasvinder Singh on 26 October 2007, in which he says that the status issue is 'known' and being forwarded to developers for inclusion in an 'upcoming' build.

[Matthew]

Originally Posted by Matthew

When setting up a new ticket Status, there is an option to make it 'private'--that is, staff can select it, and clients should be able to see it; yet it should not appear in the drop-down list of statuses available to the client when updating his/her ticket. The actual text reads:

Private: Private statuses are selectable only by staff users. If a ticket is set to a private status the client user will see this status, but they will not be able to select this status themself (sic).

Aside from the grammatical error, the advertised function is not working: the 'private' status is NOT visible to clients (it is simply blank).

It's taken some time, but this is now fixed in CVS, with kudos to Varun.

[jetnet]

Pardon me for asking such a noobish question, but how does a ticket go from "Open" to "Assigned"? Do you manually have to change that status, or is there some way when someone claims it to automatically change that status?

[Matthew]

Originally Posted by jetnet

Pardon me for asking such a noobish question, but how does a ticket go from "Open" to "Assigned"? Do you manually have to change that status, or is there some way when someone claims it to automatically change that status?

It's changed manually when someone claims it, or when the support manager assigns it.