co desk 3.1 administrator guide

Administrator Guide

Version: 3.1

Dec 08 Doc ID: CDAG: 3.1:122008: 01

Legal Notices and Disclaimer

© Copyright IBM Corp. 2002, 2008. ALL RIGHTS RESERVED

No part of this document can be reproduced, or transmitted, or stored in any form

or by any means without the prior written approval of the copyright owners.

Due care and diligence has been taken in preparing this document. Network

Solutions Private Limited, its subsidiaries, distributors, dealers, re-sellers, or

licensors shall not be held responsible for any mistake that may have

inadvertently crept in

In no event shall Network Solutions Private Limited, its subsidiaries, distributors,

dealers, re-sellers, or licensors shall be liable for any direct, consequential or

incidental damages in connection with or arising from the use of this document or

the product accompanying it

ITIL® is a Registered Trade Mark of the UK Office of Government Commerce. All

other trademarks and copyrights as referred in this document are the property of

their respective owners

Contact Information

Network Solutions Private Limited - An IBM company

32, Grape Garden, 6th block

17th 'H' Main Road, Koramangala

Bangalore - 560 095

Tel:+91-80-2550 8365 / 2553 5228

Fax: +91-80-2552 0949 / 2552 3379

E-Mail: [email protected]

Website: http://www.netsol.co.in


coDesk 3.1 Administrator Guide of 65

Table of Contents

Legal Notices and Disclaimer.......................................................................................... 2

1. About this Guide....................................................................................................... 7

1.1 Intended Audience .......................................................................................... 7

1.2 Acronyms and Conventions .......................................................................... 7

1.3 Contents of this Guide.................................................................................... 8

2. About coDesk............................................................................................................ 9

2.1 What is coDesk................................................................................................ 9

2.2 What’s New in coDesk 3.1.............................................................................. 9

2.3 Features of coDesk 3.1 ................................................................................. 10

2.4 Benefits of coDesk 3.1.................................................................................. 12

3. Architecture............................................................................................................. 15

4. Terms Used in coDesk 3.1 ..................................................................................... 19

5. Incident Management in coDesk 3.1..................................................................... 33

6. Problem Management in coDesk 3.1 .................................................................... 43

7. Change Management in coDesk 3.1 ..................................................................... 47

8. Configuration Management in coDesk 3.1 ........................................................... 53

9. Dashboard view in coDesk 3.1 .............................................................................. 59

10. Knowledgebase ...................................................................................................... 61

11. Index......................................................................................................................... 65



Table of Tables Table 1-1: Acronyms and Conventions............................................................................................. 8 Table 1-2: Contents of the guide....................................................................................................... 8



1. About this Guide

1.1 Intended Audience

The coDesk 3.1 Administrator guide is intended for application administrators who would

configure and create workflows for service support in coDesk 3.1. This guide provides a

concise description about the product and the various terms involved in them.

1.2 Acronyms and Conventions

Activity / Detail Usage in the guide

Chapters All chapters of the guide start on an

odd page.

References to screens, dialog boxes,

controls and other objects.

References are in bold text.

Instructions All instructions are numbered. If there

are sub instructions they are

numbered in lower roman numerals.

Note text All admonishments such as caution,

note appear within a two sided

bordered table.

Image / screen numbering Screens in the guide are numbered in

a sequence. The first number

indicating the chapter number and the

second number indicating the screen

order in that chapter.

The screen numbering is followed by

the figure title.

Tables Tables in the guide have a pre-

About this Guide

of 65 coDesk 3.1 Administrator Guide

determined width and indentation from

the left margin.

Tables are numbered in a sequence.

The first numbers indicate the chapter

number followed by the order of the

table in that chapter.

The number is followed by the table

title in bold.

Reference to the application name

and version In this document, “coDesk” refers to the coDesk application version 3.1.

Table 1-1: Acronyms and Conventions

1.3 Contents of this Guide

Chapter Description

Chapter 1

About this guide

A brief introduction about the intent of

the guide, acronyms used in the guide

and its contents.

Chapter 2

About coDesk 3.1

Speaks about the features and

benefits of coDesk

Chapter 3

Architecture

Brief introduction about the various

components of coDesk 3.1

Chapter 4

Terms used in coDesk 3.1

Introduces the various terms involved

in coDesk 3.1 for better understanding

the product

Chapter 5

Incident Management

Explains the overview of incident

management in coDesk. 3.1

Chapter 6

Problem Management

Briefs about the overview of problem

management in coDesk 3.1

Chapter 7

Change Management

Briefs about the overview of Change

management in coDesk 3.1

Chapter 8

Configuration Management

Briefs about the overview of

Configuration management in coDesk

3.1

Chapter 9

Knowledgebase

Briefs about the overview of

Knowledgebase in coDesk 3.1

Table 1-2: Contents of the guide



2. About coDesk

2.1 What is coDesk

coDesk is an enterprise class, web based, workflow enabled, service desk application

that automates ITIL® best practices for Service Support. coDesk is designed for external

and internal service support for a variety of domains like IT help desk, service request

automation, issue management, etc. It provides configurable and flexible workflow and

routing capabilities that allows service delivery automation and enables quick resolution

of customer support issues

2.2 What’s New in coDesk 3.1

coDesk offers enhanced support for ITIL® best practices for Service Support. New

features and capabilities include -

1. The database for coDesk can be deployed on IBM DB 2® V 9.5 Database and

Microsoft® SQL Server® 2005 Database.

2. The coDesk is enhanced to display the reports based on dashboard views. The

data in the dashboard view are displayed in Pictorial, Graphical and Tabular

formats. There are five pre-defined dashboards based on the type of users in

coDesk.

i. Helpdesk Administrator’s dashboard: For one who manages the helpdesk

function and keeps track of the loads, tool availability and performance.

ii. Service Administrator’s dashboard: For one who manages services and is

responsible for service delivery and its performance.

About coDesk


iii. Agent’s dashboard: For one who delivers service to the end user.

iv. End User’s dashboard: For one who receives the service from the service

desk.

v. Executive dashboard: For stakeholders who are interested in the services

offered by the service desk and can make informed decisions based on

the performance of the service.

3. Users can be removed from different dependent objects.

4. Enhanced SNAPPiMON Integration

i. Provision to map time zone with the SNAPPiMON Instance.

ii. Provision to utilize the asset attributes for ticket logging.

iii. Provision to define ticket workflow on occasions of SNAPPiMON Open

and Close events.

iv. Provision to customize the ticket description with ability to map

SNAPPiMON specific fields.

5. Provision to view audit summary of Configuration masters to know the actions

performed on the masters.

6. Change Request is enhanced with the allocation feature. While allocating the

ticket, permissions to modify the ticket parameters like More Fields,

Attachments and Queries can be provided. Based on the permissions provided

the agent can view the modify ticket details.

7. Super Administrator can now view user audit report. Information like

Login/Logout date/time, User Authentication, User details(login name,

organization, department, workgroup, designation, role, region, location and

time zone) and Log details(Invalid/Successful login date/time) of each valid

user in coDesk.

8. The Change password and Forgot password are available as a part of Email

template. Any changes in the user details or the user information will be notified

to the user through email. The Change password and Forgot password

templates can be customized.

2.3 Features of coDesk 3.1

1. Multi-touch suite that automates the complete support and service life-cycle-call

logging, qualifying, assigning, categorizing, prioritizing, routing, escalating,

tracking, closing, reporting and monitoring.

2. Completely web-based service support system that manages tickets from

submission to closure.

About coDesk


3. Easy to use for both customers and staff.

4. Strong support for automating ITIL® best practices for Service Support

including Incident Management, Problem Management, Change Management

and Configuration Management.

5. Scalable and Flexible engine - allows coDesk to suit various needs – Case

Management, Issue Management, Service Desk, Helpdesk, Customer Care,

Change Management, Bug Tracking etc.

6. coDesk provides Web & Email based call logging. Tickets can be routed based

on multiple attributes of the ticket. These attributes include Category,

Classification, Severity, Impact, Location, Time of the Day, Day of the week,

etc. Intelligent call router that auto-routes and assigns a ticket to the right

resource based on Team, Team role, Agents and Shifts etc, thus resulting in

faster resolution.

7. Strong and Flexible E-mail and SMS notifications triggered at every stage of the

process.

8. Built-in Knowledgebase allows customer self-service and hence lower call

loads and enables dynamic growth of organizational knowledge.

9. Multiple pre-defined reports generate reports for specific functions like list of

closed tickets, engineer performance, status summary of different tickets, re-

opened tickets etc.

10. Supports multiple instances of coDesk on a single system.

11. Integrated support for Incident, Problem, Change and Configuration

Management, and Service Level Management for Support Processes.

12. Scalable, High Performance solution and Web based User Interface.

13. Supports Windows 2003 Server OS and MS-SQL Server® 2005 database /

IBM DB 2® database and IBM DB 2® on Linux.

14. Supports multiple Time Zones. Users can be associated with a timezone and

view all data in the timezone they belong to. Users can also change their

timezone as part of their profile updates.

15. Asset service has the option to define permissions for provider and receiver

groups for viewing assets. Show and Hide permissions can be set for all the

assets mapped to the service.

16. Users can view the email call logging mode details in the Audit page. Call

logging mode in the audit page will display the email id of ticket logger who is

not configured in coDesk and the mapped coDesk end user name.

17. User Definition has the Advanced Search option to search for users by adding

multiple conditions.

18. Assets and Users can be exported in CSV format.

19. Online help is provided across all the modules.

About coDesk


20. Provision to set user specific personalized home pages.

21. Provision for end users to rate the call directly from the Incident Closure mail.

22. Supports multiple instances of SNAPPiMON to integrate into coDesk. Event

template has been introduced to capture event patterns from SNAPPiMON.

Multiple Event Templates can be mapped to a coDesk service.

23. Work Queues has the New and Transferred tabs that display the tickets in

queue and the transferred tickets with the total number of entries.

