Ticketing System

Software Requirements Specification

Saravanakumar CAD MAcRO Design & Solutions (P) Ltd 11/16/20

Document Distribution List

Name Distributed Date

(Yes / No) (mm/dd/yy)

Modification History

Version Date Documents

Changes made Author Reviewers
No. <mm/dd/yy> Affected

Approvals

Role Organization Authorized Person Response Date

 1. Introduction

Purpose of this document

The Challenge
The challenge was to develop an application which could track service requests within an organization
with content management and performance analysis.

Scope of this document

The Solution
Ticket Management System (TMS) handles work assignments, workflows, document management,
ticket history maintenance, feedback, and chart analytics.
TMS offers the following features:

• Tickets can be assigned to users (and users can view all tickets assigned to or assigned by them).
• A Ticket supports various statuses such as: New, Work in Progress, Fixed, Closed, Rejected by
User, and Reassigned. Also, different priorities as: Low, Normal, High, and Critical are in place.
Both status and priority are configurable.
• E-mail notifications for new and updated tickets.
• E-mail integration allows tickets to be created and updated via e-mail, with support for
attachments. New users can be automatically created.
• Easily customizable as per client’s need.
• Tickets with overdue time-frame are highlighted.
• Auto-escalation of tickets on the basis of priority and specified time-frame.
• High level analytics, charts, and reports.

2. General description

The Help Desk Software is a web application where the company customers can submit support tickets
to be resolved by support staff members and a support forum (that can be seen as a public knowledge
base, FAQs) where the company customers the company support staff members can collaborate
online.

A customer can create a ticket by sending an email to the support email address of the company or by
filling an online form on the support portal of the subscribing company. Once created, a ticket can be
assigned to a support staff member. It is also possible for a support staff member to create a ticket in
the system on behalf of a customer for example when the customer prefers to create a support
requests by phone. The customer and the assigned support staff members are notified by email when
a new comment is made on the ticket or the ticket status is changed and they can reply with a comment
either from an email or by filing an online form. The system will have to keep track of all the
conversation between the customer and the support staff member.

There are two main areas of the Help Desk Software: (1) the subscribing company administration area
where the company help desk administrator can configure the help desk and where the support staff
members can manage the tickets, and (2) the subscribing company support portal where the company
customers can create support tickets and browser the support forums.
The Help Desk Software will also have an API which allows the users, based on their rights in the
software, to interrogate and change the data available for their account. The API and web-based
operations will be synchronized to ensure the data integrity and system rules.

Another requirement for the project, besides the Help Desk Software application implementation, is
the creation of a presentation website for the Help Desk Software. The presentation website will
contain a description of the main features of the Help Desk Software, a page where the companies can
subscribe to the service, a page with subscription prices and will offer the possibility to create pages
with custom content.

The Benefits Before After

Issue tracking was very complex Tracking became simpler without any limit on the
number of issues
Work assignment was manual and time- Work assignment streamlined
consuming
Very difficult to handle many employees Able to handle any number of employees as it’s a
scalable application
Manual document storage Document Management with version, log and
enabled security
Performance reporting and analysis not SLA(Service Level Agreement) time-frame analysis
possible with many customizable reports
User feedback and reviews not captured User feedback and reviews captured with their
history and available for analytics

Overview

Functions Description
View Summary Lists all tickets. Each row displays summary data for a
single ticket.
Create/View Create new tickets, or add or modify notes in existing
tickets.
Delete/Archive Permanently delete tickets or move tickets into archival
storage.
Migrate Tickets Migrate Ticketing tickets to and from Service Desk tickets.
Notify Policy Determine when email notifications are sent out by the
Ticketing module.
Access Policy Determine who can edit and/or display fields in tickets.
Assignee Policy Create policies to automatically assign users to a new or
existing ticket.
Due Date Policy Define default due dates for new tickets based on field
values and email subject lines.
Edit Fields Define, modify, or create ticket fields used to classify
tickets.
Email Reader Setup automatic polling of a POP3 email server to gener-
ate new ticket entries.
Email Mapping Define default field values for new tickets received using
the Email Reader.
 3. Help Desk Software Objects and Concepts
This chapter contains a summary of the main objects and concepts used by the Help Desk Software.

3.1 User Roles, Groups, Departments

There are 3 types of roles a user can have in a Help Desk Software account:

Administrator – this type of user is allowed to do any operation in the account like adding new users,
create and assign tickets. It also includes the Support Staff Member role privileges.

Support Staff Member – a support staff member can create tickets, comment tickets, create end
users and moderate forums

End User – is in general a customer of the subscribing company who can create tickets and eventually
view tickets from other users in the same department when this operation is allowed

The support staff members can be assigned to a Group. A support staff member can be part of many
groups defined in the account. For example, a subscribing company can have a Support Group and a
Sales Group. It is possible to define rules in the system to direct tickets to a group based on some
conditions. Also, a support staff member can be restricted to view and comment only to tickets from
its group.

Support Staff Members and End Users can be assigned to a Department. A support staff member or an
End User can be part of many departments defined in the account. Unlike a group which contains only
support staff members, a department can contain both support staff members and end users. For
example, a subscribing company can define a department for each company that requested and a
support staff member can offer support for many companies (departments). It is possible to define
rules in the system to direct tickets to a department based on some conditions. Also, a support staff
member or an end user can be restricted to view and comment only to tickets from its department.
An end user can be automatically assigned to a department if his email address is from a specified
domain. The access to various sections of the forum of company support portal can be granted at the
department level, which means that some topics of the forum can be accessible only for the support
staff members and end users from a department. It is possible to setup an end user to see all the tickets
in a department this way expanding the tickets visibility and reducing duplicate tickets from multiple
users in the same department.

When the account is created the user, who created the subscription will have both the role of
administrator and support staff member, a Support group will be created and a Department with the
name of the company will be created and the user will part of the Support group and of the
CompanyName department.

All the users of an account (admins, support staff members, end users) have a common login point in
the system (a login page) where they can enter the username (email address) and password. Based on
their role in the system, the users will be presented with a different interface and will be allowed to
do different operations for their role.
3.2 Tickets
A ticket represents a support request from an End User. A ticket can be created by 4 methods.

(1) A ticket is created when an end user sends an email to any email address of the
CompanyName.HelpDeskSoftware.com subdomain assigned to the subscribing company.

(2) A ticket can also be created by an End User by filling a standard form on the support portal and
submitting that form.

(3) A support staff member can also create a ticket from his administrative area on behalf of a
customer (this can be useful for example when a company accepts support tickets by phone).

(4) A ticket can be created by an API call

The ticket will maintain an information about the method used for its creation.

For example an email sent to support@CompanyName.HelpDeskSoftware.com or at

sales@CompanyName.HelpDeskSoftware.com will create a ticket. A ticket can be updated by
support staff members or by end users. Examples of ticket updates are commenting, type changing,
priority changing, assigned group or staff member changing and status changing.

The commenting of the ticket can be made either directly by email or by using the Help Desk Software
web interface. For example, when the ticket gets assigned to a support staff member (a support staff
member can be assigned to a ticket by another support staff member having access to the ticket), the
support staff member will be notified by email with the request sent by customer and will be able to
reply to this email to update the ticket. Alternatively, the support staff member can log in to Help Desk
Software and comment the ticket from there. The end user will be notified about the support staff
member comment by email and will be able to respond to that email with his comment or he can log
in to his account and comment the ticket from there.

3.2.1 Ticket Attributes

Any ticket has the following set of attributes, some of them being optional:

Requester – is the name of the user who created the ticket. This is a required attribute.

Subject – is the ticket subject. This is a required attribute.

Description - is the first comment on the ticket and contains a description of the ticket. This attribute
is required

Status – is the ticket status. A ticket can go through many states during it lifecycle as detailed in the
section 3.2.4. The status is a required attribute.

Type – the ticket type as described in section 3.2.2. The type is an optional attribute

Priority – the ticket priority as described in 3.2.3. The priority is an optional attribute

Group – is the support staff members group to which this ticket is assigned. This is an optional
attribute.

Assignee – is the support staff member assigned to handle this ticket. This is an optional attribute.

Keywords – is a list of the tags used to offer a hint about the ticket content and it is used for fast
search operations. The keywords is an optional attribute.

Custom Attributes – a ticket can have many custom attributes. The custom attributes that can be
assigned to a ticket can be of many types. The custom attributes can be used anywhere a standard
attribute can be used in the system.

3.2.2 Ticket Types

There are four possible types of tickets: Question, Incident, Problem and Task.

The Question ticket is a question for the support staff and is the simplest type of ticket. The possible
attributes for a Question are the common attributes described in 3.2.1.

An Incident is an issue generated by a problem. An incident can be linked to a Problem ticket and when
the Problem ticket is solved all the incidents linked to the problem are automatically marked as solved
(see the Ticket States section for more details about the ticket lifecycle). An Incident has all the
common attributes and optionally an attribute to link to the problem that generated the incident

A Problem ticket represents a problem that needs to be solved. A problem can generate many
incidents. When a problem is solved, all the Incident tickets linked to that problem are automatically
marked as solved. The possible attributes of a problem are common attributes for a ticket.

