• Author:TechExcel co.Ltd
  • Date:
TechExcel ServiceWise Admin Guide

TechExcel ServiceWise offers a complete solution for managinginternalhelp desk support—the support services that are offered to a company’s employees.

Using TechExcel ServiceWise, support organizations may optimize every aspect of their support processes.

• Managing support incidents and events

• Managing employees

• Maintaining a knowledge base as a support resource

• Tracking company assets

• Managing professional services

TechExcel ServiceWise provides a comprehensive, high-end solution that can be configured to match any internal support process.

ServiceWise uses the “project” concept to represent and manage company employee and support management processes. In ServiceWise, each project represents a distinct area of work and is controlled by a set of administrator-defined workflow rules.

There are two types of ServiceWise projects: base projects and work projects:

• A base project enables businesses to store and manage employee data.

• A work project enables businesses to manage specific activities related to internal help desk support.

Every employee base project may support one or more work projects. Knowledge can also be shared among work projects. You can create a knowledge base so multiple support projects can all work together to build and share knowledge. Although all support incidents are work project-specific, project members may share incidents (interproject copying) and events (global events) across work projects. (as well as global events.)

Abase projectis a tool for storing and managing the employee, asset, and knowledge data that is shared by multiple work projects. The base project acts as a centralized datastore for the work projects and enables them to freely share employee, asset, and knowledge data while maintaining their own incident and event data, team structures, and workflow rules.

Subprojects organize the incidents tracked in a project into discreet subfolders to provide project teams with a clearer and more realistic view of the incidents managed in each project.

Generally, subprojects represent incidents that are grouped together based on incident types, incident ownership, serviced employees, or schedules. But subprojects may be used to organize support incidents by any criteria that is useful or meaningful to the support organization.

Every subproject is defined by s schedule —start and end dates, access controls, and parent-child relationships with the other subprojects. Every subproject may be the parent of multiple subprojects, which in turn are the parent of child subprojects.

ServiceWise administration is process of installing, integrating, and configuring a ServiceWise site—an implementation of ServiceWise components, applications, and modules, and of customizing that implementation and its projects to support their internal business processes.

TechExcel ServiceWise is designed to be extremely flexible so that businesses may quickly implement and define tools that enable them to run their business. TechExcel ServiceWise system administration and project customization tasks require no programming. All ServiceWise configuration, customization, and administrative tasks may be managed in the ServiceWise Admin client using point-and-click tools

The ServiceWise model is designed so that businesses may configure ServiceWise projects to support business processes rather than changing their business to fit the limitations of the application. All projects, incidents, events, and employees are fully customizable so that support organization may track the data that is important to them.

As we have seen, administrators may create as many or as few projects as are needed to manage and track their business and each project may be defined by unique incident, event, and workflow definitions.

In addition, all access controls are defined on a project-by-project basis. ServiceWise users may log into and work in many different projects, be assigned a unique account type, privileges, and responsibilities in each project using a single ServiceWise license.

ServiceWise administration is managed at two levels: the system level and the project level.

System-level administrative tasks include the creation of ServiceWise base and work projects, the creation and management of ServiceWise user accounts and licenses, and the administration of ServiceWise system configurations. System-level administrative tasks fall into three general groups:

• System-level project administrative tasks include the creation and maintenance of base projects and work projects as well as all ServiceWise site configurations.

• System-level user administrative tasks include the creation and management of user accounts and licensing, the definition of system team groups, and the creation and management of administrator account types.

• System-level tool administrative tasks include the installation of ServiceWise applications and modules, the configuration of the ServiceWise Email Server, ServiceWise Document Server, and TechExcel Search Engine, and all integration configurations.

All system level administrative tasks are managed by a system administrator—a licensed ServiceWise user that has been assigned a system administrator account type. A system administrator account type defines the privileges that are granted to that user in the ServiceWise site.

System-level administrative tasks include the definition of what is tracked in the project, how it is tracked, and who may track that data.

Project administration tasks may be broken into four inter-related areas:

• Project definition

• Incident definition and GUI customization

• Project member administration

• Workflow administration

Both system and project-level administration tasks are controlled by account type-based access controls. The access controls that enable administrators to perform system-level and project-level configuration and customization tasks may be defined independently of one another enabling support organizations to create many different administrative accounts with different levels of access and power.

ServiceWise enables project administrators to define and represent their support organizations based on their job responsibilities and team membership and to implement project workflow and security.

All incident, employee, and knowledge management tasks in ServiceWise are controlled using a set of account type-basedaccess controls. The ability of project members to perform specific tasks may be controlled.

The account type-based approach provides administrators with greater flexibility to customize project workflow and security to meet their unique requirements and procedures.

• Account types

• Team groups

• Group folders

ServiceWise administration is managed at two levels: the system level and the project level. System-level administrative tasks include the creation of ServiceWise base and work projects, the creation and management of ServiceWise user accounts and licenses, and the administration of ServiceWise system configurations.

System-level administrative tasks fall into three general groups: ?System-level project administrative tasks include the creation and maintenance of base projects and work projects as well as all ServiceWise site configurations.

• System-level user administrative tasks include the creation and management of user accounts and licensing, the definition of system team groups, and the creation and management of administrator account types.

• System-level tool administrative tasks include the installation of ServiceWise applications and modules, the configuration of the ServiceWise Email Server, ServiceWise Document Server, and TechExcel Search Engine, and all integration configurations.

All system level administrative tasks are managed by a system administrator—a licensed ServiceWise user that has been assigned a system administrator account type. A system administrator account type defines the privileges that are granted to that user in the ServiceWise site.

Once a user account is designated as a system administrator, that user may log into ServiceWise Admin using their username and password and configure system-level settings. All system-level administrative tasks are performed in the System Settings project.

In ServiceWise, aprojectis a tool for storing, organizing, and managing incident, event, employee, asset, knowledge, and project team data. Every ServiceWise implementation—called aServiceWise site—consists of two different types of projects: base projects and work projects.

• Abase projectis a tool for storing and managing the employee, asset, and knowledge data that is shared by multiple work projects.

• Awork projectis a tool for storing and managing incident and event data. Every work project represents adistinct area of workand is defined by unique team structures (account types, team groups, and group folders) and workflow rules. Every ServiceWise work project is linked to a single ServiceWise base project.

Generally, the configuration and customization of ServiceWise projects is the responsibility of a project administrator. However, many project administrative tasks are the responsibility of the system administrator.

ServiceWise system-level project management tasks include:

• Understanding Active and Inactive Projects

• Creating ServiceWise Base Projects

• Creating New Work Projects

• Copying ServiceWise Project Settings

• Backing Up ServiceWise Projects

• Restoring Backed Up Projects

• Creating Projects Based from Backed Up Projects

• Deleting ServiceWise Projects

System administrators may create, delete, open, close, back up, and restore ServiceWise base projects and work projects in the General System Settings folder of the ServiceWise Admin client.

Abase projectis a tool for storing and managing the employee, asset, and knowledge data that is shared by multiple work projects.

The base project acts as a centralized datastore for the work projects and enables them to freely share employee, asset, and knowledge data while maintaining their own incident and event data, team structures, and workflow rules.

System administrators may create new ServiceWise base projects using the New Project command in the File Menu. The New Base Project dialog box enables administrators to define the project title, the project type, and to import project settings from previously-defined projects.

When creating a ServiceWise base project, system administrators may create the project from scratch or they may import project properties from previously defined ServiceWise projects. For information on importing project properties from other ServiceWise projects see “Copying ServiceWise Project Settings” on page 25.

To create a new ServiceWise base project:

1Invoke the New Project command.

The New Project command is accessible by three methods:

• Click the New Project button in the tool bar.

• Select the New Project command in the File menu.

• Press CTRL + N.

The New Project dialog box appears.

2Select the Base Project option and click the OK button.

If a base project already exists, a warning message appears. Click the Yes button.

The New Base Project dialog box appears.

3Enter a project title in the Project Name field.

Avoid using the following characters when naming a base project: / \ : ? “ < > |.

4Select the internal ServiceWise project type option.

Currently, only the internal ServiceWise project type is supported in TechExcel ServiceWise.

5Click the OK button.

Awork projectis a tool for storing and managing incident and event data. Every work project represents adistinct area of workand is defined by unique team structures (account types, team groups, and group folders) and workflow rules. Every ServiceWise work project is linked to a single ServiceWise base project.

System administrators may create new ServiceWise work projects using the New Project command in the File menu. The New Work Project dialog box enables administrators to define the project title, the base project and to import project settings from previously-defined projects.

To create a new ServiceWise work project:

1Invoke the New Project command.

The New Project command is accessible by three methods:

• Click the New Project button in the tool bar.

• Select the New Project command in the File menu.

• Press CTRL + N.

The New Project dialog box appears.

2Select the Work Project option and click the OK button.

The New Work Project dialog box appears.

3Enter a project title in the Project Name field.

Avoid using the following characters when naming a work project:/ \ : ? “ < > |.

4Select the internal ServiceWise project type option.

Currently, only the internal ServiceWise project type is supported in TechExcel ServiceWise.

5Click the OK button.

In TechExcel ServiceWise user administrative responsibilities are split between the system administrator (who administrates the entire ServiceWise implementation) and individual project administrators (who administrate projects within the implementation).

• System administrators are responsible for creating user accounts, defining user account properties, and assigning licenses to ServiceWise users.

• Project administrators may add system administrator-defined user accounts to their projects and assign account types to these user accounts.

System administrators may use controls in the Support Member Manager to create, edit, delete, and merge user accounts. User accounts are shared across all projects in a TechExcel ServiceWise implementation.

• Each user account consists of a set of user attributes that define basic information about a user such as that person’s first and last names, phone numbers, and email addresses.

• Each user account is identified by a unique user name and password which enable the user to work in the ServiceWise application.

Project administrators may add user accounts to a project after they have created account types and assigned project-level privileges to those account types. A user account may not be added to a project unless that user account is assigned an account type.

User account management tasks include:

• Understanding the Support Member Manager

• Creating and Editing User Accounts

• Defining General User Data

• Defining User Administrative Access Controls

• Defining User Administrative Access Controls

• Defining Team Member Contact Information

• Deleting User Accounts

• Defining User Profiles

• Importing and Exporting User Accounts

• Emailing the ServiceWise Installer to Project Members

System administrators may use the Support Member Manager to create, edit, delete, and manage user accounts.

The Support Member Manager displays high-level information for every project member in a ServiceWise implementation and controls that enable system administrators to manage user accounts:

Figure 3-1: Support Member Manager

Colored icons clearly identify ServiceWise users:

System administrators are displayed with a red icon.


Project administrators are displayed with a turquoise icon.

Active single-product license or suite license users are displayed with a green user icon.

Active light support license users are displayed with a yellow icon.

Inactive users are displayed with a gray icon.

The Support Member Manager displays seven different controls that enable system administrators to manage project members.

• The User Selection dropdown list enables administrators to filter the project members displayed in the Support Member Manager list by their user status: all users, active users, or inactive users.

• The Invite Selected Users to Install Client button enables administrator to email a link to the ServiceWise client installation program to the selected project member.

• The New button enables administrators to create new project members in the project.

• The Edit button enables administrators to edit project members in the project.

• The Delete button enables administrators to delete project members from a project.

• The Merge button enables administrators to merge into a single project member multiple user accounts.

• The Import button enables administrators to import user account data.

• The Report button enables administrators to view the User Information report.

System administrators may use the New button the Support Member Manager to create new ServiceWise user accounts. Once a system administrator has created a user account and defined the user properties for that account, project administrators may add that user account to ServiceWise work projects.

The Member Information page enables system administrators to define the user account properties for new and existing ServiceWise user accounts.

Figure 3-2: The User Information Manager

The Member Information page consists of three tabs: the General tab, the License/ Privilege tab, and the Advanced tab.

• The General tab displays basic user account properties including their name, email, and user status in the ServiceWise   implementation.

• The Advanced tab displays controls that enable the administrator to define a user’s pager and mobile phone numbers and addresses.

To create a user account:

1Click the Support Member Manager icon in the tool bar.

The Support Member Manager appears.

2Click the New button.

The Member Information manager appears.

The Member Information manager displays three tabbed pages: the General tab, the License/Privilege tab, and the Advanced Settings tab.

3Define basic user account properties in the General tab.

For detailed instructions see “Defining General User Data”.

4Define licensing and system administrative privileges in the License/Privilege tab.

For detailed instructions see “Defining User Administrative Access Controls” and “Managing User Licenses”.

5Define contact information in the Advanced Settings tab.

For detailed instructions see “Defining Team Member Contact Information”.

6Click the OK button.

The user account is displayed in the Support Member Manager list.

To edit a user account:

1Click the Support Member Manager icon in the tool bar.

The Support Member Manager appears.

2Select the user account in the Support Member Manager list.

3Click the Edit button.

The Member Information page appears.

4Define basic user account properties in the General tab.

For detailed instructions see “Defining General User Data”.

5Assign the user account to a system team group in the General tab.

A system team group is an administrator-defined grouping of users that represents a internal company structure such as a product division or an office. For more information see “CreatingSystem Team Groups”.

6Define licensing and system administrative privileges in the License/Privilege tab.

For detailed instructions see “Defining User Administrative Access Controls” and “Managing User Licenses” .

7Define contact information in the Advanced Settings tab.

8Click the OK button.

System administrators may define basic account properties including user names, passwords, and phone numbers whenever they create or edit ServiceWise user accounts.

The General tab displays basic user account properties including their name, email, and user status in the ServiceWise implementation. The basic user account properties displayed in the Basic tab include:

Member Name:The Member Name property represents the name that the project member uses to log into the application.

First Name:The First Name property stores the first name of project members.

Last Name:The Last Name property stores the last name of project members.

Initial:The Initial property stores the first initial of the project member’s middle name.

Password:The Password property stores the password that project members use to log into the ServiceWise project.

Confirm Password:The Confirm Password control enables administrators to confirm the password entered in the Password control.

Phone (W):The Phone (W) property may be used to store the work phone number of project members.

Phone (H):The Phone (H) property may be used to store the work phone number of project members.

Fax:The Fax property may be used to store the fax number of project members.

Email:The Email property may be used to store the email address of project members.

System administrators may use controls in the Support Member Manager to define a grant administrative privileges to users within a ServiceWise implementation.

• TheIs a System Administrator optionenables the user to perform system administrative tasks. A system administrator has TechExcel ServiceWise Admin access to all system level features and full access to all projects in TechExcel ServiceWise.

• TheIs a Project Administrator optionenables the user to perform system administrative tasks. A project administrator has TechExcel ServiceWise Admin access to only those projects for which they have been defined as project administrator.