24. Transfer Analysis report in Problem and Incident services. This report tracks

every action in the cycle of ticket transfer and calculates the percentage of

successful transfers, average transfer per ticket, and the Maximum transfers on

any ticket.

25. Paging control to support MS SQL 2000, MS SQL Server® 2005 and IBM DB

2®.

26. Provision to save the queries per user per report under Analytics. The saved

queries will generate reports based on current dates.

27. The Turn Around Time report in Change Requests include ‘Scheduled

Variance’ column.

28. Users can customize columns in the list views provided permissions are

defined for them in the User Template.

29. Provision to enable or disable the Request Types globally.

30. Ticket Number can be generated even before the ticket is submitted. Once the

ticket logging is cancelled, the ticket is considered as ‘abandoned’.

31. Agents can view the number of ‘Tickets in Queue’ and the ‘Active Tickets’

(pending) at the time of Transfer Action.

32. Two filters under Pending Tickets, namely Transferred in, Allocated out and the

respective icons to view the tickets that are transferred or allocated to agents.

33. Additional Notes can be added even after closing the call.

34. Provision to modify and delete the assets through bulk operations.

35. Multiple searches can be done by choosing filters across all pages.

2.4 Benefits of coDesk 3.1

Centrally manage all issues & requests with comprehensive tracking

1. coDesk is a multi-touch suite that automates the complete support and service

life-cycle. You can centrally track and manage multi-channel requests - phone

(Verbal), email, Enterprise Management System (EMS) as well as web forms.

About coDesk


2. Record, qualify, route, assign, categorize, prioritize, escalate, close and monitor

issues and requests throughout the service life cycle.

Improve your call flow and operations

1. Track adherence to service level agreements (SLA). Manage by exception.

2. Organize Agents into teams and track performance by agent or by teams.

Supports multiple teams at multiple locations.

3. Provides multiple tenancy support for service providers.

4. Manage the change requests with logging, approval, delivery and re- record

process.

5. Implement your Service Provider Group’s specific workday calendar (Service

Window).

6. Enable quick qualification of tickets to determine the organization's obligation to

provide support or service.

7. Send customizable email alerts and notifications, including mass emails.

8. Log issues / requests through emails.

Improve First Time Resolution

1. Track ticket escalation, re-assignment, transfers and also re-occurrence and

hence address critical issues.

2. Track staff performance and hence identify re-training needs.

3. Records all issues/problems in a centralized database to create a searchable,

sort able, historical archive from which support staff and developers can identify

patterns and recurring problems to facilitate rapid resolutions.

4. Serves as a resource for known problems and their resolutions, allowing

system administrators/support staff to be proactive in identifying and

addressing potential problems.

Empower staff and users with Self-service

1. Built-in knowledgebase provides anytime / anywhere access to organizational

knowledge.

2. Provides the Agents and customers the ability to search knowledgebase for

finding solutions – without contacting the support center.

3. This results in lower call load, increased productivity and lower operational

costs.

4. Create a self-learning organization.

5. Bulletin Board is introduced in coDesk to post and reply messages based on

permissions.

About coDesk


6. Ticker messages are displayed in the home page of the users to intimate the

users with status of various elements.

Provide customer service 24/7

1. Empower customers with the ability to submit and track their own issues.

2. Keep customers informed with email status notifications regarding the status.

3. Analyze customer feedback on service response and resolution.

Efficiently manage resources

1. Permits support staff managers to coordinate, assign and delegate problem

solving among their staff based upon workload and expertise.

2. Managers can divide and assign the workload based upon the skill and

knowledge levels of their support personnel.



3. Architecture

coDesk is an ITIL® centric service desk product to suit the business needs of the growing

IT infrastructure. The various components and features of coDesk are shown in the figure

below.

Figure 3-1: coDesk Summary

coDesk provides support for the following process

i. Incident Management

ii. Problem Management

Architecture


iii. Change Management

iv. Configuration Management

coDesk also offers flexible routing and effective permissions and access control. It

provides well organized knowledgebase which maintains the articles published by

different users. Integrated Configuration Management Database CMDB provides effective

and efficient asset management.

coDesk offers effective reporting and analysis, notifications are intimated to users while

performing every activity and SLA; escalations are enabled to offer quick resolution of

customer tickets.

The logical view of coDesk components is displayed as shown below

Figure 3-2: coDesk Logical components

Web Portal

Web Portal is used for user management and application configuration. Several actions

and activities can be performed using the web portal

Analytics and Dashboards

coDesk is used for effective analysis of the efficiency of the Agents in resolving the ticket.

It offers several reports to quickly and correctly interpret the ticket management process.

Architecture


coDesk uses several parameters like end user ticket rating, SLA breached etc to build

reports based on them. Dashboards provide a pictorial, graphical and tabular

representation of data in coDesk to analyze the reports easily.

Notifications and Alerts

coDesk offers effective and efficient email alerts and notifications triggered at every stage

of the call flow process. coDesk can be configured to provide alerts before SLA breaches

Status change etc. These notifications and alerts provide information to the end users

who logged the ticket and the other configured users. Escalation notifications can be sent

to superiors so that the superiors will act on the ticket and the ticket can be resolved to

the entire satisfaction of the customers.

Incident Management, Problem Management and Change Management

Incident Management, Problem Management and Change Management are various

processes that can be carried out by coDesk. coDesk is completely ITIL® centric and all

these functions are carried out based on best practices and recommendations of ITIL®.

User Management

User management in coDesk is easy to configure and use. The users can be created /

deleted / modified. Users can be made inactive if they are not needed. Users can belong

to roles that correspond to either agent or end user role types. Service Provider is

independent of the organizations and can accommodate users of several organizations to

belong to a common Service Provider.

Knowledge Base

The Knowledge Base is a data store repository that is used to store and share FAQs,

workarounds, troubleshooting tips and articles. Commonly encountered issues can be

documented in knowledge base. The agent and the customer can refer the

knowledgebase to solve the issues. Many new technologies can be documented and

stored in knowledgebase and thus it offers a self help facility.

Bulletin Board

Bulletin board messages can be posted and replies can be given to those messages

based on permissions. This enhances the communication between different users of the

application.

Ticker Messages

Ticker messages appear in the home page of the users and are based on permission

centric. These messages provide warning alerts and information about the various

issues.

SLA Engine

Service Level Agreements are the maximum time limits within which the ticket must be

responded or resolved. The SLA engine tracks and escalates Response and Resolution

SLAs.

Access Control and Permission

Architecture


Access control and permissions are role based and the user can navigate and perform

operations in the application based on permissions.

Integrated CMDB

Configuration Management Database (CMDB) is integrated with IBM/Netsol Asset

Manager to offer better service.

Process Manager

Process Manager interacts with each of the components and maintains a flow between

the processes.



4. Terms Used in coDesk 3.1

coDesk is a web based Service Desk software application built on ITIL® standards,

hence most of the terminology used and applicable are ITIL® centric. However the user

needs to be familiar with some of the key concepts associated with the product before

using the application. The purpose of this section is to familiarize users with coDesk

specific concepts and terminology.

Accept Action

When a ticket is logged by the end user, the ticket is placed in the work queue of the

agent. The agent working on the ticket needs to perform an Accept action to work on the

ticket.

Actions

Actions are pre defined and it is essential to map the actions to the status.

Acknowledge Resolution

Acknowledge resolution an activity if configured for a service allows the agent to

manually specify the Resolution time. The resolution time specified manually during

acknowledge resolution activity or the time at which the resolve action is performed can

be taken as the actual resolution time depending on the agent’s decision. The agent can

override the resolution time any number of times before the ticket is closed using

resolution acknowledge activity. The time provided during acknowledge resolution must

be greater than the ticket logged time.

Acknowledge Response

Acknowledge Response activity if configured for a service, will allow the agent to

manually specify the response time for the ticket. In such circumstances, performing

accept action will only transfer the ownership of the ticket. Hence it is necessary to

perform acknowledge response activity before resolving the ticket. The time manually

specified during acknowledge response must be greater than the ticket logged time.

The acknowledge response activity can be performed any number of times and the

response time can be modified before closing the ticket.

Terms Used in coDesk 3.1


Approval Team

Approval Team includes group of users whose consent is required before starting the

implementation process for a change. However the change manager can override the

approval of the members of approval team if required.

Users of the approval team can belong to any organization. Many approval teams can be

configured and the change manager can select the needed approval team for the ticket.

There are two types of approval team namely Change Advisory Board and Change

Advisory Board Emergency Committee. Under normal situations, the CAB members can

approve / disapprove the RFC. Under emergencies, CAB E/C can be involved for the

approval process. The change request has to be approved before it is implemented.

Assets

Configuration Management provides a logical model of infrastructure or service by

identifying, controlling, maintaining, verifying and reporting assets in existence including

their version, constituent components and relationship. Assets include all components

that build the infrastructure of the organization.

Auto Closure Time

After a ticket is resolved, the ticket has to be closed. The end user or the agent can close

the ticket. If the ticket is not closed by the agent or the end user the ticket gets closed

automatically after the interval defined by auto closure time.

Bulletin Board

Bulletin Board messages can be posted and replies can be provided by users based on

permissions defined in the user template. Create, modify delete, reply, modify reply and

delete reply can be performed by users based on permissions. This enhances the

communication between the users of the application.

Call Modes

Call Modes refer to the various call modes by which the end user can log a ticket. Some

of the call modes are Web Form, Phone, SMS, email etc. The application currently

supports web based, email and SMS based call logging.

Category

Category, sub category and classification are used to identify a ticket. There can be many

sub categories under a category. But classification is independent of category and sub

category. Category, sub category and classification are used in Service Rule to uniquely

route the ticket to the associated agent.

Change Artifacts

Change Artifacts are the type of attachments that can be added by agents while working

on the Change Request tickets. The agent while adding activity notes on a change

request ticket can add attachments of the configured artifacts type to support service

notes.



Change Calendar

The various activities of the change manager, approval team, and implementation team