A Task is an assignment that have a date and time for completion. The completion date and time is
an additional attribute for the Task ticket besides the common ticket attributes.

3.2.3 Ticket Priorities

There are four priorities that can be assigned to a ticket: Low, Normal, High and Urgent.

3.2.4 Ticket States ( Ticket Lifecycle )

The status of ticket can be changed automatically by the system as result of an action or manually by
a support staff member. A ticket can be in one of the following 4 states:

New - This is the initial status of the ticket after it has been created. After the ticket moved into a
new state it will never go back to New state

Open – This is the state automatically entered by a ticket after it has been assigned to a support staff
member and indicates the ticket is under work. A ticket can go from Open to Waiting or Solved when
manually assigned to one of these states by a support staff member.

Waiting – A support staff member can put an open ticket into this state to indicate that some
feedback from the end user is expected and the work cannot continue until that information is
provided by the end user. A ticket can go automatically from Waiting to Open when the end user
comments the ticket.

Solved – An open ticket can be put by a support staff member in the Solved state which marks that the
support staff member and the end user agreed on a resolution. A Solved ticket can go to Open or
Closed state. A support staff member can manually move a ticket from the Open to Solved state. A
Solved ticket can automatically enter the Closed state if it wasn’t reopened for a number of days (this
is a setting at the account level)

Closed – This is the final state of the ticket. A ticket can enter the Closed state only automatically
when a solved ticket is not reopened for a specified number of days. A Closed ticket can
automatically go to Open state when the ticket is updated. A support staff member can manually
move a ticket from the Closed to Open state.

3.3 Emails Processing

Emails processing is the heart of the Help Desk Software. The final result of the emails processing is
the creation and the commenting of the tickets.

When a subscribing company creates an account a subdomain of the Help Desk Software presentation
website is automatically created. An example of such a subdomain is
CompanyName.HelpDeskSoftware.com, where the CompanyName is the name of the subscribing
company and the HelpDeskSoftware.com is the presentation website for the Help Desk Software.

Any email sent to any email address from CompanyName.HelpDeskSoftware.com becomes a ticket
or comment to a ticket in the Help Desk Software account of the company.

3.3.1 Catchall Mailboxes

There will be a set of catchall mailboxes defined in the mail server collecting all the emails sent to all
the accounts in the Help Desk Software (the number of catchall mailboxes is predefined but it can be
changed from Help Desk Software administration area – by default, will be 30 catchall mailboxes
defined in the mail server). There will be a hash table mapping an account to a catchall mailbox (for
example a hashing algorithm would be to sum character codes of the account owner email address
and divide that sum to the number of catchall mailboxes, the rest of division giving the catchall mailbox
index). All the emails for an account will get into the catchall mailbox designated by the hash table
mentioned above. There will be a set of threads (one thread per catchall mailbox) continuously
retrieving emails by POP3 and parsing emails from the catchall mailboxes and making the necessary
updates against the ticket to which the email belongs.

For example, an email sent to support@CompanyName.HelpDeskSoftware.com or to

sales@CompanyName.HelpDeskSoftware.com will get into the
catchall_nnn@CompanyName.HelpDeskSoftware.com mailbox, where nnn is the hash index of the
catchall mailbox corresponding to the account for CompanyName. The thread associated with the
mailbox will retrieve the email and find that it was sent to
support@CompanyName.HelpDeskSoftware.com (see below how an email from the catchall mailbox
can preserve the original destination) and will determine the email was for CompanyName. From the
email content the thread will determine the ticket associated with this message (see below the
methods used to associate a message with a ticket) and will update the ticket or create a new ticket if
no ticket associated with the message is found.

Because emails sent to different accounts get into the same mailbox there should be a way to
differenciate the emails and find out to which account and to which address the message was initially
sent. Therefore, the message received in the catchall mailbox will have a custom header indicating the
initial email address where the message was sent
(e.g.support@CompanyName.HelpDeskSoftware.com or
sales@CompanyName.HelpDeskSoftware.com ). The initial email address also necessary for other
operations, for example when we want to automatically assign the emails sent to
sales@CompanyName.HelpDeskSoftware.com to the Sales staff group and the emails sent to
support@CompanyName.HelpDeskSoftware.com to the Support staff group or when we want to
customize the From and the Reply To address of a messages sent by the staff members to appear as
coming from the same mailbox where the email was initially sent.

3.3.2 Emails Forwarding

A subscribing company can choose to accept support requests directly to an email address from
CompanyName.HelpDeskSoftware.com subdomain or it can choose to accept support requests to an
email address from its domain (e.g. support@CompanyName.com ) and then automatically forward
all the emails received at support@CompanyName.com to an address from subdomain ( e.g.
support@CompanyName.HelpDeskSoftware.com ) .

An account has a Default, Sender And ReplyTo Email Address

( e.g. support@CompanyName.HelpDeskSoftware.com ) which is used as sender (From field) and
as a Reply To address for the comments sent by help desk staff members to end users. This
default, Default, Sender and ReplyTo Email Address can be configured in the account.

The Default, Sender and ReplyTo Email Address is normally a mailbox from the help desk account
subdomain but the company can decide to use an email address from its own domain ( e.g.
support@CompanyName.com ). In this case the company should configure its email server to
automatically route all the emails from support@CompanyName.com to an email address from the
help desk account subdomain and to add a SPF record to DNS configuration to lower the risk of emails
coming from the help desk to be treated as a spam. A SPF ( Sender Policy Framework ) record is a DNS
TXT record which specifies the SMTP servers that are authorized to send emails on behalf of the
company.

3.3.3 Subdomain Mapping

The web address of the support portal for a company is a subdomain like

http://CompanyName.HelpDeskSoftware.com. A company has the possibility to map its own domain