• TheIs an Asset Administrator optionenables the user to administrate asset management setting in AssetWise. An asset administrator has access to AssetWise Administrator, a separate application available if the AssetWise add-on module is purchased.

• TheIs an Form Administrator optionenables the user to manage forms in FormWise A form administrator has access to create and manage forms in FormWise, a set of features available in the TechExcel ServiceWise client.

System administrators may use the Delete button in the Support Member Manager to delete user accounts from ServiceWise projects.

System administrators may only delete user accounts that are not members of any ServiceWise project. For step-by-step instructions on removing a user account from a project see “Defining User Profiles” on page 40.

To delete a user account:

1Select an inactive user account in the Support Member Manager list of the SupportMember manager.

System administrators may only delete inactive user accounts.

2Click the Delete button.

The warning dialog box appears.

3Click the OK button.

TheServiceWise Document Serverenables support organizations to upload and download files to the project knowledge base, to attach knowledge items to support incidents, and to access all project knowledge including file attachments, email attachments, and knowledge documents.

ServiceWise Document Server configurations enable ServiceWise projects to locate the external document server and to download or upload knowledge items. ServiceWise Document Server administration is a three step process:

The ServiceWise Document Server talks to the ServiceWise Application Server and the ServiceWise Web Server through a TCP/IP connection. Administrator-defined ServiceWise Document Server settings apply to every project in the ServiceWise site.

ServiceWise Document Server administrative tasks include:

• Configuring the ServiceWise Document Server

• Viewing the Document Root Directory

• Configuring Web Server Access to the Document Server

• Configuring Client Access to the Document Server

Administrator-defined ServiceWise Document Server configurations enable ServiceWise projects to locate the external document server so that project members may manage project knowledge using the ServiceWise Windows and Web clients.

System administrators may configure the ServiceWise Document Server in the Document Server Setting page of the General Settings folder.

TechExcel recommends configuring the TechExcel ServiceWise Document Server using TCP/IP settings. System administrators must define ServiceWise Document Server properties:

• The server name (or IP address) is the exact name or IP address of the computer where the document server resides.

• The port number represents the port number used by the document server. The default port number is 8229.

To configure the ServiceWise Document Server:

1Select the System Setting project in the Project dropdown list of the tool bar.

2Select the Document Server Setting page in the General Settings folder.

The Document Server Setting page appears.

3Select the Support Document Server (TCP/IP access) check box.

4Enter the IP address or the name of the server machine that hosts the ServiceWise Document Server in the Server Name edit box control.

5Enter the port number in the Port Number edit box control.

The port number is defined when the administrator installs the ServiceWise Document Server. The default port number is 8118.

6 Optional: To test the connection to the ServiceWise Document Server, click the Check Connection button. If the connection is successful, a confirmation dialog box appears and the read-only Document Root Directory control displays the location of the project Document Root Directory.

The document root directory is a directory where all project documents are stored. The Document root directory is defined during the installation of the ServiceWise Document Server.

The Document Root Directory control in the Document Server Setting page is a read-only field that is automatically populated when a connection is established between the ServiceWise Admin client and the ServiceWise Document Server.

TheServiceWise Web Serveris an optional application that enables ServiceWise project members to access ServiceWise projects through an intranet or the Internet.

To enable project members using ServiceWise Web to upload, download, and access project knowledge, the system administrator must identify the location of the ServiceWise Document Server so that it can be found by the ServiceWise Web Server.

The ServiceWise Web Server may access the ServiceWise Document Server by three methods:

• Direct access by a local path

• Direct access by a network path

• TCP/IP access

To configure Web Server Access to the Document Server:

1Select the System Setting project in the Project dropdown list of the tool bar.

2Select the Document Server Setting page in the General Settings folder.

The Document Server Setting page appears.

3Select and define the method by which the ServiceWise Web Server accesses the ServiceWise Document Server.

• To enable access by a local path, select the Direct Access Through the Following Local Path radio button and define the path in the edit box.

• To enable access by a network path, select the Direct Access Through the Following Network Path radio button, click the Browse button, and locate the path in the custom browser.

• To enable access by a TCP/IP connection, click the TCP/IP Access radio button.

To enable project members using the ServiceWise Windows client to upload, download, and access project knowledge, the system administrator must identify the location of the ServiceWise Document Server so that it can be found by the ServiceWise clients.

The ServiceWise Web Server may access the ServiceWise Document Server by two methods:

• Direct access by a network path

• TCP/IP access

To configure Client Access to the Document Server:

1Select the System Setting project in the Project dropdown list of the tool bar.

2Select the Document Server Setting page in the General Settings folder.

The Document Server Setting page appears.

3Select and define the method by which the ServiceWise Windows clients accesses the ServiceWise Document Server.

• To enable access by a network path, select the Direct Access Through the Following Network Path radio button, click the Browse button, and locate the path in the custom browser.

• To enable access by a TCP/IP connection, click the TCP/IP Access radio button.

ServiceWise email error handling enables system administrators to track and diagnose problems with incoming and outgoing email notifications. All email error handing settings are defined in the System Settings project. System-level settings apply to all project in a ServiceWise site.

Email retrieval and email notification settings are defined separately.

• The Email Retrieval page enables system administrators to define rules for managing incoming email errors.

• The Email Notification page enables system administrators to define rules for managing outgoing email errors.

Figure 4-1: Email Retrieval Page

Using the Email Retrieval page and the Email Notification page in the System Setting page, system administrators may define general settings including trace levels for email notification errors, create error logs, and define email notification service messages.

System administrators may define general mail error handling settings using tools in the Mail Notification Service Error Handling Setting manager. General settings include the email trace level and email service settings.

Email trace levels determine the types of messages that are logged when email errors occur. System administrators may choose one of three email trace settings:

• The Info, Warning, and Error trace level

• The Warning and Error trace level

• The Error trace level

Email service settings determine the sensitivity of the email notification service. Email notification may either continue to operate when an error occurs, or stop. System administrators may choose between two service settings:

• The Continue Running the Service with Log Messages service level

• The Stop Service when Error Occurs service level

To define general settings:

1Select the Mail Notification page.

The Mail Notification page appears.

2Select an option from the Email Trace Level dropdown list.

3Select an option from the Email Service Setting dropdown list.

System administrators may enable ServiceWise to write error messages to a log file and define the name of that log file using tools in the Mail Notification Service Error Handling Setting manager.

To create log files:

1Select the Email Retrieval page.

2Select the Enable to Write Error Messages to Log File check box.

3Define the name of the log file in the Log File Name field.

 

Project administrators are responsible for managing project-specific properties, project GUI customizations, and assigning privileges to project members.

 

Project administrators define what is tracked in the project, how it is tracked, and who may track the data. Project administration tasks may be broken into four inter-related areas:

 

• Project definition

• Incident definition and GUI customization

• Project member administration

• Workflow administration

 

A ServiceWise implementation (site) may support multiple projects, and every project administrator is responsible for defining the scope of their projects and the nature of the incidents tracked in that project.

 

Project scope determines what is tracked in the project, how it is tracked and who may track it. A project is a tool for managing and trackingincidents. An incident is a collection of data that represent the tasks (discreet units of work) that project members may perform in a project. The incidents manged in a project and the data represented by the incident depend on the project type.

 

Every ServiceWise site consists of a base project and one or more work projects. Base projects are used to manage the employees that are shared by multiple work projects.

 

Project administrators may define a unique project team, workflow rules, auto-routing rules and escalation rules for each project.

 

 

Project administrators are responsible for customizing thegraphical user interface(GUI) of the project to represent and track the incidents tracked in that project.

 

By customizing the project GUI, the project administrator also defines what data is tracked in the project. An incident is a collection of data that is submitted, updated, and tracked in the project.

 

Project administrators may customize and add pages and controls and define parent-child relationships between selection controls. All project customizations are manifested in the ServiceWise client Window and Web interfaces.

 

 

Defining the project team and project account types. Project administrators may define all of the project members, group teams, and group folders used in the project.

 

Project administrators are responsible for adding user accounts to a project and assigning each user account an account type that determines that project members project-level privileges.

 

• In ServiceWise all privileges are assigned toaccount typesand not to individual user accounts. User accounts are granted project-level privileges based on the account type they have in the project.

 

• Aproject memberis a user account that has been added to a project and assigned an account type by a project administrator.

 

Team groupsrepresent teams of project members that share a common set of responsibilities within a project. Each group enables project teams to assign incidents to multiple project members who do not necessarily share the same account type.

 

Group foldersrepresent a common repository for incidents that may be owned by multiple project members. Every group folder is owned by a group and access to the incidents contained in the group folder is protected by group-membership and account type-based access privileges. Only project members that belong to the group that owns the group folder and who have the privileges to access a group folder may view, own, and forward group folder incidents.

 

Account types, groups, and group folders enable administrators to define flexible team representation in a project.

 

Project administrators are responsible for defining all project workflow rules and process automation settings including incident auto-routing, incident notification, and incident escalation.

 

Administrator-defined workflow rules enable organizations to ensure that incidents are managed in an effective and timely manner.

 

In ServiceWise, every incident hasone and only oneowner at every stage of the development life cycle. The owner of an incident may be an individual project member or a group folder, but current incident owner is always tracked in a project.

 

Although system administrators are responsible for creating ServiceWise projects and defining many project properites, project administrators may edit or update many basic project properties.

 

System administrators are responsible for creating projects, defining the project type, and the based project.

Project administrators are responsible configuring work projects to support help desk processes.

 

In the General Project Settings folder, project administrators may define general project information and enable certain advanced features. The General Settings folder contains nine different system pages that enable project administrators to define

 

project properties, team membership, project account types and privileges, and optional features. The Project Properties page enables project administrators to edit and update fundamental project properties.

 

                                 

 

                                                       Figure 5-1: Project Properties Page

 

Basic project properties include the name of the project, the project description, and the incident ID prefix used.

 

The Base Project is defined by the system administrator when the work project is created. Project administrators may not change the base project of their work project.

 

The Project Name property defines the name of the current project.

 

The Base Project Type is defined by the system administrator when the base project is created. Project administrators may not change the base project type of the base project. This field is editable only in base projects.

 

The Project Type is defined by the system administrator when the project is created. All ServiceWiseServiceWise work projects belong to the ServiceWise project type. The Project Type control is not visible in base projects.

 

The Description property defines a general description of the current project.

 

The ID Prefix property defines a numerical or character prefix that is added to each incident ID in the project. This feature may be used so that incidents associated with a particular project are easier to identify.

 

The ID Starting No. property defines the initial incident ID number. If an administrator enter 100 in this field, the first incident created is incident number 100.

In ServiceWise, all customer incidents are managed and tracked assupport incidentsin the incident view of the ServiceWise client. A support incident represents a task or set of tasks that may be managed by the support organization in workflow throughout the life cycle of that incident.

In ServiceWise, support incidents are managed and tracked in the incident view of the ServiceWise Windows and web clients. Project administrators are responsible for defining the data that is tracked in a work project and for customizing the graphical user interface that support engineers use to manage and track incident data.

Every incident is represented by a unique incident ID, a description of the incident, an incident workflow state, a work description, and other dynamic properties. Most incident properties are fully customizable.

The data that comprises and incident may vary from project to project. Project administrators may define which properties comprise an “incident” on a project-by-project basis.

Incident administration is essentially the task of identifying the data that needs to be tracked in a project and customizing tools that enable support engineers to collect, manage, and track that data.

Define the data collected and tracked in each project by customizing system controls and creating and defining custom controls. Incident administration tasks fall into a number of broad categories.

• Customize function pages to display system pages and custom pages.

• Define user access to pages and controls in the ServiceWise client applications.

• Define relationships between data managed in pages and data-entry controls.

• Create employee pages and custom controls.

The ServiceWise client is fundamentally a tool for creating, managing, and tracking incidents and the employees, events, and assets that are related to those incidents.

The ServiceWise client GUI provides support teams with a tool for viewing and updating all information about the incident. Project members may update incident details, add notes and note attachments, view incident history, or create links between related incidents

Project administrators may customize almost every page and data-entry control displayed in the ServiceWise client to support and manage their business processes.

Figure 6-1: The ServiceWise Windows Client

The incident view of the ServiceWise client consists of two primary panels: theincident list paneland theincident detail panel. Each panel contains tools that enable project members to manage and track incident data.

• The incident list panel displays high-level information about multiple incidents simultaneously. Each row represents a specific incident. Each column represents an incident property such as its title, incident ID, current owner, and incident workflow state.

• The incident detail panel displays detailed information about a single incident in multiple tabbed form pages—the Description page, Current Status page, Events tab, Assets tab, and so on. Each page displays data entry controls that enable project members to define and track incident properties.

Project administrators may choose which pages are displayed in the incident detail panel and which data-entry controls are displayed in each page. They may define any number of custom pages and add any number of custom controls to each page.

In ServiceWise, all incident data is stored, tracked, and managed in two categories of controls: system controls and custom controls.

• System fields are predefined fields that represent core object properties. System fields are represented in the client by controls that are specifically designed to manage incident data. Many system fields are linked to other fields or to other ServiceWise features, and are not fully customizable. Project administrators may customize the title of each system control.

• Custom fields are custom defined by the project administrator in each project and are managed in the client using administrator-defined controls. Custom controls are fully customizable.

Project administrators may use controls in the General Settings page to define general incident settings in work projects.

General incident view customization tasks include:

• Renaming Support Incidents

• Defining the Status Control as Read-only

• Enabling Co-owner Events

• Configuring Employee Access to Support Incidents

• Displaying Work Description in Forward Incident Manager

• Customizing the Incident List Panel

In ServiceWise, all customer support incidents are managed and tracked assupport incidents. The termincidentis used throughout the ServiceWise Admin, Windows, and Web clients.

ServiceWise enables project administrators to customize the name that is used to refer to support incidents in each work project. Support organizations may choose to call incidents,tickets,items, or any other term that is familiar to their support team.

The Refer Incident As control enables administrators to change the Incident label used in TechExcel ServiceWise. The text entered in this edit box is displayed in instead of the wordincidentthroughout the TechExcel ServiceWise Windows and Web client.

In ServiceWise, incident linking facilitates the management and tracking of related support incidents and enables project administrators to define complex rules to manage related incidents based on their relationships.

Incident linking enables support organizations to identify and track related support incidents as single units.

• Linked incident details may be viewed and updated whenever its link is accessed.

• Administrator-defined workflow rules may tie the progress of a support incident to the successful completion of other incidents that are linked to it.

An incident link creates a relationship between two support incidents and defines rules that define how those incidents are managed in the project. Every incident link is based on an administrator-defined link type.