can be scheduled and reminders and notifications can be sent to the configured users at

the configured time using change calendar option.

Change Origin

Change Origin refers to the activity which initiated the change. Change origin and change

reason are provided by the end user at the time of logging the ticket.

Change Outcome

Change Outcome is the result obtained after implementing the approved change. The

Change manager after performing the approved change will provide change outcome

before closing the ticket. All the possible change outcomes must be defined before using

the application.

Change Override Reason

Change Request ticket must be approved before implementation. If the decision made by

the approval team is not satisfactory then the change manager can himself approve or

disapprove the change request. The decision made by the change manager is final if he

has permission to override. During such situations, the change manager has to specify

the reason for overriding approval team’s decision.

Change Reason

Change reason is provided by the end user while logging a change request ticket. For

example, if there is a network failure, then change reason would be “not able to connect

to network”. Change origin would be “network failure” and the effect of Non

implementation would be “All users in the network will not be able to connect to network”

and finally after resolving the ticket, the change outcome would be “Network working

properly”

Change Reminder

The change calendar will schedule the various activities for change manager, approval

team and implementation team. The start time and the end time for the activity must be

provided and the change calendar can be designed to provide reminder before starting

the activity and before ending the activity. This helps to complete the process in time.

According to the planned start and end dates the implementation team and the change

manager can act and implement the change.

Closure

When a ticket is closed, the agent closing the ticket needs to provide closure comments.

This helps the agent to keep track of the various activities carried out while closing the

ticket. You can define the closure codes that are used while closing the ticket.

Default Operational Rule

The user logs a ticket for a service, providing details like category, sub category,

classification, impact, urgency, region and location. The ticket looks for the best match



Service Rule according to the parameters provided. If an exact match is not found in the

Service Rule, it looks for the routing precedence configured for the service. If no match is

found according to the routing precedence defined the ticket will follow the default

Operational Rule.

Denied Service Name

The user of a service receiving organization can be denied to log tickets for a particular

service. This can be configured in Configurations > Permissions > Service Receiver

Template. If Open action is not allowed for a particular user, for a specific service, then

that user can log tickets for that particular service.

Department

coDesk uses department to configure the department of the users in various

organizations. Each user in coDesk is associated with a department in an organization.

Designation

Every user in an organization is associated with a designation. coDesk defines the

designations of the users using this option.

Domain

When a user is authenticated by Active Directory mode, domain passwords need to be

provided to check the credentials. An Active Directory authenticated coDesk user will

provide the user name and the Active Directory password while logging in to the

application

Emergency Change

Emergency Change is of great significance and its implementation at the earliest is

necessary to restore the proper functioning of the various activities in an Organization.

Emergency change requires the approval of Change Advisory Board (CAB) Emergency

Change (E/C) before implementing the change. The change cannot be implemented

without receiving the approval.

Escalation

Escalation is the process of passing information through email to the superiors or experts

if a ticket is not resolved within the specified time duration.

Escalation Level

There can be many escalation levels. The application can send escalation alerts to

different people at different escalation time intervals.

Force Own

Force own depends on the permissions provided for the agents in the provider template.

The agent will be able to force own the ticket by searching the ticket from the title bar in

the home page.

Hierarchy Labels



Each and every asset is associated with a hierarchy label. Hierarchy label is used to

identify the position of the asset in an organization. Four levels of hierarchy labels can be

provided for each asset.

Holiday Window

Holiday window is used to define Holiday dates and the business hours of the

organization during the holidays. You can configure Holiday windows in different

timezones.

Identification Codes

Identification codes are used to identify a problem. Identification code is selected by the

user at the time of logging a problem ticket.

Implementation Team

Implementation Team is group of change managers who will implement the change

request approved by the members of the approval team. After implementing the change

the members of the implementation team will provide work order notes to intimate the

ticket owner about the change.

Known Error Database (KEDB)

Known Error Database is the database containing temporary work around and permanent

solutions of some possible known errors.

Known Errors

Problem management deals with finding the underlying cause for multiple incidents.

When the root cause for the problem is identified, temporary work around and solution

are developed, problem becomes a known error

Major Change

Major change is a classification of RFC which is of more importance and approval from

the members of the approval team is required.

Major change requires approval from the members of Change Advisory Board (CAB)

before implementing the change.

Major Incident

There can be many secondary incident tickets that are related to a primary incident ticket.

Finding a solution to the primary incident will in turn provide solution to the secondary

incidents. The primary incident is called the major incident and the other incidents that

are related to this primary incident are called minor incidents. Closing the major incident

will close all the related minor incidents

Manager

Managers are associated with the users in the application. Each user can have several

managers associated for different functions.

Map Vendor



Vendors can be mapped to the service. Hence, if any ticket is logged to a service the

ticket can be assigned to the vendor of the mapped service only.

Minor Change

Minor change is of very little importance and hence any change manager of the Service

Provider can approve the minor change.

Minor Incident

Minor incidents are secondary incidents which have a common root cause. There may be

many tickets which have the same root cause. All the tickets can be resolved by resolving

an incident ticket. The tickets that are related and resolved by solving the primary ticket

are called minor incidents.

Navigation Template

Navigational templates are used to grant navigation permission to the user roles that

have been configured in the application. Based on the permissions granted, the user will

be able to perform the actions using the application. The administrator can decide on the

module headings and subheadings that should appear on the application screen for

different roles. It is also possible to provide user specific navigation permission using this

option.

Non Implementation

The end user while logging a change request ticket can provide the effect of not

implementing the change. The agent working on the ticket can understand the

significance of the change. All the possible effects of non implementing the change

request tickets need to be defined before logging change request tickets.

Open Action

When a ticket is logged, the default action for the ticket is Open. Open action is not

available for the user.

Organization

coDesk stores the organizations of users. The organizational details like the Contact

person, telephone number, email address and fax number help to uniquely identify the

organization of the user using the application.

Proactive Problem

Proactive problem management is the process of identifying and solving problems and

known errors before incidents occur. The problem is foreseen and is resolved even

before its actual occurrence.

Problem Codes

Each problem is associated with a root cause, temporary work around and a permanent

solution. A problem code is provided for each root cause, temporary work around and

permanent solution. You can then associate these problem codes to Known errors and

store them in Known Error Database (KEDB).



Problem Outcome

Problem outcomes are the end results obtained after resolving the problem tickets. The

agent while resolving the problem ticket needs to specify the outcome of the ticket. All the

possible outcomes must be predefined to enable the agent to use them while resolving a

problem ticket.

Projects

Projects are used in Asset Management for mapping the assets.

Provider Template

Provider template provides permissions for the actions, activities and views for the users

associated with a specific service from a particular service provider. The first service

provider template created for any service is the default template. User specific actions,

views and activities can also be defined and the users can be associated with the

templates. Ticket proxy logging view can be defined for provider templates. The tabs and

the fields to be displayed while logging a ticket can be configured using this option. Asset

Service Action Mapping can be defined for asset service provider template.

Queries

When a problem or a change request ticket is logged by the user, the user can provide

clear picture of the situation by answering the queries. Queries can be defined separately

for problem and change request service types by the administrator. The end user can

select queries and provide answers for them while logging a ticket. The answers provided

by the end users help the agent in resolving the ticket.

Rating

After a ticket is resolved by the agent, the customer can rate the ticket according to the

satisfaction of the service received for the ticket. The rating determines the efficiency of

the agent working on the ticket.

Reactive Problem

Reactive Problem refers to the process of solving problems in response to one or more

incidents. By default the problem tickets logged are reactive in nature.

Receiver Template

Actions, activities and views can be defined for the service receiver. The first receiver

template created for a service is the default template. Users can be associated to non

default templates and user specific actions, activities and views can be defined. Ticket

logging view can be defined for receiver templates. The tabs and the fields to be

displayed while logging a ticket can be configured using this option.

Recurring Escalation

Escalation can be defined to repeat after specific time duration. The time interval for the

escalation alert message to repeat is called recurring time. Recurring frequency is the

number of times the escalation alert messages need to be sent.

Region and Location



Region and Location refers to the Region and the Location of the user logging a ticket.

The Region and Location must be associated with the Service Rule for resolving the

ticket. Time zones must be associated with the region and location. All the locations

under a region will have same timezone.

Reject Action

If the agent working on the ticket considers the ticket to be inappropriate, then the agent

can perform reject action before working on the ticket. Accept, reject and assign are the

three actions that an agent can perform before working on the ticket.

Reject Reason

The agent working on the ticket can reject the ticket from the work queue. While rejecting

the ticket the agent needs to specify the reject reason. All the possible reject reasons

must be configured

ReOpen Reason

The ticket can be reopened by the agent who was working on the ticket or by the end

user who logged the ticket. When the ticket is reopened, it is necessary to specify the

reason for reopening the ticket.

Reopen Action

The agent or the end user who logged the ticket can re-open the ticket. While performing

a reopen action it is necessary to specify the reason for reopening the ticket.

Resolution

After the ticket is resolved, the agent must provide the resolution code. The resolution

code helps the agent to keep track of the resolution outcomes for the ticket. You can

define the resolution codes before using the application.

Resolution Time

Resolution time refers to the time elapsed between the SLA start state and the SLA end

state discarding the time duration for which the ticket was placed in SLA Hold state. By

default the SLA start state is Opened and the SLA end state is the time at which the

resolve action is performed on the ticket. If the resolution time taken by a ticket exceeds

the time specified in the SLA, then the SLA for the resolution time is breached.

Resolution time refers to the time elapsed between the SLA start state and the time when

a resolve action is performed on the ticket discarding the time duration for which the

ticket is put in SLA hold state.

Resolve Action

Agent will need to resolve the ticket after diagnosing the issue and provide a solution.

Once the Resolve action is performed on the ticket, the ticket can be either closed or

reopened only.

Response Time



Response time refers to the time taken by the agent to accept / reject / assign the ticket

from the time the ticket is logged. The above actions must be undertaken before the

