When creating a ticket in our ticketing system, each ticket has to have a type. Type could be "System Crash" (SystemError::ServerCrash) or "User problem with spam filtering" (UserProblem::Spam), etc. They indicate something about the ticket.
The type of a ticket is not useful for solving the customer's problem, but is very useful for management to track tickets later based on type. It helps the Support Group to answer questions of the following nature:
And so on. Therefore it is important that an engineer creating a ticket must select the type of ticket correctly. The system has a pre-defined set of types, and more can be added by administrators. This note describes ticket types and indicates the meaning of each type, to help the Support Engineer select the correct type of each ticket.
The types are grouped into categories and subcategories. There are the following broad categories:
OpsTask:: These are tickets which will be created by Support Engineers when they are asked by the client to perform an operational task. These tickets are only for situations when there are no problems in the systems. Typical examples: back up some data, restore something from backup, reset a user's password, etc.
This type of tickets will only be created by Support Engineers.
SystemError:: These are tickets which will be created by Support Engineers when there are problems at the system level, ie. when an entire server is down or a service is malfunctioning. In other words, these are situations where all users of that server or service are being hit. Typical examples: disk space full on server, or AV module not functioning, or DNS resolution problem, or server running very slowly.
This type of ticket will only be created by Support Engineers.
UserProblem:: These are tickets which will be created by Support Engineers when there are problems reported for one or a few users but not at the system level (i.e. affecting all users or the whole office). Typical examples: email has not reached, or a mail sent by a user bounced back because of attachment type restrictions, etc.
This type of ticket will only be created by Support Engineers.
PSG:: These tickets will be created by Project Engineers of PSG for tasks which they are asked to execute. These are not support tasks. When a support ticket moves from L1 to L2 queue, it comes under the scope of work of PSG. But this does not change the type of ticket.
This type of ticket will only be created by Project Engineers of the PSG, or by Shraddha or myself as instructions to PSG.
STG:: These tickets will be created by System Software Engineers of the STG for tasks they have to undertake for product development, maintenance, and release. These are not support tasks. When a support ticket moves from L2 to L3, the job comes under the scope of work of STG, but the type of the ticket does not change. Typical tickets of type STG include: release the next version of the Merce CD, upgrade the ClamAV package to the latest version in the Merce source base, replace the old mail-fetching UI with a new Dojo-based version, etc.
These tickets will only be created by STG members or myself.
Below this category, there is one major subcategory OpsTask::MerceInfra::. This subcategory is for all operational tasks that Support Group has to do on the IS infrastructure of our company.
Other than this sub-category, all the other types under OpsTask:: are for tasks which customers ask us to perform. One or two are internal, e.g. OpsTask::CDprepare refers to preparation of Merce CDs that Support Engineers have to do sometimes.
OpsTask::Printing:: has two sub-categories, depending on what our Support Group is asked to do. If they have to attend to some printer setup on the Merce Linux servers, then the ticket type should be OpsTask::Printing::Merce. If they have to work to sort out some problem from Windows desktops or laptops, then the ticket type should be OpsTask::Printing::Windows.
There are two large sub-categories under SystemError:
Under SystemError::ServerCrash there are a whole bunch of sub-types which all relate to the reason why the server crashed. Most are self-explanatory. One unusual type is SystemError::ServerCrash::VirusOutbreak. Though we know that Linux servers never get infected by viruses, a virus outbreak on the LAN can bring down our servers due to heavy traffic. Another unusual type is SystemError::ServerCrash::VOODOO, which should only be used if you have a server crash whose reason you simply cannot identify. This is the rarest of rare cases where our analysis has not given us any idea.
Under SystemError::ServiceFailure, there are the various services which may fail. These components and services are self-explanatory. If your customer complains that one of these things has failed and all users are affected, create a ticket of this type.
Under SystemError:: there is SystemError::VM. This may be confusing because there's also a SystemError::ServerCrash::VM. These two types are separate because the former refers to all tickets which involve some malfunctioning due to virtualisation, whereas the ServerCrash::VM type refers to tickets where a virtual server has crashed because of VM problems.
The SystemError::VOODOO is for errors whose cause or sub-system or component cannot be identified. These will be the rarest cases, maybe once in six months or even less. The SystemError::WindowsSvr type is for all system errors reported by the customer related to Windows servers, e.g. Windows compute servers, Windows database servers (as in Zodiac), etc. The SystemError::highload type is for tickets where the customer reports that one of our Merce servers is showing very heavy load and slow response.
I expect that the UserProblem:: tickets will be the most common. Therefore, I have created many sub-types under this, for mail, Web access, etc, and under each sub-type, I've created two sub-sub-types. For instance, there are
and so on. The aim here is that Support Group should be able to hear a problem description and decide whether this is known or unknown. If it seems to be a known problem, the engineer will set ticket type to ::knownL1. If it's strange, it'll be set to ::unknown. This will help us quickly capture how many unknown problems we are encountering here.
Some topics where I expect there will be less complaints for UserProblem:: have been left without splitting into ::knownL1 and ::unknown.
If this is found to be useful, we will do this type of split between ::knownL1 and ::unknown for SystemError:: types too, later. If this is found to be useless, we can remove these sub-types from UserProblem:: later.
Under PSG:: there are just five sub-types.
If a Project Engineer needs to visit a customer, without doing any hands-on setup work or computer-configuration stuff, then that ticket goes under PSG::MeetingCustomer::. Under this sub-type, if the party is a customer, then the ticket type will be ::Customer. If it is not yet a customer, then the type will be ::presales.
If a PSG member goes to a client site for any setup tasks, then it will come under PSG::Setup::. Here again, for a firm order and a paying customer, it becomes PSG::Setup::Customer, and for a prospective customer, it becomes PSG::Setup::Pilot.
If a PSG member works on our company's internal infra tasks, then the ticket type will be PSG::MerceInfra. This is quite often the case when new servers are set up, backups are managed, etc, which have nothing to do with technical support. Therefore these tickets will directly go to PSG and will not go through the Support queues.
STG will have four types of task tickets. If they are doing product development, then those tickets will come under STG::ProdDev::. If they are working on a specific problem where maybe a bug fix or some R&D is needed, then it will go under STG::ProdSupport::. I am not clear what kind of tickets will be non-Support-related and will directly hit the STG tasks queue but will be of type STG::ProdSupport::. We will see if the need arises.
If STG is asked to attend to a specific task for Merce's own IS infrastructure, and this is too technical for PSG to handle (e.g. write scripts to automate some backup tasks or other stuff), then the ticket type will be OpsTask::MerceInfra::ServerMgmt. The ticket will be created in Support L3 queue directly, because it will be understood that this type of work can't be handled by Support Group or PSG, so there's no point making the ticket move from L1 to L2 to L3.
Ticket types have to be set carefully. Support Group in particular will have to understand the meaning of each type, and set the type correctly when creating a ticket. The Support Head will contribute a lot of guidance in this area.