ServiceWise incident linking administrative tasks include:

• Understanding Incident Linking

• Defining Referential Link Types

• Defining Parent-Child Link Types

ServiceWise enables support organizations to create two different types of links between incidents: referential links and parent-child links.

• Referential links define a simple relationship between two incidents and facilitates the management and tracking of these incidents.

• Parent-child links define a relationship in which the workflow state of one incident may be defined by the progress made on the other incident.

An incident link facilitates the tracking and management of related incidents. Linked incidents may be tracked in the ServiceWise client. All incident linksbidirectional: project members may view and track detailed information about either incident by accessing the linked incident in the ServiceWise client.

Whenever a project member creates a link between two incidents in the ServiceWise client, the project member must select an administrator-defined link type to define the relationship between those incidents and the rules that manage their relationship.

Using interproject linking, administrator-defined link types may also define the relationship between incidents in separate ServiceWise projects, between support incidents in ServiceWise and CustomerWise projects, or between ServiceWise support incidents and DevTrack development issues.

Once a link type is defined in the Link Type manager that link type is available for selection in the ServiceWise client whenever a project member creates a link between two incidents.

Referential links may be used to define simple relationships between two support incidents and to enable support organizations to better identify and track multiple incidents that are related to one another.

Every referential link is based on an administrator-defined referential link type. A referential link type is defined by three properties: its link type name, link type category, and link type description.

Unlike parent-child link types, referential links do not define workflow enforcement rules for managing the linked incidents. Either incident in a referential link may be updated or closed freely without affecting the incident state of other incident in the relationship.

To define a referential link type:

1Access the Link Type manager. All link types may be defined in the Link Type manager in the ServiceWise Admin client. Project administrators may access the Link Type manager from two pages.

• Click the Define Link Type button in the Incident Link Type page of the Incident View folder.

• Click the Define Link Type button in the Interproject Copy page in the Advanced Settings folder. The Define Link Types manager opens.

2Click the New button. The Define a Link Type Define dialog box opens.

3Enter a name in the Link Type Name text box.

4Select the Reference Link radio button in the option Link Type Category area.

5Enter a brief description of the link type in the Link Type Description control.

6Click the OK button. The Link Type Define dialog box closes.

Parent-child links define dependency relationships between two support incidents and enable support organizations to manage the workflow of related incidents as a single unit.

Parent-child links define relationships based on aworkflow enforcement rule. Enforcement rules define how linked incidents when a project member attempts to close a parent or child issue:

No Enforcement: Freely Close Parent or Child IncidentThe No enforcement: Freely Close Parent Or Child Incident rule creates a simple referential relationship between the linked incidents.

Warning: Do Not Close A Parent Incident Until All the Child Issues Get ClosedThe Warning: Do Not Close a Parent Incident Until all the Child Incidents Are Closed rule creates a warning message that is displayed in the client whenever a project member attempts to close parent incident that is linked to open child incidents.

Enforce: Cannot Close A Parent Incident Until All the Child Issues Get ClosedThe Enforce: Cannot Close a Parent Incident Until all the Child Incidents Are Closed rule mandates that a project member close all child incidents before a parent incident can be closed.

Warning: Do Not Close Child Incident Until the Parent Issue Is ClosedThe Warning: Do Not Close a Child Incident Until the Parent Incident Is Closed rule creates a warning message that is displayed in the client whenever a project member attempts to close a child incident that is linked to open parent incident.

Enforce: Cannot Close Child Incident Until the Parent Issue Is ClosedThe Enforce: Cannot Close a Child Incident Until the Parent Incident Is Closed rule mandates that a project member close the parent incident before the linked child incident can be closed.

Auto Close Child Incident When Parent Incident Is ClosedThe Auto Close Child Incident when Parent Incident Is Closed rule automatically closes all child incidents whenever a linked parent incident is closed.

Every parent-child link is based on an administrator-defined parent-child link type. A parent-child link type is defined by four properties: its link type name, link type category, link type description, and a workflow enforcement rule.

To define parent-child link types:

1Access the Link Type manager.

All link types may be defined in the Link Type manager in the ServiceWise Admin client. Project administrators may access the Link Type manager from two pages.

• Click the Define Link Type button in the Incident Link Type page of the Incident View folder.

• Click the Define Link Type button in the Interproject Copy page in the Advanced Settings folder. The Define Link Types manager opens.

2Click the New button. The Define a Link Type Define dialog box opens.

3Enter a name in the Link Type Name text box.

4Select the Parent-Child Links radio button in the Link Type Category area

5Define parent-child link close time enforcement rules.

The Close Time Enforcement area displays six options:

• No enforcement: freely close parent or child issue

• Warning: do not close a parent issue until all the child issues get closed

• Enforce: cannot close a parent issue until all the child issues get closed

• Warning: do not close child issue until the parent issue gets closed

• Enforce: cannot close child issue until the parent issue gets closed

• Auto close child issues when the parent issue gets closed.

6Enter a brief description of the link type in the Link Type Description page.

7Click the OK button. The Link Type Define dialog box closes.

8Click the Close button in the Link Types manager.

The web conversation is a useful tool for communicating with employees. The Web Conversation page provides support project members a powerful tool for communicating with employees about their incidents. The Web Conversation page features a rich text chat-like interface, with time stamped and logged data input.

Project administrators may use controls in the Web Conversation page to automatically add a new web conversation note whenever an email is sent, or when a new event is added from that employee to the incident.

Project administrators may enable two options in the Web Conversation page:

• The Auto Add a New Web Conversation when a Employee Submits a New Event option

• The Auto Add a New Web Conversation when a Employee Sends a New Email option

Project administrators must enable support for the Web Conversation feature in the Project Properties page. Web conversations are enabled in each project independently.

ServiceWiseinterprojectmanagement enables support organizations to copy incidents from one project to another project, create links between incidents in different projects, and track linked support incident or development issues usinginterprojectactions.

Interproject actions andinterprojectlinks provide support organizations with greater flexibility and power to manage support incidents across multiple projects.

Interproject Copy:Aninterprojectcopy is a procedure by which a ServiceWise project member may copy a support incident to other ServiceWise projects, CustomerWise or DevTrack projects from a ServiceWise client.

Interproject Link:Aninterprojectlink ties incidents in different projects together and enables project teams to view and manage incidents in other projects. Support incidents that are managed and tracked in ServiceWise projects may be linked to development issues managed in TechExcel DevTrack projects or to sales and marketing incidents managed in TechExcel CustomerWise projects.

Interproject actions and linking provide support organizations with the following benefits:

• Interproject incident copying: Project members may copy incidents in a ServiceWise project and submit those incidents to a target project.

• Interproject linking: Project members may create referential or parent-child links between incidents submitted or copied to a target project and incidents in the originating ServiceWise project.

• Tracking and editing linked incidents: Interproject links may enable project members to view, edit, and manage the linked incidents in the ServiceWise client.

Standard interproject action and linking administration is a four step process:

• Enable target projects: All standard interproject actions and linking is defined on a project-by-project basis. Project administrators must define rules for each project independently.

• Enable and define standard interproject actions: Standard interproject actions (interproject submission and interproject copying) are defined by default incident owner rules, default account access rules, default incident templates, and concatenated incident titling rules. Standard interproject action rules are defined on a project-by-project basis in the Properties tab of the Interproject Copy page.

• Define applicable link types for interproject linking: For each enabled target project, project administrators may define one or more applicable link types. Link types define the relationship between linked incidents in different projects. Every link type belongs to one of two link type categories: the referential link type category or the parent-child link type category.

• Define field mapping and field choice mapping: The mapping of incident property fields between projects, enables project members to submit or copy incidents between heterogeneous projects. Interproject mapping is defined in the Field Map tab of the Interproject Copy page. Interproject field choice mapping is defined in the Field Choice Map tab of the Interproject Copy page.

Interproject actions enable project members to copy the incidents managed in one ServiceWise project and submit copies of those incidents to other ServiceWise, CustomerWise, or DevTrack projects. Interproject links between the original incident and its copy enable project members in either project to track the progress of linked incidents in the other project.

To define interproject copying and linking rules, an administrator must first identify applicable target projects, enable interproject copying, enable interproject linking, define applicable link types for target projects, map fields between incidents in different projects.

Project-level interproject action and linking settings define the options that are available to project members in the ServiceWise clients. Project members may perform no action, linking, or editing unless that task has been defined applicable by the project administrator. And all actions, linking, and editing rules are defined independently for each target project.

• Interproject copying is enabled on a project-by-project basis. Project administrators may enable or disable interproject actions for each target project.

• Interproject linking is enabled on a project-by-project basis. Project administrators may enable or disable interproject linking for each target project.

• Link types are enabled on a project-by-project basis. Project members may create links between incidents in different projects using any link type that has been defined as applicable to the target project.

• Interproject linked incident editing rules are enabled or restricted on a project-by-project basis.

Interproject administrative tasks include:

• Enabling Target Projects

• Enabling Interproject Copying

• Enabling Interproject Linking

• EnablingWorkflowStateEditing

• Enabling Incident Owner Editing

• Defining Default Owners in Target Project

• Work Description Editing Rules

• Title and Description Editing Rules

• Defining Concatenated Incident Title Prefixes

• Defining Default Account Type Access Rules

• Defining Default Subprojects

A target project is a ServiceWise, CustomerWise, or DevTrack project that has been identified and enabled by the project administrator. Incidents may be copied from the current project to the target project and links may be created between project incidents and incidents or issues in the target project.

To enable interproject copying and linking between the current project and another project, select the project in the project list of the Interproject Copying page of the Advanced Project Settings folder. A red check mark is displayed next to the title of the enabled target project.

Once a project has been enabled for interproject copying, the administrator may enable and define interproject action settings including interproject copying and interproject linking.

Workflow is a business process used to manage the tasks that compose a project.

Workflow rules enable project managers to define and track the flow of work between individuals and teams. A well-defined set of workflow rules enable an organization to perform tasks in an efficient and repeatable manner.

TechExcel ServiceWise delivers a flexible workflow model that enables project administrators to replicate and enforce their processes in ServiceWise projects. By combining administrator-defined workflow, incident, and incident escalation rules, TechExcel ServiceWise enables administrators to define flexible and powerful process management tools.

• Project workflow determines the life cycle of ServiceWise incidents. Project administrators may define workflow settings once in TechExcel ServiceWise Admin, all project members will manage incidents according to existing processes.

• Incident routing enables administrators to define rules for automatically assigning incidents to appropriate project members based on the incident attributes and project member skills and workload.

• Incident escalation enables administrators to define rules for automatically escalating incident statuses if the due date has passed or if no progress has been made in several days. Project administrators may also enable email notifications for all escalations.

TechExcel ServiceWise enables each project administrator to define a unique set of workflow rules to manage the incidents in that project. Each work project is managed by its own workflow rules.

Administrator-defined workflow rules define the life cycle of incidents in TechExcel ServiceWise projects.

Workflow rules enable project administrators to define which states an incidents must go through during its life cycle and how project members may update the incident state of incidents within that project.

Project administrators define workflow by defining the workflow model, workflow options, and workflow rules in that project.

Incident workflow administrative tasks include:

• Defining the Project Workflow Model

• Enabling Workflow Rule Options

• Creating, Editing, and Deleting Workflow States

• Defining Applicable Owner Workflow Rules

• Defining Incident Access (Who Can Change Workflow Rules)

• Defining Read-Only Field Workflow Rules

• Defining Invisible Field Workflow Rules

• Defining the Mandatory Field Workflow Rules

• Defining Default Submission States

• Enabling Closed Event Restriction

Project administrators may use controls in the Workflow Settings page to select the workflow model that is used to define manage incidents in ServiceWise projects. Project administrators may choose between three options:

• The No Workflow model

• The State-dependent Workflow model

• The Transition-dependent Workflow model

The workflow model selected determines how incidents are managed in ServiceWise projects. Project members may submit, update, forward, close, and reopen incidents based on administrator-defined workflow rules. How project members go about managing incidents in a project and which rules an administrator may define and enforce are determined by the workflow model selected.

In TechExcel ServiceWise, project workflow may be based on two different models: the state-dependent model or transition-dependent model. The workflow model determines how project members may manage incidents within the project.

To select a project workflow model:

Project administrators may select one of three options for defining workflow in a ServiceWise project:

Status Can Be Freely Changed Without Workflow Restriction:The Status Can Be Freely Changed Without Workflow Restriction option enables project members to freely change the incident state of an incident.

Status Change Is Based On Workflow and Via Selecting the Next State:The Status Change Is Based On Workflow and Via Selecting the Next State option enables project members to change the incident state of an incident to the next state in project workflow. This is known as state-dependent workflow.

Status Change Is Based On Workflow And Via Performing A State-to-State Transition:The Status Change Is Based On Workflow And Via Performing A Stateto- State Transition option enables project members to change the incident state of an incident to the next state in project workflow by performing an action. This is known as transitiondependent workflow. Each transition represents an action.

Project administrators may enable and define six different types of workflow rules for each workflow state in the incident life cycle.

Next State:Next State rules determine the sequence of workflow states in the incident life cycle.

Applicable Owners:Applicable Owner rules determine which project members, groups, or group folders may own incidents in each workflow state.

Who Can Change :Who Can Change rules determine which project members, groups, or group folders may update incidents in each workflow state.

Read-only Fields:Read-only Fields rules determine which pages or fields are editable in each workflow state.

Invisible Fields:Invisible Fields rules determine which pages or fields are visible in each workflow state.

Mandatory Fields:Mandatory Fields rules determine which pages or fields are mandatory in each workflow state. Mandatory fields must be completed for an incident to be passed to the next state in project workflow.

 

ServiceWise subproject management is the process of creating and managing subprojects in a hierarchical tree structure that represents and defines the project work breakdown structure.

 

Project members may create subprojects in the Incident view and define subproject statuses and priorities. Project members may manage subprojects in a TechExcel ServiceWise projects based on subproject privileges that are granted to their account type by a project administrator.

 

Subprojects organize the incidents tracked in a project into discreet subfolders to provide project teams with a clearer and more realistic view of the incidents managed in each project. All ServiceWise support projects may be managed using a combination of subprojects, incidents, and events.

 

Subprojectsare groups of incidents that are organized together by support member teams, serviced employees, or schedules. Subprojects may be used to organize support incidents by any criteria that is useful or meaningful to the support organization. Every subproject has a defined beginning and end and defined relationships with the other subprojects. Every subproject may be the parent of multiple subprojects, which in turn are the parent of child subprojects.

 