response time configured in the SLA elapses. If the response time exceeds the

configured Response SLA time, then the SLA for the response time is breached.

Request Types

Request Types are configured for incident tickets. There are four predefined request

types. The user can change the label names to suit their needs. Request types appear in

the ticket logging page based on permissions configured in Ticket Logging view of the

receiver template.

Role Types

There are two different role types in coDesk. They are agent and the End user. The agent

is a person who is working on the ticket (Service Provider). The end user is a person who

is logging a ticket (Service Receiver). You can configure users of any of these two role

types.

Each user in coDesk is associated with a First name, Last name, User name, Password,

Organization, Department, Work Group and Role. The contact details of the users like

Contact address, Phone number, Region, Location and Search code is also provided.

Root Cause

While resolving an incident ticket, the agent needs to specify the root cause associated

with the ticket. All the possible root causes for various incidents must be pre configured

before using the application.

Self Registration

Users can register themselves in the application using self registration. All the self

registered users will be part of end user role type. The self registered users can be

associated to different services.

Service

Each service is associated to a service type, service group, Service Provider and Service

Receiver. All the configurations selected for the Service Group are available for the

service. You can select the Category, Sub category and Classification associated with

the service. You can also select the Impact, Urgency and Priority associated with the

service. You can select the Actions, Status codes and the SLA for the service. The

incident service can also be configured for Acknowledge response and Acknowledge

resolution activities.

You also need to define the Default Operation Rule and the additional fields for the

service. Service provider Template and Service Receiver Template must be configured

for a service.



Service Code

Service Codes are pre fill codes defined in the application. The service codes can be

configured in the application to which the services and mailboxes are associated. These

codes can be selected while logging the tickets for the incident, problem and change

request service. That will automatically populate the other fields required to log the ticket.

The codes can also be mapped to the mailboxes for email call logging of the incident

tickets. These codes are provided in the Subject box while logging an incident ticket

through email. In addition, if the message is not provided while logging the ticket, then the

default message is sent in the email that is configured in the code.

Service Rule

A service can have any number of Service Rules. Each Service Rule is identified by a

unique combination of Category, Sub category, Classification, Region, Location, Priority

and Operational Rule. When a ticket is logged for a service, a Service Rule

corresponding to the ticket logged is searched and the corresponding Operational Rule is

selected. Depending on the Operational Rule, Service Window and the Routing Rule are

selected and the ticket is routed to the agent.

Service Group

Service Group is a collection of related services. The categories, classification related to

the service group, impact, urgency and priority related to the service group, the status

codes related to the service group and the additional codes like root cause reason,

closure and re-open reason can be configured. The fields selected for a service group

can only be used by services which are a part of the service group.

Service Level Agreement (SLA) / Operational Level Agreement (OLA)

Service Level Agreement (SLA) defines the response time, resolution time and SLA

breach time for Incident tickets. OLA defines the response time, resolution time and SLA

breach for Problem tickets.

SLA Response Reminder

The Administrator can configure the application to provide a reminder before the SLA for

the response time for a specific Service Rule breaches. For example if the value is

provided as 1hrs, and the response time for the ticket according to the Service Rule is 4

P.M then a reminder message is sent to the agent working on the ticket by 3 PM

Service Notes type

Service Notes are provided by the agents working on the ticket while performing various

actions and activities on the ticket. This helps to keep track of the various actions and

activities that are performed to resolve the ticket. All the possible service notes types

must be defined before using the application.

Service Providers

Service Providers are the group of users who may belong to any organization,

department and role. Service Provider is group of users who provide a particular service.



For each service in coDesk, there should be one Service Provider. One Service Provider

can provide multiple services.

Service Receivers

Service Receivers are group of users who seek service. The Service Receivers can

belong to any organization, department, work group and role. For each service there

should be one Service Receiver associated with the service. The Service Receivers can

log tickets to the service and the ticket can be serviced by the users of the Service

Provider associated with the service. A service receiver can be part of multiple services.

Service Window

Service Window refers to the business hours of the organization. You can define different

working hours for each day of the week in a service window. A graphical representation

of the different working hours for day of the week is displayed. You can associate a

timezone with the service window when you need to create service windows for agents

who work in different timezones.

Service Window Group

Service Window Group is a combination of Service Window and Holiday Window for a

particular time period. You can group service windows based on timezones.

Shift

Shift refers to the working hours of the users in an organization. The users can work for

any number of days. The operational start time and end time can be configured

separately for all days of the week. The user can be associated with a shift while building

a team.

SLA End State

The agent needs to perform a resolve action, before closing the ticket. The resolve action

can be mapped to any state. When the agent performs the resolve action, the ticket is

automatically assigned the corresponding mapped state and the SLA clock stops. The

agent cannot assign any state to end the SLA. The agents need to perform a resolve

action to end the SLA.

SLA Hold State

When a ticket is assigned SLA hold state, the SLA clock stops and the SLA clock

resumes after the ticket is assigned a non hold state.

SLA Start State

When a ticket is assigned the SLA Start State, the SLA clock starts ticking. The SLA Start

State can be different for each service.

Standard Change

Standard Change is a pre approved change request. It is a basic change and hence by

default the standard change is approved.



State Flow

State flow refers to the next possible states that can be assigned to a ticket. It defines the

flow of the ticket. For example, if Begin state is Accepted, the possible next states for the

ticket can be defined. So when the agent assigns accepted state for a ticket then

according to the end states defined in the state flow the agent can select the other states.

Team

Team refers to a group of people involved in providing service. A SERVICE PROVIDER

can have any number of teams. You can select and set the hierarchy of the team roles

before configuring team members for a team. You can build a team by selecting the

configured team roles and shifts and associate it to users.

Team Role

Team roles are created to build a hierarchy in the team. All the team roles must be

defined before associating them with the corresponding teams. Team roles play an

important role while performing certain actions like assign. The agent can assign the

ticket to other agents who are peers are agents lower in the hierarchy. While performing

Search by Team the agent will be able to view the tickets of the agents who are peers or

lower in the hierarchy.

Ticket Status

The agent working on the ticket can put the ticket to any ticket status. The default status

of the ticket when it is logged is opened. The other status that can be assigned to a ticket

before it can be closed must be defined using this option.

Ticker Messages

Ticker messages appear in the home page of the application based on the permissions

defined in the user template. Different icons can be associated to different ticker types.

Transfer Reason

A ticket can be transferred from one agent to another agent within the same Service

Provider. When an agent transfers the ticket, the agent needs to specify the reason for

transferring the ticket. The agent to whom the ticket is transferred can either accept the

ticket or reject the ticket. If the ticket is accepted, the ownership of the ticket is modified

and if the agent rejects the transferred ticket, then the owner is not altered.

User Template

User templates define the permissions for ticker and the bulletin board messages for the

users.

Urgency and Impact

Urgency and Impact are provided by the end users while logging a ticket. These features

help in determining the priority of the ticket. Urgency refers to the necessity of the service

and the impact refers to the effect of the problem. Based on Urgency and Impact a

priority matrix is constructed for resolving the ticket.



Vendors

Vendors are organizations who are involved along with the agents while resolving the

ticket. The contact details of the vendor are configured in coDesk using this option.

Vendor Escalation

Each vendor is associated to particular service. The ticket is routed to a vendor

depending on the service for which it is associated. Vendor SLA is defined for each

vendor. It specifies the time duration within which the issue has to be resolved by the

vendor. The resolution time and the escalation time for each service and each vendor

corresponding to the service are defined. The escalation time and the resolution time

vary with the priority of the ticket.

If the ticket is in the vendor assigned state for duration more than the resolution time

given by the vendor SLA then an email is sent to the vendor. When the ticket is put in the

vendor assigned state, the normal SLA will continue to be executed while the vendor SLA

will also start. The regular escalations can be sent along with the vendor escalations only

if regular escalation option is selected while configuring the vendor escalations.

Work Group

Each organization is associated with many departments. Each department can be further

classified in to workgroups. Users can be associated to organizations, departments and

workgroups.



5. Incident Management in coDesk 3.1

According to ITIL® Service Support best practices, an incident is an event which is not a

part of standard operation and which causes or may cause interruption thereby affecting

the normal productivity in an organization. The significant role of incident management is

to restore normal operation of the service as quickly as possible with no or least impact

on the productivity of the organization. coDesk is completely ITIL® centric and offers

flexible and efficient automation for incident management. coDesk helps the incident

management team to undertake the following tasks.

1. Provide flexible support for incident classification and categorization.

2. Helps restore services as quickly as possible with minimal disruption to users.

3. Manage and track incidents through their life cycle

4. Provide support for Operational activities

5. Automatic and flexible routing of an incident

6. Support for Response and Resolution SLA with escalations and notifications

7. Ability to allocate, transfer tickets to higher skilled experts.

8. Support for searching Knowledgebase to review solutions and workarounds to

known issues, problems, errors, etc.

9. Ability to link and track minor incidents with a major incident.

10. Support to relate Incident with Known Error, Problems, Change Requests,

Assets (Desktops, Routers, etc).

11. Ability to relate to one or more assets or configuration items with an incident.

12. Multiple actions possible – Accept, Own, Transfer, Allocate, Resolve, Close,

Reopen, etc

13. Ability for end user to rate tickets and provide feedback

Incident Management in coDesk 3.1


14. Support for Root Cause Analysis

15. Ability to record investigation, outcome and diagnosis with each incident.

16. Support for notifications and emails during entire incident life cycle.

17. Ability to correspond with end user and help desk teams.

18. Real time dashboards for Agents and Managers.

19. Out of the box historical reports for analysis of Incident Management Process.

Ability to choose and pick the columns that need to be displayed in the reports.

20. Flexibility of adding additional/custom text fields to record custom/additional

information with each incident.

21. Detailed audit history is available for every incident or ticket. The history keeps

track of all changes, transfers and actions taken on the incident from creation to

closure. This provides visibility to end user on the handling of the ticket.

The overall incident management in coDesk can be depicted by the figure below.

