Support Incident Tracker (or SiT!) is a web based application for tracking technical support calls/emails. Manage contacts, sites, technical support contracts and support incidents in one place. Send and receive emails directly from SiT!, attach files and record every communication in the incident log. SiT is aware of Service Level Agreements and incidents are flagged if they stray outside of them.
As is clear from the name Support Incident tracker, incidents are an important part of SiT!, 'Incident' is the name we use for what may also be referred to as a 'support call'. 'service request' or 'helpdesk ticket'.
Incidents are usually referred to by their reference number, what we call the 'Incident Number'. Incidents have a title, an associated product, contract and contact and possibly other information as well.
After an incident is added it is always 'owned' by a SiT! user although the user can reassign this ownership while the incident is open.
Each incident has a current status which may be one of the following:
Closed incidents have an additional closing status:
Each incident has an 'updates log' which shows everything that has happened during the lifetime of the incident, a complete record of all contact with the customer, with colleagues and with external engineers.
Incidents can also have files attached.
Before you can add an incident, the customer must already have a contract that entitles them to support.
Adding an incident is a four step process that goes like this:
SiT! works in a manner that is perhaps different to other support tracking/helpdesk applications that you may have used in several respects.
We believe this to be a better, more collaborative, way of working. It helps prevent difficult or unpopular issues from being ignored or left till last and it encourages team working.
There are a number of queues and they do work in different ways, lets look at them one at a time.
Select Support | View Incidents (or simply click Support) from the menu to display your 'Action Needed' queue. From here you can select your other queues, 'Waiting', 'All Open' and 'All Closed'.
Lists all incidents that are assigned to you and require your action in some way. The list is sorted so that incidents requiring action first are displayed at the top, but you can change how the list is sorted by clicking on the column headings.
Lists incidents that are assigned to you and do not require immediate action but are waiting for response from a third party (For example an incident that is waiting for the customer to send in log files)
This queue lists all your current incidents regardless of their status. This is the same as combining the Action Needed and Waiting queues.
As is evident from the name this queue contains all the incidents that are assigned to you that are now closed.
Rows in the various queues are coloured according to their importance, the colours will vary depending on the theme you are using, in the default theme incidents are normally coloured blue, coloured yellow when they approach a target and then red as they require immediate attention.
Hover your pointer over an incident title in the queue to see a brief extract of the latest update.
The next queue we are going to look at is the 'Holding Queue', this is slightly different to the other queues in that it can contain incoming emails as well as incidents and it can be viewed by selecting Support | Holding Queue from the menu.
This special queue has four sections, 'Held Emails', 'Spam Emails', 'New Incidents' and 'Pending Re-Assignments'. The four sections show items that cannot be handled automatically by SiT for one reason or another. Incoming email is held in this queue if they arrive without the incident number correctly formatted on the subject line or if the incident number quoted in the subject relates to an incident that has been closed. Email is determined to be spam if certain text is found in the subject line (this can set by your anti-spam software for example SpamAssassin) and are always held for you to review. Next is a section with new incidents created directly by the customer that need to be assigned to engineers. The final section is a list of incidents that could not be reassigned automatically after a user went away, normally when a user marks himself away incidents are automatically assigned to substitute engineers, but in the case where a substitute engineer was unavailable the incident is displayed in this queue.
As well as viewing your own queue which shows just your own incidents you can view all incidents no matter who owns them by selecting Support | Watch Incidents from the menu. You can also view the various combined queues here by selecting, 'Action Needed', 'Waiting' or 'All Open' from the pulldown menu.
During the time an incident is open it can be passed from user to user so that several people may work on a single incident. This could be because the initial owner could not solve the incident on his/her own or because somebody else was better qualified to deal with it.
To assign one of your incidents to somebody else, select the Reassign tab from the incident popup window. You will see that SiT has already suggested and highlighted in green somebody to reassign to, this person is chosen automatically as the most appropriate person to deal with the incident based on availability and skills, you can also click the # More... link and select a different user if you would like to choose who to reassign to yourself. In the list, names that are shown in bold text have appropriate skills.
Another option when reassigning is to make the assignment temporary, this keeps you as the owner of the incident but also adds another 'Temporary' owner who will also see the incident in his/her queue. This is useful when two colleagues are working collaboratively on the same incident, it is also used by the automatic-reassign feature that assigns incidents temporarily to subsitute engineers when somebody is away.
Each incident created is allocated a service level according to the service level set in the contract. SiT comes with just one service level 'standard' defined by default, but you can add more or customize existing levels to suit your requirements via SiT! | Control Panel | Service Levels.
The service level targets define an amount of time allowed for the incident to reach a certain stage of progression, ensuring your team meet these targets helps you to provide a better service. Targets have different times for each incident priority so you can aim to respond to high priority incidents faster.
The service level targets are:
You can meet a service level target by making an update to an incident or by sending an email and marking the service level you want to meet.
* An incident review is a special type of service level target, the review period is not affected by the working week it is simply based on the amount of time an incident has been open, to review an incident make an update and mark the update type as 'Review'. Review periods are a useful way of preventing incidents from dragging on and on.
Activities are timed tasks, which are useful for when the support is chargeable based on time spent on the incident.
The idea is to start a new activity for any related actions you do, and stop it when you have finished. For incidents logged under service levels were timing is enabled there will be an Activities tab at the top of incident popup window. For other incident this tab will be hidden.
The activities tab is only displayed if the service level is timed.
On a new incident the Activities page will be blank. Starting a new activity starts an individual timer for that activity as well as an overall timer which totals all the activies for that incident. Clicking on the ID of the activity will take you to a page where you can add notes. When the activity is complete, click Mark Complete at the bottom of the notes page. This will take all your notes and time spent on the activity and create an entry in the incident log.
When you close an incident you are given the choice to mark the incident for closure or to close it immediately. If you choose to mark it for closure it will be closed after seven days. (this period can be configured by setting the closure_delay in the config file.)
You must select a closing status at this point, this can be used later to quickly see whether the query was answered etc. The options available are:
People and organisations that you provide support to using SiT are referred to within SiT as 'customers'
Every organisation that you provide to support to is referred to as a 'site' and each site can have a number of 'contacts'.
View sites by selecting Customers | Sites to get a list and then click on the site name to view details of that site, including contacts.
View contacts by selecting Customers | Contacts
You can set any of the three data protection fields on the contact record to indicate that the person does not want to be contacted by email, letter or phone.
We recommend that you never delete sites or contacts unless absolutely necessary, this is because each site or contact may have a number of associated records, such as contracts or incidents that are related only to that site. If you do decide to Delete, SiT! will prompt you to select another site or contact to receive the associated records.
Before you can add an incident on behalf of a contact there must first be an agreement in place to provide such support, these agreements are referred to within SiT as 'contracts'.
To add a new contract select Customers | Maintenance | New Contract and fill in the details on the form.
Admin Contacts are not supported contacts, you must add supported contacts seperately.
Each contract holds information about the agreement such as the product supported, the number of supported contacts allowed, the number of incidents included with the contract and the expiration date.
To be useful each contract must have at least one contact associated with it. To add a contact simply follow the link Add a support contact to this contract on the contract details page. These supported contacts are the only people who can log incidents.
You can set a contract to allow all the contacts from the associated site to be supported, if you do this then all the contacts that are currently associated with the site along with any future contacts that may be added will all be supported.
Each item that is supported by SiT! is called a skill and each should have it's own skill record. For example if you plan to support software called 'Debian GNU/Linux' you should add a skill record by selecting Customers | Maintenance | Products & Skills | Add Skill.
Don't add different versions of the same item as seperate records unless you do treat them differently in the way you support them (e.g. you plan to phase out support for an older version). You'll be prompted for a version number when adding an incident.
In order to simplify supporting a large number of different software applications SiT! has the concept of 'Products', products can be thought of as groups of software. For example, you may support three software applications, 'Debian GNU/Linux', 'SUSE Linux' and 'Mandriva Linux' but want to offer support for all three as one product called 'Linux'.
To add a product go to Customers | Maintenance | Products & Skills | Add Product, select a vendor enter a product name a description then click Add Product. Then to link skills to that, go to Customers | Maintenance | Products & Skills | Link Products/Skills.
To list existing products and the software associated with them go to Customers | Maintenance | Products & Skills | List Products.
Products can also be grouped by vendor, you can add vendors by going to Customers | Maintenance | Products & Skills | Add Vendor.
Incidents, contacts, sites and tasks can all be 'tagged' with keywords, tagging lets you quickly group or categorise data in any way you like. Add tags from the edit page of the relevant record, simply seperate a list of single word keywords with space or comma.
The tags dashboard component, when enabled, displays a tag 'cloud' on your dashboard.
A 'trigger' is a event within SiT, there are many such, for example a trigger might be that a new incident is created. You can set up actions to respond to these triggers, for example you can cause a notice to appear at the top of your SiT screen whenever an incident is assigned to you.
To configure your trigger actions go to SiT! | My Details | My Triggers
Administrators can also configure system trigger actions by going to SiT! | Control Panel | Triggers
If you have appropriate permission you can create additional SiT users. (The 'admin' user always has this permission). Go to Control Panel | Users | Add User.
Usernames must be unique and cannot contain spaces. Each user must have an email address.
There are three available roles
Each role has different permissions, and you can alter the permissions assigned to roles should you require.
After adding a user you are presented with the user permissions page where you can grant additional permissions should the user have needs beyond that provided by the nearest role.
Note that permissions are additive and you cannot take permissions away from a user that are granted by the role except by changing the users role or altering the permissions on the role itself.
To maintain data integrity there isn't a way to delete users from SiT!, however user accounts can be disabled which will prevent further logins and stop the users name from showing up in selection boxes etc.
To disable a users account go to Control Panel | Users and select Edit next to the user you would like to disable. Then select 'DISABLED ACCOUNT' from the Status drop down box and click save.
Re-enabling a user account is simple, just edit the users profile and set their status to 'In Office'.
See the Documentation section of the SiT website for a list of Frequently Asked Questions (FAQ) and more help.