Incidentsare the individual tasks that must be completed in the course of the support life cycle. All employee support tasks are represented by support incidents. Subproject workflow rules enable project administrators to define rules for managing the incidents and events that are managed in each subproject and for determining which project members and employees are applicable to a subproject and its incidents and events.

 

 

Subprojects enable support organizations to better organize and manage the support incidents in a ServiceWise project.

 

Administrator-defined subproject settings define how project members may manage subprojects in a ServiceWise project.

 

• subproject status

• subproject workflow states

• subproject access controls

 

All subproject configurations and access controls are a project-by-project basis. Subproject settings defined in one project do not affect configuration made to other work projects in the same ServiceWise site.

 

Subproject administrative tasks include:

 

• Defining General Subproject Settings

• Administering Subproject Status Definitions

• Defining Subproject Priorities

• Defining Subproject Access Controls

 

 

Administrator-defined subproject configurations define how project members may use subprojects to manage incidents in ServiceWise work projects.

 

General subproject settings determine which tools are displayed in the Subproject manager of the ServiceWise clients.

 

Project administrators may enable subproject features and define subproject settings in the General Settings page of the Sub Projects folder.

 

General subproject setting administrative tasks include:

 

• Customizing Subproject Terminology

• Enabling Subprojects in Work Projects

• Enabling Employee Assignment to Subprojects

• Enabling Subproject Applicable Owner Controls

• Restricting Incident Ownership to Subproject Members

• Restricting Event Ownership to Subproject Members

• Enabling Subproject Workflow Controls

• Enabling Subproject Cost Budgets Controls

 

By default, ServiceWise subprojects are referred to assubprojectsin all ServiceWise work projects.Support organizations that prefer to use another term may customize the ServiceWise clients to display any name that is more appropriate to their business.

 

To rename subprojects throughout the ServiceWise project, enter a name in the Refer Subproject As edit box control in the General Settings page of the Subproject folder in a ServiceWise work project.

 

 

Subprojects are an optional ServiceWise feature that must be enabled by a project administrator in each ServiceWise work project.

 

To enable support for subprojects in a ServiceWise work project, select an option from the Subproject dropdown list in the General Settings page of the Subproject folder in a ServiceWise work project.

 

The Subproject dropdown list displays three options:

 

Not Enabled:If the Not Enabled option is selected, subprojects are not enabled in the work project and the subproject tree control is not displayed in the Incident view.

 

Enabled and Support One Level of Subproject:If the Enabled and Support One Level of Subproject is selected, subprojects are supported in the work project and project members may create a subproject hierarchy consisting of a single level.

 

Enabled and Support Two Levels of Subproject:If the Enabled and Support Two Levels of Subproject is selected, subprojects are supported in the work project and project members may create a subproject hierarchy consisting of two levels.

Email integration enables ServiceWise support teams to better manage project incidents, events, and employees by automating and tracking communication conducted by email.

Using controls in the Advanced Settings folder, project administrators may enable and define email-based tools that enable project members to work together more effectively.

ServiceWise email integration is a prerequisite for the following features:

Email event trackingenables support teams to track every email sent to and received from employees through the ServiceWise client asevents. All email events are based on administrator-defined email received or email sent event templates.

• Project support formultiple incoming email addressesenable support teams to better manage and distribute email requests from employees. Each project may support multiple team email accounts, personal email addresses, and personal email aliases. The “reply to” address in project email may be based on the team email account assigned to the support engineer sending the email or the team email account assigned to the employee that received the email.

Email autoreplyenables support teams to define rules for automatically sending predefined email to employees whenever an email is received from that employee.

Incident autosubmissionenables project members and employees to submit incidents to ServiceWise projects by email. ServiceWise automatically creates new incidents based on the content of the subject line and body of the email.

Incident notificationenables project members to be automatically notified whenever an administrator-defined incident notification rule is triggered. Project administrators may define all appropriate triggers, conditions, and recipients in the Email Notification page of the Advanced Settings folder.

System-level email integration administrative tasks must be completed before project administrators may configure and define project email integration settings.

System administrators are responsible for installing the ServiceWise Email Server service, the ServiceWise Email Retrieval service, and configuring the ServiceWise environment to operate properly. System administrators are also responsible for defining email error handling rules.

System administrators must install the ServiceWise Email Server and start the email notification service to enable project administrators to implement incident notification in ServiceWise projects.

System administrators may install the ServiceWise Email Server on any Windows server machine. Once installed, the ServiceWise Mail Server service is shown running in the Windows services.

The ServiceWise Mail Server is implemented using the SMTP standard and runs as a Windows NT service.

• ServiceWise Database Server and ServiceWise Application Server must be installed before ServiceWise Email Server can execute properly.

• The ServiceWise Email Server may be installed on an existing mail server as long as it is MAPI and SMTP compliant.

When the ServiceWise Email Server is initially installed, it talks to the ServiceWise Application Server to get the database username and password for accessing the ServiceWise Database Server.

The ServiceWise Email Server communicates with the ServiceWise Database Server and sends email messages through a POP3 or SMTP mail server:

• The ServiceWise Email Server then talks to the ServiceWise Database Server and queries the ServiceWise database for email messages that must be sent.

• When the ServiceWise Email Server finds email messages to be sent, it talks to a POP3/SMTP mail server and send out the emails through that mail server.

• After it has sent the email messages, the ServiceWise Mail Server resets flags in ServiceWise Database.

• The ServiceWise Email service continues to query the ServiceWise database for new email messages that need to be delivered.

Email event tracking enables support teams to track every email sent to and received from employees through the ServiceWise client as events. All email events are based on administrator-defined email received or email sent event templates.

Anevent templateis a set of administrator-defined workflow rules, default event properties, project member access rules, employee access rules, file attachment rules, and email notification and escalation rules.

Email event templates may be based on one of two email event types: the email received event type and email send event type. In ServiceWise an event type represents a task and are managed by a set system-defined business rules.

• Email received event templates combine administrator-defined workflow rules with system-defined business rules for managing email received events.

• Email sent event templates combine administrator-defined workflow rules with system-defined business rules for managing email sent events.

In ServiceWise, email events —instances of email event templates—are automatically created in a work project whenever an email is received by or send from a team email account.

Project administrators may create multiple email received event templates and multiple email sent event templates. Every team email account may be assigned a unique set of email event templates, with unique owners, due dates, and workflow. The email templates assigned to that team email account are used to automatically create email events whenever an incoming email is received or sent from the team email account.

• An email received event based on an email received event template is created automatically whenever an employee sends an email to the support team.

• An email sent event based on an email sent event template is automatically created whenever a ServiceWise project member sends an email to an employee.

Incoming email settings determine how email sent to project team email accounts are handled by the ServiceWise system. Incoming email are email messages sent to the team email accounts defined in a ServiceWise project.

Team email accountsbundle a POP3 or MAPI email account (an incoming email server, email address, user name, and password) with administrator-defined default email event templates. Email messages sent to or from a team email account automatically create a email events based on the corresponding email received or email sent event template.

Project administrators may enable and define one or more incoming email servers, enable the retrieval of incoming email from the email server, define one or more team email accounts, and define the default event templates for email received and email sent in the ServiceWise client using controls in the Incoming Mail tab of the Email Integration page in the Advanced Settings folder.

The incoming email configurations and rules that may be defined in a project, and the data-entry controls displayed in the Incoming Mail page of the Email Integration page depend on whether the project is using standard email integration or advanced email integration.

• If advanced email integration is enabled, project administrators may define multiple incoming email servers and multiple team email accounts. Unique email received event templates and email sent event templates may be defined for each team email account.

• If advanced email integration is not enabled, project administrators may defineoneincoming mail server andoneteam email account. All incoming email generate events based on the same email received event template or email sent event template.

Incoming email server settings include:

• Enabling Email Autoretrieval in ServiceWise Projects

• Enabling Multiple Team Email Accounts

• Defining Team Email Accounts

• Defining POP3 Email Server Settings

• Defining the Reply-to Address of Outgoing Email

• Defining Reply To Email Addresses based on Employee Types

ServiceWise projects use the TechExcel ServiceWise Mail Retrieval Server, an NT service, to retrieve email from an email server using the POP3 or MAPI protocol.

To enable and execute email autoretrieval in a ServiceWise project, two administrative tasks must be completed:

• The TechExcel Mail Retrieval Server must be installed on a server machine and the email service must be started.

• The Support Email Autoretrieval check box must be selected in the Incoming Mail tab of the Email Integration page.

Once started and enabled, the TechExcel Mail Retrieval Server communicates with a designated incoming email server and establishes an authorized connection with that server using the user name and password defined in a team email account. The Mail Retrieval Server then retrieves email addressed to that account.

Project administrators may create multiple team email accounts and each of those team email accounts may connect to a different email server using a unique POP3 or MAPI email account.

To enable email autoretrieval in the current project, select the Support Email Autoretrieval check box in the Incoming Mail tab of the Email Notification page in the Advanced Settings folder.

Note:The Support Email Autoretrieval check box is grayed out if advanced email integration is not enabled in the project. For more information see See “Managing Optional Project Features” on page 106.

ServiceWise advanced email integration enables projects to support multiple incoming email servers and team email accounts.

Project administrators may define multiple team email accounts in each ServiceWise project, and each team email account may connect to a different incoming email server using its own user name and password.

Support teams may wish to use different team email accounts to manage email messages regarding the various products, services, or locations that are managed by ServiceWise support engineers.

• Each team email account has a uniqueemail address, and the email address assigned to a team email account may indicate the product, service, or location served by that email account.

• Each support project member is assignedoneteam email account in each ServiceWise project. Multiple team email accounts enable support teams to divide workload across team members based on their expertise, job role, or location.

• Each team email account represents two administrator-defined event templates: an email received event template and an email sent event template. Email messages sent to or from a team email account automatically create email events based on the corresponding email received or email sent event template.

To enable multiple team addresses in the current project, select the Support Multiple Team Addresses check box in the Incoming Mail tab of the Email Notification page in the Advanced Settings folder.

Note:The Support Multiple Team Email Addresses check box is grayed out if advanced email integration is not enabled in the project. For more information see See “Managing Optional Project Features”.

Once a project administrator has enabled support for multiple team email accounts, he or she may defined multiple team accounts in the Edit Email Property manager of the Incoming Mail tab of the Email Integration tab.

 

TechExcel ServiceWise tracks day-to-day business activity as events. Events represent the “to do” items that project members must perform in the course of processing incidents.

 

Typical events include calling or receiving a call from an employee, employee requests for equipment, an online meeting or visit to a site, receiving or sending email, or approval from management.

 

 

As incidents progress through the incident life cycle, changing workflow states and owners, events may be attached to those incidents to support multi-tasking, track day-to-day activities, and enhance incident workflow.

 

Support incidents may be open days, weeks, or even months, and events provide a way of tracking the daily tasks and actions taken to help resolve incidents. A single incident may require one or more events to be recorded as part of the support effort or as part of communicating with an employee— events may represent simple tasks, randomly occurring events, or employee inputs.

 

Events may be general events or incident-specific events.

 

• General events are not linked to support incidents.

 

• Incident-specific events are associated with one-and-only-one incident at all times in project workflow.

 

 

All events are based on administrator-defined event templates. Aevent templateis a set of rules for managing events in project workflow. The life cycle of a development event and the rules that determine how that event is managed in workflow are defined by the event template that was used to create it.

 

Event administration, therefore, is the largely a matter of creating event templates, defining the rules that manage events based on that template, and determining when events based on that event template may be created in the project.

 

 

Anevent typerepresents the many different types of tasks that project members must perform in the course of managing incidents.

 

Making phone calls, sending and receiving email, and adding documents to the knowledge base all represent very different processes and are managed by distinct business rules in ServiceWise projects. Each event type represents business logic that determines which tools and processes are used to manage events of that type.

 

The event type defines the business rules that are built into that event template. All event templates belong to one of two classes of event types: definable event types or system event types.

 

A definable event type represents a system-defined set of business rules that determine how events of a particular type are managed in a project. Project administrators may create multiple event templates for each event type and define customized workflow rules for each event template. ServiceWise features nine definable event types.

 

Each definable event type is designed to manage a particular type of event and consists of business rules tailored to that event type. Definable event types may be used to create event templates in a work project.

 

Project administrators may create multiple event templates for each of the nine definable event types:

 

asset operation event type:The asset operation event type defines a set of asset management business rules.

 

co-owner event type:The co-owner event type defines a set of business rules for managing co-owner events.

 

email announcement event type:The email announcement event type defines a set of business rules for managing email blasts.

 

email received event type:The email received event type defines a set of business rules for managing email sent from an employee to a team email account.

 

email sent event type:The email received event type defines a set of business rules for managing email sent from a team email account to an employee.

 

knowledge management event type:The knowledge management event type defines a set of asset management business rules.

 

power user event type:The power user event type defines a set of business rules for managing power users.

 

Quick Letter event type:The quick letter event type defines a set of Quick Letter management business rules.

 

regular event type:The regular event type defines a set of business rules for managing regular events such as calling employees, receiving calls from employees, requests for equipment, attending meetings, conducting online meetings, and so on.

 

 

A system event type represents a set of business rules that determine how events of a particular type are managed in a project. Project administratorsmay notcreate event templates based on system event types. ServiceWise features five system event types.

 

• The Download event template

• The Incident File event template

• The Interproject Copied event template

• The Newly Registered User event template

• The Request for Password event template

Project administrators may rename the events in the project and to enable the Calendar view in the ServiceWise clients in the General Settings page of the Event Management folder.

 

General event settings include:

 

• Renaming Events in ServiceWise Projects

• Enabling the Calendar View

 

 

Project administrators may define a custom term for the Event business object in the General Settings page of the Event Management folder

 

By default, the termeventis used to refer to a task or subincident that makes up an incident in ServiceWise projects. The termeventis displayed throughout the ServiceWise Admin client and the ServiceWise clients. Project administrators may substitute another term that better describes their workflow processes.

 

To customize the name given to events, enter a custom name in the Refer Event As control in the General Settings page of the Event Management folder of the ServiceWise Admin client.

 

 

The Calendar view in the ServiceWise client enables project members to plan, view, and create new events in monthly, weekly, and daily calendars.

 

                                

 

                                                             Figure 12-1: Calendar View in the ServiceWise Web Client

 

Using controls in the Search bar, project members may filter the events displayed in the calendars based on employee, owner, event template, event type, and due date.

 

To display the Event Calendar view in the ServiceWise client applications, select the Enable Event Calendar View check box in the General Settings page of the Event Management folder of the ServiceWise Admin client.

  

A system event type is a predefined event. Project administrators may create event templates based on system event types.

 