Figure 5-1: Incident Management Overview

The different ways by which the user can log incident tickets are provided in the left side

of the above diagram.

1. Incident tickets can be logged by accessing the web site or via email (SMTP)

2. Incident tickets can also be logged while generating Tivoli Event Console

Events. coDesk and Tivoli Event Console (TEC) are integrated and hence an

event generated in TEC will log a ticket in coDesk. Incident tickets can be

logged for SNAPPiMON events. SNAPPiMON and coDesk can be integrated

and any alarm generated in SNAPPiMON can be raised as a ticket in coDesk.



Incident ticket can be logged by the end user or the agent on behalf of other users (Proxy

incident). While logging the ticket, the user provides details like the service name,

category, sub category, classification, region, location, urgency, impact and description

for the ticket. The user can also provide attachments to support the ticket.

Self – Calls logged by end users

Proxy – Calls logged by agents on behalf of end users

Offline – Calls logged by agents after working on the calls. The agent can directly visit the

customer place and resolve the call and then later on the agent can log an offline call.

Offline calls can be logged only for incidents.

Routing

Service Rules are defined for several combinations of region, location, category, sub

category, classification, and priority for a service.

A service can have many Service Rules and when a ticket is logged to a particular

service the ticket looks for the best matched Service Rule and follows the corresponding

operational rule. From the operational rule the ticket looks for the service window and

selects the routing rule corresponding to the service window. If there is no service

window (the ticket is logged during non working hours) and the Route option in Service

Rule is not selected then the ticket takes the routing rule corresponding to the next

available service window. If a ticket is logged after the expiry of the service window

group, then the ticket is routed to the service administrator for the corresponding service.

According to the routing rule selected the ticket is routed either to a team /agent / shift/

team role / team role.

If there is a match in the Service Rule but the service window is not found and the Route

option in the Service Rule is checked, then the ticket is routed to service administrator.

The ticket takes the SLA, Response Escalation Rule, and Resolution Escalation Rule

configured for the administrator.

If no exact match in the Service Rule is found, then the ticket looks for the Routing

precedence defined for the service. According to the routing precedence defined if any

match in the Service Rule is found, then the application takes the corresponding Service

Rule. If none of the Service Rule matches with the ticket, even after considering the

routing precedence, then the ticket takes the default operational rule for the service. From

the default operational rule, the ticket looks for the service window and selects the routing

rule corresponding to the service window. If no match in the service window is found, the

ticket takes the routing rule associated with the next available service window. According

to the routing rule selected, the ticket is routed to team/agent / shift / team role. If a ticket

is logged after the expiry of the service window group, then the ticket is routed to the

service administrator for the corresponding service.

Generic Routing

Generic Routing in coDesk is used to route the ticket to the agents based on Team,

Team Role and Shift. For example if the Team is selected as Software and the Team

Role is selected as Engineer and the Shift is selected as Morning, then all the agents



satisfying all the three conditions of Team, Team Role and Shift are evaluated and the

ticket is routed to all the agents satisfying the conditions.

Specific Routing

Specific Routing in coDesk is used to route the ticket to the agents based on any one of

the following

i. Team

ii. Team Role

iii. Agent

iv. Shift

When Team option is selected, the ticket is routed to all the agents of the selected team.

When Team Role is selected, select the Team and the Team role and the ticket is routed

to all the agents of the selected team roles in the team. When the agent option is

selected, select the Team, the team role and the agent (s). The ticket is now routed to the

agent (s) configured. When Shift is selected, select the Team and the Shift the ticket is

routed to all the agents of the team and the shift selected.

Call Flow

The agent working on the ticket can perform several operations on the ticket. The ticket is

available in the work queue according to the routing and the agent needs to accept the

ticket. The time elapsed between the ticket log and the ticket acceptance / rejection is

called the response time. The response time can also be manually specified by the agent

working on the ticket if the service associated with the ticket is configured for

acknowledge response activity.

After the ticket is accepted, the agent becomes the owner of the ticket. The owner can

perform several actions like correspond with other agents or the end user, allocate the

ticket to other agents, transfer the ticket, assign to vendors, mark the ticket as major /

minor incident, relate the ticket to major incident, relate the ticket to assets, relate to

knowledgebase, raise problem or raise RFC and relate to known error. After performing

various activities on the ticket the ticket has to be resolved.

Notifications are provided to the user each time whenever there is a change in the status

or activity. This helps the end user who logged the ticket to keep track of various activities

that are performed to resolve a ticket. Notifications are sent as Email in HTML or text

format and through SMS.

Agent can mark an incident ticket as major incident while working on the ticket or logging

a proxy ticket. A major incident ticket can be related to several minor incident tickets.

Resolving a major incident ticket will prompt the agent to resolve the related minor

incidents. The agent working on the ticket can either resolve the minor incidents along

with the major incidents or can unrelate the minor incidents and resolve them separately.

Agents can look into the Known Error Database (KEDB) and the knowledgebase for easy

and quick resolution of the ticket. KEDB is a data repository which stores all the known

errors along with the root cause, temporary workarounds and permanent solutions.



Knowledgebase is a database repository which contains articles published by different

users. The agents and users based on the permission provided can go through them and

be aware of the latest technologies and improve their knowledge in problem solving. This

helps to resolve the tickets in a faster rate.

Incident Management in coDesk supports many teams for a service depending on their

shift and team role. Strong Audit capabilities are included to track of the incident tickets at

any point of time. Allocation details, details of attachments added to support the ticket,

Ticket rule summary, service notes, vendor details; related assets, related problems and

RFCs can be viewed to clearly understand the issue.

A service of incident type can be related to a service of problem or change request.

Whenever an incident ticket is logged, the particular incident ticket can be related to

problem tickets or change request tickets or assets related to the service. This relation

helps to easily identify the root cause of the problem and resolve the issue at the earliest.

Reports in coDesk are enhanced greatly to include web based reports, real time

dashboards.

Service Level Agreement

Service Level Agreement (SLA) is set of rules and norms that are agreed by the service

providing organization to offer quality service. There are normally two types of SLAs

defined for a Service Rule – Response SLA and Resolution SLA.

Whenever a user logs a ticket, the response SLA automatically starts ticking. The

response SLA ends at the moment the ticket is accepted / rejected / assigned and is

moved out from the work queue. If the service is configured for acknowledge response

activity, accepting the call is only the transfer of ownership for the call and the agent

needs to manually provide the response time by performing the acknowledge response

activity. The response time can be manually provided any number of times before closing

the ticket and the time must be greater than the ticket logged time.

When a ticket is assigned, the assigned agent cannot accept or reject the ticket and can

perform other operations on the ticket.

For example, if a user logs a ticket at 9 A.M and the response SLA for the ticket is

defined as 2 Hrs, then the agent should accept or reject or assign the ticket within 11

A.M.

If the ticket is accepted / rejected / assigned and is taken away from the work queue

before 11 A.M then the ticket has met the response SLA.

If the ticket is still available in the work queue after 11 A.M then the response SLA is

breached.

The user can configure SLA Start State and the Auto Closure Time for a service. SLA

start state refers to the state at which the Resolution SLA starts ticking. When a ticket is

put to SLA hold state, the SLA clock stops ticking but will resume again if the state is

changed to non hold status.

By default, when a ticket is logged, the Resolution SLA will start automatically if SLA start

state is mapped to the Open action. The Resolution SLA will start when the ticket is



assigned the SLA Start state. The SLA Start state can be assigned in any of the following

ways.

1. Changing the ticket status to SLA start state by using Service Notes

2. Changing the ticket status using Change Status action.

3. By performing an action that would change the status.

4. By performing transfer or allocation action.

For example if resolution SLA start state is Accepted and Accept action is related to

Accepted status then the Resolution SLA for the ticket starts immediately when Accept

action is performed on the ticket.

Whenever a ticket is assigned SLA Hold status the SLA calculation will stop temporarily,

but will continue again once the ticket status is changed to non hold status. The ticket

status can be changed by

1. Changing the ticket status to SLA start state by using Service Notes

2. Changing the ticket status using Change Status action. The change status

action will display only the statuses that are not mapped to the default actions

for a service.

Whenever a resolve action is performed on the ticket, the Resolution SLA stops. Resolve

action can be mapped to any status and the associated status becomes the SLA end

state for that service. The mapped end state is not available in change status option or

Service Notes option. The agent cannot assign that status to the ticket at any point of

time. When the agent performs Resolve action on a ticket, the ticket is assigned the

corresponding mapped status automatically and the SLA stops immediately.

Auto closure time is the time defined for each service for which the ticket is resolved and

is not reopened or closed. After the completion of the defined auto closure time, the ticket

gets closed automatically.

When a ticket is reopened the SLA resolution time continues ticking and is not started

fresh. The agent can perform all operations and activities similar to a new ticket.

For example,

SLA Start Time – 2 P.M

SLA Resolution Time - 4 hrs

Auto Closure Time – 2 hrs

The agent has resolved the ticket within 3 hrs i.e., by 5 P.M. The ticket will be closed

automatically by 7 P.M if the user who logged the ticket /agent who worked on the ticket

does not reopen the ticket. Reopen and Close actions are based on the permissions

defined for the agents and the end users in the provider and the receiver templates.

The SLA configuration for a service provides option to include / exclude the time interval

between the resolved state and the reopened state to be a part of the SLA while

configuring the Service.



If the ticket is re opened at 5.30 P.M and if the service is configured to include the time

between the resolved state and the reopened state to be the part of SLA then the agent

is left with only 30 mins to complete the ticket without breaching the SLA. But if the

service is not configured to include the time interval between the resolved state and the

reopened state to be the part of SLA then the agent is left out with 1 Hr to complete the

ticket without breaching the SLA.

SLA Resolution time is the time taken to resolve the ticket irrespective of the number of

times the ticket is reopened discarding the time interval for which the ticket is put in hold

state and the time for which the ticket was in resolved state and reopened again based

on the configurations made for the service.

