Overview
The Support template supports a typical Support
environment in which issues or requests are reported by
customers or end users and the Support team resolves the issues or
processes requests. This template incorporates 2 levels of Support:
1st Line Support attempts to process all incoming
tickets
2nd Line Support processes any escalated tickets that could not
be processed by 1st Line Support
Support Manager processes any escalated tickets that
could not be processed by 1st or 2nd Line Support
Projects
A default project called "Support"
is available in this template and is visible to all
user groups. This project can be customized
and additional projects can be added via the
Projects
section.
Forms
A default form called "Ticket" is available in this
template, is associated with the "Support" Project
and is visible to all user groups.
This form can be customized and additional
forms can be added via the
Forms
section.
Fields
The Ticket form contains the following fields. Note that
you can customize the database by adding to or removing
fields, or changing any pulldown menu values via the
Fields section.
Field names
with an asterisk are required by the system and cannot
be removed from any form(s).
PRN* |
Numeric record identifier. Assigned
at the time the ticket is created. |
Title |
A one line text summary of the
problem or request. Set at the time the ticket is created. |
Product* |
Identifies the product for which the
ticket has been reported. Set at the time the
ticket is created. |
Last Updated Date* |
The date and time the ticket was last modified.
Set automatically as the ticket is processed through the workflow. |
Platform |
Describes the hardware or
software platform where the problem occurs. An example
is the operating system (e.g. Windows XP). Set at the time
the ticket is created. |
Request Type |
Classifies the ticket. Possible values are: Bug, Contract
Requirement, Customer Feedback, Customer
Problem, Enhancement. Set at the time the ticket
is created. |
Severity |
Describes how serious the
problem is. Set at the time the ticket is
created. |
Description |
Full description of the
problem. Ideally describes the nature of the
problem and how to reproduce the behavior.
Set at the time the ticket is created. |
Reported By* |
Name of the user that
reported the ticket. Initially set to the
name of the current user logged in. Set at
the time the ticket is created. |
Date Reported |
The date the ticket was
created. Automatically initialized, and set
at the time the ticket is created. |
Workaround |
Describes how to work
around the reported problem. Set at the time
the ticket is created. |
Pending Issues |
Describes what information or tasks are
needed before a ticket can continue to be processed.
Set by the Support Engineer if issues arise that keep the ticket
from being processed. |
Status* |
Current state of the
ticket. Changes as the ticket is
processed through the workflow. |
Assigned To* |
User the ticket is currently
assigned to for processing. Set either manually
or automatically during processing of the
workflow. |
Browser |
The browser installed on the machine of the
user who reported the issue. Set automatically when the ticket
is created using the
AutoFill feature. |
Operating System |
The operating system installed on the machine of the
user who reported the issue. Set automatically when the ticket
is created using the
AutoFill feature. |
Est. Close Date |
Date when the issue or request
is expected to be resolved. Set by the Support Engineer
when deciding how to process the ticket.
|
Priority |
Describes the relative importance
of handling this ticket compared to other tickets
entered in the system. |
Close Date |
Date when the ticket
was closed. Set by Support when issue or request has
been resolved. Automatically
initialized to the current date/time. |
Close Detail |
Describes the details about how the
issue or request was resolved.
Set by the Support when the issue or request has been
resolved. |
Deleted* |
Denotes whether the ticket has been deleted. |
Support Queues
The Home Page reports can be set up as
a queue for Support Engineers to use in
prioritizing and processing incoming
tickets. TBD will be the user to which incoming
tickets are assigned while they are in a queue.
To represent a queue for the 1st Line Support team on the
Home Page, the saved query 1st Line Support Queue [Support]
was created to
display all tickets assigned to TBD in the Reported
state. To represent the queue for 2nd Line Support on
the Home Page, the saved query
2nd Line Support Queue [Support]
was created to display all
tickets assigned to TBD in the Escalated state.
Information on how tickets are processed within and outside of the
queue are discussed in the Workflow section below.
Workflows
It is assumed that tickets will be processed and moved through the workflow
process by using the Task operation. A default workflow called
"Support Ticket Process" is available
in this template and is associated with the "Ticket" Form and
is in use in the "Support" Project. You can customize the
Support Ticket Process
workflow or add additional workflows via the
Workflows section.
- State 1 - Reported
It is assumed that 1st Line Support Engineers check a queue
to pick up incoming tickets.
When a ticket is created, it is set to the state
Reported, and assigned to TBD (a placeholder user to represent
tickets that are in the queue and have not yet been assigned).
The user who reported the ticket can make changes to the ticket while
it is in the Reported state (before a 1st Line Engineer has started working
on it) using the Update Request transition. This transition allows the Reporter
to add more information that may help the Support Engineer resolve the issue.
The same fields that are available to the Reporter on the Add or Submit pages
are available in this transition. The Reporter must explain what was changed in
the History Comment field.
A 1st Line Support Engineer (sup_one)
selects incoming tickets from the queue and
decides how to process each using a list of possible workflow paths.
sup_one can choose one of the
following:
- Begin processing a ticket by selecting the transition called
Start Processing Request. The Description field
is presented for reference. sup_one must enter an
Estimated Close Date and
can optionally set the Priority of the request. This transition
will assign the ticket to sup_one and
place the ticket in the In Process state.
- Close the ticket by selecting the transition called Close.
The Description field
is presented for reference. This
transition will place the ticket in the Closed state and assign it to TBD
("no one" since this ticket will not be processed any further).
sup_one will be required to enter a reason
the ticket was closed in the Close Detail field. The Close Date will be updated
automatically.
- Delay processing of the request by selecting the Hold Request
transition. The Description field is presented for reference.
sup_one is required to enter a reason for the
delay in the Pending Issues field and an Estimated Close Date. It is
optional to set the Priority for the ticket. This transition will place the
ticket in the On Hold state and will assign it to sup_one.
This is implemented by:
Workflow Properties
- Defining Reported as the Default Add
State when a ticket is added
- Assigning TBD as the manager for
the Reported state
Transitions
- Defining a transition with New State set to Reported and
New Assignee set to "<Same Assignee>"
- Defining a transition to move a ticket to the In Process and
On Hold states where the assignee is <LoginUser>
(the user performing the task operation).
- Defining a transition to move a ticket to the Closed state
where the assignee is TBD.
Task Fields
- Configuring the History Comment (required) and the following
optional fields to be presented during the
Update Request transition: Title, Product, Platform, Request Type, Severity,
Description, Workaround
- Configuring Description (read only), Est. Close Date (required)
and Priority (optional) to be presented during
the task operation for the transition to the In Process state.
- Configuring Description (read only), Close Detail (required) and Close Date (read only and initialized)
to be presented
during the task operation for the transition to the Closed state.
- Configuring Description (read only), Pending Issues (required),
Est. Close Date (required)
and Priority (optional) to be presented during
the task operation for the transition to the On Hold state.
- State 2 - In Process
The Support Engineer (sup_one) assigned to the ticket
attempts to resolve the issue or request, then chooses
one of the following transitions:
- If the issue is resolved, sup_one
can close the issue by selecting the
transition Close. The Description field is
presented for reference. This
transition will place the ticket in the Closed state and
assign it to TBD ("no one" since this ticket will not be
processed any further). sup_one
will be required to enter a reason the ticket was closed
in the Close Detail field. The Close Date will be updated
automatically.
- If the issue has not been resolved and sup_one
needs to escalate the issue to 2nd Line Support
for troubleshooting assistance, the
Escalate to 2nd Line
transition will be selected. The Description field is
presented for reference.
sup_one is required to enter the reason for
the escalation in the Pending Comments field. This will
place the ticket in the Escalated state, will assign it
to TBD, and place the ticket in the 2nd Line Support queue.
- If the issue has not been resolved and sup_one
needs to escalate the issue to a manager
for troubleshooting assistance, the
Escalate to Manager
transition will be selected. The Description field is
presented for reference.
sup_one is required to enter the reason for
the escalation in the Pending Comments field. This will
place the ticket in the Escalated state, will assign it
to the Support Manager (sup_mgr).
- If the issue cannot be processed until a later (e.g. because
more information is needed or there is some delay before
a task can be performed), sup_one can select
the Hold Request transition. The Description field is
presented for reference. sup_one is required to enter a reason for the
delay in the Pending Issues field and an Estimated Close Date. It is
optional to set the Priority for the ticket. This transition will place the
ticket in the On Hold state, but will still be assigned to the sup_one.
This is implemented by:
Workflow Properties
- Defining Support Manager (sup_mgr)
as the manager for the Escalated state
Transitions
- Defining a transition to move a ticket to the Closed state
where the assignee is TBD.
- Defining a transition to move a ticket to the
Escalated state where the assignee is the manager of that state
- Defining a transition to move a ticket to the
Escalated state where the assignee is TBD (placeholder for the
2nd Line Support queue)
- Defining a transition to move a ticket to the On Hold state
where the assignee is <Same Assignee>.
Task Fields
- Configuring Description (read only), Close Detail (required) and Close Date (read only and initialized)
to be presented
during the task operation for the transition to the Closed state.
- Configuring Description (read only) and Pending Issues (required)
to be presented during the task operation for the transitions to
the Escalated state.
- Configuring Description (read only), Pending Issues (required),
Est. Close Date (required)
and Priority (optional) to be presented during
the task operation for the transition to the On Hold state.
- State 3 - On Hold
Processing was stopped for the tickets in this state. sup_one
can resume processing of a ticket using the Resume Processing
transition. The Description field will be provided for reference and
sup_one will have the option to update the Estimated
Close Date and Priority fields. This will place the ticket in the In Process
state and will remain assigned to sup_one.
sup_one can close the issue by using the Close
transition. The Description field is
presented for reference purposes. This
transition will place the ticket in the Closed state and
assign it to TBD ("no one" since this ticket will not be
processed any further). sup_one
will be required to enter a reason the ticket was closed
in the Close Detail field. The Close Date will be updated
automatically.
This is implemented by:
Transitions
- Defining a transition to move a ticket to the
In Process state with New Assignee set to
<Same Assignee>
- Defining a transition to move a ticket to the
Closed state and assigned to TBD
Task Fields
- Configuring the Description (read only), Est. Close Date (optional), Priority (optional)
to be presented during the Task operation for the transition to the
In Process state.
- Configuring the Description (read only), Close Date (read only, initialized),
and Close Detail (required) fields to be presented for the transition to the
Closed state.
- State 4 - Escalated
2nd Line Support or the Support Manager decides how to proceed with the
issues that have been placed in the Escalated state:
- The issue can be sent back to the sup_one
by using the De-escalate transition. The Description
field will be provided for reference. Comments to
aid sup_one to resolve the issue must be
entered into the Pending Issues field. Optionally, the Priority
of the ticket can be updated. This will place the ticket back
into the In Process state and assign it to sup_one,
who worked on the ticket when it was previously in that state.
- The issue can be closed by using the Close
transition. The Description field is
presented for reference. This
transition will place the ticket in the Closed state and
assign it to TBD ("no one" since this ticket will not be
processed any further). The user (2nd Line Support or the Support
Manager)
will be required to enter a reason the ticket was closed
in the Close Detail field. The Close Date will be updated
automatically.
This is implemented by:
Transitions
- Defining a transition to move a ticket to the
In Process state where the assignee is
<Last Assignee for New State>
- Defining a transition to move a ticket
to the Closed state where the assignee is TBD
Task Fields
- Configuring the Description (read only), Pending Issues (required), Priority (optional)
to be presented during the Task operation for the transition to the
In Process state.
- Configuring the Description (read only), Close Date (read only, initialized),
and Close Detail (required) fields to be presented for the transition to the
Closed state.
- State 5 - Closed
Processing on these tickets has been completed.
Sample Saved Charts
A set of sample saved charts are included in this template.
Click here
to see details of these sample metrics.
Email Notification
The Support template is set up to notify users as
follows:
On Add or Delete of a Record
The current assignee, the manager for
the current state, and the reporter of the ticket are notified
On Change of State to Inactive
The user who reported the ticket is notified when a ticket is moved to
a state where processing has stopped (any state included in the
Inactive state group: Closed or On Hold)
On Change of Assignment
Both the current assignee and the manager of
the current state of the ticket are notified
Security
The Support template assumes a very simple security
model reflecting a workgroup situation where all users are able
to see any ticket. This is implemented by setting
Enable Record Visibility option under General
Preferences in the Administration Task page to
No.
In addition, the privileges related to editing the field of the tickets have
been removed from users that are not managers or Admin.
With this configuration, users can rely on the Task operation to move tickets
through the workflow. This can be changed within the
User Accounts section of the Admin page.
NetResults Tracker © 1997-2014 NetResults Corporation. All rights reserved.