System events may be used to track employee actions in a ServiceWise project such as employee self-registration or downloads from the site. System event types include:

 

• The Download event template

• The Incident File event template

• The Interproject Copied event template

• The Newly Registered User event template

• The Request for Password event template

Everyeventcreated in a ServiceWise project is aninstanceof an event template and inherits administrator-defined settings from that template and system-defined business rules from its event type. Events are managed by two sets of rules in ServiceWise projects: administrator-defined workflow rules and system-defined business rules.

 

 Administrator-defined workflow rules determine how events may be managed byproject membersin a ServiceWise project.

 

 System-defined business rules determine how events are processed by theServiceWise application. Each event type represents business logic that determines which tools and processes are used to manage events of that type.

 

Anevent templateis a set of administrator-defined workflow rules, default event properties, project member access rules, employee access rules, file attachment rules, and email notification and escalation rules.

 

Every event template is based on one of nine definableevent types.Anevent typerepresents a set of system-defined business rules

 

Project members are responsible for creating event templates based on system-defined event types, defining event template workflow rules, and making event templates available to project members in the ServiceWise client applications.

 

Project administrators may create and define event templates based on nine different event types: Asset Operation Event event type, Co-owner Event event type, Email Announcement Event event type, Email Received Event event type, Email Sent event type, Power User event type, QuickLetter Event event type, and the Regular Event event type.

 

Creating event templates based on different event types requires that the administrator configure many different data-entry controls in the Event Templates page of the Event Management folder. Many of the data-entry controls or configuration settings areuniqueto some of the event types.

 

However, may event template configuration tasks are universal to all event template regardless of the event type. To properly define an event template, a project administrator must perform seven basic tasks:

 

• Create the event template and select an event type.

• Define event properties.

• Define event submission rules

• Define event editing rules

• Define event deletion rules

• Define event attachment rules

 

Each of these tasks are described in general in this section. Detailed instructions for defining event template settings that are specific to event templates based on a particular event type should look to the relevant sections.

Event template management tasks include:

 

• Creating Event Templates

• Deleting Event Templates

 

 

Anevent templateis a set of administrator-defined workflow rules, default event properties, project member access rules, employee access rules, file attachment rules, and email notification and escalation rules.

 

Project administrators may create any number of event templates for each of the nine definable event types:

 

• asset operation event type

• autodiscovery asset event type

• co-owner event type

• email announcement event type

• email received event type

• email sent event type

• knowledge management event type

• power user event type

• Quick Letter event type

• regular event type

 

Project administrators may create event templates and define unique workflow rules for each event template in the Event Templates page of the Event Management folder.

 

 

To create an event template:

 

13Click the New button in the Event Templates page of the Event Management folder.

 

The Add a New Event Template dialog box appears.

 

14Define a unique descriptive name for the event template in the Name text edit box control.

 

The Name property identifies the unique name of the event template. The event template name is the default name for all user-defined events that are based on the selected event template.

 

15Enter a brief description of the event template in the Description text edit box control.

 

The Description property provides a brief description of the workflow rules represented by the event template. The event template description is the default description for user-defined events that are based on the selected event template.

 

16Select an event type option the Event Type dropdown list control.

 

The Event Type dropdown list displays nine event type options:

 

• asset operation event type

• autodiscovery asset event type

• co-owner event type

• email announcement event type

• email received event type

• email sent event type

• knowledge management event type

• power user event type

• Quick Letter event type

• regular event type

 

The Event Type property defines the event type represented by the event template. The event template may be used to create events belonging to the selected event type.

 

17Click the OK button.

 

The event template is displayed in the Event Templates list. Project administrators may define event workflow rules for the event template.

 

18Define event workflow states.

 

For step-by-step instructions see See “Creating Event Workflow States”.

 

19Define applicable event owner rules.

 

For step-by-step instructions see See “Creating Event Workflow States”.

 

20Define event start dates and due dates.

 

For step-by-step instructions see See “Creating Event Workflow States”.

 

21Enable or disable employee access.

 

For step-by-step instructions see See “Creating Event Workflow States”.

 

22Define the event scope.

 

For step-by-step instructions see See “Defining Start Dates and Due Dates”.

 

23Define template identifier.

 

For step-by-step instructions see See “Defining Event Template Identifiers”.

 

 

To delete an event template, select the event template in the Event Template list control and click the Delete button.

 

All general event template properties may be defined in the Property tab of the Event Templates page of the Events folder.

General event template administrative tasks include:

 

• Defining Start Dates and Due Dates

• Defining the Event Template Scope

• Defining the Prefix and Help Notes

• Defining Event Number Restrictions

• Defining Event Template Identifiers

 

TechExcel ServiceWise provides businesses with powerful internal service and support solutions that enable them to effectively manage and automate their service desk processes.

As aninternalservice and support solution, ServiceWise is designed to enable company support engineers—ServiceWise project members— to manage support requests from company employees, associates, and partners.

Employee accounts represent the company employees for whom ServiceWise support engineers create, manage, and track incidents and events in a ServiceWise project. Employee accounts may be identified by their employee type, job function, site, division, department, and group.

All employees may be tracked and managed by project members in the Employee view of the ServiceWise clients. TechExcel ServiceWise enables project administrators to define businesses objects, processes, and workflow rules that enable ServiceWise work project members to manage employees effectively.

TechExcel enables businesses to manage employees through every step of the employee life cycle.

• TechExcel ServiceWise automates all employee-related processes and enables project members to view the complete history of employee interactions.

• TechExcel ServiceWise business and workflow rules ensure that employees are effectively managed and seamlessly transition between ServiceWise project members.

• TechExcel ServiceWise provides businesses with tools for analyzing employee needs and behavior.

• TechExcel ServiceWise enables project members to effectively communicate and collaborate with employees by phone, email, and web conversations.

All ServiceWise work projects share a commonbase projectthat enables project teams to share a common database of employees. Configurations and customizations made in a ServiceWise base project are passed on to every work project in the ServiceWise site. All employee and employee data is stored in a employee base projects and tracked in the child work projects through the Employee view.

ServiceWise employee administration falls into four broad categories:

• Employee view customization

• Employee support automation administration

• Employee Web Portal administration

• Web form administration

Employee view administrative tasks are performed using tools in the Employee View folder of the ServiceWise Admin client.

Employee view administrative tasks include:

• Defining employee properties and customizing the Employee view to support employee management processes.

• Enabling project members to define employees.

• Defining the domain of common email addresses and define default settings for email from that domain

• Defining employee types and employee type access controls.

• Managing power users.

• Defining the company hierarchy.

• Defining employee autoassignment rules.

• Defining Quick Web Links in the Employee view.

In ServiceWise, the Employee view provides project members with the tools they need to create, manage, and track employees in the ServiceWise Windows client and ServiceWise Web clients.

Figure 13-1: Employee View in the ServiceWise Windows Client

The Employee view consists of two windows: the Employee list window and the Employee Detail window.

The Employee list window displays high-level information about multiple employees in a tabular format.

The Employee detail window displays detailed information about a single employee in multiple tabbed pages: the Employee page, the Team page, the Incidents and Events, and up to two custom pages.

Employee view administration, configuration, and workflow settings are defined at the base-project level. In ServiceWise, all employee data is stored in a base project and tracked in child work projects through the Employee view. The same Employee view is displayed in every ServiceWise project that shares the same base project.

Project administrators may define employee management options, define project member access controls, and customize the graphical user interface of the Employee view to support and manage the employee data in the Employee View folder in the Admin tree window of base and work projects.

Employee view administration tasks include:

Defining Employee View Terminology

Defining Employee Dropdown List Size Limits

Enabling Support for Login Aliases

Customizing the Employee View Employee Page

Customizing the Employee View Team Page

Customizing the Employee View Incidents/Events Page

Customizing Employee View Custom Pages

The Employee view enables project members to create, manage, and trackemployeesin the ServiceWise Windows and ServiceWise Web clients. Project administrators may define employees and customize the graphical user interface that is used to track those employees in the ServiceWise implementation.

By default, the termemployeeis used to refer to company employees in ServiceWise projects, but a business may use any term that appropriate to their industry or business model. For example, a business may wish to refer to employees as anassociates, orpartners, or by another name that is better suited to their business or more intuitive for their support engineers.

To define a custom term for project employees, enter the term in the Refer Employee As field of the General Settings page. Once the new term is defined the wordemployeeis replaced by that term globally throughout the ServiceWise site.

The TechExcel Employee Web Portal is a secure, interactive Web site providing controlled access to a centralized communication hub and to support processes.

• The Employee Web Portal enables employees to submit and edit incidents through the Internet.

• The Employee Web Portal enables employees to view their incidents and events.

• The Employee Web Portal enables employees to access FAQs, upgrades and patch info, product documentation.

• The Employee Web Portal enables employees to search the knowledge base, download documents or software, and read whatever news or announcements administrators have determined they should see based on their role.

• The Employee Web Portal enables employees to conduct Web conversations with ServiceWise project members.

Figure 14-1: Incident List Report in the Employee Web Portal

The Employee Web Portal is composed of six views. Each Employee Web Portal view displays tools that enable employees to manage incidents, view reports, interact with ServiceWise personnel, or customize their personal information or preferences.

• The Home view

• The Incident List view

• The Submit New view

• The Employee Info view

• The Knowledge view

• The Report view

Whenever problems do arise, employees may easily search the knowledge base for information that is specific to their particular incident saving time and reducing overall support costs. The Employee Web Portal enables employees to access helpful hints, upgrades, patch info or any other information an administrator believes is relevant based on their employee type or products purchased.

The Employee Web Portal is an optional feature in TechExcel ServiceWise. Support for the Employee Web Portal must be enabled independently in each ServiceWise work project. For more information see See “Enabling the Employee Web Portal” on page 285.

Project administrators may customize the Employee Web Portal using controls in the Employee Web Portal folder of the ServiceWise Admin client.

Project administrators may configure and customize the Employee Web Portal using tools in the Employee Web Portal folder of the ServiceWise Admin client. Employee Web Portal administrative tasks include:

• Defining General Employee Web Portal Settings

• Managing Registration Controls

• Managing Web Themes

• Managing Employee Web Portal Field Access Controls

• Managing Page Style Customization

• Administering Employee Web Portal Login Controls

• Customizing the Knowledge Portal

• Managing Employee Web Portal Reports

• Defining Single Sign-on Access

Project administrators may restrict access to projects through the Employee Web Portal based on administrator-defined employee and contact accounts.

Project administrators may configure the Employee Web Portal so that only appropriate incidents and incident data are displayed to employees based on their employee type, employee status, and business type,. or the access privileges granted to a employee contact.

All employee and employee contact privileges are assigned by project members in the Employee view of ServiceWise projects. Project administrators may define employee types and contact types, assign access privileges to those employee types and contact types, and perform other administrative tasks using tools in the Employee Web Portal folder.

Project administrators may completely customize the Employee Web Portal so that its appearance is consistent with their corporate Web site. Company logos, images, background colors, foreground images, and fonts are all fully customizable.

Project administrators may enable and configure the Employee Web Portal for each ServiceWise work project.

• Employee access to a support project using the Employee Web Portal is the most typical implementation.

• Employees must pass the associated runtime key for that project in the URL to access each work project.

The Employee view in the ServiceWise clients enables project members to create, manage, and track employees.

Employee and contact information is stored in a employee base project.The employee base project enables project teams to share a common database of employees. Each ServiceWise project may be associated with one employee base project. The employee base project is shared by multiple ServiceWise work projects.

All ServiceWise work projects share a commonemployee base project. A employee base project enables project teams to share a common database of employees. All employee and employee contact data is stored in a employee base projects and tracked in the child work projects through the Employee view.

Project administrators may enable the Employee Web Portal, define default work projects, visible projects, and other basic settings in the General Setting page of the Employee Web Portal page.

Figure 14-2: General Setting Pages

General Employee Web Portal definitions include:

• Enabling the Employee Web Portal

• Reloading Web Settings

• Defining Default Work Projects

• Defining the Title of the Employee Web Portal

• Defining Runtime Keys

• Enabling Incident List Reports

• Customizing the Employee Web Portal Logos

• Displaying Multiple Projects to Employees

Project administrators may enable web clicks, web points, employee profiling, and form management in the General Settings page of the Web Activity and FormWise folder in the ServiceWise Admin client.

Web clicksenable project teams to record Employee Web Portal activity so that they may track employee interest in products and services.

Web pointsenable project teams to assign points to pages, links, or the answers given to form questions to gauge employee interest.

FormWise formsenable project teams to gather employee data with user-defined form questions and form templates.

Employee profile questionsenable project teams to link form questions to employee data that is managed in ServiceWise projects.

All FormWise settings are defined on aproject-by-projectbasis. Support for Web Activity tracking, forms, web points and other FormWise features may be enabled in one project and disabled in or projects within the same TechExcel ServiceWise implementation.

Note:FormWise is an optional feature in ServiceWise projects and project administrators must enable support for FormWise within their project using controls in the Optional Features page of the General Project Settings folder in the ServiceWise Admin client.

Once project administrators have enabled support for FormWise features within their projects, they may enable and define individual FormWise features in the General Settings page of the Web Activity and FormWise folder.

Targeted email announcements may be sent to employees based the answers given to form questions. Project administrators may pre-schedule these email announcements.

FormWise administrative tasks include:

• Enabling Web Activity Management (Web Clicks)

• Enabling FormWise for Standard Forms

• Enabling Employee Profile Questions

• Defining the FormWise URL

• Administering Web Points

• Defining Web Points Access Controls

Web clicks enable project teams to record Employee Web Portal activity so that they may track employee interest in products and services. Each page viewed by a employee may earn that employee a set number ofweb pointsbased on the link clicked.

To enable project teams to track employee web activity usingweb clicks, select the Enable Web Activity Management check box in the General Settings page of the Web Activity and FormWise folder.

To enable project teams to create and manage standard FormWise forms, select the Enable FormWise for Standard Forms check box in the General Settings page of the Web Activity and FormWise folder.

Project administrators must enable support for standard forms in their project for ServiceWise project members to publish forms.

 

The ServiceWise Web Server is an add-on component that enables project members to access work projects over the Internet using web browsers.

 

The ServiceWise Web Server needs to be installed if users must access ServiceWise through the Web. TechExcel recommends installing the ServiceWise Admin module on the ServiceWise Web Server computer so that changes made to the ServiceWise Web Server can be quickly modified in ServiceWise Admin.

 

System administrators may use tools in welcome message Admin to manage general welcome message Web settings and welcome message Web image settings for an entire welcome message implementation.

 