Incident tickets need to be reopened before it is closed. Closed incident tickets cannot be

reopened.

Acknowledge Response

The ticket is routed to the work queue depending on the routing rule. The agent can

perform an accept action to work on the ticket.

The actual response time at this instant is the time at which accept / reject /assign action

is performed on the ticket.

If Acknowledge Response activity is configured for a service, the time at which the accept

action is performed on a ticket is just the transfer of ownership from the work queue. The

agent needs to manually provide the response time for the ticket. The response time

must be greater then the ticket logged time. The response time can be specified any

number of times and the time provided during the latest acknowledge response activity is

considered as the actual response time.

The actual response time should be less than or equal to the estimated response time.

Otherwise the response SLA for the ticket is said to be breached.

Acknowledge Resolution

Acknowledge Resolution if configured for a service, allows the agent to manually specify

the resolution time for the tickets associated with the service. The actual resolution time

depends on the time taken to perform the resolve action or the time specified during the

acknowledge resolution activity. Acknowledge resolution can be performed any number

of times and the application allows the agent either to retain the previous resolution time

or override that with the newly provided resolution time.

The estimated resolution time must be greater than or equal to the actual resolution time.

Otherwise the resolution SLA for the ticket is said to be breached.

SLA Escalation

Service Level Agreements (SLA) is configured to assure quality and quick service to the

end users. Response SLA is the time within which the ticket must be accepted or rejected

or assigned and moved away from the work queue or the time specified during

Acknowledge Response activity depending on the service configuration. Resolution SLA

is the time within which the ticket must be resolved. If the time taken to perform this



action exceeds the configured SLA time then the SLA is said to be breached for this

ticket. The resolution time can be manually provided by the agent while performing

Acknowledge Resolve activity depending on the service configuration.

The ticket can be escalated to the configured person as per the configured time which

corresponds to the SLA time. Many levels of escalations can be defined and notifications

and alert messages can be sent to different people at different duration. If the configured

escalation time duration is 12 hrs and the other configured escalation time duration is 6

hrs then, after the response SLA is started, the application waits for the least configured

time duration (6 hrs in this case) and checks if the ticket is not yet responded. If the ticket

is still available in the work queue and exceeds the response escalation time configured

for the ticket, then the ticket is escalated to the users configured for the escalation.

Similarly if the ticket is not resolved within the resolution escalation configured, then the

ticket is escalated to the configured users. Escalation levels are independent of the order

in which they are configured. The escalations levels are considered in ascending order of

escalation time. The second level escalation happens after the next least configured time

duration from the time the SLA is started (In this example it is 12 hours after the response

SLA is started.)

Note

Escalation time interval is calculated from the instant the SLA is

started. The minimum configured escalation time is taken as the

first level of escalation. For example if the configured escalation

levels are 10 Hrs and 6 Hrs, then the first escalation happens 6

Hrs after the SLA is started and the second escalation happens 10

Hrs after the SLA is started. The 10 Hrs also includes the first

configured 6 Hrs. If first escalation happens at 8 A.M in the

morning, then the second escalation happens at 12 noon.

Escalation Notifications can be provided for any number of times according to the

recurring frequency. If the recurring frequency is 4 and the recurring time interval is 5 hrs,

then escalation will happen after 5 hrs since the last escalation time. In a similar manner

escalation will repeat once in 5 hrs for 4 times. According to the recurring time and

recurring frequency the ticket can be escalated to higher personnel. The recurring

escalation time is calculated after the last level of escalation and is sent to the configured

users at that level. Escalation can also be continued irrespective of the frequency till the

ticket is closed.

Email Call Logging

coDesk enables end users and also the users who are not part of coDesk to log tickets

through email. When a user who is not part of coDesk logs a ticket, the user will be

mapped to a coDesk user. Email call logging facilitates ticket logging for incident tickets

only. Tickets logged through email follow the same call life cycle as the tickets logged

through other call modes. For email call logging, mailboxes and prefill codes have to be

configured. The email id for the mailbox, username and password can be configured in



the mailbox settings. The configured mailbox can then be associated with the prefill

codes.

TEC Integration

coDesk provides bidirectional integration with Tivoli Event Console (TEC). coDesk is

integrated with TEC by connecting TEC to coDesk database server through the CTA

(coDesk-TEC Adapter) tool. TEC Severity, TEC Template, and TEC Classes need to be

configured in coDesk for logging a ticket when an event is generated in TEC. TEC

Severity name should be same as in TEC.

SNAPPiMON Integration

coDesk provides bidirectional integration with SNAPPiMON 3.7. Multiple SNAPPiMON

SP4 instances can be integrated into coDesk. Each SNAPPiMON instance is configured

by its instance name, IP address, and port number.

SNAPPiMON events need to be configured in coDesk to log a ticket when an event is

generated in SNAPPiMON. coDesk is pre configured with certain common events fired in

SNAPPiMON. The user can also define new SNAPPiMON events in coDesk. However,

the events’ names should be same as in SNAPPiMON. The SNAPPiMON events need to

be mapped to coDesk incident service for logging a ticket.

Asset Manager Integration

Asset Manager 3.5 SP2 can be integrated with coDesk to maintain and keep track of the

assets available in an organization. Both Asset Manager and coDesk must share the

same database for integration. Asset Manager is integrated with coDesk by its server IP

address, port number, protocol type and instance name.

Permissions

Permission in coDesk is template based. The templates define the permitted actions,

activities and views for end users and agents. Separate templates are defined for Service

Provider and Service Receiver. Agents and end users will be mapped to multiple

templates for different services. There will be one default template for agent and end user

per service.



6. Problem Management in coDesk 3.1

According to ITIL® best practices, Problem Management investigates the underlying

cause of incidents and aims to prevent the incidents of the same time from occurring

again. Problem management assists the incident management in finding the underlying

solution for the event. When the root cause of the event is found the problem becomes a

Known Error. Each known error is associated with an error statement, temporary work

around and permanent solution. Effective problem management prevents similar

incidents from occurring again.

Problem management automation in coDesk provides the following capabilities:-

1. Log, track, transfer and manage problems.

2. Identify errors within the IT infrastructure.

3. Find root causes and initiate corrective action.

4. Reduce number & severity of incidents by proactively identifying improvements

to IT infrastructure.

5. Support for problem logging, categorization.

6. Support for recording problem analysis, investigations.

7. Support for root cause analysis including multiple workarounds, solutions, etc.

8. Support for multiple problem teams.

9. Support for Operational Level Agreements for Problem Resolution.

10. Support for multiple actions on Problems including Accept, Reject, Own,

Transfer, Transfer Accept, Transfer Reject, Analyze, Resolve, Close, Reopen,

etc.

11. Strong support for Error Control including Error detection and identification.

12. Support for recording error assessment, error resolution, etc.

Problem Management in coDesk 3.1


13. Monitoring Problem and Known Error through their life cycle.

14. Multiple reports provide excellent analysis capabilities.

15. Ability to associate problem record with change requests.

16. Ability to associate incidents with problems.

17. Ability to relate problem or known error with one or more Configuration Items or

Assets.

18. Multiple actions possible – Accept, Own, Transfer, Allocate, Resolve, Close,

Reopen, Assign etc.

19. Detailed audit history provided for each problem and known error across its

entire life cycle.

The overview of the problem management is as shown below.

Figure 6-1: Problem Management – Overview

A problem ticket can be logged in any of the following three ways

1. Problem ticket can be logged directly by the user using the application. Web

based ticket logging can be made by providing the required features and

descriptions for making the ticket.

2. Problem tickets can be raised from an incident to find the root cause of the

event. Hence problem ticket can be raised based on the need to close one or

more incidents of the same nature (reactive problem management). Problems

tickets can also be raised from change requests.

3. A problem can be proactively identified by analyzing either the incident trends

or by other proactive analysis and the solution for the problem can be found.

Proactive problem identification is the process of identifying the problem which

might occur in feature and finding the root cause, temporary work around and

permanent solution. Thus a problem can be solved even before its occurrence.

4. Proxy Problem tickets can be logged by the agent on behalf of other users.



Users while logging a problem ticket provide details like service name, category, sub

category, classification, impact, urgency, region and location. The user also provides a

brief description about the ticket. The user can also add attachment to support the ticket.

The user can also provide answers to some questions. The problem tickets can be

related to incident tickets, assets or RFC, Known error, Knowledgebase etc.

After a ticket is logged, the ticket is routed to the team / team role / shift / individual. The

problem management in coDesk can support multiple teams for a service and the ticket is

routed to the agent based on the routing configuration (team / team role / shift / agent).

The agent accepts or rejects the ticket. The agent working on the ticket needs to find the

root cause of the problem. The agent can perform several actions and activities like

allocate, correspond, transfer, relate to assets, relate to change request, relate to

incident, relate to knowledgebase, etc. After the agent finds the root cause of the

problem, the problem becomes a known error and the details of the known error are

stored in a Known Error Database (KEDB). The agent can then perform a root cause

analysis and add the temporary work around and a permanent solution for the problem.

Known Error Database (KEDB) in problem management is a data repository which stores

all the known errors and their associated root causes, temporary work around and

permanent solutions. Thus any agent working on the ticket can look in to KEDB to find

the appropriate solution for the problem. This reduces the time spent in re inventing the

wheel. The agent can link the problem ticket to the known error and provide the

associated solution for the problem. The agent can increase the first time resolution and

provide a cost and time effective solution.

Proactive problem management helps to keep identify the key areas and aspects that

might lead to problem and find a resolution for the problem. Since the resolution for the

problem is known in advance, such problems can be avoided. This avoids the time and

the money spent in resolving the problems and increases the productivity of the business.

Role based permissions and access control for data and actions are provided to control

accessibility.

Permission in coDesk is template based. The templates define the permitted actions,

activities and views for end users and agents. Separate templates are defined for service

provider, service, user and navigation. Agents and end users will be mapped to multiple

templates for different services. There will be one default template for agent and end user

