- About Support Incident Tracker
- Support
  - Incidents
  - Adding an Incident
  - Incident Queues
  - Watching Incidents
  - Service Levels
  - Activities
  - Reassigning an Incident
  - Closing an Incident
- Customers
- Contracts
- Skills & Products
- Tags
- Triggers
- Control Panel
  - Adding Users
  - Removing Users
- More Help

### About Support Incident Tracker

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.

### Incidents

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 that may be one of the following:

- Active
- Closed
- Research Needed
- Called And Left Message
- Awaiting Colleague Response
- Awaiting Support Response
- Awaiting Closure
- Awaiting Customer Action
- Unsupported

Closed incidents have an additional closing status:

- Sent Information
- Solved Problem
- Reported Bug
- Action Taken
- Duplicate
- No Longer Relevant
- Unsupported
- Support Expired
- Unsolved
- Escalated

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, colleagues and external engineers.

Incidents can also have files attached.

### Adding an Incident

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:

1. Enter all or part of the contact name in the box and click on the Find Contact button
2. From the list of contacts or people, click the appropriate Add Incident link
3. Enter full details of the incident, give the incident a title and enter a problem description, etc.
4. Assign the incident to an engineer who is to work on it

### Incident Queues

SiT! works in a manner that is perhaps different to other support tracking/helpdesk applications that you may have used in several respects.

- It's possible for any engineer to view and even work on incidents that are in other engineers queues
- Incidents are assigned to engineers as soon as they are logged, rather than waiting in a central pending queue or inbox for an engineer to decide to work on them.
- Incidents can be passed easily from engineer to engineer by re-assigning
- Engineers can keep an eye on incidents that their colleagues are working on, if they have skills in those areas

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, let's 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'.

#### 'Action Needed' Queue

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.

#### 'Waiting' Queue

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)

#### 'All Open' Queue

This queue lists all your current incidents regardless of their status. This is the same as combining the Action Needed and Waiting queues.

#### 'All Closed' Queue

As is evident from the name this queue contains all the closed incidents that were assigned to you.

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 can be viewed by selecting Support | Holding Queue from the menu.

#### Holding Queue

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. Usually when a user marks themself away incidents are automatically assigned to substitute engineers. In the case where a substitute engineer was unavailable the incident is displayed in this queue.

### Watching Incidents

As well as viewing your own queue that shows just your own incidents, you can view incidents for all owners 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 pull-down menu.

### Reassigning Incidents

While an incident is open it can be passed from user to user so that several people may work on it. This may 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 suggests and highlights 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 manually. In the list, names that are shown in bold text have appropriate skills.

#### Temporary Assigns

Another option when reassigning is to make a temporary assignment. This keeps you as the owner of the incident and adds another 'Temporary' owner who will also see the incident in his/her queue. This is useful when somebody is away.

### Service Levels

Each incident created is allocated a service level according to the service level set in the contract. By default SiT! has just one service level 'standard' defined, 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:

- Initial Response
- Problem Determination
- Action Plan
- Resolution
- Review*

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 but is 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

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 where timing is enabled there will be an Activities tab at the top of incident popup window. For other incidents 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 that totals all the activities 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 combine all the notes and time spent on the activity and create an entry in the incident log.

### Closing an Incident

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:

- Sent Information
- Solved Problem
- Reported Bug
- Action Taken
- Duplicate
- No Longer Relevant
- Unsupported
- Support Expired
- Unsolved

### Customers

People and organisations that you provide support to using SiT! are referred to as 'customers'

#### Sites & Contacts

Every organisation that you provide 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 the 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.

### Contracts

Before you can add an incident on behalf of a contact there must 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 separately.

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.

### Skills & Products

Each item that is supported by SiT! is called a skill and each should have its 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 separate 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 are 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.

### Tags

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 separate a list of single word keywords with space or comma.

The tags dashboard component, when enabled, displays a tag 'cloud' on your dashboard.

### Triggers

A 'trigger' is a event within SiT! 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 configure system trigger actions by going to SiT! | Control Panel | Triggers

### Adding Users

If you have 'Add Users' permission then 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

- Administrator
- Manager
- User

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 if the user has access requirements over and above that granted by the 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.

### Removing Users

To maintain data integrity there is no way to delete users from SiT!, however user accounts can be disabled which will prevent further logins and stop the user's name from showing up in selection boxes, etc.

To disable a user's 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.

To re-enable a user account edit the user's profile and set their status to anything other than 'DISABLED ACCOUNT'.

### More Help

See the Documentation section of the SiT! website for a list of Frequently Asked Questions (FAQ) and more help.