All system-level ServiceWise Web settings are defined at the System Settings project in the ServiceWise Admin client.

 

• The ServiceWise Web Server configuration dialog box enables system administrators to define and update the connections between the ServiceWise Web Server and the ServiceWise Application Server and the ServiceWise Database Server.

 

• The Web Support manager enables administrators to define the server path for the ServiceWise Web Server, the system runtime key, Issue List and reporting refresh options, and the welcome messages displayed in ServiceWise Web and the Employee Web Portal.

 

• The Web Image and Multimedia Attachment Settings dialog box enables administrators to enable project members to add images, movies, and sound to issues as attachments and to define the maximum size for these files.

 

• The Web Authentication dialog box enables administrators to define the method the ServiceWise system uses to authenticate project members logging into ServiceWise Web. ServiceWise supports three methods: ServiceWise login and password, Windows NT authentication, third-party authentication.

 

• Interproject switching enables ServiceWise Web client users to switch quickly between a ServiceWise project and other TechExcel projects (TechExcel DevTrack, TechExcel CustomerWise).

 

System administrators may use controls in the Web Server Access to Document Server area of the Document Server page to define how the TechExcel ServiceWise Web publishing service communicate with the ServiceWise Document server.

 

The Web file publishing service gets a copy of the requested document from the ServiceWise Document Server whenever a project members requests a document through the ServiceWise Web Server. The document is then published to the Web file folder for downloading.

 

Administrators may enable and define one of three access options:

 

• The Direct Access through a Local Path on the Web Server enables the administrator to directly link the ServiceWise Web Server and ServiceWise Document Server. This option is available if the ServiceWise Document Server is installed on the same computer as the ServiceWise Web Server. The folder containing the ServiceWise Document Server must be shared, so it is possible that files could be accessed from the network path if the folder settings are not correctly configured. Only administrators that know how to define folder permissions that meet company security standards should use this access method. TechExcel does not recommend the Direct Access option.

 

• The Direct access through a Network Path enables the administrator to link the ServiceWise Web Server and ServiceWise Document Server on the network. Only administrators that know how to define folder permissions that meet their company security standards should use this access method. The folder containing the ServiceWise Document Server must be shared, so it is possible that files could be accessed from the network path if the folder settings are not correctly configured.TechExcel does not recommend the Direct Access option.

 

• The TCP/IP access to the Document Server option is the configuration recommended by TechExcel. This method uses TCP/IP protocol to access the folder that contains the documents and is the most secure approach.

 

 

Administrators may choose between two options for defining TechExcel ServiceWise Windows client access to the ServiceWise Document Server.

 

• TCP/IP access to the document server – this is the suggested choice for allowing the client applications to access the documents in the document server. This method uses TCP/IP protocol to access the folder that contains the documents and is the most secure approach.

 

• Direct access through the following network path – this method is not recommended, but is an option for advanced users that know how to set the folder permissions to meet their company security standards. The document server folder will need to be shared, so it is possible that files could be accessed from the network path if the folder settings are not correctly configured.

 

System administrators may define general ServiceWise Web Server settings in the Web Server Setting page in the System Setting project. The Web Server Setting page enables administrators to define system runtime keys, enable database connection pooling, and define default settings for projects displayed in the ServiceWise Web client.

 

ServiceWise Web Server settings may be defined in the System Settings project only. System-level ServiceWise Web Setting apply to every project in a ServiceWise site.

 

Administrators may enable and define three ServiceWise System Web Settings in the General Settings page:

 

• Defining the System Runtime Key

• Enabling Database Connection Pooling

• Defining the Number of Records in ServiceWise Web

• Defining ServiceWise Web Login Titles

 

 

 

Administrations may use the Web Support page to define a system runtime key for a ServiceWise project.

 

When the administrator has defined both the project runtime key and the system runtime key, project members may access ServiceWise through two different URLs, each with the appropriate level of access.

 

System runtime keys may either be used in conjunction with a project runtime key or on their own to add an additional level of security to a project.

 

• Companies that maintain several ServiceWise projects and who wish to restrict access to certain projects may use a system login key in combination with the project runtime key.

• The system runtime key may also be used without project runtime keys. In this situation only team members that know the system runtime key will have access to ServiceWise projects.

 

With runtime keys adding another level of access control, the following configurations are possible for a company:

 

Option 1

 

Enable users to access all ServiceWise projects if the correct system runtime key is specified. The format for including the system runtime key is as follows:

 

http://[WebServerName]/scripts/texcel/servicewise/ clogin.dll?runtimekey=systemkey

 

Option 2

 

Enable users to access the login page for a project that has no runtime key (by leaving the project runtime key blank). The format for accessing a project with no runtime key is as follows:

 

http://[WebServerName]/scripts/texcel/servicewise/ clogin.dll?projectid=#

 

Enable users to access the login page for a project that has a runtime key by passing both the project ID and runtime key in the URL.

 

The project ID or a project can be found by selecting File > Open Project in ServiceWise Admin. The project ID is displayed next to each project.

 

 

Note:The system runtime key does not replace the Web login process; it is an additional level of access control. After passing the appropriate runtime key, user authentication is still required toaccess a project.

 

 

 

 

Database connection pooling may improve the performance of TechExcel ServiceWise Web based on the current database system. This function works for all supported databases.

 

With database connection pooling enabled, the ServiceWise Web Server can maintain up to 80 connections.

 

TechExcel ServiceWise and AssetWise each use an administrator-defined Asset Inventory to represent company product and asset structures. The structures defined by administrator determine which products and assets may be managed in a project, how they are managed, and by whom they are managed.

In TechExcel ServiceWise the Asset Inventory defines company assets for help desk management purposes.

Every asset is based on an administrator-defend asset template.Project administrators may configure the Asset Inventory in both ServiceWise projects:

The Asset Inventory enables project members to define, view, and update asset properties in the client application. Every asset is represented by a set of unique properties that distinguish that item from the other assets tracked in the project.

Project administrators may define how products and assets are represented in projects by customizing the data-entry controls that project members use to define assets in TechExcel ServiceWise and AssetWise projects. The Asset Inventory may display four system pages and up to ten custom pages.

Project administrators may customize each of these pages by adding, removing, or customizing system-defined and custom controls.

• TheDescription tabenables administrators to customize the data-entry controls displayed in the Description page and choose whether an asset template may be used to track individual asset items or the quantity and usage of assets.

• TheValue tabdisplays a set of edit box controls that may be used to define system-level properties. Value page data-entry controls are only customizable at the system level.

• TheSupport Plan pageenables administrators to define the support plan and contract options and to customize the data-entry controls displayed in the Support Plan page.

• Thecustom pagesenables administrators to create custom data-entry controls to track administrator-defined asset properties. Project administrators may add up to ten custom pages to the client applications.

Project administrators may add, remove, or customize system-defined and custom controls to the Asset Inventory at three different levels: the system level, the category level, and the template level.

Asset Inventory definitions are inherited from top to bottom. System-level properties are inherited by all categories. Category-level definitions are inherited by child templates. Template-level customizations are not visible in the parent category.

System-level asset propertiesare shared by every asset in a project. Adding or customizing a control at the system-level ensure that every asset is defined by that property. System-level properties are inherited by asset category andcannotbe overridden by category-level definitions or template-level definitions. System-level properties are generally rare.

Category-level asset propertiesrepresent properties that are shared by by many but not all assets.Category-level customizations enable administrators to define broad categories of assets that are identified by a unique set of properties. Asset categories might include applications, servers, or laptops. Custom controls defined at the category level are inherited by every asset template that belongs to that category.

Template-level asset propertiesrepresent properties that are specific to a single asset. Template-level customizations enable administrators to define the asset templates that represent specific assets or products in AssetWise and TechExcel ServiceWise. Project members use asset templates to create new assets in their projects. Custom controls defined at the template level are specific to a single asset template and are not displayed in any other asset template in the project. Customizing the data-entry controls that project members use to define assets requires careful planning and testing. Project administrators may make customizations to the Asset Inventory at each level. But not every customization can be made at every level:

Customizing the data-entry controls that project members use to define assets requires careful planning and testing. Project administrators may make customizations to the Asset Inventory at each level. But not every customization can be made at every level:

Table 17-1: Asset Description Page Customizations

System-level asset properties are shared by every asset managed in a project. Project administrators may add or customize system or custom controls at the system level. Controls customized at the system level cannot by customized at the category or template level. System-level properties are inherited by every category of asset andcannotbe overridden by category-level definitions or template-level definitions. Generally, the number of asset properties that are defined at the system level is extremely rare. System-level customizations are generally limited to the following:

• Adding or removing one or more system-defined dropdown list controls in the Description page.

• Editing the field label for controls in the Description page.

• Customizing Value page data-entry controls. These controls cannot be defined at the category level or the template level.

Category-level asset properties enable administrators to define multiple categories of assets that are identified by a unique set of properties.

Project administrators may define asset categories by customizing data-entry controls at the category level. Every asset that belongs to that asset category displays the data-entry controls and control customizations made to the Asset Inventory for that category of asset.

Asset categories represent groups of assets that share many properties in common. Examples of asset categories might include applications, servers, laptops, or desks.

Figure 17-1: Asset Categories and Asset Templates

Every asset in the Asset Inventory is represented by an asset template. Every asset template is the child of a parent asset category and inherits data-entry controls from the parent category. Project administrators may define appropriate properties at the category level and these controls are manifested by every asset that belongs to that category.

The laptop asset category represents three asset templates: the Toshiba, ThinkPad, and Dell asset templates. Data-entry controls defined by the administrator at the category level are inherited by every template belonging to that category.

Template-level asset propertiesrepresent the properties of the actual assets managed in the Asset Inventory. Every asset is represented by an administrator-defined asset template.

Asset templates define the general properties of the assets managed in projects. Every user-defined asset created and managed in a ServiceWise or AssetWise project is based on an administrator-defined asset template.

Asset templates inherit customizations made to the Asset Inventory at the parent category level. Project administrators must define asset categories before they can define the child asset templates.

Customizations made to the Asset Inventory at the template level are unique to each asset template. Template level customizations are not visible in the parent asset category.

Project members can also define some fields properties to be at the template-level and overwrite the fields category-level definition. Define the default values for as many fields as possible at the template-level.

Subassets represent the component parts that make up a particular asset. Every subasset is defined by three properties: the subasset relationship, the maximum quantity, and the auto-added quantity.

Subassets may be defined at thetemplate level only. The Sub Asset tab is only displayed in the Template Level Properties page.

Project administrators may create, edit, or delete subassets for each asset template in the Sub Asset tab of the Template Level Properties page.

Figure 17-2: Select Asset Dialog Box

Subassets are defined by three properties:

TheSubasset Relationship propertydetermines whether the subasset asset is created manually or automatically.

TheMaximum Quantity propertydetermines the maximum number of the selectedsubasset that may be associated with the parent asset.

TheAuto Added Quantity propertydetermines the number of the selected subassets that are automatically associated with the parent asset.

Note:Project administrators must enable subasset support in each standard asset operation. To enable subasset support, select the Asset Template control in the General Settings page in the Asset Management (AssetWise) folder.

To add subassets:

1Click the New button.

The Select Asset dialog box appears.

2Select an asset category in the Asset Category list.

3The Asset Template list displays all asset templates applicable to the selected asset category.

4Double-click the asset template in the Asset Template list.

The Edit Sub Asset dialog box appears. Define the subasset properties:

The Subasset Relationship property determines whether the subasset asset is created manually or automatically.

The Maximum Quantity property determines the maximum number of the selected subasset that may be associated with the parent asset.

The Auto Added Quantity property determines the number of the selected subassets that are automatically associated with the parent asset.

5Click the OK button.

The Edit Sub Asset dialog box closes.

6Click the Add button.

Asset template breakdownsenable organizations to track both assets and subcategories of assets in a single asset template.

Each asset template may be “broken down” into subgroups of the asset it represents. Project administrators may use the asset template to track both the quantity of the asset and the quantity of each subgroup of that asset.

Whereas subassets represent the component parts of an asset, asset breakdowns represent groupings of that asset. For example, a sporting goods store may sell twelve balls: four white balls, four blue balls, and four red balls. The ball is the asset. The colors white, blue, and red represent the asset breakdowns.

An asset breakdown of the asset template enables the sporting goods store to track both of the total number of balls sold (12) and the number of balls sold of each asset breakdown(4).

Note:Project administrators must enable asset breakdown for each standard asset operation. To enable the breakdown of asset templates, select the Enable Breakdown of Asset Template control in the General Settings page in the Asset Management (AssetWise) folder.

TechExcel ServiceWise features powerful document and knowledge management tools that enable project team members to build a knowledge base of data, manage that data in a central repository that is shared across multiple ServiceWise projects, and control employee and project member access to knowledge items based on administrator-defined privileges.

Knowledge management tasks may be performed in the Knowledge view of the ServiceWise clients and through the Employee Web Portal. ServiceWise enables project members and employees to add documents, topics, HTML links, announcements and attachments to the database and access knowledge items using keyword searches.

TechExcel KnowledgeWise provides businesses with a forum for managing and sharing information across projects that enables them to capitalize on their expertise. A centralized knowledge base of important company documents can increase efficiency, prevent lost or misplaced information, track document histories and reduce the system and maintenance costs.

• Internal teams and external employees can search the knowledge base for self-service content based on administrator-defined privileges.

• ServiceWise knowledge base content may be linked to other knowledge base management systems.

Project-level administrative tasks include:

• Grant knowledge management privileges to project members based on their account type.

• Defining the text editors that may be used to create and edit knowledge items.

• Configure email announcement settings.

• Enable and define dynamic FAQ settings.

• Customize the pages displayed in the Knowledge view of the ServiceWise clients.

• Enable and configure the ServiceWise Knowledge Portal.

• Enable and configure integration with third-party knowledge management solutions.

• Enabling and configuring the TechExcel Search Engine.

• Enabling knowledge item auto recommendations and defining knowledge base search result ranking rules.

Note:The TechExcel ServiceWise Document Server must be installed and the server settings defined for this feature to work correctly. For information on installing the document server please see the installation instructions.

Project teams may build knowledge base adding existing knowledge documents and Web pages, and by publishing knowledge items from resolved support incidents.

KnowledgeWise enhances employee support process by improving support response time, speeding training for new employees, and standardizing resolutions to common issues.

Project members may build knowledge by adding documents, topics, HTML links, announcements, and attachments to knowledge base from within the ServiceWise client applications.

Note:Project members may build knowledge using the ServiceWise Web client only if knowledge building through the Web is supported in the ServiceWise project. Knowledge management through the Web must be enabled separately in each work project.