per service.

Problem tickets are associated with Operational Level agreements (OLA). OLA is similar

to SLA in Incident management. OLA calculations and escalations in problem

management are exactly similar to incident management. However Problem

management does not include Acknowledge Response and Acknowledge Resolution

activities.

Notifications and alert messages are sent to the end user and the configured agents

whenever there is a status change in the ticket during its life cycle.

The status of the ticket can be tracked at any point of time by the end user to know the

progress of the ticket. The ticket can be reopened by the user who logged the ticket or



the agent who worked on the ticket. Only resolved problem tickets can be reopened. The

agent working on the ticket can reopen / close the ticket provided proper permissions are

allowed. When a ticket is reopened the same Problem ID is retained.

Problem Management in coDesk offers strong and effective reporting and Analytics.

Several reports are included to efficiently evaluate and assess the performance of the

agents in resolving the customer tickets.



7. Change Management in coDesk 3.1

According to ITIL®, Change Management is a process to ensure that standardized

methods and procedures are used for efficient and prompt handling of all changes in

order to reduce the impact of change related incidents upon service quality and

consequently improve the day to day operations of the organization.

coDesk provides significant capabilities to automate ITIL® recommended best practices

for Change Management Process. coDesk helps the Change Management team to

1. Implement standard procedures for efficient handling of changes including

logging, planning, scheduling, etc.

2. Automate Approval and Authorizations for all changes

3. Track every Change across Approval, Build, Test and Implementation.

4. Minimize risks associated with changes.

5. Support for change request (RFC) logging, categorization

6. Support for automating change approval process

7. Support for Change Advisory Board (CAB), CAB Emergency Committee

(CAB/EC)

8. Support for authorizing change implementation. Allows for risk analysis and

mitigation.

9. Support for implementing change calendar and schedule including reminders.

10. Ability to relate assets and configuration items with change request

11. Ability to relate incident, problems with change requests.

12. Support for tracking change across multiple steps including building, testing,

implementation and release cycles.

Change Management in coDesk 3.1


13. Ability to categorize change request as Minor, Standard, Major, Emergency,

etc.

14. Ability to prioritize change request based on impact & urgency.

15. Support for Post Implementation Review.

16. Excellent analysis via out of the box reports and dashboards.

17. Detailed notifications and alerts provided through out the life cycle of the

change.

18. Detailed audit history provided for every change request from creation to

closure.

The overview of change management is as shown below.

Figure 7-1: Change Management – Overview

Request for Change (RFC) can be raised under any of the following three situations.

i. A problem ticket can be raised from an incident and the change request

ticket (RFC) can be raised as a result of problem.

ii. Whenever an asset needs to be changed, a RFC is raised.

iii. Whenever there is an urgent / vital need for a service a RFC is raised. A

proxy RFC can also be raised by the agent on the behalf of other users.

coDesk supports multiple change teams namely Change Advisory Board (CAB), Change

Advisory Board / Emergency Committee (CAB/EC), Test Implementation team, Releasing

team etc.



Classification of Changes

In coDesk RFCs are classified into four different categories as follows

i. Standard Change

ii. Minor Change

iii. Major Change

iv. Emergency Change

Standard Changes are pre approved changes and hence there is no need for approval

from the change manager.

Minor Change is of little consequence and does not involve a greater risk. Minor changes

needs approval by the change manager before the change could be implemented.

Major Change is of greater consequence, and involves greater risk and impact on the

service. Such change requests are discussed in the CAB meetings that are scheduled for

particular dates. The risk, cost and the effect of the change request are analyzed in the

scheduled CAB meetings and are approved based on the needs.

Under certain circumstances, it may not be possible to wait until a CAB is created and the

problem is discussed. The problem may be very serious and it will be very necessary to

act on issue quickly. This type of change is called an Emergency Change. Emergency

change requires the consent of CAB/ EC.

Change Advisory Board (CAB)

Change Advisory Board is a set of people who are involved in authorizing the change

request. CAB includes people from various departments to assess and evaluate the need

and the risk involved in performing this change. Only after receiving the approval of the

CAB all the major change requests are carried out.

Change Advisory Board / Emergency Committee (CAB/EC)

CAB/EC is a subset of CAB. It contains only the important members of CAB. The change

request may be urgent that the organization cannot wait until it is approved by all the

members of CAB. The CAB / EC can approve the change request considering the risk

and loss involved.

After a ticket is logged the agent can accept or reject the ticket. Once the ticket is

accepted, the agent can perform any of the three operations on the ticket. They are:

i. Activity Notes

ii. Change Status

iii. Classify RFC

Activity note is similar to service notes in Incident and Problem management. In Activity

Notes, the agent can provide the start time and the end time of the activity, the activity



duration, the current status, the cost involved in the activity, the artifacts to support the

change request.

Change status option is used to change the status of the ticket.

Classify RFC is used to classify the change request ticket. After a RFC is classified, the

change manager can disqualify or close or reopen the RFC. Once a ticket is disqualified

all associated correspondences and relations are removed. The disqualified RFC is

removed from the application. Approval team and Implementation teams can be built only

after the RFC is classified.

According to the RFC classification, the approval process for the ticket changes. After

classifying the change request ticket based on the impact and the risk, the change

manager needs to build an approval team. The approval team must involve all the key

persons involved in the change request. The approval team can be either CAB or

CAB/EC depending on the requirements. The RFC needs to be approved by all the

members of the approval team before implementation. If there is a delay in the approval

or the change manager is not convinced by the decision of the approval team, then the

change manager can override the decision of the approval team. After the RFC is

approved and authorized, the implementation team must be identified and built. Artifacts

like Risk analysis and Implementation Reviews are obtained to effectively implement the

change.

End user, Implementation team members, Approval Team members and Change

Manager (including Ticket owner and other members of the Service Provider) of a

particular ticket can correspond among themselves. Ticket can be transferred to other

agents or the agent themselves can force own other change manager’s ticket

A RFC can be closed and can be reopened only once by the ticket owner or the end

user.

The change calendar is built which will schedule the various activities for change

manager, approval team and implementation team. The start time and the end time for

the activity must be provided and the change calendar can be designed to provide

reminder before starting the activity and before ending the activity. This helps to complete

the process in time. According to the planned start and end dates the implementation

team and the change manager can act and implement the change.

There is no SLA or escalation defined for change management in coDesk. Notifications

are provided to users whenever there is a change in the ticket status. Reminder alerts are

sent to configured users before beginning and before ending the activity.

Audit history is available to the user who logged the ticket to keep track of the progress

made in the ticket. Each and every step carried out in the process of solving the ticket is

available in the ticket audit which helps to determine the call flow process. coDesk

displays unique audit details according to the nature of actions and activities performed

by different users involved in the process. For example, the ticket owner can view all the

details of the audit and the end user can view only the RFC logged, rejected, closed and

reopened related audit details.



The agent can perform different activities including transferring a RFC, relating to

incident, relating to problems, relating to assets, relating to known error, relating to

knowledgebase etc. This helps to integrate the tickets and establish a relation between

them.

Wide range of reports and analytics are included in coDesk. Reports help to measure the

performance of various activities and thereby help the users to pay attention to the areas

in which improvements are to be made. Real time dashboards are also available to

display the various activities carried out during the implementation process.

Role based permissions and action control are provided in coDesk to perform various

activities.



8. Configuration Management in coDesk 3.1

According to ITIL® the goal of configuration management is to provide a logical model of

IT infrastructure that is accessed by ITIL® processes to drive consistency among them.

Activities of configuration management include identifying, controlling, maintaining and

versioning Configuration Items (CIs).

coDesk provides excellent support for configuration management. It supports the

integrated Netsol CMDB which is also shared with Netsol Asset Manager. When

integrated with Netsol Asset Manager, financial, contractual information of assets can

also be tracked. Configuration Management integrated with Netsol Asset Manager helps

in managing finances, contracts, AMC and usage of IT assets throughout their lifecycles

for the purpose of maintaining an optimal balance between business service

requirements. Some of the activities of asset management include inventory, software

license, vendors, procurements, leases, warranties etc.

coDesk provides significant capabilities to automate ITIL® recommended best practices

for Configuration Management Process. coDesk helps the IT team to

i. Efficiently manage assets related to IT Infrastructure

ii. Identify, Control and maintain IT and non-IT assets through their life cycle

iii. Maintain relationship of assets with end users, projects, departments,

locations, etc.

iv. Record and track status and changes to asset configuration across asset

life cycle.

v. coDesk integrated with Netsol Asset Manager helps to Maintain and track

financial, vendor and contract information

vi. Categorize assets across different types of servers, desktops, laptops,

routers, switches, links, operating systems, databases, applications, etc

Configuration Management in coDesk 3.1


Some of the features of coDesk Asset Management are:

1. Ability to record Serial id, Name, Version Identifier, Description, Category, Sub

category, Type status of an asset.

2. Ability to associate asset with Projects, End users, Departments and Asset

owner.

3. Ability to associate asset with 4 levels of geographical information. For

example, an asset can be associated with Location, Building, Floor and

Cubicle.

4. Ability to relate an asset or CI to Incident, Problem or Change Request.

5. Ability to track status and audit history of open and closed Incidents, Problems

and Change Requests with each asset.

6. Strong audit history capabilities to track changes made to asset across it’s life

cycle

7. coDesk integrated with Netsol Asset Manager helps in tracking Annual

Maintenance, Contracts, Invoices, Purchase Orders, Payments, Depreciation

with each asset

8. Fine grained access control and permission based model for enhanced data

security.

9. coDesk integrated with Netsol Asset Manager supports for reminders before

expiry of support contracts, payments due, insurance premium & renewals, etc.

10. Excellent analytics via out of the box reports.

The overview of Configuration Management in coDesk is as follows

Figure 8-1: Configuration Management – Overview



Configuration Item (CIs) is a component of infrastructure or an item associated with IT

infrastructure. Configuration Management Database (CMDB) is a data repository which