to this subdomain, e.g. http://support.CompanyName.com , such that the company users will see a
web address from the company domain instead of a Help Desk Software subdomain. In order to do
this a company has to set the mapped domain (http://support.CompanyName.com ) in the account
and additionally will have to add a CNAME DNS record in its DNS table to create an alias for the
mapped domain.

3.3.4 Preserve Sender Mailbox Name

Another option for emails processing is to Preserve Sender Mailbox Name. This option is off by default,.
When this option is on the mailbox name where the message was sent will be used in the sender email
address. For example, if the message entered the help desk at the
sales@CompanyName.HelpDeskSoftware.com address the mailbox name is sales. The domain name
of the email address will be taken from the Default, Sender and ReplyTo Email Address. For example,
it can be an email address from help desk subdomain, e.g.
support@CompanyName.HelpDeskSoftware.com, and in this case the sender email address will be
sales@CompanyName.HelpDeskSoftware.com or it can be an email address from company domain,
e.g. support@CompanyName.com , and in this case the sender email address will be
sales@CompanyName.com .
3.3.5 Reply To Address Mapping

The account administrator will also have the possibility to define a list of mappings between the
email address on CompanyName.HelpDeskSoftware.com domain to which the email was received
and the Reply To address used in the response message to end user. For example, the administrator
can define a mapping from support@CompanyName.HelpDeskSoftware.com to
support@NewCompanyDomainName.com . When a message (the message can be a new ticket or a
comment to an existing ticket) is received at support@CompanyName.HelpDeskSoftware.com and an
agent responds to this message, the From address and the ReplyTo address of the response email will
be support@NewCompanyDomainName.com .

The Reply To Address Mapping has priority over the Default, Sender and ReplyTo Email Address and
over the Preserve Sender Mailbox Name option.

3.3.6 Personalized Sender Email Address

Another option is to use Personalized Sender Email Address. When this option is true the name of
the help desk staff member is included in the email sender address and replyto address when the
staff member comments a ticket. By default, this option is true. When is false a generic name will be
used for all the help desk staff members?

Any ticket has an unique ID which is a sequential number for the account. The IDs can be configured
to start from a specified number such that the real number of tickets received by the company is not
disclosed.

3.3.7 Tickets and Comments Association

When the tickets are commented by email there must be a way to correctly track to which ticket the
comments belong and create a thread of discussion for the ticket. There are 2 methods of maintaining
the thread of discussion for a ticket, the second one being used as a backup for the first one.

The main method is based on the Message-ID and in In-Reply-To email headers. When a email
message is received in the help desk account is parsed and the a message ID is extracted from the In-
Reply-To email header if this header exists. Then the message ID is searched in the database to see if
there is any ticket containing a comment with that ID. If such a ticket is found the comment is added
to the ticket. If the message does not contain an In-Reply-To header then the second method for
constructing the thread of discussion is used. If the ticket cannot be found based on the second
method then a new ticket will be created and the new ticket ID will be added to the subject of the
future ticket comments.

The second method for finding the ticket of a comment consists in maintaining the ticket ID in the
subject of the comments. A special marker like (Ticket #nnnn) is added to the subject of the ticket
comments. When the help desk receives an email, it will try to extract the ticket ID from the subject.
This ID will be eventually used as a backup method to associate a comment with a ticket when the
main method described above fails.

When a message is sent by the help desk software a unique ID is generated for the message and
associated with the message so it can be searched in the future by the message ID extracted from
the In-Reply-To header.

3.3.8 Plain Text and HTML Content of a Comment

In general, the emails are sent with multipart/alternative as Content-Type which means that there is
part containing the message as plain text and a part containing the message as HTML if the message
was created as HTML and contains rich text.

The Help Desk Software will keep track of both plain text and html content for the ticket comments.
The plain text is useful for a simple presentation of the tickets and for text search operations in
database while the HTML is useful for presenting a rich content.

When a comment is made online from the Help Desk Software web interface, the users will have the
possibility to write the comment in a HTML editor. When the email notification for this comment is
composed, the plain text will be extracted from HTML and both plain text content part and HTML
content part will be included in the message. The plain text from the previous comments will also be
added both at plain text and in HTML versions of the comment being created.

When a message is received by the Help Desk Software both the plain and html content are
extracted. If it’s a new comment to a ticket then the previous comments are eliminated from the plain
text (the previous comments are also sent in email notifications to maintain the discussion thread)
and only the current comment in plain text format is recorded in the database (the next section
explains how to extract the latest comment from the discussion). If the comment also has a HTML
content this content will be saved unchanged in a file outside the database from where it can be
displayed on demand by users.

3.3.9 Ticket Comment Extraction and Comment Delimiter in Email Notifications

In order to extract the content of the latest comment from an email containing all the discussion
thread it is necessary to add a delimiter to the top of the email notification. All the content above
the delimiter will represent the latest comment from the thread. The latest comment will be
extracted only from the plain text, the HTML content will be fully saved in a file on a files server as
explained in the previous section.

The comments delimiter can be configured in the account.

3.3.10 Email Aliases and CCs for End Users

An End User can reply to a comment using an address different from the email address used when he
sent the initial request. In this case the new email address will be added as an alias to the end user
profile.

Also, an end user can add other email addresses to CC list when they create a ticket by email. If CCing
is enabled in account administration, the CC recipients will receive email notifications on future
updates of the ticket. The CC recipients will be able to add comments to the ticket either by replying
to the email notification or using the online portal.

An end user can add CC recipients via email any time during the ticket lifecycle. Only help desk staff
members can delete CC recipients once they have been added. When CCing unknown end users in an
open help desk via email, the new users will be created automatically if users are not required to
register to access the help desk. Maximum 10 CCs are allowed for a ticket during its lifecycle to avoid
sending notifications to a very large number of users.
CC recipients are notified by email when a ticket is commented and the CC was not notified by any
conditional action and the CC recipient is not the author of the comment.

There will be an option in the account administration area saying if only staff members are allowed
to add CCs. IF only staff members are allowed to add CCs then CCs on emails from users will not be
added to the ticket.

There will be an option to define a list of Forbidden CCs containing a list of email addresses which are
never CCed.

The text informing the CCed recipient that has been added to the CC list of a ticket can be
customized in the account administration area.

3.3.11 Tickets Assignment in Help Desk

When an end user sends a request by email or from web interface a ticket is created in Help Desk. If
there is a single group of staff members and a single staff member in that group then the ticket will be
automatically assigned to that staff member and the staff member will be notified by email about the
assignment. If the ticket is assigned to group because of an existing mapping between organizations
and groups or because of a custom conditional action defined in the account, all the staff members in
group will be notified about the assignment of the ticket to their group (if there is a single staff member
in the assignee group, the staff member will be automatically assigned to that ticket and will be notified
by email about the assignment). If the ticket is not assigned to any group or staff member then all the
staff members allowed to access the ticket will be notified about the unassigned ticket.

Any staff member can respond to an unassigned ticket and in this case only the requester will be
notified about the comment.

A staff member can login to Help Desk and assign the ticket to himself or to another staff member. In
this case the ticket will become assigned and the assignee will be notified by email about the
assignment.

3.4 Users Adminission in Help Desk Account of a Subscribing Company

The help desks for an account can be a Private Help Desk or a Public Help Desk, based on a
configuration property in account.

Private Help Desk – only the previously registered end users can send support requests. If an unknown
end user sends a request then a ticket in a suspended state will be created. An agent can choose to
manually or automatically recover the suspended ticket and transform it into a normal ticket. When
the ticket is recovered the ticket will become a normal ticket and the unknown end user will be added
to the list of end users and will be notified to register in order to see the ticket status online.

Public Help Desk – any user can submit a request. This is the default, option.

For a public help desk there is the option to Ask End Users to Register. This option is not enabled by
default, for a public help desk and all the request are received as tickets, but if it’s enabled then the
tickets sent by an unknow user are suspended and the unknow user are automatically notified by
email to register in order to see the ticket details online.

For an public help desk it is also possible to define 2 lists, White List and Black List, containing the
domain names from which the tickets are always accepted or always rejected (means that the tickets
are put in a suspended state)

3.4.1 Users Adminission Procedure in a Public Help Desk

The behavior of a public help desk depends on if Ask End Users To Register option is enabled or not.

3.4.1.1 Ask End Users To Register is Not Enabled

The most permissive help desk is the public help desk when the Ask End Users To Register option
is not enabled.

In this case the company support portal entry page will contain a web page with 3 tabs:

(1) A Home tab with a content that can be defined in administration area. This tab contains
forum topics marked as Pinned to Home Page in forum topic properties.
(2) A Forums tab containing all the forum visible to everybody
(3) A Submit a Request tab where the end user can send anonymously (while not logged in) a
request.
(4) A Login to Check or Submit Requests tab which is a login page where the user can enter the
username and password to login and also the links to signup in order to send requests or to
recover the password.

The Home tab can contain forum topics pinned to the home page (this procedure will be described in
a later section) and which are marked as available for everybody in Forum administration. It is also
possible to display a Search Box on the home page which can be used to search for a text in forum
topics.

The Submit a Request tab is used to send requests while not logged in to the help desk because this
operation is permitted by a Public Help Desk with Ask Users to Register option disabled. In order to
submit an anonymous request, the end user must provide an email address, a subject, a description
and pass a captcha verification. Submitting a request anonymously is equivalent to sending directly an
email to the help desk email address.

If the end user already has a username and password in help desk, he will be able to login in the Login
to Check or Submit Requests and check status of his existing tickets or submit new tickets. If the end
user does not have a help desk account but he still wants to send requests as a logged in user he can
choose to signup online. For signup he will fill a form with Full Name, Email address, password and a
captcha to ensure that the signup is performed by a human and not a computer. After the signup form
is submitted a verification email will be sent to the registered email address containing a link to a
temporary page where the user can choose a password and login into help desk account. After the end
user account was verified, he will be able to login using the email and the chosen password at any time.
If the end user is already registered in help desk either because he previously submitted a signup
form or because he sent a support request by email or submitted an anonymous request online, he
will be able to ask for an email with a link to a page where to reset the password and login to his
account.

The requests submitted by unknown users by email are accepted as normal tickets and the user will
be registered in the help desk as a not verified user and will be notified by email to verify his email
address. Even if he wasn’t verified, the user will still be able to communicate with the help desk staff
by email. However, in order to see the ticket status online and all the other tickets submitted in the
past the end user will have to login. The requests submitted by unknown users by email is equivalent
to submitting an anonymous request online.

3.4.1.2 Ask End Users To Register is Enabled

In this case the company support portal entry page will contain a web page with only 2 tabs:

(1) A Home tab with a content that can be defined in administration area. This tab contains
forum topics marked as Pinned to Home Page in forum topic properties.
(2) A Forums tab containing all the forum visible to everybody
(3) A Submit a Request tab where the end user can send anonymously (while not logged in) a
request.
(4) A Login to Check or Submit Requests tab which is a login page where the user can enter the
username and password to login and also the links to sign up in order to send requests or to
recover the password.

The Home tab can contain forum topics pinned to the home page (this procedure will be described in
a later section) and which are marked as available for everybody in Forums administration. It is also
possible to display a Search Box on the home page which can be used to search for a text in forum
topics.

The Submit a Request Anonymously tab where the end user can send anonymously (while not logged
in) is not present anymore.

The end user will have to login before sending requests online. An end user can still send emails
directly to the help desk email address or anonymously but the tickets he sends will be put in a list of
suspended tickets. Also the after an end user send anonymously a request he will receive a notification
asking to choose a password and login to account. After the end user has chosen a password and
logged in to account the suspended ticket will become a normal ticket. The end user will be notified
that the ticket was received and the help desk staff members will be notified that a new ticket has
arrived.

Also, a suspended ticket can be recovered by a staff member and transformed into a normal ticket.
In this case the end user will be admitted in the help desk (with the unverified status) and the next
tickets created by the user will not enter in the suspended tickets list.
3.4.2 Users Admission in a Private Help Desk
In a Private Help Desk the user must be previously register by the help desk staff before sending
requests.

The support portal entry page for a Private Help Desk contains:

(1) A Home tab with a content that can be defined in administration area. This tab contains
forum topics marked as Pinned to Home Page in forum topic properties.
(2) A Login link to login page where the user can enter the username and password to login. There
are no links to signup only a link to a page where the end user can request to receive a link to
a page where to reset the password.

The Home tab can contain forum topics pinned to the home page (this procedure will be described in
a later section) and which are marked as available for everybody in Forums administration. It is also
possible to display a Search Box on the home page which can be used to search for a text in forum
topics.

An anonymous request by email produces a suspended ticket that can be recovered by a help desk
staff member to transform it into a normal request. In this case the end user will be notified by email
with a link to a web page where to choose a password in order to be admitted in the help desk.

3.4.3 Support Portal Home Page for a Logged In End User

After an end user was admitted in the help desk, he can use a username and a password to login.
After login, the landing page for the account will contain 3 tabs:

(1) A Home tab with a content that can be defined in administration area of the subscribing
company account.
(2) A Forums tab containing all the forum visible to logged in users
(3) A Submit a Request tab where a logged in end user can send a request.
(4) A Manage Your Requests tab where a logged in end user can see all his requests and submit
comments.

The Home tab contains forum topics pinned to the home page (this procedure will be described in a
later section) and which are available for the logged in user based on his privileges (some forums are
available only for help desk staff members and other forum topics are available for everybody or for
everybody who was logged in). It is also possible to display a Search Box on the home page which can
be used to search for a text in forum topics.

The Forums tab contains all the forums which are available for the logged in user based on his
privileges (some forums are available only for help desk staff members and other forum topics are
available for everybody or for everybody who was logged in).

The Submit a Request tab contains a form with the ticket Subject and Description that the user can fill
and submit to create a ticket.

The Manage Your Requests tab displays the list of tickets visible to the user based on his privileges.
3.4.3 Support Portal Home Page for a Logged In Administrator

An administrator can use a username and a password to login. After login, the landing page for the
account will contain 4 tabs:

(1) A Home tab with a content that can be defined in administration area of the subscribing
company account.
(2) A Forums tab where the administrator can edit the company forums
(3) A Manage menu where the administrator can choose to manage People, Views, Macros,
Reports, Tags, Ticket Fields, Conditional Actions and Mail Notifications, Automations, System
Level Targets
(4) A Account Settings menu where the administrator can choose to Personalize the account,
setup Mails And Domains, User Admission, Ticket Options, Security, UI Panels, Support
Own Cloud, Targets, Company Profile, Subscription.

The Home tab contains forum topics pinned to the home page (this procedure will be described in a
later section) and which are available for the logged in user based on his privileges (some forums are
available only for help desk staff members and other forum topics are available for everybody or for
everybody who was logged in). It is also possible to display a Search Box on the home page which can
be used to search for a text in forum topics or to display a categorized list of forums on the home page.

The Forums tab contains all the forums which are available for the logged in user based on his
privileges (some forums are available only for help desk staff members and other forum topics are
available for everybody or for everybody who was logged in).

The Manage menu where the administrator can choose to manage People, Views, Macros, Reports,
Tags, Ticket Fields, Conditional Actions and Mail Notifications, Automations, System Level Targets.

The Account Settings menu where the administrator can choose to Personalize the account, setup
Mails And Domains, User Admission, Ticket Options, Security, UI Panels, Support Own Cloud, Targets,
Company Profile, Subscription.

4. Help Desk Account Administration

This chapter contains a summary of the administrative options available when the Help Desk account
administrator is logged in. Some of the options were already mentioned in previous chapter and they
will be detailed in this chapter.

Some administrative operations are available both for admins and with some possible restrictions to
the other staff members (Help Desk operators).
 4.1 Help Desk Account Administration for Admin Users and Staff
Members
4.1.1 Forums Administration

The forums are a collection of discussion topics which are related. Each topic is a collection of
comments on a subject. The forums can be grouped in categories or they can be uncategorized.

The administrator can add forum categories, can add forums to categories and can add topics to a
forum.

When the administrator adds a category of forums he is asked to provide a name for category and a
description for the category.

When the administrator adds a forum he is asked to provide the following information:

- Forum Title
- Forum Description
- The category to which this forum belongs or None if the forum is not categorized
- Forum Visibility (Everybody, Logged in Users, Staff members Only)
- Who can create new topics in forum (logged in users, Unrestricted staff members and
moderators)?
- Restrict access to a list of departments or set access as unrestricted to a department

When an administrator adds a topic he is asked to provide the following information:

- The forum to which this topic belongs

- The topic content in HTML format
- A list of tags for the content which helps in search operations
- Choose if the comments are allowed for the topic
- Choose if the topic is pinned on the home page
 - Allow the creation of a list of attachments for the topic

4.1.2 Users, Groups and Departments Administration

There are 3 categories of users: End Users, Staff Members and Administrators. The Support Staff
Members can be grouped in Groups (e.g. Support group, Sales group etc). The End Users are the
company customers creating support tickets. Support Staff Members and the End Users can be linked
to a department (e.g. a department represents the relationship with a company). See section 3.1 for
more details.

When the Help Desk account is created during signup process the following objects are automatically
created:

- An user with the roles of Administrator and Support Staff Member. The name and the email
adress of this user are those specified at account signup
- A department having the name of the subscribing company specified at signup. The
administrator who created the account is automatically added as member of the department
- A group of staff members named Support having the administrator who created the account
as a default, member

An administrator can add end users, agents and other administrators. A Support Staff Member can
add only end users.

4.1.2.1 Adding New Users

When adding a new user the following information is requested:

- Name – required - is the display name of the user used throughout the help desk
- Email – required - used when logging in
- Phone number – optional
- Time Zone – required - users can have their own personal time zone added to their account.
This enables the end users or staff members that might be in different locations to see the
various timestamps in Help Desk relative to their own time zone, rather than the global time
zone of the account. The time zone of the account is automatically determined from the
information provided during web browser request when the account is created and can be
later changed from Account Personalization
- Detailed Information – optional - detailed information about this user like address. This
information is visible to agents only.
- Notes – optional - notes concerning the user
- Department – optional – the departments are used for example to group end users and staff
members in companies. It is possible to setup users within an department to see each other’s
tickets, expanding the tickets visibility and reducing duplicate tickets from multiple users in
the same department. When the Department is not set the default, department mapping will
be applied. By default, the user is not assigned to any department.
- Role – required – can be End User (an end user submits support tickets to the help desk), Staff
Member (a staff member is a help desk operator who receives and resolves tickets from end
users), Admin (manages the help desk rules, users, organizations, groups, has access to all
tickets). The default, role is End User.
If the Role is set to End User the following additional information is requested:

Tickets Access – required – the user can have access only to tickets created by the user or the user
can have access to all the tickets in the user department. If the user belongs to a shared department
(a shared department allows all the end users in the department to view tickets from all users in the
same department), this will override the ticket access option and the user always has access to the
tickets in that department.

If the Role is set to Staff Member the following additional information is requested:

Member of Groups – required – is a list of groups to which this staff member belongs. If there is only
one group the staff member will be automatically assigned to this group, otherwise he won’t be
automatically assigned to any group

Tickets Access – required – the staff member can have access to all tickets (in this case the staff
member can also add or modify tickets and can assume the role of an end user), can have access to
the tickets requested by the end users in a agent’s organization (in this case the staff member cannot
see forums in other organizations) or can have access only to tickets that were assigned to this staff
member.

Type of Comments Can Add – required – the type of comments the staff member can add can be
Public and private or Private Only (the private comments are visible only to staff members)

Can Moderate Topics in Forums (edit, delete, reorder topics) – required – default, is No

If the Role is set to Admin the following additional information is requested:

Group - required – the support staff group to which the admin is assigned. If there is only one group
the admin will be automatically added to this group, otherwise the admin won’t be assigned to any
group

4.1.2.2 Adding New Groups

The groups are used to categorize the staff members. For example, a company can define groups like
Support, Sales, PR, etc. By default, when the account is created a Support group is also created by
default, this group will have as default, member the admin who created the account.

When creating a group, the required information is the Group Name. It will also be possible to select
the staff members to be added to this group.

4.1.2.3 Adding New Departments

The departments are used to group together end users from a company and staff members responding
to tickets from those end users. It is possible to setup users within an department to see each other’s
tickets, expanding the tickets visibility and reducing duplicate tickets from multiple users in the same
department.

The same end user can belong to many departments and the same staff member can belong to many
departments. The forums access can be restricted to some organizations.
The information requested when creating a new department is:

Department Name – required

Detailed Information – optional – information regarding the department

Notes – optional – notes about the department. Notes are visible only to staff members and not to
end users

Users to Department Mapping – optional – is a list of email domains separated by space (e.g.
domain1.com domain2.com). The users from those email domains are automatically set as members
of that department. When this list is changed all the users are scanned to see if they have to be made
members of the department.

Organization to Group Mapping – optional – this option allows to automatically assign incoming
requests from users in this department to a staff members group

Shared Department for End Users – this is an option which allows all End Users in the department to
view tickets from all users in the same department. A tab will appear in the end user’s portal giving
access to views to all tickets in the department. When Shared Department option is enabled, an
additional option will be enabled which allows End Users in department to add comments to all tickets
in the department

4.1.2.4 Manage existing Users, Groups and Departments

There will be a separate list for end users, staff members, admins, groups and departments. For each
element in the list (an element can be a user, staff member, etc.) there will be an edit button which
allows to modify the element properties and a delete button which allows to delete an element from
the list.

4.1.2.5 Assume the Identity of Another User

In the list of users, besides the Edit button there will be an Assume button which allows an admin or a
staff member to assume the identity of another user with lower or equal privileges. For example, an
admin can Assume the identity of any other admin, staff member or end user. A staff member can
assume the identity of another staff member or end user. An end user cannot assume other identities.
There will also be possible to assume the identity of an anonymous end user

When a user assumed the identity of another user, he will see the Help Desk from the perspective of
that user. There will be an option to revert the identity to the initial identity.

4.1.3 Tickets Views Administration

Views are used to select a group of tickets based on a condition. There are a few predefined views
like My unsolved tickets, Unassigned tickets, all unsolved tickets, Recently updated tickets, New
tickets in your groups, Pending tickets, Recently solved tickets, Unsolved tickets in your groups,
Current Tasks, Overdue tasks.
A view can be deactivated or cloned. Views are available in a VIEWS tab in the header of every
administrative page. Deactivated views are never included in the VIEWS tab and the views without
tickets are displayed as grayed.

There is also the possibility to define a custom view. When adding a custom view the following
information is requested:

View Title – required – is the name of the view

Filtering Condition – required – the condition is the result of the logical AND on 2 conditions: Meet
ALL Condition (such a condition is met if all the sub-conditions in a list of sub-conditions are satisfied)
and Meet ANY Condition (such a condition is met if any of the sub-conditions in a list of conditions
is satisfied).

For example, the condition below will filter all the urgent tickets which are tasks or problems

Meet ALL of the following conditions (Meet ALL Condition):

Ticket Priority is Urgent (sub-condition)

(Logical AND with)

Meet ANY of the following conditions (Meet ANY Condition)

Ticket Type Is Task (sub-condition)

Ticket Type Is Problem (sub-condition)

Formatting Options – required – choose a default, output format for the view which can be list or
table

View Access – required – defines the users who can use the view and can be All Staff Members, Staff
members in My Groups, Only Me
 4.1.4 Macros Administration
Macros are predefined responses for tickets enabling a staff member to quickly respond to common
requests with a standard reply. Macros can also set ticket properties (type, priority, comment, etc)
and can be applied when a staff member creates or updates a ticket. Macros can be grouped in
categories.

There will a predefined set of macros. It is possible to create a custom macro. The information
requested when creating a custom macro is:

Macro Title – required – is the macro name

Actions List – required – the list of actions performed by the macro (e.g. Set Priority to Urgent, Set
Type to Problem, etc.)

Macro Access – required - defines the users who can use the macro and it can be All Staff Members,
Staff members in My Groups, Only Me
 4.1.5 Reports and Exports Administration
There is a series of predefined reports available for staff members and there is also the admins have
also the possibility to define new reports based on some conditions similar to conditions for Tickets
Views described in section 4.4. The admins have also the possibility to edit the predefined reports.

The predefined reports are Unresolved Tickets Evolution, High and Urgent Priority Tickets, Incident
Evolution, Resolution Times, Ticket Priorities.

When adding a new report, the required information is:

Reporting Period – required – it can be a period Relative to Today and in this case the options are to
create the report for the Last Week, Last 2 Weeks, Last Month or Last 3 Months or it can be a Custom
Interval specified by a start date and an end date for the report.

Data Series – required – represents a list of data series displayed in the report chart. When adding a
data series, the required information is the name of the series used in chart legend, the type of tickets
considered for the data series (can be Created Tickets, Resolved Tickets, Unresolved Tickets, Old Tickets
or All Tickets) and a set of filtering conditions to select the Tickets in the data series.

For example a report can be Evolution in Last Week of High Priority Tickets in Support Group and Urgent
Tickets in Sales Group. In this case the Reporting Period is Relative to Today for 1 Week. There will be
2 data series: a Support Tickets data series containing tickets of type Unresolved Tickets with condition
Groups Is Support and a Sales Tickets data series containing tickets of type Unresolved Tickets with
condition Group Is Sales.

Besides the only reports, it is possible to export the data in the Help Desk in CSV or XML format. A
Staff Member can request to export data. The export creation is asynchronous. The staff member
who requested the export will be notified by email when the export is ready and will receive a
download link for the export. In the administration area there will be a link to the latest CSV or XML
export created and this link will be available for the other staff members and admins.
 4.2 Help Desk Account Administration for Admin Users Only

4.2.1 Tags Administration

Tags are placed on tickets and on forum topics to help searching from information in help desk. The
administrators will be able to display a list with the most used 100 tags. This list is updated once a
day.

When clicking on a tag in the list all the tickets and forum topics tagged with that tag will be
displayed.

4.2.2 Ticket Attributes Administration

The tickets defined in the Help Desk have a set of attributes as described in section 3.2.1. Some of
the attributes are predefined (Subject, Description, Status, Type, Priority, Group and Assignee) but
there is also the possibility to define custom attributes for tickets which can participate in any
mechanism of the Help Desk (Views, Conditional Actions, etc.) like any predefined attribute.

The predefined attributes for tickets can be edited by administrators. The administrators can also
define new attributes for tickets. The information required when defining an attribute are:

Attribute Type – required – can be selected from following options: Drop Down List, Text, Multi-Line
Text, Integer, Decimal, Checkbox, Regular Expression

Attribute Title – required – the name of the custom attribute

Attribute Title for End Users – optional - the name of the attribute as it is displayed for end users in
case the default, Attribute Title is not suitable for being viewed by end users

Required for Agents – required – an option saying if the attribute can be left blank or not when the
ticket is solved. Default, is false and the attribute can be blank

Visible for End Users – required – an option saying if the attribute is visible for end users. Default, is
false. If it is set on true then an additional selection is necessary asking if the Attribute is Editable by
End Users (default, is false). If the attribute is editable by the end users then an optional attribute
description for end users can be entered and also it is possible to select if the editable attribute can
be left blank or not by end users.

For other types of attributes additional information will be required. For example, for a custom
attribute of type drop down list it will be possible to define the list of items in the drop-down list.
 4.2.3 Conditional Actions Administration
The conditional actions are used to perform an action when certain changes are applied to a ticket.
For example, a possible conditional action is to send a notification by email to the ticket requester
when a staff member makes a comment on the ticket.

The order of the conditional actions is important because a conditional action can do actions based
on the changes made by previous conditional actions.

When a ticket is changed all the conditional action will be run one by one in the order they are
defined. For each conditional action the condition is evaluated and if it is met then the actions are
executed. If the actions changed the ticket then this will cause all the conditional actions to be
evaluated once more in the order they are defined.

Important Note: In order to avoid the infinite recursion when executing the conditional actions, if a
conditional action was executed then it will not be executed again when the ordered list of
conditional actions is reevaluated again after a previous conditional action changed the ticket.

The event history for a ticket will keep a detail track of each change that was made to a ticket: when
it happened, who caused it and which conditional actions were executed.

Invalid conditional actions will not be executed (e.g. setting an unassigned ticket to Solved state).

Conditions are used to select the tickets for which do to something when they are created or updated.
The conditions are grouped into 2 sections: Meet ALL of the Following Conditions and Meet ANY of
the Following Conditions.

In general only the conditions in the ALL section will be used but there are cases when is needed to
match a ticket attribute that can have more than one value. For example, the following conditional
action will notify by email the Special Group when a ticket with high or urgent priority is created:

Meet ALL of the Following Conditions:

Ticket Status Is New

Meet ANY of the Following Conditions:

Ticket Priority Is High

Ticket Priority Is Urgent

Actions:

Notify by Email Special Group

Conditions are in the format Attribute Operator Value, for example Status is New or Requester is
User1 . The Value and Operator are optional. For example, Priority Changed is a valid condition (the
Attribute is Priority and the Operator is Changed, the Value is missing). Ticket is Updated is another
valid condition (the tested Attribute is Ticket is and the Value is Updated)
The available operators depend on the tested attribute. The most common operators are:

Is – condition is TRUE if the attribute current value equals Value

Is Not – condition is TRUE if the attribute current value does not equal Value

Less Than – condition is TRUE if the attribute current value is less than Value Greater

Than – condition is TRUE if the attribute current value is greater than Value Changed

– condition is TRUE if the attribute value changed

Changed To – condition is TRUE if the attribute value changed to Value

Changed From – condition is TRUE if the attribute value was Value and changed to a different value

Not Changed – condition is TRUE if the attribute value did not change

Not Changed From – condition is TRUE if the attribute value did not change from Value (but could
have changed)

Not Changed To – condition is TRUE if the attribute value did not change to Value (but could have
changed)

The tested attributes can be predefined attributes (e.g. Type), custom attributes (see section 4.2.2)
or special attributes (e.g. Ticket Source).

Status - tests for the status of the ticket. When a ticket is created, it gets status New, which means it
is not yet assigned to a staff member or group. The Less than and Greater than conditions can be
used to check where in the processing workflow is a ticket. The sorting order of possible values is
given by the dropdown from where the tested value of the atribute is selected. For example, Less
Than Solved means that the status is New, Open or Pending.

Type - this attribute is used to match the type of the ticket: Question, Incident, Problem and Task.

Priority – similar to status, the Less Than and Greater Than operators can be used to check for
multiple values, for example Less Than Urgent.

Group - the Group attribute is used to check to which group a ticket is currently assigned. A common
practice is to automatically assign a ticket to a group and then let an agent from the group take the
ticket manually. The tested group values can be (assigned group) and in this case when testing with Is
operator the result is always true or the Group Name selected from the list of the defined groups in
Help Desk account.

Assignee - the assignee attribute is used to test who is assigned to the ticket. The tested values for
this attribute can be (current user), (requester), (assignee), StaffMemberName selected from the list
of staff members. When testing with Is operator against the (current user) value, the condition is true
if the assignee is the user that just updated the ticket. When testing with Is operator against the
(current user) value, the condition is true if the requester is also the person assigned to the ticket.
When testing with Is operator against the (assignee) value, the condition is always true.

Requester - the requester condition is used to test who requested the ticket. The possible tested
values are (current user), (requester), (assignee), StaffMemberName or EndUserName

Department - this attribute can be used to check from which department is requested the ticket and
it's the requester's department.

Tags - test for the presence or absence of tags. Each word is a tag. Multiple tags are separated by
spaces.

Ticket Source - test from where the ticket is updated or created. The possible values are Web Form
(the ticket is updated via the staff member interface, end user portal or the drop box), Mail (the ticket
is updated via email), Web Service (the ticket is updated via Help Desk API), Conditional Action or
Automation (the ticket is updated by a conditional action or automation)

Updater - The updater is the user who is updating the ticket. The possible tested values are (agent),
(end user) , StaffMemberName

Ticket is - this attribute is used to test whether the ticket is Created or Updated.

Ticket received at – Help Desk allows to forward emails to any address from Help Desk account
subdomain. For example, emails to sales@CompanyName.com can be forwarded to
sales@CompanyName.HelpDesk.com and emails from support@CompanyName.com can be
forwarded to support@CompanyName.HelpDesk.com . The Ticket received at attribute can be tested
to see to which address the ticket was received. This attribute is almost always used in conjunction
with a Ticket is Created condition.
Comment is - a condition based on this attribute checks the type of the comment (Public, Private) or
whether a comment is present.

Comment text - in some cases it is useful to check the presence of certain text in the comment (the
comment text includes both email subject and body)

When the conditions in a conditional action are met, all the associated actions will be performed.
Note that any actions that update the ticket will cause all the conditional actions to be evaluated
once more in the order they are defined. Most of the actions have a "-" option, which will set the
attribute to no value.

Actions have the form ActionTarget Option. The possible ActionTarget options are:

Status – an action having this action target will set the status of the ticket to New, Open, Pending,
Solved or Closed.

Priority - set the priority to Low, Normal, High or Urgent.

Type - set the type to Question, Incident, Problem or Task. Note that it's currently not possible to
perform incident-problem linking or set task due date using this action.

Group - assign the ticket to a group. The possible values (assigned group) - no effect, Group Name
which is the name of a group defined in Help Desk account

Assignee - assign the ticket to a staff member. The possible values are (current user) - the user who
caused the update if the user is a staff member, (requester) - the requester if the requester is a staff
member, (assignee) - no effect

Set tags - Replaces the current tags with a new lits of tags. The tags are separated by spaces.

Append tags - adds a list of tags to the ticket.

Remove tags - removes the listed tags from the ticket if present.

Email user - notify a user by email. The possible values are: (current user) - the user who caused the
update will be notified, (requester) - the ticket requester will be notified, (assignee) - the assignee
will be notified, (all non-restricted agents) - all non-restricted agents will be notified

Email group - notify all agents in a group. The possible values are: (assigned group) - notify all the staff
members in the group to which the ticket is assigned, Group Name a group selected from the list of
groups define in the Help Desk account.

Notify target - notify a target such as an API or Clickatell.

There will be a set of predefined conditional actions for each account. These predefined conditional
actions are: Notify requester of comment update, notify requester of solved request, Notify assignee
of comment update, Notify assignee of assignment, Notify assignee of reopened ticket, Notify group
of assignment, Notify all agents of received request.
It will be possible to define new conditional actions. The required information will be the conditional
action name, the condition (the ALL and ANY sections) and the action. It will be possible to edit, clone,
deactivate a conditional action and to reorder the conditional actions list.

4.2.4 Automations Administration

Automations are used to escalate tickets, notify staff members and users, change assignments and
other. Automations depend on time-based conditions. An example of automation is Set Ticket Status
to closed, when a ticket has been solved for more than 4 days.

Automations will run once every hour and only for tickets that have been updated within the last 30
days.

The order of your automations can be important because an automation can result in an action that
activates another automation.

Automations can be edited, cloned or deactivated. Inactive automations will not run.

The information requested when adding a new automation is:

Automation Title – is the automation name

Automation Condition – is the condition of the automation which consists in 2 sections: Meet ALL
Conditions and Meet ANY Condition.

Exclude Non-Working Days – when this option is true the time measured for triggering the
automation will consider only working days and will exclude non-working days (holidays, weekends,
etc). The default, value is false. The days considered not working days can be defined in the account
and can include weekends and special days in calendar. This option is useful for businesses which
cannot offer 24/7 support. The time zone used in automations is the time zone of the Helpdesk
account by default, but if the ticket is assigned to a staff member then the time zone of the assigned
staff member will be used.

There will be a predefined set of automations available by default, when a Help Desk account is
created. These automations are: Close ticket 4 days after status is set to solved, Pending notification
24 hours, Pending notification 5 days.

4.2.5 Service Targets Administration

The Service Targets is a set of rules describing the desired limits in which the help desk account
should work. There is a set of predefined service targets available by default, for an account. These
service targets can be be added and new service targets can be added. The predefined service
targets are:

- 100% of tickets with a priority equal to urgent must be assigned to an agent immediately and
solved within 1 hour
 - 50% of tickets with a priority less than urgent must be assigned to an agent immediately and
solved within 1 hour
- 80% of tickets must be assigned to an agent within 1 hour and solved within 1 hour
- 95% of incidents with a priority less than urgent must be assigned to an agent within 24
hours and solved within 120 hours

Besides the predefined service targets, new service targets can be added. The existing service targets
can be edited, cloned or activated. By default, all the predefined service targets are deactivated and
can be manually activated.

When adding a new service target, the information required is:

- Fulfillment target percentage – is the minimum percentage of tickets that must meet the
service target conditions
- Service Target Conditions – the conditions that must be met by a ticket to comply with the
service target
- Exclude Non-Working Days – when this option is true the time measurements for evaluating
the ticket compliance with the service target condition will consider only working days and
will exclude non-working days (holidays, weekends, etc.). The default, value is false. The days
considered not working days can be defined in the account and can include weekends and
special days in calendar. This option is useful for businesses which cannot offer 24/7 support.
The time zone used in service targets is the time zone of the Helpdesk account by default, but
if the ticket is assigned to a staff member then the time zone of the assigned staff member
will be used.

The tickets that don’t meet the conditions in a service target will be highlighted in separate system
views.

4.2.6 Help Desk Customization

The possible help desk customizations are:

Help Desk Name - the name of the help desk. Appears on the help desk home page, mails and RSS
feeds. The help desk name does not affect the URL of the help desk subdomain, which is always the
one chosen at the help desk account signup

Time Zone - by setting the time of the Help Desk account, the timestamps will be relative to time zone
of the account country or location. For example, when forum topics are posted, or when tickets are
submitted the timestamp displayed will be relative to the account time zone. All staff members and
end users will be able to set their own time zones. The default, time zone is detected at signup.

End Users Language – is the default, language used for the end user portal. It is selected from a list of
available languages for the end user portal. All the interface for the end user will be in the selected
language.
Additional End Users Languages – is a multiple selection list where the administrator can select the
languages available for the end user portal. The end user will be able to select one of these languages
when he enters the portal.

Staff Members Language – is the default, language used for the staff members while logged in the
help desk account. It is selected from a list of available languages for the staff members. All interface
for staff members will be in that language.

Additional Staff Members Languages – is a multiple selection list where the administrator can select
the languages available for the staff members while logged in the help desk account. The staff
members will be able to select one of these languages when they log in the help desk account. The
selected language will be saved and the next time when the staff members logs in the last used
language will be the default,

Forums Name - The title of your forums as it will be seen by End Users. Default, name is „Forums".
The Forums can be renamed to something like „Knowledge base" or „Messages".

Enable forums search on the home page – when this option is enabled the users will be able to search
the forums with a search text box on the top of the home page. By default, this option is enabled.

Show pinned topics on the home page – when this option is enabled the topics which were marked as
"pinned" will be displayed on the home page. The order of the topics will be chronological and cannot
be changed. When this option is enabled, another option will be made available to choose between
displaying both topic title and content or only the topic title. By default, this option is enabled and both
titles and content of the topics is displayed.

List forums on the home page – when this option is enabled a categorized list of all available Forums
will be displayed on the home page. By default, this option is enabled.

Reverse order of comments in forum topics – if this option is enabled the comments in topics are
shown last to first. By default, this option is disabled and the comments are shown in first to last
order.

Header Logo – allows the administrator to choose a logo image for the account.

Favicon - allows the administrator to choose a small logo image that will appear in the left of the
browser address bar

Help Desk Colors – allows the administrator to select colors for Page header, Page background, Side
bar and the other zones of the pages displayed to end users. There will also be a button which allows
the administrator to revert to default, colors
 4.2.7 Mails and Domains Administration
This section allows the administrator to setup the template of the emails sent from Help Desk, Reply
To Address mappings, Host Mapping, Personalized Sender Email Addresses and others.

HTML Email Template – this is a text box where the administrator can edit the template of the emails
sent from Help Desk. There are a few placeholders in the email template like for header, footer,
content and delimiter. There will also be a Revert to Default, button which allows the administrator to
revert to the default, email template if it was modified.

Mail Delimiter - the mail delimiter is used to inform the mail recipient that he must reply above a
certain line in the email. This can be used to get the latest comment from an email.

Personalized Sender Email Address – when this option is enabled, the name of the help desk staff
member is included in the email sender name and replyto address when the staff member comments
a ticket. By default, this option is true. When is false a generic name will be used for all the help desk
staff members?

Reply To Address Mapping – this section allows the administrator to set how the ReplyTo addresses
for the emails sent by staff members are calculated. There are a few options involved in this
algorithm:

- Default, Sender And ReplyTo Email Address - ( e.g.

support@CompanyName.HelpDeskSoftware.com ) which is used by default, as sender (From
 field) and as a Reply To address for the comments sent by help desk staff members to end
users. The Default, Sender and ReplyTo Email Address is normally a mailbox from the help
desk account subdomain but the company can decide to use an email address from its own
domain ( e.g. support@CompanyName.com ). In this case the company should configure its
email server to automatically route all the emails from support@CompanyName.com to an
email address from the help desk account subdomain and to add a SPF record to DNS
configuration to lower the risk of emails coming from the help desk to be treated as a spam.
A SPF (Sender Policy Framework) record is a DNS TXT record which specifies the SMTP servers
that are authorized to send emails on behalf of the company.
- Preserve Sender Mailbox Name - another option for emails processing is to Preserve Sender
Mailbox Name. This option is off by default, when this option is on the mailbox name where
the message was sent will be used in the sender email address. For example, if the message
entered the help desk at the sales@CompanyName.HelpDeskSoftware.com address the
mailbox name is sales. The domain name of the email address will be taken from the Default,
Sender and ReplyTo Email Address. For example it can be an email address from help desk
subdomain, e.g. support@CompanyName.HelpDeskSoftware.com, and in this case the
sender email address will be sales@CompanyName.HelpDeskSoftware.com or it can be an
email address from company domain, e.g. support@CompanyName.com , and in this case the
sender email address will be sales@CompanyName.com .
- Reply To Address Map - the account administrator will also have the possibility to manually
define a list of mappings between the email address on
CompanyName.HelpDeskSoftware.com domain to which the email was received and the Reply
To address used in the response message to end user. For example, the administrator can
define a mapping from support@CompanyName.HelpDeskSoftware.com to
support@NewCompanyDomainName.com . When a message (the message can be a new
ticket or a comment to an existing ticket) is received at
support@CompanyName.HelpDeskSoftware.com and an agent responds to this message, the
From address and the ReplyTo address of the response email will be
support@NewCompanyDomainName.com . If the address mapping target is an email address
from another domain (outside HelpDesk.Com) then a SPF record to should be added by
customer to its DNS configuration to lower the risk of emails coming from the help desk to be
treated as a spam. The Reply To Address Map has priority over the Default, Sender and ReplyTo
Email Address and over the Preserve Sender Mailbox Name option.
 4.2.8 Host Mapping Administration
Host mapping allows the Help Desk account administrator to enter a custom domain name that will
mapped to Helpdesk subdomain. For example, it will make possible to use
Support.MyCompanyName.com instead of CompanyName.HelpDesk.com. The domain set in host
mapping will also be used in links inside emails sent from Help Desk software. Once the host mapping
is set it will be used by Help Desk immediately. Therefore, the proper CNAME DNS record must be
created by customer on this servers to map his own domain to point to Help Desk subdomain.

4.2.9 Users Admission Administration

The user’s admission defines if the help desk is public or private (see section 3.4 for a detailed
description about the users admission in public and private help desks), set welcome messages
templates, enable OpenID sign in and other options. The options that the administrator can set for
users’ admission are explained below.

Public Help Desk – when this option is true anybody can submit tickets to help desk. By default, this
option is true. When this option is false the help desk is private and only previously registered users
can submit tickets and the tickets sent by anonymous users will be suspended and only staff members
can recover them and transform them in normal tickets (see section 3.4.2 for more details about the
Users Admission in a Private Help Desk). When this option is true there are a few other options
controlling the user’s admission.
 - Ask End Users to Register – when this option is enabled, after submitting a ticket, the new
users will receive a welcome message requiring them to register in order to make their ticket
appear in the help desk (or to move the ticket from the list of suspended tickets if the ticket
was sent directly to email address – see section 3.4.1.2 for more details). When this option is
disabled, all the tickets will be accepted in help desk. By default, this option is not enabled
- White List – is a list of emails and email domain names separated by spaces from which the
help desk will always accept tickets
- Black List - is a list of emails and email domain names separated by spaces from which the help
desk will always suspen or reject tickets. White List has priority over Black List. However, it will
be possible to also black list addresses which otherwise are accepted by the White List using
the suspend and reject keywords in the black list.

Welcome Message for End Users – is message emailed to users after signup

Allow Users to Sign in Using OpenID – when this option is enabled the users will be allowed to sign in
using the OpenID instead of normal Help Desk username/password. This option is false by default,

Allow Users to View and Edit Their Profile – when this option is true the users can edit their profile
data otherwise, they won’t be able to do this. By default, the option is true and the users are allowed
to edit the profile data.

4.2.10 Ticket Options Administration

The options for tickets that can be set in this section are:

Display Empty Views – when this option is true the empty views are displayed in the Views menu,
otherwise they are not displayed. By default, this option is true

Comments are Public – this option sets the default, mode for the comments made by staff members
on the ticket. Public comments are visible to end users and end users’ CCs. Private comments are
visible only to staff members. By default, all the comments are public

Allow Tickets Tagging – when this option is true the staff members are allowed to add tags to tickets
for fast search, otherwise the tickets tagging is not allowed. By default, the tagging is allowed.

Allow End Users to Upload Attachments – when this option is true the users can submit attachments
in the help desk, including attachments from emails sent to help desk. This option is true by default,

Allow Staff Members to Delete Tickets – when this option is true the staff members can delete tickets,
otherwise they cannot. By default, this option is false and the staff members cannot delete tickets.

Reverse Events Order on Ticket Page – when this option is true, the tickets events (including
comments) are displayed from last to first instead of first to last. By default, this option is false.

Requester and CC Editing – when this option is true the staff members are allowed to change the
requester and add CCs for an existing ticket, otherwise they are not allowed. By default, this option is
false
Agent Signature Template – a text box where the administrator can add a standard text template for
the staff members signature in public comments for tickets. The template can contain placeholders
for staff member name, phone, etc.

Next Ticket ID - set the ticket id counter, useful if the administrator wants tickets to start at a greater
index, for example all the tickets to have am ID greater than 1000. Setting this option will not modify
the IDs of existing tickets, only tickets created afterwards. The value set for this option must be greater
than the current maximum ticket ID in use. The value set here should will be limited to 6 digits. The
ID should be a 64-bit number.

4.2.11 Panels Administration

The panels are small HTML fragments that can embedded in any page of the Help Desk. Panels can
be used to integrate external data in the help desk interface.

The HTML in the panels can use text placeholders to display details about help desk objects.
Depending on what page the panel is displayed different text placeholders become accessible.

For example, the content of a panel could be Hi {{current_user.name}} which would display a
welcome message for the user.

There are a few predefined types of panels that can customized by users.

Types of Visible Panel:

Forums Panel – provides shortcuts and quick search tool for forums

Ticket Views Panel – displays links to ticket views

Department Panel – displays detailed information about the department

Custom HTML Panel – contains custom HTML fragments to be included in help desk pages

Image Panel – contains an image and a text to be displayed under the image

Types of Hidden Panels:

Global CSS Panel – CSS to be used in all the help desk pages

Global JavaScript Panel – JavaScript code to be executed in all the help desk pages

When creating a new panel first the type of panel will be selected then additional information
necessary for each type of panel will be requested. For example, for a Custom HTML Panel the HTML
code to be included in panel will be requested, for Image Panel the URL to the image and the text to
be displayed under the image are requested.

The following information is always requested for all types of panels:

Panel Title – as it will be displayed on the Help Desk pages

Hide Panel Title – when this option is true the panel title will not be displayed. The default, vale is
false and the title will be displayed Availability – specifies for who will be visible the panel. The
possible options are: Anyone (includes logged in end users and staff members and also users who
are not logged in), Staff Members, Logged In End Users.

After the panel was created, the administrator can choose various pages of the help desk where the
panel will appear. The pages accepting panels will have an Edit Panels button. The administrator will
be able to edit panels on that page, delete panels or add new panels to the page. When adding a panel
to some types of pages (like forum topic page, forum category page, add new user page, tickets view
page, etc) the panel will be added to all the pages in that category. For example, if the administrator
added a panel on the page of a forum topic then the panel will be visible on the page of any forum
topic for any user (including the anonymous user) who is allowed to view the panel based on the panel
availability. If the panel is removed from a forum topic page it will be removed from the all the forum
topic page.

The administrator can place panels on pages which are not accessible for him. This possible by
assuming another user identity, including Anonymous user. This way the administrator can place
panels on the Login page or on Submit a Ticket page.

4.2.12 Own Cloud Administration

Own Cloud is a form that can be embedded into the customer website as a tab on every page, allowing
the customer to capture support requests, feedback, pricing enquiries etc. The form contents will be
converted to a ticket in the Help Desk after submit.

4.2.1 Targets Administration

Targets allows the customers to call into external systems upon specific ticket events. For example,
send a SMS when an urgent ticket has been unattended for more than 48 hours. The following types
of targets will be possible: Clickatell (to send SMS), URL target (invoke a custom URL by GET or POST),
Email target (send emails to specified email addresses).

4.2.2 Company Profile Administration

The administrator can edit account information like: the email address where copies of the invoices
are sent, details about company like company name, VAT number, address, website URL, etc.

4.2.3 Subscription Administration

In this section the administrator can manage the Help Desk subscription. For example, he can choose
the type of subscription (Basic, Standard, Premium, Unlimited) based on the number of staff members
needed to operate the Help Desk account.

5. Help Desk Software Administration

There will be a web interface to allow the administration of the Help Desk Software. The Help Desk
Software administration includes:
 - the definition of account types (Basic, Standard, Premium, Unlimited) and prices for each
type of account
- customer accounts management (manually suspend or delete accounts), view and edit
accounts information.
- Definition of the Presentation website content in many languages
- Definition of the content of all email messages sent to customers with placeholders for
customer name, email address and for all the other variables in the message

6. Help Desk Software API

The Help Desk Software API will be a REST API. There will be an API for manipulating Departments,
Groups, Users, Tickets, Attachments, Tags, Forums, Search and Ticket Attributes.

The API calls will be synchronized with the usage of the Help Desk Software though the standard web
interface. The implementation will take into account that API calls and web interface operation might
act against the same objects and the integrity and coherence of the data should be ensured during this
type of interaction between the API and web interface.

The use of the API always happens through an existing user in Help Desk account. There is no special
API user. The API allows all the operations allowed for the user authenticated to the API. User
credentials when using the API are sent via HTTP Basic Authentication.

To ensure continuous quality of service, API usage can be subject to throttling. The throttle will be
applied once an API client reaches a certain threshold in terms of a maximum of requests per minute.
Most clients will never hit this threshold, but those that do, will get a HTTP 503 response code and a
text body of “Number of allowed API requests per minute exceeded”.

The API developers will have to anticipate this error, and take appropriate measures like using a
cached value from a previous call, or passing a error message to the end user.

7. Software Tools and Technical Recommendations

The web applications will be developed using the ASP.NET MVC as development framework, Visual
Studio 2010 as development tool and .NET 4.0 as target platform.

The managed server where the application will be installed will be a 64-bit Windows 2008 server.

The database server will SQL Server 2008 which allows the creation of full text indexes used to for a
full text search of forums.

The mail server will be MailEnable Enterprise. It allows an appropriate configuration of the catchall
mailboxes and allows the storage of its configuration in a database for better scalability. It also allows
the training of a spam filter and can mark the mail messages identified as spam with a custom header
for further processing within the Help Desk Software.

Rebex Mail for .NET can be optionally used to read and parse email messages through POP3.
MagicSpam for MailEnable will be used in front of the MailEnable mail server to filter most of the
spam messages. The messages passing this filter will go into the MmailEnable spam filter. The spam
messages identified by MailEnable will be marked with a special header and the tickets created for
these messages will go into a suspended state.

Paypal will be used as payments processor for the Help Desk subscriptions management.

7.1 MailEnable Configuration

7.1.1 Catchall mailbox configuration

There will be a HelpDesk.Com post office defined in MailEnable. This post office will have a set of
catchall mailboxes defined (the number of catchall mailboxes can be configured in the Help Desk
Software Administration). Each Help Desk account will be mapped to one of these catchall mailboxes
as explained in section 3.3.1 based on a hashing algorithm.

Each Help Desk account has a subdomain name assigned to it (e.g.

CompanyName.HelpDeskSoftware.com is the subdomain assigned to a company). It will also have an
associated domain with the same name (e.g. CompanyName) in MailEnable under the HelpDesk.com
post office. The domain in MailEnable will be automatically created using the MailEnable API when
the Help Desk Software account is created. Then a catchall mailbox will be configured for the domain.
This catchall mailbox will catch all the emails sent to any email address of the
CompanyName.HelpDeskSoftware.com subdomain.

The C# code to create a domain in MailEnable and associate it with a catchall mailbox (Own Cloud)
with it is:
using System;

using
System.Collections.Generic;
using System.Linq;

using System.Text;

using

MailEnable.Administration;

namespace MEAPITestConsole

class Program

static void Main(string[] args)

{
 if (args.Length != 2)

Console.WriteLine("Usage: apitest.exe postoffice

subdomain"); return;

string subdomainName = args[1];

string postofficeName =
args[0];

Postoffice postoffice = new

Postoffice(); postoffice.Account = "";

postoffice.Name =
postofficeName;
postoffice.Status = -1;

if (postoffice.FindFirstPostoffice() != 1)

Console.WriteLine(String.Format("Could not find postoffice {0}",

postofficeName));

return;

Console.WriteLine(String.Format("Found postoffice {0}",

postofficeName)); Domain subdomain = new Domain();

subdomain.DomainName =
subdomainName; subdomain.Status = 1;

subdomain.DomainRedirectionStatus = 0;
subdomain.DomainRedirectionHosts = "";
subdomain.AccountName =
postofficeName;

if (subdomain.AddDomain() != 1)

Console.WriteLine(String.Format("Could not add subdomain

{0}", subdomainName));

return;

Console.WriteLine(String.Format("Added subdomain {0}",

subdomainName)); AddressMap addressMap = new AddressMap();

addressMap.Account = postofficeName;

addressMap.DestinationAddress = String.Format("SF:{0}/Own Cloud",

postofficeName); addressMap.Scope = "0";
 addressMap.SourceAddress = String.Format("*@{0}", subdomainName);

if (addressMap.AddAddressMap() != 1)

Console.WriteLine("Could not add catch-all address map for subdomain");

return;

Console.WriteLine("Added catch-all address map for

subdomain"); Console.WriteLine("Done");

In this code sample the "SF:{0}/Own Cloud" is one of the predefined catchall mailboxes. Since emails
addressed to many subdomains can get to the same Own Cloud email address, there should be a way
to know the original destination for an email. Fortunately, MailEnable will preserve the original
destination of the message.

Please note that the code using the MailEnable API assemblies should run in 32-bit mode since there
is no 64-bit version of the MailEnable API assemblies.

7.1.2 MailEnable Spam Filter Configuration

The MailEnable Enterprise supports marking of the email messages identified as spam with a custom
header. The messages identified as spam will generate suspended tickets.

The procedure to mark a spam message with a custom header is:

In MailEnable Administration Console -> MailEnable Management -> Messeging Manager -

>Filters add a new filter.

Set „Where the message has over certain spam probability” as filter criteria check on Enabled and
set a minimum probability treshold for the new filter.
Press the Add Action button and select Add Message Header. Select a name and avalue for the
custom header. The name can be X-MailEnableSpam and the value can be the treshold probability.

7.1.3 MailEnable Scalability

The MailEnable will be configured to store its configuration in a SQL Server database for maximum
scalability.
 7.2 Full Text Search

The database tables using text content to be searched will be indexed and interrogated using the
Full Text Index feature from SQL Server 2008. The Search text boxes will have 2 options: Full Text
Search (default,) and Fast Search By Tags. In the first case a full text search will be performed, in the
second case only the tags will be searched.

7.3 Scalability

For maximum scalability the data for the Help Desk Software accounts will be kept in many
databases. All the data for an account will be stored in the same database and the same database
can store data for many accounts. There will be a script which allows the system to be configured
with a specified number of databases.

7.4 Synchronization Between API Calls and Web Interface

The implementation will ensure the data integrity and coherence when API calls and web interface
operations are executed concurrently.

7.5 Deliverables Design documents

Source code of all the projects composing the application Scripts to create and maintain the database

Third party components

Scripts to fill the database with test data Test applications for the Help Desk API

7.6 Testing

The software will be tested and should be responsive with large data sets like 500,000 accounts, each
account having 1000 staff members and 1,000,000 tickets.

The API requests and the web interface requests will be tested in parallel, therefore the implementation
of the API and the web interface should be done simultaneously.