Internal teams and external employees can search the knowledge base for self-service content based on administrator-defined privileges.

ServiceWise knowledge base content may be linked to other knowledge base management systems.

ServiceWise project members may use tools in the Knowledge view to manage knowledge items (documents, topics, HTML links, announcements, and attachments) in project knowledge base.

Project administrators are responsible for enabling and configuring knowledge management features and tools and for granting knowledge management privileges to project members based on their account type.

ServiceWise knowledge management tasks include:

Build and manage a knowledge base of knowledge items: Project members may add, modify, delete, categorize, and index the documents, topics, HTML links, and email announcements stored in the knowledge base. The ServiceWise Knowledge view enables development teams to manage all project-related knowledge items (documents, HTML links, announcements topics and attachments) including nternal design documents, system requirements, user specifications, and test cases in a central repository.

Manage multiple versions of project documents: Control document actions at the project, folder, or item level. Project members may use the ServiceWise version control system to manage versioning of project documentation. Tools available in the Knowledge view and the Notes page of the Main view provide project members with access to past versions of documents and ensure that only one project member may access a document at any one time.

Define and manage project member and employee self-service: Provide employees with help topics, release notes, and other self-help documentation.

• Define keywords and relevancy of keywords for knowledge items stored in the knowledge base.

Track resolved incidents: Add resolved incidents to the knowledge base to enable self-service and speed diagnosis and resolution.

• Searching the knowledge base for knowledge items: Full text and keyword searches ranked by relevancy.

• Add knowledge items as attachments to incident notes or email them to other users.

• Extend the knowledge base by linking knowledge items to third-party knowledge management solutions. Link TechExcel ServiceWise and ServiceWise with third-party knowledge management tools

ServiceWise enables project members to manage knowledge items (documents, web pages, topics, and attachments) in the Knowledge view.

The Knowledge view contains tools designed to manage four different types of knowledge items. The Knowledge Tree window organizes knowledge items into a hierarchy of folders.

Documentsinclude all external files that saved in the ServiceWise database through the Knowledge view. Documents may either be created internally from document templates or externally using a word processing or spreadsheet program.

Announcementsare predefined emails that are created in the TechExcel ServiceWise client, and are then delivered to one or multiple employees also through the client.

HTML linksenable project teams to create a library of project-related URLs. Development issues can be linked with a dynamically changing web site or page-based HTML document for easy reference and access.

Topicsare knowledge items specifically designed to enable project teams to build a knowledge base of problems and resolutions. Each topic knowledge item consists of a description page, a resolution page, and a links page.No file is attached and the information is maintained in the database. Topics can help save time in resolving redundant issues.

Attachmentsare documents that have been attached to issues in the Main view Notes page. Although these knowledge items are visible through the Knowledge view, they are managed using tools in the Notes page.

Knowledge privileges enable project members to build, publish, and manage knowledge items in TechExcel ServiceWise projects.

All privileges are granted by project administrators to account types in ServiceWise projects. Project members inherit privileges when they are assigned an account type in a project.

Project members assigned a light account type cannot perform any of the knowledge-related operations.

Project administrators may assign 13 different knowledge management privileges to each regular account type.

Table 18-1: Knowledge View Access Controls

Project administrators may enable text and HTML editing tools using controls in the General Settings page of the Knowledge view folder.

TechExcel ServiceWise enables project members to create email announcements and knowledge items using advanced HTML and text editing tools.

Project administrators may choose between four editors:

• Text editor

• Standard TechExcel web edit control.

• eWebEdit control 20 users edition (separate purchase is required)

• eWebEdit control unlimited users edition (separate purchase is required)

The HTML editor folder contains the copies of HTM files that have been edited by project members in the ServiceWise client applications.

To define the HTML Editor folder, define the local folder for HTML editor control.

Email announcementsare predefined emails that are created in the TechExcel ServiceWise client, and are then delivered to one or multiple employees also through the client.

In TechExcel ServiceWise project members that have been granted the Can Email Blast Knowledge Announcement privilege may create a knowledge announcement in the Knowledge view and blast the customized email to all employees with a single click.

Project administrators may use controls in the Email Announcements page of the Knowledge view folder to enable email announcement support and email announcement settings in TechExcel ServiceWise projects. Email announcement settings are defined on a work project by work project basis.

Project administrators may not define email announcements in base projects. Project administrators may configure email announcement properties using controls in the Email Announcement page of the Knowledge view folder.

Note:The TechExcel ServiceWise Email Server programs must be installed for this feature to work correctly. The email retrieval service must be installed to process incoming emails, and the email notification service must be installed to process outgoing emails.

Email announcement administrative tasks include:

• Defining Email Blast Announcement Settings

• Defining Criteria for Redundant Email Announcements

• Enabling and Defining Email Announcement Engine Settings

• Defining Employee Subscription Options

TechExcel ServiceWise offers a complete solution for managinginternalhelp desk support—the support services that a business offers to its employees.

Using the service agreement manager, project members may define, manage, and track service level agreements in ServiceWise projects. Each service level agreement defines a level of support services that may be offered to the company employees.

Different employees may receive different levels of service— guaranteed response times, resolve times, and support schedules—based on their account type, the incident type, or the associated asset.

• Thesupport scheduledefines the dates, days, and hours during which support services are contracted to the employee.

• Theresponse timedefines the time in which a incident submitted by an employee must be responded to by the support team.

• Theresolve timedefines the time in which a incident submitted by an employee must be resolved by the support team.

ServiceWise service agreement support is an optional ServiceWise feature.

Support engineers may manage and track employee service level commitments using administrator-defined service templates, event service templates, and service agreement templates.

• Service-level agreement templates enable project administrators to define business rules that determine how particular incidents are managed and tracked based on the incident type or the employee.

The Service Agreement Manager tracks all service plan charges, generates appropriate invoices, and tracks all payment and renewal history. Using the Service Agreement Manager each employee may be assigned one or multiple service agreements.

• Service plan pricing can be a fixed fee per incident, annual contracts, or may include a base level of support with additional service charges per hour or per incident.

• Guaranteed response time can be defined for each service plan, with incidents automatically escalated if the time is exceeded.

Every incident submitted to a TechExcel ServiceWise project is assigned a service plan that covers the support cost of the incident based incident properties.

• Based on the incident properties, TechExcel ServiceWise can automatically select a valid service level agreement and decide if support is covered.

• A default service agreement can also be specified to cover incidents that do not match predefined conditions.

Service agreement templates

In ServiceWise, every service agreement is based on an administrator-defined service agreement template.Service-level agreement templatesrepresent the support plan that exists between an employee and the support organization.

Aservice-level agreement templateis a cluster of service agreement settings—a support schedule, response time, resolve time, and other settings—that enable project members to quickly apply the appropriate service level agreement to each support incident.

Cost calculation and invoicing

Every administrator-defined service agreement template defines not only level of service promised to the employee—the support schedule, response time and resolve time, but also predefined support cost calculation and corresponding invoicing methods.

Employees may be assigned multiple service agreements across multiple product lines.

Note:TechExcel ServiceWise features the same service agreement tools available in the TechExcel CustomerWise Suite of customer management tools including service agreement management, cost calculation, and invoicing. Although most businesses do not invoice their own employees for support services, ServiceWise provides businesses with the flexibility to manage and track support services to suit their business model.

In ServiceWise, all service agreement configurations are encapsulated in administrator-defined service agreement templates.

Aservice-level agreement templateis a cluster of service agreement settings—a support schedule, response time, resolve time, and other settings—that enable project members to quickly apply the appropriate service level agreement to each support incident.

But to create service agreement templates, a project administrator mustfirstdefine the appropriate time tracking and service settings—the work type and service template objects, and one or more company support schedule, service type, and service agreement status objects. Every service agreement template is built on a foundation of time tracking and service management configurations.

The following business objects must be defined before the administrator can define ServiceWise service agreement templates:

Service templatesrepresent a service that is performed for an employee. Each service template is a cluster of administrator-defined configurations: a work type, cost method, sales method, and time-tracking method. Every service templates may be time-related or non-time-related.

Shipping and payment method settingsdefine how the services mandated by the service level agreement are to be shipped and charged to the employee.

For more information and step-by-step instructions for creating support schedules see See “Administering Support Schedules”.

• Theemployee support scheduledefines the dates, days, and hours during which support services are contracted to the employee.

For more information and step-by-step instructions for creating support schedules see See “Administering Support Schedules”.

• Theservice agreement statusof a service agreement indicates the current status of that service agreement and may trigger an administrator-defined action. Every service agreement template is defined by a default service agreement status.

For more information and step-by-step instructions for creating support schedules see See “Administering Service Agreement Statuses”.

All service agreement configurations are built on a foundation of time tracking and service management configurations.

The project administrator must also enable service agreement support in the project and define account type-based access controls. Service agreement is an optional ServiceWise feature. For more information and step-by-step instructions for creating support schedules see See “Administering Service Agreement General Properties”.

Project administrators may define service agreement templates in the Service Agreement folder of the ServiceWise Admin client.

Service agreement templates and service agreement management is an optional feature in TechExcel ServiceWise.

Project administrators may enable service agreement support in ServiceWise projects and grant service agreement privileges to project members in the General Settings page of the Service Agreement folder of the ServiceWise Admin client.

If an administrator enables service agreement management in a project, two changes are made to the TechExcel ServiceWise client applications:

• The Service Tracking page is displayed in the Incident view of the ServiceWise clients.

• Whenever a new incident is submitted to the project, a valid and active service agreement plan is automatically selected and assigned to that incident.

Note:All service agreement settings are specifically defined in each work project. The Service Agreement folder is not displayed in the Admin tree window of employee base projects

Service agreement administrative tasks include:

• Enabling Service Agreement Support

• Defining Service Agreement Access Controls

To enable service agreements in a ServiceWise support project, project administrators must select the Enable Service Agreement Support check box in General Settings page of the Service Agreement folder.

The system pages displayed in the Time/Service Management folder enable project administrators to define time tracking and professional service management features in ServiceWise projects.

Note:The majority of these settings are specific to the current work project. Only the Work Type page and Service Template pages are stored in and are available in the base project.

Time and service management features fall into two categories: standard time and service management and Advanced time and service management.

Four standard time/service management pages in the Time/Service Management folder:

• The General Setting system page

• The Work Type system page

• The Standard Rate system page

• The Privileges system page

Advanced Time Tracking and Service Management pages enable administrators to configure advanced time tracking and service management features. Five additional Advanced Time Tracking and Service Management pages may also be displayed in Time/Service Management folder.

• Work Order

• Budget Control

• Service Template

• Access Control

• Event Service Template

Advanced professional service management functions require the separate purchase of the Service Agreement Manager. The Advanced Time Tracking and Service Management features require the purchase of the Service Agreement Module.

Project administrators may also enable advanced time tracking and service management features in the Optional Features page.

Project administrators may enable professional services management settings in the General Setting page of the Time/Service folder.

General time and service management administrative tasks include:

• Enabling Professional Services Time Tracking

• Enabling Professional Services Cost Tracking

• Enabling Professional Services Sales Tracking

• Enabling Service Template Support

• Enabling Time Usage Recording

• Displaying the Billable Check Box to Employees

ServiceWise professional service time tracking enables businesses to track the time that is required for support engineers to process support incidents.

To enable professional service time tracking, select the Enable Time Tracking check box in the General Setting page.

ServiceWise professional service cost tracking enables businesses to track the outgoing costs that are paid to process support incidents.

To enable cost tracking, select the Enable Cost Tracking check box in the General Setting page.

ServiceWise professional service sales tracking enables businesses to track the revenue generated through support incidents.

To enable sales tracking, select the Enable Sales Tracking check box in the General Setting page.

In ServiceWise, service templates define the methods used to track the time, cost, and price of support services.

To enable support service templates, select the Support Service Templates check box in the General Setting page.

Service templates are only needed if the company needs to track the time spent, the cost, or the price of individual support services. For more information see See “Administering Service Templates” on page 393.

 

ServiceWise incident notifications and incident escalations provide support organizations the means to ensure that incident stakeholders are automatically notified at key junctures in the incident lifecycle, enforce accountability, and drive the quality of services provided to employees.

 

All incident notifications and incident escalations are based on administrator-defined rules which identify the triggers, conditions, notification methods and messages, and recipients of every notification or escalation action.

 

Incident notifications and escalations enable support teams to ensure that incident stakeholders are kept abreast of the status of their incidents. The primary difference between ServiceWise incident notification and incident escalation is how these rules are triggered:

 

Incident Notification:Incident notifications alert incident stakeholders whenever key changes are made to their support incidents— subscribers may be notified whenever incidents are created, updated, or closed in a support project.

 

Incident Escalation:Incident escalations alert incident stakeholders at key points in the lifecycle of support incidents or when insufficient action is taken on an incident in a defined time period and provide for the reassignment of escalated incidents to other project members and workflow states.

 

Both ServiceWise incident notification and incident escalation support:

 

• Customized notification triggers. The trigger defines the specificaction(incident notification) orlack of action(incident escalation) that prompts the delivery of the notification message.

 

• Customized conditions that limit the scope of the trigger to a subset of incidents based on an administrator-defined query.

 

• Customized email notification messages and notification methods (email, pager, and mobile phone)

 

• Customized subscription rules including mandatory and optional notification subscriptions.

 

 

TechExcel ServiceWise supports bothpush notification subscriptionsandpull notification subscriptions.

 

All incident notifications and escalations are defined by administrator-definedsubscription rules. Subscription rules determine whether a project team member must, can, or cannot receive a notification.

 

Subscriptions rules may mandate that certain project members receive incident notifications for certain incidents while others mayopt inoropt outof individual subscriptions. Project administrators may also mandate that certain project memberneverreceive incident notifications based on incident notification rules.

 

• Push notifications are “instantly and actively transferred (pushed)” to subscribers. A project member is subscribed to all incidents and is always notified when changes are made to incidents based on that rule.

 

• Pull notifications are optionally sent. A project member may choose to subscribe to a notifications on an incident-by-incident basis.

 

 

The ServiceWise Mail Service enables support organizations to integrate ServiceWise workflow, incident notification, event scheduling, and incident escalation with the convenience of email.

 

All email, pager, and mobile phone notifications are sent to subscribers through the the ServiceWise Mail Service. ServiceWise incident notification and escalation and event notification and escalation require the installation and configuration of the ServiceWise Mail Service.

 

The ServiceWise Email Server communicates with the ServiceWise Database Server and email server to find and send email messages generated within a ServiceWise project. The ServiceWise Mail Server retrieves the user name and password needed to access to the ServiceWise Database Server from the ServiceWise Application Server.

 

 