contains all relevant details of assets and details of important relationships between

assets Tracking contracts and financial information and the customizable CMDB is

available with Netsol Asset Manager Integration.

Each Asset contains a

i. Category

ii. Sub category

iii. Classification

iv. Relationship

v. Status

Flexible geographical hierarchy levels like location, building, floor, cubicle etc can be

defined for an asset. This enables efficient identification of an asset by its physical

location.

The assets in coDesk can be related with projects, users and departments. The

configuration item is also related to different hierarchy labels like location, building and

cubicle. Configuration management also helps to keep track of the assets and their

status. Each asset is identified uniquely by the category, sub category and classification.

coDesk integrated with Asset Manager provides support for Flexible & Extensible

Configuration Management Database.

It stores relations between Assets, Users, Owners, Locations, Buildings, Departments,

Projects, etc.

coDesk provides role based permission & access control for data and actions. Each

Asset service in coDesk associated with one Service Provider and one Service Receiver.

The Service Provider for asset service will have users (agents) who can perform activities

like creating assets, viewing assets , modifying assets , deleting assets , editing assets

relationships, change status, adding service notes, responding to requests associated

with a RFC, assets specific permissions, raise RFC, incidents, problems for assets ,

viewing related incidents, related problems and related assets based on permissions.

coDesk integrated with Asset Manager helps in relating and viewing financial information.

The Service Provider for asset service cannot be divided into teams. Each Configuration

Item can be associated with only one service. The same asset cannot belong to two

different configuration services. The members of the Service Provider can perform

actions on the associated assets based on permissions. A coDesk user can be a part of

more than one Service Provider. Under such situations, the user will be able to access

assets of different services.

The Service Receiver for asset service are end users who can perform activities like

logging an incident ticket for assets , logging a problem ticket for assets , logging an RFC



for assets, viewing assets specific details including the relationships, the status and audit

history.

Provider templates can be configured for asset service to provide permissions for the

users of service provider for performing actions, activities, and views on the assets.

Receiver template can be configured for asset service to provide permissions for the

users of service receiver for viewing assets.

Asset service can be configured to provide show and hide permissions on the assets for

all the users of service provider and service receiver. Show and hide permissions can be

granted for all the users of service provider and service receiver to perform actions,

activities, and views on the assets as configured in the provider and receiver templates.

Permissions on the Assets are a combination of asset service and asset override.

Permissions evaluate under these conditions:

1. If you provide show permission for service provider and service receiver in an

asset service, all users of service provider and receiver in that asset service will

be able to perform actions, activities and views on all assets based on provider

and receiver templates. You can provide deny permission for particular users in

that asset service in Asset Override.

2. If you provide hide permission for service provider and service receiver in an

asset service, all users of the service provider and receiver in that asset service

will not be able to perform actions, activities and views on all assets. You can

provide allow permission for particular users in that asset service in Asset

Override.

3. If the user is part of service provider and service receiver, service provider

permission will have precedence over service receiver permission.

4. If you provide hide permission for owner and end user of the assets who are

part of service provider and service receiver, they will be able to perform

actions, activities and views on all assets based on provider and receiver

templates unless they are provided deny permission in Asset Override.

5. If the owner and end user of assets are not part of service provider and

receiver, you cannot provide deny permission for them in the Asset Override

template. In this case, they will only be able to view the assets.

Asset Override rule can be configured to provide allow and deny permissions on the

assets for particular users in an asset service which will override the permission given in

that asset service.

The Service Receiver for asset service can contain agents from other service (like

incident / problem / change management) and end users. The end users as a part of

Service Receiver can only log tickets and view minimum asset details.

Configuration Management has relations with other services; Incident Management uses

assets information to identify what assets are involved in an incident. Problem

Management uses assets information to help track down the root cause of a problem.



Change Management uses assets information to understand the ramifications of a

proposed change.

coDesk provides ability to keep track of changes to assets over a period of time and

provides strong Audit Log capabilities for Asset history. It also provides ability to relate

Assets/ assets to Incidents, Problems, and Change Requests.



9. Dashboard view in coDesk 3.1

coDesk is enhanced with the dashboard feature. Dashboard in coDesk is the graphical,

pictorial and tabular representation of the data and reports available in the coDesk

database. This feature helps the user to easily understand and view the status of

SLA/OLA and various tickets across various services available in coDesk. It also helps

the user to monitor the SLA/OLA and also provides a clear view of the Ticket Life Cycle.

Users’ can view various types of reports with respect to the services available in coDesk.

There are five pre-defined dashboards based on the users in coDesk.

i. End User dashboard: For users who are a part of the service receiver

template and receives service from the service desk.

ii. Agent dashboard: For users who are a part of the service providers

template and provides service for the end user.

iii. Service Admin dashboard: For one who manages services and is

responsible for service delivery and its performance.

iv. Helpdesk Admin dashboard: For one who manages the helpdesk function

and keeps track of the loads, tool availability and performance.

v. Executive dashboard: For stakeholders who are interested in the services

offered by the service desk and can make informed decisions based on

the performance of the service.

Dashboards are based on permissions. The user can view the information in the

dashboard based on the permissions provided.

End User Dashboard

The End User who has logged into the coDesk can view the dashboard based on the

permission provided. The end user will not be able to view the agents and service admin

dashboard since they are not part of the service providers template.

The End User dashboard displays reports related to Pending Tickets, Ticket Rating and

Trend Analysis with respect to the various service types available in coDesk.

Dashboard view in coDesk 3.1


The End User dashboard reports are based on three service types in coDesk namely

Incident, Problem and Change Request.

Agent Dashboard

The Agent who has logged into the coDesk can view the dashboard based on the

permissions provided. The agent can view the end user dashboard only if the agent is

part of the service receiver template.

The Agent dashboard displays reports related to various SLA types, various OLA types,

various Pending Tickets status, Ticket Rating by user, Ticket Trend Analysis and change

analysis.

The Agent dashboard reports are based on three service types in coDesk namely

Incident, Problem and Change Request.

Service Admin Dashboard

The user who is a part of administrator group in coDesk can view the dashboard based

on the permissions provided. Service Admin can also view Helpdesk admin and

Executive dashboard with respect to the permissions provided.

The Service admin dashboard displays various reports for the specific service. The report

helps the service admin to monitor the health of the service in terms of Load, Team

performance, SLAs, End user satisfaction, First call resolution, Ticket life cycle, Agent

analysis and Trends.

The Service Admin dashboard reports are based on three service types in coDesk

namely Incident, Problem and Change Request.

Helpdesk Admin Dashboard

The Helpdesk Admin dashboard helps the user to monitor the Availability, Performance

and Load of the application. The report displays the Application Server Health, Database

Server Health, Ticket Load Analysis and User Load Analysis.

The user can view the helpdesk admin dashboard reports based on the permissions

provided. Any user regardless the user is part of the Receivers/Providers group can view

the helpdesk admin dashboard based on the navigational permissions provided to the

user.

Executive Dashboard

The Executive dashboard helps the user to monitor the SLAs, Trends, Availability,

Performance and Service health metrics. The report displays the Ticket Analysis, Ticket

Logging, Ticket Resolution, SLA/OLA Analysis, Trend Analysis and Service health

metrics.

The user can view the executive dashboard reports based on the permissions provided.

Any user regardless the user is part of the Receivers/Providers group can view the

executive dashboard based on the navigational permissions provided to the user.

Knowledgebase


10. Knowledgebase

Knowledgebase is a database repository which can be shared by all users of the

application. Knowledgebase is based on permissions and if configured, the user can

store new articles related to any category. The agent can look into the knowledgebase to

resolve the ticket. Knowledgebase acts as a first hand solution to resolve a ticket. The

major features of knowledgebase in coDesk are given below.

coDesk provides support for other users to enhance the already configured articles by

providing contributions. Any number of contributions can be added by the users of the

application. This helps to build and share valuable library of articles between users.

coDesk provides options to search for articles. The user can search and view the articles

and can rate the articles accordingly.

coDesk provides option to search for the articles based on popularity and ratings.

Popularity is based on views. Each time any coDesk user looks for articles, the view is

incremented. Popularity and ratings are independent of each other. Rating refers to the

value for the articles as provided by the user benefited by the article. View refers to the

number of times the article is viewed by the coDesk user irrespective of the rating.

Knowledgebase in coDesk can have contributions in the form of attachments or external

URLs or hyperlinks.

Every article in the knowledgebase provides us with the following information – Title,

description, table of contributions, last updated by, last updated on and other details.

coDesk offers excellent tracking and auditing capabilities for each KB article.

Knowledgebase in coDesk is permission driven and access control is provided for

creating, searching and viewing and contributing entries.



Table of Figures

Figure 3-1: coDesk Summary ......................................................................................................... 15 Figure 3-2: coDesk Logical components......................................................................................... 16 Figure 5-1: Incident Management Overview ................................................................................... 34 Figure 6-1: Problem Management – Overview ............................................................................... 44 Figure 7-1: Change Management – Overview ................................................................................ 48 Figure 8-1: Configuration Management – Overview ....................................................................... 54



11. Index

A

About this Guide, 7

B

Benefits of coDesk 3.1, 12

C

Change Advisory Board (CAB), 47 Change Advisory Board / Emergency

Committee (CAB/EC), 47 change calendar, 48 Classification of Changes, 46

F

Features of coDesk 3.1, 11

I

incident management in coDesk, 34

K

Knowledge Base, 57 Known Error Database (KEDB), 43

L

logical view of coDesk components, 16

O

overview of change management, 46 overview of the problem management, 42

P

Proactive problem management, 43

R

Routing in coDesk, 35

S

Service Level Agreement in coDesk, 37 SLA Escalation in coDesk, 39

T

Terms Used in coDesk 3.1, 19

W

What is coDesk, 9

co desk 3.1 administrator guide

Business

features of codesk

benefits of codesk

guide chapters

administrator guide

administrator guide

table of tables table

disclaimer copyright

pre copyright ibm