The ServiceWise Email Notification Service must be stopped and restarted whenever a change is made to incident notification settings.

 

To reload email notification settings, click the Reload Email Service Setting button in the Incident Notifications page of the Advanced Settings folder.

 

 

The incident notification activity date identifies the beginning date for all incident notifications in a ServiceWise project.

 

• Notification rules triggered subsequent to the activity date generate incident notifications.

 

• Notification rules triggeredpriorto the activity datedo notgenerate incident notifications.

 

To define project incident notification activity dates, select the Start Date for Applying Notification rules control in the Incident Notifications page of the Advanced Settings folder.

  

 

In ServiceWise, incident notification is the process by which stakeholders are notified (by email, pager, or mobile phone) whenever a specific change—such as the creation or deletion—is made to a support incident.

 

All incident notifications are based on administrator-defined incident notification rules. An incident notification rule is defined by anotification trigger, one or morenotification actions, and one or moresubscribers. The scope of an incident notification rule may be defined by anotification condition.

 

Using controls in the Add Notification Rule manager and the Properties tab of the Incident Notifications page, project administrators may define and update many notification rule properties.

 

Notification Trigger:A notification trigger identifies the incident management task that triggers a notification action.

 

Notification Condition:A notification condition limits the limit the scope of the trigger to a subset of incidents based on an administrator-defined query.

 

Notification Action:A notification action defines the notification message and the notification method (email, pager, mobile phone).

 

Subscribers:Subscribers represent project members that are both potential recipients of an incident notification and who are subscribed to the incident notification rule. Project administrators may assign one of four subscriptions to project members, account types, and groups: the Must Subscribe subscription, the Optional Yes subscription, the Optional No subscriptions, and the Never Subscribe subscription.

 

 

Incident notification is an optional ServiceWise feature that must be enabled on a project-by-project basis.

 

To enable incident notification select the Enable Email Notification check box in the Incident Notifications page of the Advanced Settings folder.

 

ServiceWise event notifications and event escalations provide support organizations the means to ensure that event stakeholders are automatically notified at key junctures in the event lifecycle, enforce accountability, and drive the quality of the services offered to company employees.

All event notifications and event escalations are based on administrator-defined rules which identify the triggers, conditions, notification methods and messages, and recipients of every notification or escalation action.

Event notifications and escalations enable support teams to ensure that event stakeholders are kept abreast of the status of their events. The primary difference between ServiceWise event notification and event escalation is how these rules are triggered:

Event Notification:Event notifications alert event stakeholders whenever key changes are made to their support events— subscribers may be notified whenever events are created, updated, or closed in a support project.

Event Escalation: Event escalations alert event stakeholders at key points in the lifecycle of support events or when insufficient action is taken on an event in a defined time period and provide for the reassignment of escalated events to other project members and workflow states.

Both ServiceWise event notification and event escalation support:

• Customized notification triggers. The trigger defines the specificaction(event notification) orlack of action(event escalation) that prompts the delivery of the notification message.

• Customized conditions that limit the scope of the trigger to a subset of events based on an administrator-defined query.

• Customized email notification messages and notification methods (email, pager, and mobile phone)

• Customized subscription rules including mandatory and optional notification subscriptions.

TechExcel ServiceWise supports bothpush notification subscriptionsandpull notification subscriptions.

All event notifications and escalations are defined by administrator-definedsubscription rules. Subscription rules determine whether a project team member must, can, or cannot receive a notification.

Subscriptions rules may mandate that certain project members receive event notifications for certain events while others mayopt inoropt outof individual subscriptions. Project administrators may also mandate that certain project memberneverreceive event notifications based on event notification rules.

• Push notifications are “instantly and actively transferred (pushed)” to subscribers. A project member is subscribed to all events and is always notified when changes are made to events based on that rule.

• Pull notifications are optionally sent. A project member may choose to subscribe to a notifications on an event-by-event basis.

In ServiceWise, event notification is the process by which stakeholders are notified (by email, pager, or mobile phone) whenever a specific change—such as the creation or deletion—is made to a support event.

All event notifications are based on administrator-defined event notification rules. An event notification rule is defined by anotification trigger, one or morenotification actions, and one or moresubscribers. The scope of an event notification rule may be defined by anotification condition.

Using controls in the Add Notification Rule manager and the Properties tab of the Event Notifications page, project administrators may define and update many notification rule properties.

Notification Trigger: A notification trigger identifies the event management task that triggers a notification action.

Notification Condition:A notification condition limits the limit the scope of the trigger to a subset of events based on an administrator-defined query.

Notification Action:A notification action defines the notification message and the notification method (email, pager, mobile phone).

Subscribers: Subscribers represent project members that are both potential recipients of an event notification and who are subscribed to the event notification rule. Project administrators may assign one of four subscriptions to project members, account types, and groups: the Must Subscribe subscription, the Optional Yes subscription, the Optional No subscriptions, and the Never Subscribe subscription.

Event notification is an optional ServiceWise feature that must be enabled on a project-by-project basis.

To enable event notification select the Enable Email Notification check box in the Event Notifications page of the Advanced Settings folder.

An event notification rule identifies which project team members are notified whenever a specific change is made to a support event.

An event notification rule is defined by anotification trigger, one or more notification actions, andnotification subscription rules. Optional event notification conditions limit the scope of the rule to a subset of support events

Any number of notification rules may be defined in a project.

To define an event notification rule:

1Select Advanced Features > Event Notifications.

2Click the New button.

The Add Notification Rule dialog box appears.

3Provide a name and description for the event notification rule.

A unique name and note that describe the logic of the event notification rule enables project administrators to save time when they review or update event notifications.

Notification trigger

4Select a trigger in the Trigger dropdown list.

The Trigger dropdown list displays six system triggers and all administrator-defined status change and field change triggers. Every event notification rule is defined by a single notification trigger.

Notification conditions

5 Optional: To limit the scope of a notification rule, select an event notification condition in the Condition dropdown list.

The Condition dropdown list displays all administrator-defined conditions.

Applicable event templates

6Select one or more event templates in the Applicable Regular or Co-Owner Event Template list.

The scope of the event notification rule is restricted to support events based on the selected regular and co-owner event templates.

7Click the OK button.

The Add Notification dialog box closes and the event notification rule is displayed in the Notification Rules list.

Notification actions

8Define one or more notification actions in the Actions tab.

A notification action is defined by anotification method(email, pager, or mobile phone) and anotification message.

• To define an email notification action, select the Notify By Sending Email option and select appropriateinternal(project team member) andexternal(employee) messages.

• To define a pager notification action, select the Notify By Pager option and select an appropriate message.

• To define a mobile phone notification action, select the Notify By Mobile Phone option and select an appropriate message.

Custom notification messages may be defined in the Define Email window. For step-by-step instructions see “Select the Yes or No option in the Option dropdown list.”.

Potential recipients

9Define potential recipients in the Potential Recipient tab.

A potential recipient is a project team member whomay subscribeto an event notification rule. A project team member may be identified as a potential recipient based on their account type, team group, or potential recipient variable.

Potential recipient subscription rules

10Define subscription rules in the Subscription Option tab.

Potential recipient subscription rules define whether a potential recipient can, cannot, or must subscribe to an event notification. Subscription rules may be defined for each account type, team group, or user account and affect only those project team members that have been designated as potential recipients of event notifications.

Subscribers

11Define subscriptions in the Potential Recipient tab.

Event notification subscriptions define which project team members are subscribed and which project team members are not subscribed to each event notification rule.Event notification rules are specifically defined for each user account and override all potential recipient subscription rules.

To rename an event notification rule

To rename an event notification rule, select the rule in the Notification Rules list and click the Rename button. The name of the rule may be changed in the dialog box.

To delete an event notification rule:

To delete an event notification rule, select the rule in the Notification Rules list and click the Delete button.

TechExcel Outlook Sync provides Microsoft Outlook users the ability to interact with TechExcel ServiceWise data from directly within Outlook. The TechExcel Outlook Synd adds additional buttons to the Microsoft Outlook interface making it easy for salespeople and customer support technicians to synchronize activities performed within Outlook to ServiceWise. Synchronizing communications, activities, and tasks from Outlook to ServiceWise improves both user efficiency and visibility.

Capture Outlook Emails

Incoming and outgoing Outlook emails may be selected and linked with the appropriate customer in ServiceWise with a single click. Or, more detailed Employee search may also be used to find and match the email with the appropriate customer record.

Automatic Record Matching

Emails sent and received are automatically matched with existing ServiceWise information based on matching email addresses. Support teams link new and existing emails with employees, requests, or support incidents while adding Outlook emails to ServiceWise. If no match is found, users may also choose to perform a search of ServiceWise employee data from within Outlook.

Online/Offline Customer Contact Support

Search the ServiceWise employee database from within Outlook even when offline. TechExcel Outlook Sync maintains a local database of customer, contact, opportunity, and event information so sales and support users may access and update information while offline. All updates made locally will be synchronized with the ServiceWise server when online.

Employee Manager

Add or update ServiceWise employee information directly from Outlook at the same time you add an email, task, or appointment.

Create Outlook Tasks and Activities from ServiceWise Events

ServiceWise Events may be configured to automatically create calendar appointments or tasks in Microsoft Outlook. ServiceWise Events are also workflow driven so you may configure a process which automatically updates users task lists and calendars as a part of the IT management or support workflow to ensure incidents, requests, or changes are worked on consistently and in a timely manner.

Server Requirements

• TechExcel ServiceWise 8.0 or above

• Outlook Integration must be enabled and configured by Administrator

End User Requirements

• Microsoft Windows 2000, XP, XP Professional, or Vista

• Microsoft Outlook XP, 2003, and 2007

• Permission to perform Outlook Sync Actions

TechExcel System Administrators must configure Outlook Sync within the Admin Client before use. There are two areas within the Admin Client that must be configured:

1. Support Member Manager

System administrators must grant team members permission to use Outlook Sync. This privilege is granted using a new checkbox in the Team Member Manager.

The image below shows a new privilege “Can perform Outlook Integration” that must be checked for team members allowed to perform actions.

2. Outlook Integration Settings

The second step is to configure the Outlook Integration settings found under the Advanced Project Settings folder in the Admin Client.

The image below shows the new Outlook Integration page and is followed by a brief description of each control on the page.

1.Enable Outlook integration

This checkbox must be checked to enable syncing Outlook items with events and saving emails as events in the work project.

Event Sync Options Tab

Control how events sync from TechExcel ServiceWise to Microsoft Outlook with these settings. Only the events that meet the criteria defined here will be synced to Outlook appointments or tasks.

2.Sync options

For each event template there are three sync options available:

1. Don’t sync

2. Sync to appointment

3. Sync to task

3.Sync Statuses

For each event template, the administrator may choose the event statuses in which the event will be synced.

4.Date Range

The administrator may define date ranges to further limit event syncing so not all events are synced at once. The Administrator may create Date Range rules based on the event Create Date, Start Date, and End Date. The date range rules are global and will apply to all event templates configured to synchronize with Outlook.

Save Emails as Events Tab

End users may save emails from Microsoft Outlook to TechExcel ServiceWise as an event. When users choose to save an email as an event, they will be able to choose from the events the administrator has selected as applicable event templates. Only event templates with an event type of ‘Email received’ or ‘Email sent’ (defined in the event template settings) are available to administrators when defining applicable events. A default event template may also be defined by the administrator for the most commonly used event.

If you have not installed the TechExcel Outlook Sync plug-in, please see the AppendixInstalling TechExcel Outlook Syncfor detailed installation instructions.

Configuring Outlook Sync for Use

1. Press Configuration

Before using TechExcel Outlook Sync, you need to run the Configuration wizard. The wizard will run automatically the first time you open Outlook after installing. You may also run the configuration wizard by pressing the Configuration button in the Outlook toolbar, or selecting the new ServiceWise menu option, and selecting Configuration.

2. Press User Login

Enter your TechExcel ServiceWise login credentials, select the correct web service connection, select the project to synchronize emails, and press the OK button.

Having Trouble Logging In?

• Do you have permission to use the Outlook Sync?

Contact your ServiceWise Administrator to request permission to use Outlook Sync.

• Does the project you belong to allow for Outlook Sync?

Contact your ServiceWise Administrator to inquire if the project allows Outlook integration.

• Not Seeing Synchronization?

Make sure you have selected the correct project in the Select Project dropdown. You may only synchronize with one project at a time. However, you may always return to this configuration screen and switch projects.

3. Press Setup Local DB

After you have configured user profile information, the wizard will ask you to set up a local database. Or, you may select theSetup Local DBitem in the Configuration menu. The local database will be used to preferences and also actions performed while offline. When a connection becomes available, the actions performed will synchronize with the live ServiceWise system.

To configure your local database

Select the Database Type. Choose between:

• Microsoft Access

• Microsoft SQL server

Once you have completed the database connection information, press the OK button. The configuration wizard will populate the local database with the correct tables and synchronize data from live ServiceWise database.

4. Finishing Configuration

After the local database is updated, the configuration wizard will display a list of event synchronizations and email settings defined by your ServiceWise Administrator.

This summary shows the ServiceWise event templates used for synchronizing Outlook events and appointments and also the ServiceWise events created when saving Outlook emails to ServiceWise.

You may always utilize the Configuration menu to reconfigure local settings.

For example,

• Set up local DB: Create a new or change the local database.

• Sync time: Re-synchronize the time difference between the local and master database.

• Restore local DB: Overwrite the local database with data from the live ServiceWise database.

When sending an email, you may now choose to save the email to TechExcel ServiceWise and associate the email with a customer and a specific support incident if connected to a support project or sales opportunity if connected to a sales project.

1. Create a new message within Outlook.

2. Press the Add-Ins toolbar or menu item.

3. Press theSend and Save Email to ServiceWisebutton (Shown in image below).

4. Confirm the Send Email information is correct or make adjustments using the Save Event dialog (shown below).

5. The correct employee will be selected automatically based on the matching email information from TechExcel ServiceWise.

• You may add Employees using theNew…buttons next to Employee fields.

• You may search Employees using theicon next to the Employee field.

• You may edit the existing information using any of theEditbuttons for the Employee.

Please Note:Creating/editing employee information is only available when there is an interment connection. Functions performed offline will be done on the local database and synchronized to main TechExcel ServiceWise database when a connection becomes available.

6. Choose the related incident to associate the email event.

7. Choose theEvent templateandEvent statusused to track this email activity in TechExcel ServiceWise.

8. You will now see this Email event and message from within TechExcel ServiceWise.

Please Note: An email can only be saved to one event. Once saved, the ‘Save email to ServiceWise’ button will be disabled for that email.