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

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

• Managing support incidents and events

• Managing customers

• Maintaining a knowledge base as a support resource

• Tracking company assets

• Managing professional services

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

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

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

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

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

Every customer 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.)

1.1.2 Base Projects

 

Abase projectis a tool for storing and managing the customer, 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 customer, asset, and knowledge data while maintaining their own incident and event data, team structures, and workflow rules.

 

1.1.3 Subproject Management

 

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 customers, 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.

 

1.2 CustomerWise Administration

 

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

 

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

 

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

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

 

Every customer 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.)

 

1.2.1 System-level Administration

 

System-level administrative tasks include the creation of CustomerWise base and work projects, the creation and management of CustomerWise user accounts and licenses, and the administration of CustomerWise 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 CustomerWise 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 CustomerWise applications and modules, the configuration of the CustomerWise E-mail Server, CustomerWise Document Server, and TechExcel Search Engine, and all integration configurations.

 

All system level administrative tasks are managed by a system administrator—a licensed CustomerWise 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 CustomerWise site.

 

1.2.2 Project-level Administration

 

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

 

1.2.3 Administrative Accounts and Access Controls

 

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.

1.3 Team Representation and Management

 

Abase projectis a tool for storing and managing the customer, 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 customer, asset, and knowledge data while maintaining their own incident and event data, team structures, and workflow rules.

 

1.3.1 Account types

 

TechExcel CustomerWise uses a account types to coordinate project members in project workflow and to implement security in CustomerWise projects. Anaccount typedefines the role of a user account—the privileges and responsibilities granted to that user—in a CustomerWise work project.

 

Every licensed CustomerWise user is assigned an account type in each work project. The account type defines the role that the user plays in that project. Project members that have different responsibilities in different projects may be assigned account types that reflect their role in each project.

 

In CustomerWise, all project-level access controls are assigned to account types and not to individual user accounts. Project members inherit privileges from the account type they are assigned in a project. A user may belong to many different projects and be assigned different account types in different work projects.

 

Project administrators may define any number of account types in a project and assign a unique set of privileges to each account type providing them with the flexibility to define many different levels of project security.

 

1.3.2 Team groups

 

A team group represents a group of project members that share a common set of responsibilities in a CustomerWise work project, but who do not necessarily share the same role or responsibilities.

 

Whereas an account type represents a specific role, team groups represent a team of project members that belong to the same work group, but have different responsibilities.

 

Using team groups, project administrators may organize project team members into smaller, more useful entities for the assignment of incidents, events, and customers.

 

If the project administrator defines a team group as an applicable owner in an event template, every member of that team group is deemed to be an applicable owners of every event that is based on that event template.

 

1.3.3 Group folders

 

The group folder concept reflects the fact that a support incident may belong to a group instead of an individual team member at a particular phase in its life cycle. CustomerWise group folders store common support incidents and enable flexible and definable workflow control.

 

Group folders represent a kind of buffer between the a team group and the incidents assigned to that group. Each group folder is owned by a particular team and protected by access controls: View, Put, and Get privilege.

 

Only those project members with the appropriate account type may view incidents assigned to a group folder (Get), add incidents to a group folder (Put), or forward those incidents to another project member or group.

 

Group folders are particularly useful to administrators when they define project workflow and determine how tasks are distributed to project members in the project. Anything that may be assigned to a project member in the project may all be assigned to a group folder.

 

1.4 Incident and Event Management

 

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 customers, 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.

 

1.4.1 Incident Management

 

The primary vehicle for managing and tracking support issues in CustomerWise are collections of data calledincidents. Eachincidentrepresents a particular task or set of tasks that must be managed by a support team. CustomerWise incidents are usually associated with an customer and one or more subtasks calledevents.

 

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. Project administrators may define which properties comprise an “incident” on a project-by-project basis.

 

CustomerWise projects are fundamentally tools for creating, managing, and tracking incidents and related customers, events, and assets.

 

Incident management tasks include:

 

• Tracking incidents

• Creating incidents

• Forwarding incidents

• Closing and reopening incidents

 

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

 

Meanwhile, at any time during its life cycle, project members may communicate with customers by web conversations, automated e-mail notifications, or personalized incident summaries by e-mail.

 

1.4.2 Incident Workflow

 

Workflow rules enable project managers to define and track the flow of work between individuals and teams.

 

Workflow is a business process used to manage the tasks that compose a project. A well-defined set of workflow rules enable an organization to perform tasks in an efficient and repeatable manner.

 

Incident 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 customers are applicable to a subproject and its incidents and events.

 

• Project workflow determines the life cycle of CustomerWise incidents. Project administrators may define workflow settings once in TechExcel CustomerWise 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 e-mail notifications for all escalations.

 

1.4.3 Incident Escalations

 

CustomerWise incident notification enables support teams to ensure that all appropriate stake holders are notified (by e-mail, pager, or mobile phone) whenever incidents are created, updated, or closed in a CustomerWise project. CustomerWise incident notification is based on administrator-defined incident notification rules. Incident notification rules consist of triggers, conditions, actions, and subscribers.

 

CustomerWise enables administrators to manage bothpush e-mailandpull e-mailfor each incident notification rule using subscription rules. Project administrators 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.

 

1.4.4 Incident Routing

 

Incident routing is an optional feature that enables administrators to define rules for automatically routing CustomerWise incidents to project members based on administrator-defined routing rules.

 

Incidents may be automatically routed and assigned to project members based on one of four sets of criteria:

 

• Based on project member workloads

• Based on project member skill levels

• Based on a formula that is based on the workload and the skill level of potential targets

• Based on availability— administrators may optionally mandate that a user must be logged into a project to be subject to routing rules.

 

1.4.5 Incident Escalation

 

CustomerWise incident escalation enables project teams to ensure that support incidents do not “fall through the cracks” by ensuring that project teams are automatically notified if insufficient progress is made on CustomerWise incidents during a defined time period.

 

Escalation actions include reassigning the incident to a new owner, changing the progress state of the incident, or even automatically generating e-mail notifications. incident escalation.

 

Project teams may be notified by e-mail, pager, mobile phone, or personal folder based on an administrator-defined escalation schedule. If still no action is taken, incidents may be automatically reassigned to another project member, group, or group folder.

 

1.4.6 Event Management

 

TechExcel CustomerWise 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.

 

Every event is either an incident-specific event or a general event.

 

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.

 

Typical events include calling or receiving a call from an customer, customer requests for equipment, an online meeting or visit to a site, receiving or sending e-mail, or approval from management.

 

Events in views

 

Project members may manage and track events in the Event view of the CustomerWise client. Events may also be managed in the Incident view, Customer view, and Calendar view. Most events are the child of a parent incident, are associated with a single customer, and owned by a single CustomerWise project member, and may be managed based on these relationships.

 

• The Event view displays events and information about incidents and customers that are related to specific events. Project members may also manage sibling events in the Event view.

 

• The Incident view displays incidents and information about all of the child events of each incident.

 

• The Customer view displays customers and information about all of the incidents and events associated with that customer.

 

1.5 Customer Management

 

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

 

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

 

The CustomerWise model is designed so that businesses may configure CustomerWise projects to support business processes rather than changing their business to fit the limitations of the application. All projects, incidents, events, and customers 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. CustomerWise users may may log into and work in many different projects, be assigned a unique account type, privileges, and responsibilities in each project using a single CustomerWise license.

 

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

 

1.5.1 Tracking E-mail

 

Communication by e-mail between support engineers and customers is represented in CustomerWise project by e-mail events.

 

Events represent the subtasks that must be performed before an incident can be resolved and closed. Events are generally the children of a parent incident and represent a task that must be performed within an incident workflow state.

 

One of the most common events in CustomerWise projects to send or receive e-mail from a customer. All e-mail events are instances of an administrator-defined event template belonging to one of three event types:

 

• The E-mail Sent event type represents a set of business rules for managing e-mail sent to a customer from a CustomerWise project member.

 

• The E-mail Received event type represents a set of business rules for managing e-mail sent to a project member from a customer.

 

• The E-mail Announcement event type represents a set of business rules for managing e-mail announcement events.

 

1.5.2 Web Conversations

 

The web conversation is a useful tool for communicating with customers. The Web Conversation page provides support project members a powerful tool for communicating with customers about their incidents.

 

The Web Conversation page features a rich text chat-like interface, with time stamped and logged data input. Customers may communicate through the Customer Web Portal.

 

Web conversations enable support team to see when customers add new web conversation to an incident. Incidents can be flagged in the Incident list so that the team members can easily spot them. Flagged incidents may also be displayed in the home page of each team member. Team members may manually clear the web conversation flags by checking the Clear the New Customer Request check box on web conversation page and clicking the Submit button.

 

1.5.3 CTI Integration

 

Computer telephony integration, or CTI, is a technology that enables telephone and computer interactions to be integrated or coordinated.

 

TechExcel CustomerWise features CTI tools that enable support teams to improve customer support over the telephone by using a plug-and-play solution based on the CTI Data Connector (CDC) from Mirage Computer Systems. CustomerWise CTI integration introduces the following features:

 

• On-screen dialing of outgoing phone numbers from the TechExcel CustomerWise client improves support efficiency. Project members may dial customers by selecting phone numbers in the CustomerWise client.

 

• Automatic on-screen display of caller data for all inbound calls. PRoject members can immediately see who is calling and do not need to look up customer names and service history.

• On-screen caller ID of incoming and outgoing phone calls. CustomerWise CTI automatically matches incoming and outgoing calls with phone numbers stored in the base project.

 

1.5.4 Customer Web Portal

 

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

 

• The Customer Web Portal enables customers to submit and edit incidents through the Internet.

 

• The Customer Web Portal enables customers to view their incidents and events.

 

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

 

• The Customer Web Portal enables customers 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 Customer Web Portal enables customers to conduct Web conversations with CustomerWise project members.

 

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

 

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

 

The Customer Web Portal may be fully integrated with TechExcel DownloadPlus, enabling your users to download software or documents based on their profile.

 

1.6 Knowledge Management

 

System-level administrative tasks include the creation of CustomerWise base and work projects, the creation and management of CustomerWise user accounts and licenses, and the administration of CustomerWise 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 CustomerWise 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 CustomerWise applications and modules, the configuration of the CustomerWise E-mail Server, CustomerWise Document Server, and TechExcel Search Engine, and all integration configurations.

 

All system level administrative tasks are managed by a system administrator—a licensed CustomerWise 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 CustomerWise site.

 

1.6.1 Incident Knowledge Management

 

Incident knowledge management is the management of incident-specific data in support incidents. A support incidents is a tool for tracking and sharing information about a specific support task. Each support incident serves as a centralized repository for storing, managing, and sharing information.

 

All incident-specific information is directly embedded in, or attached to, the support incident used to track the incident. incident-specific information may be managed and tracked in incident descriptions and work descriptions, incident histories, and incident notes and note attachments.

 

1.7 Asset Management

 

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

 

1.7.1 Asset Inventory

 

AssetWise asset structures —called theAsset Inventoryin TechExcel CustomerWise and theProduct Catalogin TechExcel CustomerWise—facilitate the definition, management, and tracking of company assets.

 

An asset is any article—tangible or intangible—that requires management and tracking. AssetWise asset structures enable support organizations to organize assets into distinctasset categories—hardware, software, spare parts, licenses, keys, parking permits, office equipment, and so on— based on shared properties.

 

Asset management requires that support organizations track different kinds of data for different categories of assets. Hardware is managed and tracked differently than software. And software is tracked differently from licenses. Asset structure administration is serves a dual purpose:

 

• Asset structures define and organize company assets.

 

• Asset structures define the tools that project members use to manage assets in the AssetWise, HelpDesk, and CustomerWise clients.

 

• Asset structures determine how company assets are created, managed, and tracked in the AssetWise, HelpDesk, and CustomerWise clients.

 

1.7.2 AssetWise LinkPlus

 

Asset detection applications enable IT organizations to reduce hardware and software costs and to make informed decisions about their need for hardware and software by providing them with visibility of all IT assets.

 

TechExcel AssetWise features integration with Microsoft SMS or LANDesk through TechExcel AssetWise LinkPlus. AssetWise-SMS integration enables business to map assets with AssetWise asset templates, automatically synchronize autodetected assets, and to assign and manage ownership of assets by customers in TechExcel CustomerWise projects.

 

TechExcel AssetWise IT auditing and inventory management solutions provide asset managers view to their entire network— from personal computers and servers, to network printers and switches, to personally-owned gadgets like PDAs, USB sticks, and MP3 players.

 

1.7.3 AssetWise Discovery

 

TechExcel AssetWise enables support organizations to integrate their AssetWise asset management system with AssetWise Discovery, map autodetected assets to AssetWise asset templates, and to schedule the automatic synchronization of asset data.

 

AssetWise-AssetWise Discovery integration provides support teams with greater control and flexibility to effectively manage their assets:

 

• Automatic transfer of autodetected assets in TechExcel AssetWise using an NT service.

 

• Support for integrated AssetWise Discovery asset operations within the TechExcel AssetWise client, HelpDesk Windows client, or CustomerWise client.

 

• Management and tracking of asset detection operations as events in TechExcel AssetWise, HelpDesk, and CustomerWise projects.

 

• Linking of autodetected IT assets to customer or customers and management of those assets in the TechExcel AssetWise, HelpDesk, and CustomerWise Windows clients.

 

• Enhanced asset management reports

 

AssetWise Discovery makes critical IT audit metrics available to key stakeholders throughout the company.

 

1.8 Professional Services Management

 

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.

1.8.1 Service Agreement Management

 

CustomerWise service agreement support is an optional CustomerWise feature that enables project members to define service level agreement settings for managing and tracking the different levels of support services that may be offered to the customers supported by a CustomerWise project.

 

Support organizations may define many different levels of service based on customer account types, incident types, and the company assets supported.

 

• Analyze incident and problem records and service level accomplishments

• Identify unacceptable service levels and unreasonable service promises

• Improve customer understanding and satisfaction

• Define multiple service levels based on user defined variables

 

Using the CustomerWise Service Agreement Manager, support organizations may define service level targets and analyze service achievements and shortcomings.

 

• The support schedule defines the dates, days, and hours during which support services are contracted to the customer.

 

• The response time defines the time in which a incident submitted by an customer must be responded to by the support team.

 

• The resolve time defines the time in which an incident submitted by an customer must be resolved by the support team.

 

Service teams may continually improve the quality of their services and increase customer satisfaction using the service level monitoring, escalation, and notification features provided.

 

Support teams may define guaranteed response times for each service plan and define rules for automatically escalating the incident if the response time is exceeded.

 

1.8.2 Professional Services Management

 

TechExcel HelpDesk provides complete functionality for professional service tracking. It can be used to track the time and cost in professional services, and to control service budget. Different prices can be pre-defined for different people and different work types. When the service time is entered or auto calculated, the cost will also be auto calculated. Invoices can be generated easily for billing customers on services.

 

The system pages displayed in the Time/Service Management folder enable project administrators to define time tracking and professional service management features in CustomerWise projects. Time and service management features fall into two categories: standard time and service management features and advanced time and service management features

 

1.9 CustomerWise Add-On Modules

 

CustomerWise 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, customer, and knowledge management tasks in CustomerWise 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.

 

1.9.1 TechExcel LinkPlus

 

LinkPlus enables businesses to write and retrieve customer incident, and event data to and from TechExcel CustomerWise projects, synchronize data between these TechExcel applications and third-party business applications, and integrate either application with third-party business solutions.

 

Using the Microsoft NET Framework as a foundation, CustomerWise LinkPlus provides businesses with the ability to integrate their CustomerWise support projects with third-party business applications to better manage their customer and incident data.

 

TechExcel LinkPlus enables bidirectional data synchronization between TechExcel CustomerWise and third-party applications and database servers.

 

• LinkPlus enables businesses to develop integrated custom applications that extend the power of TechExcel customer incident, and event management to third-party applications.

 

• LinkPlus enables businesses to integrate their TechExcel CustomerWise projects with third-party business software. Organizations that have an existing customer management system or other business software may use LinkPlus to integrate that solution with TechExcel CustomerWise.

 

1.9.2 TechExcel FormWise

 

FormWise enables paperless form creation and management with workflow support. It is seamlessly integrated with the CustomerWise applications and web servers.

 

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

 

• Web clicks enable project teams to record Customer Web Portal activity so that they may track customer interest in products and services.

 

• Web points enable project teams to assign points to pages, links, or the answers given to form questions to gauge customer interest.

 

• FormWise forms enable project teams to gather customer data with user-defined form questions and form templates.

 

• Customer profile questions enable project teams to link form questions to customer data that is managed in CustomerWise projects.

 

1.9.3 CustomerWise Wireless

 

CustomerWise Wireless Web enables support engineers, field service technicians, and customers to access and manage support incidents using handheld devices such as personal digital assistants.

 

CustomerWise supports the Palm OS and Windows Mobile operating systems and features:

 

•E-mail event improvement:Project members may read the body of e-mail messages in the CustomerWise Wireless Web interface.

 

•Transition-based workflow support:CustomerWise Wireless Web now supports transition-based workflow actions.

 

1.9.4 TechExcel DownloadPlus

 

CustomerWise Wireless Web enables support engineers, field service technicians, and customers to access and manage support incidents using handheld devices such as personal digital assistants.

 

CustomerWise supports the Palm OS and Windows Mobile operating systems and features:

 

•E-mail event improvement:Project members may read the body of e-mail messages in the CustomerWise Wireless Web interface.

 

•Transition-based workflow support:CustomerWise Wireless Web now supports transition-based workflow actions.

 

 Chapter 2 System-Level Project Administration

2.1 Understanding System-Level Administration

CustomerWise administration is managed at two levels: the system level and the project level. System-level administrative tasks include the creation of CustomerWise base and work projects, the creation and management of CustomerWise user accounts and licenses, and the administration of CustomerWise 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 CustomerWise 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 CustomerWise applications and modules, the configuration of the CustomerWise E-mail Server, CustomerWise Document Server, and TechExcel Search Engine, and all integration configurations.

All system level administrative tasks are managed by a system administrator—a licensed CustomerWise 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 CustomerWise site.

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

Note:CustomerWise Admin is delivered with a default system administrator defined—User Name: Admin, Password: (blank). The user name is not case-sensitive. TechExcel recommends that administrators change the default login name and password as soon as possible for security reasons.

2.2 Administering CustomerWise Projects at the System Level

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

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

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

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

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

2.2.1 Creating ServiceWise Base Projects

A base project is 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 See “Copying ServiceWise Project Settings” .

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.

2.2.2 Creating New 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.

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.

2.2.3 Copying ServiceWise Project Settings

System administrators may use the New Project dialog box to create new ServiceWise projects based on previously-defined ServiceWise projects. System administrators may import settings when creating new base projects or work projects.

The Copy Settings from an Existing Project command enables administrators to import project properties into the new project. Copying ServiceWise project settings cuts down the time required to configure a ServiceWise project if the different projects share similar information.

The project settings that the administrator may import into the new project depend on the project type.

For work projects administrators may import any of the following settings:

• Project members, groups, and group folders

• Workflow settings

• Timetrack settings

• Search Queries and E-mail Queries

• Auto Routing settings

• Knowledge view settings

• E-mail integration settings

• Incident Notification settings

• Auto Escalation settings

• Auto Assign settings

• Service Agreement settings

• Event Management settings

For base projects administrators may import any of the following settings:

• Project members, groups, and group folders

• Workflow settings

• Timetrack settings

• Search Queries and E-mail Queries

• Auto Routing settings • Knowledge View settings

• E-mail integration settings • Incident Notification settings

• Auto Escalation settings

• Auto Assign settings

• Service Agreement settings

Event management settingsmay notbe imported for base projects.

To create ServiceWise projects based on existing projects:

1Select the New Project command in the File menu.

The New Project dialog box appears.

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

The New Project dialog box appears.

3Define project settings.

• Project name

• Project type

• Base project (for work projects only)

4Select the Copy Settings from an Existing Project check box and click the OK button.

A list of all existing projects is displayed in the Project list.

5Select a project in the Project list.

6Click the OK button.

The Copy Project Settings dialog box appears.

7Select the project settings options to be imported and click the OK button.

The new project opens.

2.2.4 Understanding Active and Inactive Projects

Every ServiceWise project has either an active or inactive status. The status of a project determines the tasks that an administrator may perform on that project.

System administrators define the status of a project by selecting the Active Project check box in the Project Properties page of the General Project Settings folder of the ServiceWise Admin client. All project status settings are defined on a project-by-project basis in the appropriate project view.

2.2.5 Active projects

System administrators may perform the following tasks in active ServiceWise projects:

• System administrators may open active projects in ServiceWise Admin and configure project settings.

• System administrators may use the Support Member Manager to add user accounts as project members to active projects.

• System administrators may import project properties from active projects.

2.2.6 Inactive projects

Inactive ServiceWise projects may be deleted using the Delete Project command in the File menu. Active projects cannot be deleted.

2.2.7 Backing Up ServiceWise Projects

System administrators may use the Backup Project command and the Back Up Project dialog box to back up individual ServiceWise projects or the entire ServiceWise database.

ServiceWise stores backups of ServiceWise projects in a proprietary SWS file format. Once the administrator define the project information, the administrator may back up either the entire database or only selected projects. ServiceWise Admin creates the backup file with the selected project data.

ServiceWise Admin stores backed up projects in a proprietary SWS file format.

Note:ServiceWise backup feature is a good way to save project properties, but cannot be considered a substitute for regular database server backups.

To back up ServiceWise projects:

1Invoke the Back Up Project command.

• Select the Back Up Project command in the File menu.

• Press CTRL + B. The Back Up Project dialog box appears.

2Click the Ellipsis button to navigate to the location of the backup file.

The Backup dialog box opens.

3Navigate to the location of the backup files.

4Enter a name for the SWS file in the File Name field.

5Select the ServiceWise Backup File SWS option in the Save as Type dropdown list.

6Click the Save button.

The Backup dialog box closes.

7Select a back up option:

• Click the Settings Only option to back up project settings.

• Click the Settings and Data option to back up project settings and project data.8Select an option in the Projects Selected area:

• To back up all projects, select the All Projects radio button.

• To back up selected projects, select the Selected Projects radio button and click the applicable projects in the Project Name to Select/Deselect list.

9Click the OK button.

The project is backed up.

2.2.8 Restoring Backed Up Projects

System administrators may use the Restore Project command to restore backed up projects and backed up databases. When restoring backed up ServiceWise projects administrators may overwrite existing projects or create new projects based on the backed up projects.

Note:Restoring a project may take several minutes to a few hours, depending on size of the project.

ServiceWise stores backups of ServiceWise projects and databases in a proprietary SWS file format. System administrators may back up selected projects or the entire database using the Back Up command in the File menu. The Restore Project command enables administrators to restore projects or databases from SWS files.

The Restore Manager enables administrators to choose which projects are restored from a SWS file, what is restored (data, settings, or data and settings), and the method used to restore projects.

Figure 2-1: Restore Manager

The options available to administrators in the Restore manager depend on whether they are attempting to restore individual projects or an entire database.

System administrators may choose one of three restoration options:

• The Both Settings and Data option

• The Settings Only option

• The Data Only option

The restoration option selected is applied to all projects backed up in the SWS file.

Note:Restoring project data may delete the existing data in the current database. The Restore data operation should only be used to recover a damaged database or to move project data to another server computer.

System administrators may select a different restoration method for each project to be restored.

• Skip, do not restore this project

• Restore to the same project, overwrite records

• Restore project, do not overwrite records

Alternatively, administrators may create new projects based on a backed up project.

To restore ServiceWise projects:

1Invoke the Restore command.

• Select the Restore command in the File menu.

• Press CTRL + R.

2Locate the backed up project and click the Open button.

ServiceWise stores backups of ServiceWise projects in a proprietary SWS file format.

The Restore Project manager appears.

3Select an option in the Restore Options area.

System administrators may choose one of three restoration options:

• Both Settings and Data

• Settings Only

• Data Only

4To restore system settings, select the Restore System Settings check box.

5Select a project in the Projects to Restore list.

6Select an option in the Restore Method area.

System administrators may select a different restoration method for each project.

• Skip, do not restore this project

• Restore to the same project, overwrite records

• Restore project, do not overwrite records

7Apply the restore method to one or more projects:

• To apply the restore method to a single project, select the Apply button. The restore method for the selected project in the Projects to Restore list is updated.

• To apply the restore method to projects displayed in the Projects to Restore list, select the Apply All button.

8Click the OK button.

The project is restored.

2.2.9 Creating Projects Based from Backed Up Projects

System administrators may use the Restore command to create new ServiceWise projects from backed up copies of existing projects. TechExcel ServiceWise automatically assigns the project a new project ID number.

Whenever an administrator backs up a ServiceWise project, ServiceWise saves a copy of that project in a proprietary SWS file format. System administrators may create a new ServiceWise project from SWS files.

To create a new project from a backed up project:

1Invoke the Restore command.

• Select the Restore command in the File menu.

• Press CTRL + R.

2Locate the backed up project and click the Open button.

ServiceWise stores backups of ServiceWise projects in a proprietary SWS file format. The Restore Project manager appears.

3Select an option in the Restore Options area.

System administrators may choose one of three restoration options:

• Both Settings and Data

• Settings Only

• Data Only

4To restore system settings, select the Restore System Settings check box.

5Select a project in the Projects to Restore list.

6Select the Restore to a New Project option in the Restore Method area.

7Define the name of the new project in the New Project Name text field.

8Apply the restore method to one or more projects:

• To apply the restore method to a single project, select the Apply button. The restore method for the selected project in the Projects to Restore list is updated.

• To apply the restore method to projects displayed in the Projects to Restore list, select the Apply All button.

9Click the OK button.

The new project is created.

2.2.10 Deleting ServiceWise Projects

System administrators may use the Delete command to deleteinactiveServiceWise projects.

System administrators may only delete projects that have an inactive status. For instructions on making a project inactive see See “Understanding Active and Inactive Projects” on page 25.

Note:Deleting a project from the system is permanent. System administrators must perform all appropriate back ups before deleting a project.

To delete a project:

1 Select the Delete command from the File menu.

The Delete Project dialog box appears.

The Delete Project dialog box displays all of the projects that may be deleted. Only those projects that have an inactive status may be deleted.

2 Select a project.

Click the Delete button.

2.3 Managing Solution Templates

A base project is 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 See “Copying ServiceWise Project Settings” .

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.

2.3.1 Installing Solution Templates

Each solution template includes both a configuration file and a solution template configuration document. Loading the configuration file loads the pre-configuration that most closely matches the business needs of different industries.

Note:Restoring solution template configuration files overwrite the existing database. To save existing data, back up all data prior to restoring the solution template.

The installation process places a heavy load on the database, which may in turn significantly slow down the application. TechExcel recommend that administrators log off all the users while installing solution templates.

To install solution templates:

1Select the Install Solution Template command in the File menu.

The Install Solution Template File wizard appears. Once selected, TechExcel ServiceWise will automatically load the selected solutions project data in that file.

2Locate the solution template on the local machine or network.

Solution Template configuration files are stored in a proprietary SLT format.

3Click the Next button.

4The File Information page appears.

The File Information page describes the solution template to be installed.

5Click the Next button.

The Confirmation page appears.

The Confirmation page enables administrators to run a full analysis to compare the contents of this solution template with the data in the current system.

6Compare current data with that contained in the solution template.

• To run the comparision, click the Next button.

• To skip the comparision, select the Skip Comparision check box and click the Next button.

The Analyzing page appears.

7Click the Start button.

2.3.2 Viewing Solution Template Notes

Solution templates can be very beneficial to both the evaluation and deployment of TechExcel ServiceWise. System administrators may learn more about solution templates and determine which template makes sense for their company in the solution template notes.

To view the solution template notes, select the Show Solution Template Notes command in the File menu.

2.3.3 Updating the Solution Template Configuration Document

Thesolution template configuration documentdescribes the business processes included in the configuration file. System administrators may use the configuration document as the blueprint for defining business processes and provides a documented view of ServiceWise solutions.

Updating solution template configuration document to include all significant changes made to the system ensures that the business process document is always be up to date.

2.4 Running the Go Live Wizard

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.

 Chapter 3 System-Level User Administration

3.1 Administering User Accounts at the System Level

In TechExcel CustomerWise user administrative responsibilities are split between the system administrator (who administrates the entire CustomerWise 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 CustomerWise 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 CustomerWise 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 e-mail addresses.

• Each user account is identified by a unique user name and password which enable the user to work in the CustomerWise 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.

3.1.1 Understanding the Support Member Manager

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 CustomerWise implementation and controls that enable system administrators to manage user accounts:

Figure 3-1: Support Member Manager

Colored icons clearly identify CustomerWise 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.

3.1.2 Support Member Manager controls

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 status: all users, active users, or inactive users.

• The Invite Selected Users to Install Client button enables administrator to e-mail a link to the CustomerWise 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 Profile button enables administrators to view and edit the user profile for user accounts.

• 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.

3.1.3 Creating and Editing User Accounts

System administrators may use the New button the Support Member Manager to create new CustomerWise 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 CustomerWise work projects.

The Member Information page enables system administrators to define the user account properties for new and existing CustomerWise 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, e-mail, and status in the CustomerWise 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 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 See “Managing User Licenses”.

5Define contact information in the Advanced Settings tab.

For detailed instructions see 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 “Creating System Team Groups”.

6Define licensing and system administrative privileges in the License/Privilege tab. For detailed instructions see “Defining User Administrative Access Controls” and See “Managing User Licenses”.

7Define contact information in the Advanced Settings tab.

8Click the OK button.

3.1.4 Defining General User Data

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

The General tab displays basic user account properties including their name, e-mail, and status in the CustomerWise implementation. The basic user account properties displayed in the Basic tab include:

Table 3-1: User Account Properties

3.1.5 Defining User Administrative Access Controls

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

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

• TheIs a Project Administrator optionenables the user to perform system administrative tasks. A project administrator has TechExcel CustomerWise 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 CustomerWise client.

3.1.6 Deleting User Accounts

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

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

To delete a user account:

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

System administrators may only delete inactive user accounts.

2Click the Delete button.

The warning dialog box appears.

3Click the OK button.

3.1.7 Defining User Profiles

System administrators may use the User Profile page in the Support Member Manager to define a user profile for an account type within a CustomerWise project.

The User Profile page of the Support Member Manager enables the administrator to assign an account type, team group membership, and workflow rules for a user account in one place.

The User Profile page consists of three tabs. Each tab in the User Profile page enables the administrator to define a different aspect of the user profile for a user account.

To assign an account type:

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

2Click the Profile button.

The User Profile page appears.

3Select the Account Type tab.

4Select a project in the Project list.

5 Optional:To make the user account a project member select the Is a Project Member check box.

6 Optional:To assign an account type select an option from the Account Type dropdown list.

To define team group membership:

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

2Click the Profile button.

The User Profile page appears.

3Select the Group Member tab.

4Select one or more project members in the Group list.

The project member is added to a project members if a black check mark appears in the check box next to the project members name.

To define workflow ownership rules:

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

2Click the Profile button.

The User Profile page appears.

3Select the Workflow tab.

4Select workflow states in theWorkflowStatelist.

The project member may be an applicable owner of an incident in each workflow state if a black check mark appears in the check box next to the name of the workflow state.

3.1.8 E-mailing the CustomerWise Installer to Project Members

System administrators may use the E-mail the Selected Users for Client Installation button to e-mail a link to the CustomerWise client installation program.

Once the administrator has defined all user accounts and defined project membership, the administrator may use this command to send the CustomerWise installation program available to future CustomerWise project members.

To e-mail the client installation program:

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

The Support Member Manager window appears.

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

3Click the E-mail the Selected Users for Client Installation button.

The e-mail client appears. The e-mail is automatically addressed to the selected user account.

3.1.9 Managing User Licenses

System administrators may define a user licensing settings whenever they create or edit a user account in the Support Member Manager. System administrators may assign different types of licenses user account.

The License/Privilege tab displays controls that enable administrators to assign licenses to user accounts.

Figure 3-3: License/Privilege Tab in the Member Information Manager

System administrators may assign one of two different classes of licenses to each CustomerWise user account. Alternatively, administrators may choose not to assign a license to a user account.

• The No License (Inactive User) option defines the user account as inactive. Inactive users cannot log into CustomerWise projects.

• The Fixed License option assigns a fixed license to a user account. A fixed license enables a project member to log into any project in a site family.

• The Floating License option enables a user account to use a floating license to access projects in a CustomerWise site. Floating licenses are not assigned to any one user, but are assigned to a particular CustomerWise site. Floating licenses regulate the number of users who may be logged into a CustomerWise site at one time. A single floating license may be assigned to three different users, but only one of those users may log into CustomerWise at any one time.

System administrators may also assign a license type to each CustomerWise user account.

• The Support License option enables project members to perform all activities in a project granted to them by the project administrator based on their account type.

• The Light License option restrict the ability of project members to perform certain actions in CustomerWise projects. Light licenses enable users to log into CustomerWise projects through the Employee Web Portal. For more information on privileges available users holding a light license see “Understanding Light License Access Controls”.

3.2 Defining Team Member Contact Information

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 CustomerWise implementation and controls that enable system administrators to manage user accounts:

Figure 3-1: Support Member Manager

Colored icons clearly identify CustomerWise 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.

3.2.1 Defining User Autologin Settings

The Auto Login Name represents the domain user name used for TechExcel CustomerWise Web if NT authentication is enabled.

System administrators may define the login name here, or allow the Web server to automatically populate the login name.

TechExcel CustomerWise Web automatically links the NT domain user account with the User ID if this feature is enabled.

3.2.2 Defining User Pager Service Information

System administrators may define user pager service information in the Advanced tab of the Support Member Manager.

Controls in the Pager Service area of the Advanced tab enable administrators to manage user pager information including their provider, type, and e-mail address.The secondary e-mail address may also be specified for paging purposes.

A drop down menu enables the administrator to specify if the pager is numeric or alpha numeric (text).

This information can be used for notifications.

3.2.3 Defining User Mobile Service Information

System administrators may define user mobile phone information in the Advanced tab of the Support Member Manager.

This information can be used for notifications.

3.2.4 Defining User Account E-mail Signatures

An signature is a brief message that is automatically added to the bottom of e-mail messages sent from a CustomerWise project. Signatures frequently display the name, job title, phone number, and other contact information of the e-mail sender. Signatures may also be used to add boilerplate paragraphs to all outgoing e-mail messages.

Administrator-defined user account signatures are unique signatures that are appended to all e-mail sent from a particular user account in a CustomerWise site.

In CustomerWise, signatures may be defined at two other levels besides the user account level.

• Manual e-mail template signatures are signatures that are appended to e-mail messages manually sent by project members from within the CustomerWise client. System administrators may define three different e-mail templates: the Incident E-mail template, the Resend E-mail template, and the Reply E-mail template. Each e-mail template may have a unique signature.

• Notification e-mail template signatures are signatures that are appended to e-mail messages that are automatically sent from a CustomerWise project based on administrator-defined e-mail notification rules.

The signature displayed in an outgoing e-mail depends on administrator-defined e-mail notification configurations.

To enable and define CustomerWise user account signatures:

1 Select the Team Member E-mail Address Assigned to the Team Member option in the Default Reply E-mail Address dropdown list of the General Settings tab of the E-mail Integration page.

The administrator-defined e-mail signature overwrites both manual template signatures and notification e-mail templates only if this option is selected. If this option is not selected, the administrator-defined user account signatures are ignored.

2Double-click a user account in the Support Member manager.

The Member Information manager appears.

3Enter the text of the signature in the E-mail Signature control of the Advanced tab in the Member Information manager.

4 Click the OK button.

3.3 Importing and Exporting User Accounts

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 status: all users, active users, or inactive users.

• The Invite Selected Users to Install Client button enables administrator to e-mail a link to the CustomerWise 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 Profile button enables administrators to view and edit the user profile for user accounts.

• 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.

3.3.1 Importing User Accounts from Structured Text Files

Structured text breaks data into distinct rows and columns using field delimiters and text qualifiers.

• The field delimiter defines the beginning and end of each field imported. System administrators may between five different delimiters: The pipe character (|) usually gets the best results.

• Text qualifiers define the beginning and end of text within fields and indicate that the Import Wizard should interpret the text exactly as it appears in the structured text file. Text qualifiers should be used if the text contains spaces or characters that might be read as field delimiters. Any character may be used as a text qualifier, but the default text qualifier is the double quotation mark (“).

The Import wizard enables system administrators to quickly create multiple user accounts.

To import user account attributes:

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

The Support Member Manager window appears.

2Click the Import button.

The Select a User Import Source dialog box appears.

3Select the Import from an External File option.

The File and Format dialog box appears.

4Inthe User Information field locate the file that contains the data that may be imported.

5Select a field delimiter from the Field Delimiter dropdown list.

The fields delimiter defines the beginning and end of each field that an administrator may import. System administrators may choose from five different delimiters: # , ; {tab} |

6Enter a text delimiter in the Text Delimiter field.

7 Optional:To exclude Field names from the first row, select the Field names on the first row check box.

8Select the Next button.

The Mapping User Fields dialog box appears.

9For each field displayed in the User Field column select an option from the appropriate Column in File dropdown list.

10Click the Next button.

The Import page appears.

11Select all appropriate options in the Import dialog box.

• To overwrite duplicate records, select the Overwrite check box.

• To keep a record of all records in the text file that are not loaded into the database check the Log failed or skipped records check box. System administrators may define where CustomerWise saves the test file by selecting the Browse button.

12Click the Finish button.

3.3.2 Importing User Accounts from a LDAP Server

CustomerWise-LDAP integration enables administrators to manage user data (user names, phone numbers, and so on) in a directory server instead of their CustomerWise sites.

System administrators may import user account attributes from an integrated LDAP server into a CustomerWise base project using the LDAP Import wizard.

3-2: Select Support Members Wizard

The LDAP Import wizard enables administrators to quickly create or update project user accounts by importing data from an integrated LDAP server. While importing user data, the administrator may also assign a license to the user.

Note:System administrators that plan to use CustomerWise to authenticate user logins into the CustomerWise clients must redefine the passwords of user accounts imported from an LDAP directory server. LDAP passwords are encrypted and cannot be imported into CustomerWise base projects from LDAP directory servers.

System administrators must define integration settings between a CustomerWise site and an LDAP servers in the LDAP Server List, LDAP Authentication, and LDAP Sync Settings pages of the LDAP Integration folder before user accounts may be imported from an LDAP server. For more information see See “Administering LDAP Integration”.

To import user account attributes:

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

The Support Member Manager appears.

2Click the Import button.

The Select a User Import Source dialog box appears.

3Select the Import from LDAP option.

The Select Support Members wizard appears.

4Select an LDAP Server from the LDAP Server dropdown list.

CustomerWise must be integrated with an LDAP server, otherwise no options are displayed in the LDAP Server dropdown list. The system administrator may configure CustomerWise integration with multiple LDAP servers using the LDAP Information Setting manager. For more information see See “Administering LDAP Integration”.

5 Optional: To search for user accounts based on the first name of the user, enter a query string in the First Name control.

To filter user accounts based the first name of the user, the appropriate LDAP attribute must be mapped to the CustomerWise First Name field. For example, the CustomerWise First Name field may be mapped to the LDAP givenName attribute. For more information see See “Defining Project Member Matching Identifiers”.

System administrator may use the asterisk * wild card character to search for text strings in the First Name control. For more information on LDAP user account attribute searches see See “Filtering User Accounts in the LDAP Import Wizard”.

6 Optional: To search for user accounts based on the last name of the user, enter a query string in the Last Name control.

To search for user accounts based on the last name of the user, the appropriate LDAP attribute must be mapped to the CustomerWise Last Name field. For example, the Last Name field may be mapped to the sn attribute.For more information see See “Defining Project Member Matching Identifiers”.

System administrator may use the asterisk * wild card character to search for text strings in the Last Name control. For more information on LDAP user account attribute searches see See “Filtering User Accounts in the LDAP Import Wizard”.

7 Optional: To search for user accounts based on any LDAP user account attribute, enter a query string in the Search Filter control.

The query string entered in the Search Filter must identify both theattributeand theattribute value. For example, the query sn=smith returns all LDAP user accounts with the last name “Smith”.

System administrators may define complex queries using four logical operators in the Search Filter control: The asterisk wildcard character, the ampersand & AND operator, the pipe | OR operator, and the exclamation point! NOT operator. For more information on LDAP user account attribute searches see “Filtering User Accounts in the LDAP Import Wizard”.

8Click the Search button.

Data matching the search parameter defined is displayed in the LDAP Users list.

9Add or remove users to the Selected Users list.

• Click the Add button to move users from the LDAP Users list to the Selected Users list.

• Click the Remove button to move users from the Selected Users list list to the LDAP Users list.

10Click the Next button.

The Select Users to be Overwritten page appears.

11 Optional:To overwrite properties of existing user accounts with their mapped LDAP attributes, select one or more user accounts.

Any LDAP user accounts that match existing CustomerWise user accounts based on administrator-defined matching identifiers is displayed in the Select Users to be Overwritten page. For more information see “Defining Project Member Matching Identifiers”.

12Click the Next button.

The License Assignment page appears.

13Select one or more user accounts in the User list and click the Assign License button.

The Select a License Type dialog box appears.

14Assign appropriate licenses to the user.

15Click the OK button.

The Select a License Type dialog box closes.

16Click the Finish button.

The user accounts are imported into the CustomerWise base project.

3.3.3 Filtering User Accounts in the LDAP Import Wizard

The LDAP Import wizard enables system administrators to search for and import LDAP user accounts from a directory server and into the base project of a CustomerWise site.

System administrators may filter the user accounts displayed in the LDAP Users list by defining search criteria based on LDAP user account attributes. in the First Name control, Last Name control, and Search Filter control in the LDAP Import wizard

• The First Name and Last Name controls enable administrators to define simple queries based on the name of the user. To search for LDAP user accounts by name, the appropriate LDAP user account attributes must be mapped to the CustomerWise First Name and Last Name fields. For more information see “Defining Project Member Matching Identifiers” .

• The Search Filter control enables administrators to define complex queries based on any user account LDAP attribute.

System administrators may define complex search criteria in the Search Filter control based on user account attributes. System administrators may use four characters to define user account search parameters:

• The asterisk * character represents the wildcard character and may be used to search for text strings in the First Name, Last Name, and Search Filter controls.

• The ampersand & character represents the AND operator and may be used to define complex queries in the Search Filter control.

• The pipe | character represents the OR operator and may be used to define complex queries in the Search Filter control.

• The exclamation point! character represents the NOT operator and may be used to define complex queries in the Search Filter control.

3.3.4 Wildcard character

The asterisk (*) character may be used to represent any number of characters in a search string.

To search for all user accounts that have a last name (surname) that begins with the letterA, enter the query string sn=a* in the Search Filter control.

3.3.5 AND operator

The ampersand (&) character represents the AND operator and may be used to search for user accounts based on multiple criteria. The AND operator may establish a relationship between two attribute-attribute value pairs.

To search for user accounts that have a organization attribute value of ABCSoftware and a country attribute value of USA, enter the query string (&(o=ABCSoftware) (co=usa)) in the Search Filter control.

The query string returns only those LDAP user accounts that match both organization attribute and the country attribute criteria.

3.3.6 OR operator

The pipe (|) character represents the OR operator and may be used to search for user accounts based on multiple criteria. Unlike the AND operator which returns that both criteria are met, a user account that matches either of the criteria in an OR query string is returned.

To search for user accounts that have a organization attribute value ofABCSoftwareor a country attribute value ofUSA, enter the query string (|(o=ABCSoftware)(co=usa) in the Search Filter control.

The query string returns all LDAP user accounts that match either of these criteria. All users in theUnited Statesor users working for ABCSoftware regardless of their country.

3.3.7 NOT operator

The exclamation point (!) character represents the NOT operator and may be used to filter out user accounts based on user account attributes or attribute values.

To search for all user accounts that do not have a StreetAddress attribute, enter the query string(!(STREE=*)) in the Search Filter control.

3.4 Administering System Team Groups

System administrators may use the New button the Support Member Manager to create new CustomerWise 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 CustomerWise work projects.

The Member Information page enables system administrators to define the user account properties for new and existing CustomerWise 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, e-mail, and status in the CustomerWise 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 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 See “Managing User Licenses”.

5Define contact information in the Advanced Settings tab.

For detailed instructions see 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 “Creating System Team Groups”.

6Define licensing and system administrative privileges in the License/Privilege tab. For detailed instructions see “Defining User Administrative Access Controls” and See “Managing User Licenses”.

7Define contact information in the Advanced Settings tab.

8Click the OK button.

3.4.1 Creating System Team Groups

System administrators may create new system team groups whenever they create or edit a user account. The System Team Group manager enables administrators to define addresses for each system team group.

System team groups are defined at the system-level. System team group definitions apply to every work project in a CustomerWise site.

To create a system team group:

1Open the Support Member Manager.

• Select the Support Member Manager command in the Tool menu.

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

The Support Member Manager appears.

2Open the Member Information page.

• To create a new user account and assign that account to a system team group, click the New button.

• To edit an existing user account and assign that account to a system team group, select the user account in the User List window and click the Edit button.

The Member Information page appears.

3Click the New button.

The System Team Group manager appears.

4Define basic information in the Info tab.

5Click the OK button.

6 Optional:To edit or delete a System Team Group, click the Edit or Delete buttons.

3.4.2 Assigning Users System Team Groups

System administrators may assign a user account to one or more system team groups whenever they create or edit a user account in the General tab of the Member Information page.

To assign a user to a system team group:

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

The Support Member Manager appears.

2Open the Member Information page.

• To create a new user account and assign that account to a system team group, click the New button.

• To edit an existing user account and assign that account to a system team group, select the user account in the User List window and click the Edit button.

The Member Information page appears.

3Select one or more system team groups in the Member of System Team Group list.

System team groups are project-independent and a user account may belong to one or more system team groups.

4Select an option from the Primary Group dropdown list.

The option selected represents the default address assigned to the user account.

5Select an option from the Time Zone dropdown list.

The option selected represents the default time zone assigned to the user account.

3.5 Administering User Logins

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

The General tab displays basic user account properties including their name, e-mail, and status in the CustomerWise implementation. The basic user account properties displayed in the Basic tab include:

Table 3-1: User Account Properties

3.6 Administering User Licensing

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

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

• TheIs a Project Administrator optionenables the user to perform system administrative tasks. A project administrator has TechExcel CustomerWise 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 CustomerWise client.

3.6.1 Loading CustomerWise Licenses

System administrators may update product licenses, view a list applications, modules, and services covered by the current license, and view the availability oflicense classesin the License Manager.

Figure 3-6: License Manager

The License Manager enables administrators to manage every user seat in a CustomerWise implementation. The License Manager is divided into four areas:

• The Runtime ID control enables the administrator to load CustomerWise licenses.

• The Product Type area displays a list of the CustomerWise applications, modules, and services that are covered by the current license.

• The License area displays the license type and edition purchased.

• The License Type area displays the number of licenses purchased and used of each license type.

To load licenses:

1Select the License Manager page in the Admin Tree window of the System Settings project.

2The License Manager is only accessible in the System Settings project.

The License Manager appears.

3Click the Update button.

The Open dialog box appears.

4Locate the license file on the local directory.

5 Click the Open button.

3.7 Managing Administrator Account Types and Access Controls

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

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

To delete a user account:

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

System administrators may only delete inactive user accounts.

2Click the Delete button.

The warning dialog box appears.

3Click the OK button.

3.7.1 Creating System Administrator Account Types

A system administrator account type enables a licensed user account to perform system-level administrative tasks in a CustomerWise site.

CustomerWise uses system administrator account types to manage site security and control. Every administrator-defined system administrator account type represents a unique set of access controls that enable users assigned that account type to perform administrative tasks.

A system administrator account type may represent up to 11 different access controls:

Create ProjectPerformProject Operations

Perform System UpgradeGo Live

Manage LicensesManage Team Members

Administer LoginSet up General System Settings

Administer Document Server SettingsAdminister Web Server Settings

Setup Web GUI Standard

For more information about system administrator access controls see “Understanding System Administrator Access Controls” .

All administrator account types are defined by a system administrator in the Administration Account Types folder of the System Settings project.

Project members may be granted system administrator account types in the License/ Privilege tab of the Support Member manager. For more information See “Defining User Administrative Access Controls”.

To create system administrator account type:

1Select the System Admin Account Type page in the Admin Tree window of the System Settings project.

2Click the New button.

3Define the name of the account type.

4Click the OK button.

5Define system-level administrative privileges for the account type.

3.7.2 Understanding System Administrator Access Controls

A system administrator account type enables a licensed user account to perform system-level administrative tasks in a CustomerWise site.

CustomerWise uses system administrator account types to manage site security and control. Every administrator-defined system administrator account type represents a unique set of access controls that enable users assigned that account type to perform administrative tasks.

A system administrator account type may represent up to 11 different access controls:

Create ProjectPerformProject Operations

Perform System UpgradeGo Live

Manage LicensesManage Team Members

Administer LoginSet up General System Settings

Administer Document Server SettingsAdminister Web Server Settings

Setup Web GUI Standard

For more information about system administrator access controls see “Understanding System Administrator Access Controls” .

All administrator account types are defined by a system administrator in the Administration Account Types folder of the System Settings project.

Project members may be granted system administrator account types in the License/ Privilege tab of the Support Member manager. For more information See “Defining User Administrative Access Controls”.

To create system administrator account type:

1Select the System Admin Account Type page in the Admin Tree window of the System Settings project.

2Click the New button.

3Define the name of the account type.

4Click the OK button.

5Define system-level administrative privileges for the account type.

 Chapter 4 System-Level Tool Administration

4.1 Administering the CustomerWise Document Server

The CustomerWise Document Server enables 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, e-mail attachments, and knowledge documents.

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

The CustomerWise Document Server talks to the CustomerWise Application Server and the CustomerWise Web Server through a TCP/IP connection. Administratordefined CustomerWise Document Server settings apply to every project in the CustomerWise site.

4.1.1 Configuring the CustomerWise Document Server

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

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

TechExcel recommends configuring the TechExcel CustomerWise Document Server using TCP/IP settings.

System administrators must define CustomerWise 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 CustomerWise 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 CustomerWise 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 CustomerWise Document Server. The default port number is 8118.

6 Optional: To test the connection to the CustomerWise 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.

4.1.2 Viewing the 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 CustomerWise 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 CustomerWise Admin client and the CustomerWise Document Server.

4.1.3 Configuring Web Server Access to the Document Server

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

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

The CustomerWise Web Server may access the CustomerWise 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 CustomerWise Web Server accesses the CustomerWise 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.

4.1.4 Configuring Client Access to the Document Server

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

The CustomerWise Web Server may access the CustomerWise 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 CustomerWise Windows clients accesses the CustomerWise 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.

4.2 Administering E-mail Error Handling

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

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

TechExcel recommends configuring the TechExcel CustomerWise Document Server using TCP/IP settings.

System administrators must define CustomerWise 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 CustomerWise 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 CustomerWise 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 CustomerWise Document Server. The default port number is 8118.

6 Optional: To test the connection to the CustomerWise 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.

4.2.1 Defining General E-mail Error Tracking Settings

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

E-mail trace levels determine the types of messages that are logged when e-mail errors occur. System administrators may choose one of three e-mail trace settings:

• The Info, Warning, and Error trace level

• The Warning and Error trace level

• The Error trace level

E-mail service settings determine the sensitivity of the e-mail notification service. E-mail 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 E-mail Trace Level dropdown list.

3Select an option from the E-mail Service Setting dropdown list.

4.2.2 Creating Log Files

System administrators may enable CustomerWise 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 E-mail 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.

4.2.3 Define E-mail Service Messages

System administrators may enable e-mail notification of service messages and define service message properties using tools in the Mail Notification Service Error Handling Setting manager.

E-mail notification service messages are delivered when e-mail handling error occur with the e-mail notification service.

• The SMTP server name

• Require authentication

• E-mail recipient and sender addresses

• The e-mail log level

• The time interval

To define e-mail service messages:

1Select the E-mail Retrieval page in the Mail Error Handling folder in the System Settings view of the CustomerWise Admin client.

2Select the E-mail Notification of Service Messages check box.

3Define the name of the SMTP server in the SMTP Server Name field.

4 Optional:To require user authentication, select the Require User Authentication check box and enter the user name and password.

5Define the e-mail address for service message recipients in the E-mail Recipients field.

6Define the e-mail address for service message senders in the E-mail Senders field.

7Select an option from the E-mail Log Level dropdown list.

8Select an option from the Time Interval for Sending Log dropdown list.

4.2.4 Defining E-mail Service Error Reports

System administrators may use the E-mail Notification Error Service Handling Setting manager to define e-mail notification error reports.

If an e-mail notification message is not delivered to any selected recipients, the sender automatically receives an error report e-mail and e-mail attachment that explains why the e-mail notification was not delivered.

System administrators can define the recipient, sender, the level of detail, and the time interval of the e-mail service error report e-mail in the E-mail Notification Error Service Handling Setting manager.

To define e-mail error report settings:

1Select the E-mail Retrieval page in the Mail Error Handling folder in the System Settings view of the CustomerWise Admin client.

2In the General Settings area, define the E-mail Trace Level and Mail Service Setting.

3In the Message Log Setting, select the Enable to write mail messages to a log file and name the log file in the Log File Name field.

4Click the Enable e-mail notification service messages check box.

5Define the SMTP Server Name.

6Enter the e-mail address of the error report recipient in the E-mail Recipient Address field.

7Enter the e-mail address of the error report sender in the E-mail Sender Address field.

8Select the scope of the error report by selecting an option from the E-mail Log Level dropdown list.

9Select a time interval for the error report e-mails by selecting an option from the Time Interval for Sending log dropdown list.

10 Select the OK button.

4.3 Administering LinkPlus Integration

The document root directory is a directory where all project documents are stored. The Document root directory is defined during the installation of the CustomerWise 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 CustomerWise Admin client and the CustomerWise Document Server.

4.4 Administering System Messages

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

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

The CustomerWise Web Server may access the CustomerWise 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 CustomerWise Web Server accesses the CustomerWise 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.

4.4.1 Defining System Welcome Messages

System administrators may use the System Message dialog box to define system-wide welcome messages. Welcome messages enable administrators to communicate critical information to CustomerWise users across all projects.

After logging in to the application, TechExcel CustomerWise windows client users are taken to a project selection dialog box, while Web users are taken to a home page displaying all available projects. Administrator may create welcome messages that are displayed on either screen to display a company specific message, or disseminate critical information to all users.

To define welcome messages:

1Select the Project Selection page in the System Message folder in the System Settings view of the CustomerWise Admin client.

The System Message page appears.

2Enter a message in the Message for CustomerWise Web (in HTML) text area.

3Enter a message in the Message for CustomerWise Client (in TEXT) text area.

The format the message using standard HTML markup tags.

4Click the OK button.

4.4.2 Defining System Warning Messages

System administrators may use the System Warning dialog box to define system-wide warning messages. Warning messages enable administrators to communicate critical information to CustomerWise users across all projects.

Organizations may occasionally plan to take their CustomerWise project offline to perform system or database maintenance. System administrators may notify users of the scheduled down time system warning messages.

For each warning message administrators must define a beginning and ending date and time. The warning system message is broadcast to all CustomerWise users in all projects for the duration of the administrator-defined broadcast period.

During the broadcast period the system warning message replaces the welcome message in the project selection page. When the broadcast period is over, the welcome message returns to the page.

Note:Companies may occasionally plan to take the CustomerWise system offline to perform system or database maintenance. System administrators may use warning messages to alert CustomerWise users prior to an upgrade and provide them with the chance to plan their work around the system downtime.

To define system warning messages:

1Select the System Warning page in the System Message folder in the Admin tree window of the System Settings view in the CustomerWise Admin client.

The System Warning page appears.

2Define the warning message.

• Enter a message in the Message for CustomerWise Web (in HTML) text area.

• Enter a message in the Message for CustomerWise Web (in Text) text area.

3Select the Display message at project selection page check box.

4Choose the beginning time and date in the Date/Time From control.

5Choose the ending time and date in the Date/Time To [control].

6To automatically log users off the system, select the Log Off the User from the System check box.

All CustomerWise client users are automatically logged off the CustomerWise system at the time and date defined in this page. CustomerWise users cannot access their CustomerWise projects for the duration of the outage.

7Choose the beginning time and date in the Date/Time From [control].

8Choose the ending time and date in the Date/Time To [control].

9Click the OK button.

4.4.3 Managing User Sessions

An organization may occasionally plan to take the CustomerWise system offline to perform system or database maintenance. CustomerWise enables administrators to communicate and manage CustomerWise client users during an upgrade.

• The Warning System Message Manager enables project administrators to remind project members of the scheduled downtime and automatically log off users at a specified time.

• The Login Manager enables project administrators to view the current status and login history of all DevTest project members and to manually log off CustomerWise client users.

CustomerWise Admin provides system administrators with two methods for managing user sessions:

• Automatically log all users off the system using tools in the Warning System Message Manager.

• Manually log users off the system using the Login Manager

4.5 Administering System Time Zones and Time and Date Formats

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

The CustomerWise Web Server may access the CustomerWise 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 CustomerWise Windows clients accesses the CustomerWise 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.

4.5.1 Defining Date and Time Formats

Project administrators may define system time and date formats using the Time Zone & Date Format Setting control in the Project Properties page.

System date and time format represent the default formats used to display dates and times in a CustomerWise site. System administrators may choose to mandate that all project members and employees use administrator-defined time and date format.

Date and time formats may be defined both at the system level and at the project level. If the administrator does not mandate that the system date and time formats are used in the CustomerWise implementation, project administrators may define time and date formats for their projects individually.

To define project date and time zone settings:

1Select the Time Zone & Date Format page in the Admin Tree window of the System Setting project.

System time zone settings may be defined in the System Setting project only.

2Select the System Date/Time Format tab.

Note:Any changes made to the date format require that the web server be stopped and restarted for the change to be visible in the CustomerWise Web clients. System administrators may reload web settings by clicking the Reload button in the tool bar.

3Define date and time formatting.

• Select a formatting option from the Date Format dropdown list.

• Select a formatting option from the Time Format dropdown list.

4Define time and date format options for project members and employees.

System administrators may mandate that all project members and all employees use administrator-defined time and date formats.

• Enforce all team members to use system time and date formats

• Enforce all employees to use system time and date formats

4.5.2 Defining System Daylight Savings Settings

Project administrators may enable daylight savings and define beginning and ending hours in the Daylight Savings tab of the Time Zone & Date Format page in the System Setting project.

4.6 Administering CTI Integration

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

E-mail retrieval and e-mail notification settings are defined separately.

• The E-mail Retrieval page enables system administrators to define rules for managing incoming e-mail errors.

• The E-mail Notification page enables system administrators to define rules for managing outgoing e-mail errors.

Figure 4-1: E-mail Retrieval Page

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

4.6.1 Installing and Configuring CDC for CustomerWise Integration

TechExcel CustomerWise offers CTI features through the CTI Data Connector TechExcel Edition from Mirage Computer Systems.

The CTI Data Connector TechExcel Edition is a plug-and-play solution especially developed to work with TechExcel CustomerWise and TechExcel CustomerWise. The CTI Data Connector (CDC) responds to all incoming and outgoing calls in background mode.

To configure CustomerWise CTI features, a system administrator must first install and configure the CTI Data Connector TechExcel Edition from Mirage Computer Systems and install an executable and XML file from TechExcel.

Required components include:

• Mirage CTI Data Connector TechExcel Edition

•HDpop-up.exe

• cdc.xml file

The CTI Data Connector TechExcel Edition and the CTI Data Connector license are both available from Mirage.

The CustomerWise CTI program (HDpopup.exe) and the cdc.xml file are available for download from TechExcel.

To install and configure CDC for CustomerWise integration:

1Run thecdckernel.exe to install the CTI Data Connector.

The CTI Data Connector is installed to C:\Program Files\CTI Data Connector by default.

2Configure the CTI Data Connector.

System administrators may configure the CTI Data Connector using the CTI Data Connector Configuration Wizard. For step-by-step instructions installing the CTI Data Connector see documentation from Mirage Computer Systems.

3Add theCTIData.dll to the CustomerWise web server.

The default location for CustomerWise scripts: C:\Inetpub\scripts\texcel\CustomerWise

4Copy thecdc.xml to the \CTI Data Connector folder.

5Copy theHDpop-up.exe file to the \CTI Data Connector folder.

6Edit thecdc.xml file to point to the HDpop-up.exe.

The name of the pop-up executable must match the name of the executable defined in the cdc.xml file. System administrators have two options:

• Rename the HDpop-up.exe to pop-up.exe, matching the name in the cdc.xml file.

• Open the cdc.xml file in Notepad and edit the file so that it points to the HDpop-up.exe.

7Double-click and run theHDpop-up.exe.

8Right-click the CTI Data Connector icon in the top-left corner of the CTI Data Connector page, and select the Settings command in the shortcut menu.

The CTI Setting dialog box appears.

9Define the location of the CustomerWise Web Server.

The default CustomerWise URL:

http://localhost/scripts/texcel/helpdesk/helpdesk.dll 

10Click the OK button.

Once the administrator has installed and configured CDC to work with CustomerWise, the system and project administrators may configure CustomerWise CTI integration settings in the CustomerWise Admin client.

• Configure system-level CTI integration in the System Settings project of the CustomerWise Admin client.

• Configure project-level CTI integration in the CustomerWise Admin client.

4.6.2 System-Level Integration Configuration

CustomerWise CTI integration must be enabled at both the system and project levels in the CustomerWise Admin client.

System administrators may enable data connector integration and define the hot key for all outgoing calls in the CTI Integration page of the CTI Integration folder of the System Settings project.

4.6.3 Enabling CTI Integration

System administrators may enable CTI integration in the General Settings page of the CTI Integration folder of the System Settings project.

To enable CTI integration in a CustomerWise site, select the Enable CTI Data Connector Integration button in the General Settings page of the CTI Integration folder in the System Settings project.

4.6.4 Enabling and Defining Keyboard Shortcuts for Outgoing Calls

Keyboard shortcuts are a combination of keystrokes that perform a predefined function. Each keyboard shortcut consists of one or more modifier keys and a hot key.

Administrator-defined outgoing phone call keyboard shortcuts enable CustomerWise project members to quickly dial employees by highlighting a telephone number in the Employee list window and pressing the predefined combination of keys.

System administrators may enable and define keyboard shortcuts for outgoing calls in the General Settings page of the CTI Integration folder of the System Settings project.

To enable and define hotkeys for outgoing calls:

1Select the Activate Hotkey for Outgoing Calls check box in the General Settings page of the CTI Integration folder.

2Select one or more modifier keys in the Modifier area.

System administrators may choose up to three modifiers: the CTRL, ALT, and the SHIFT keys.

3Select the hotkey from the Hotkeys dropdown list.

The Hotkey dropdown list displays ten options: the F1-F10 function keys.

4.7 Administering the TechExcel Search Engine

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

E-mail trace levels determine the types of messages that are logged when e-mail errors occur. System administrators may choose one of three e-mail trace settings:

• The Info, Warning, and Error trace level

• The Warning and Error trace level

• The Error trace level

E-mail service settings determine the sensitivity of the e-mail notification service. E-mail 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 E-mail Trace Level dropdown list.

3Select an option from the E-mail Service Setting dropdown list.

4.7.1 Installing the TechExcel Search Engine

System administrators may install the TechExcel Search Engine to enhance the searching capabilities of project members in CustomerWise projects.

The TechExcel Search Engine runs as a service and may managed using the Services manager in Administrative Tools of a Windows operating system.

• The CustomerWise search service must be installed on the machinebeforea project may enable TechExcel Search Engine support and index the searchable fields in the project.

• The TechExcel Search Engine should be installed on the same computer as the CustomerWise Document Server.

To install the TechExcel Search Engine:

1Run the Search Setup executable.

The CustomerWise Search Server Installation wizard installs the TechExcel Search Engine.

2During the installation the administrator must:

• Accept the license agreement.

• Ensure that the TechExcel Search Engine can connect to the CustomerWise Application Server.

3The TechExcel Search Engine Configuration dialog box appears.

4Define the name of the current TechExcel Search Engine in the Referred as Service Name field.

Each TechExcel Search Engine installed in a CustomerWise site may have its own name enabling administrators to differentiate between them. System administrators may choose which TechExcel Search Engine is used for each work project. Multiple projects may use the same TechExcel Search Engine.

5Define the location of the index directory.

6Click the OK button.

7Click the Finish button.

4.7.2 Configuring Search Engine Settings

System administrators may enable TechExcel Search Engine support, select an appropriate TechExcel Search Engine for a project, and index the multiple-line text box controls in that project using controls in the TechExcel Search Engine page.

To define TechExcel Search Engine settings:

1Select the Search Engine page in the Enterprise Edition Features folder of the CustomerWise Admin Tree window.

2Select the Enable Memo Fields Search check box.

3Click the Select a Search Engine button.

The Select a Search Engine dialog box appears.

4Select a TechExcel Search Engine option in the Search Engine list.

System administrators may install multiple TechExcel Search Engines in their CustomerWise site. Each CustomerWise project may have its own Search Engine or multiple projects may share the same TechExcel Search Engine.

5Click the Select button.

The Select a Search Engine dialog box closes.

4.7.3 Indexing Multiple-selection List Controls

System administrators may enable TechExcel Search Engine support, select an appropriate TechExcel Search Engine for a project, and index the multiple-selection list controls in that project using controls in the TechExcel Search Engine page.

The TechExcel Search Engine performs search indexing on multiple-selection list controls. The first time an administrator indexes a large database, the process may take hours. Subsequent indexing of project multiple-selection list controls is only performed on newly added records and the execution time is significantly reduced.

To index project multiple-selection list controls:

1Select the Search Engine page in the Enterprise Edition Features folder of the CustomerWise Admin Tree window.

2Click the Index Now button.

The Initialization of Search Index dialog box appears.

3Click the Start button.

The Initialization of Search Index dialog box closes.

The Current Status control displays the current status of the indexing process. When indexing is complete the Current Status control displays the textIndexing process finished.

4.8 Administering LDAP Integration

System administrators may enable CustomerWise 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 E-mail 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.

4.8.1 Understanding LDAP

CustomerWise-LDAP integration enables system administrators to manage the user data (user names, phone numbers and e-mail addresses) of CustomerWise user accounts in an LDAP directory server instead of the CustomerWise base project.

The Lightweight Directory Access Protocol orLDAP, is a protocol for accessing online directory services. A directory service organizes content in a directory server into a logical and accessible structure.

• LDAP provides a single, consistent database in which to store information about the network and all network-based resources including users, servers, files, printers, and shares.

• LDAP acts as a central authority that can securely authenticate resources and manage identities and relationships between them.

4.8.2 Understanding System-level Integration Tasks

In TechExcel CustomerWise, all LDAP integration, authentication, and synchronization settings are defined at the system-level in the CustomerWise Admin client.

System administrators are responsible for enabling and defining CustomerWise- LDAP integration settings, enabling and defined CustomerWise authentication settings, and mapping CustomerWise user account properties to LDAP user attributes and defining synchronization settings and schedules.

Not every configuration tasks may be performed in every CustomerWise project. Every CustomerWise project consists of at lease three projects (a system settings project, a base project, and one or more work projects). LDAP integration tasks are completed in different projects within a CustomerWise site.

• LDAP integration tasks may be performed in the System Settings project or the base project.

• LDAP authentication tasks may be performed in the System Settings project only.

• Project team member field mapping and synchronization schedules may be performed in the System Settings project or the base project.

• Employee field mapping and synchronization schedules may be performed in the base project only.

4.8.3 Defining LDAP Directory Server Connection Settings

Project administrators may define directory server connection settings including the server name, user DN and password, and search filter in the LDAP Server List page of the LDAP Integration page.

Table 4-1: LDAP Server List Page

Identifying the LDAP servers to integrated is the first step towards defining and integrated CustomerWise-LDAP environment.

System administrators define directory server connection settings before they may enable LDAP authentication, LDAP synchronization, or the importation of user accounts from a directory server.

To identify LDAP servers:

1Select the LDAP Server List page in the LDAP Integration folder of the System Settings project.

The LDAP Server List page appears.

2Click the New button.

The New LDAP Server dialog box appears.

3Define the name and server type.

• The server name may be any name that enables the administrator to identify the LDAP server within CustomerWise.

• CustomerWise supports MS ADAM, MS Active Directory, and other LDAP server types.

4Click the OK button.

The LDAP server is displayed in the LDAP Server List of the LDAP Server Setting manager.

After selecting the LDAP server and defining its name and server type, the administrator may define the LDAP server settings.

4.8.4 Defining LDAP Server Settings

System administrators may use the Server Information tab in the LDAP Server List page to define LDAP server settings.

LDAP server settings must be definedbeforeadministrators may import user account data from LDAP server or use LDAP servers to authenticate user logins.

The Server Information tab enables project members to define, update, and test LDAP server connections, define a DN (designated name) path and password to access appropriate data, and define a search filter to limit the scope of LDAP data accessed.

Table 4-2: Server Information Tab

To connect to the LDAP server the administrator must define the appropriate host name, port name, distinguished name and password, search filter, and attribute name.

4.8.5 DN (distinguished name)

System administrators must enter a distinguished name (DN) and password that enables them to connect to the LDAP server. The DN is a path to the LDAP server that enables CustomerWise to access LDAP data.

The DN consists of acontainer name(CN) and one or moredomain controls(DC). For example,CN=users,DC=mydomain,DC=com

4.8.6 Search filter

The Search Filter field enables administrators to identify the LDAP data they want to import. For example,objectClass=user

Always use a search filter. If no search filter is defined, CustomerWise cannot import data from the directory service.

4.8.7 Attribute name

The Search Filter field enables administrators to identify the LDAP data they want to import. For example,objectClass=user

Always use a search filter. If no search filter is defined, CustomerWise cannot import data from the directory service.

 Chapter 5 Project-Level Project Administration

5.1 Understanding Project Administration

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

5.1.1 Project definition

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.

5.1.2 Incident definition and GUI customization

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.

5.1.3 Project member administration

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.

5.1.4 Workflow administration

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.

5.2 Managing Project Properties

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.

5.2.1 Updating Project Names

Project administrators may update the title of a project in the Project Name field of the Project Properties page.

All project names are defined by system administrators when they create ServiceWise projects.

When updating project names, project administrators should avoid using the following characters: / \ : ? “ < > |.

5.2.2 Updating Project ID Prefixes

Project administrators may define incident ID prefixes and incident, event, employee, contact, invoice, and support plan ID starting numbers in the Define Starting IDs manager.

To access the Define Starting IDs manager, click the Starting IDs button in the Project Properites page of the General Project Settings folder in a project view of the ServiceWise Admin client.

The ID Prefix control enables administrators to define a numerical or character prefix that is added to each incident ID in the project. ID prefixes make the incidents associated with a particular project easier to identify.

While these IDs are posted automatically, managers may find it helpful to assign starting numbers so that certain components in the project are easier to recognize. All starting ID settings are optional.

The Defining Starting ID manager is divided into three areas: the Employee/Contact area, the Incident area, and the Event and Invoice area:

• The ID Scope control enables administrators to define if these settings are unique to the base project, or if they should apply to the entire database.

• The Employee ID Starting No. control enables administrators to define an employee ID starting number.

• The Contact ID starting No. control enables administrators to define a contact ID starting number.

• The ID Prefix control enables administrators to add a numerical or character prefix (up to four characters) to each incident ID. This feature may be used so that incidents associated with a particular project are easier to identify.

• The ID Starting No. control enables administrators to define the initial incident ID number. If an administrator enters 100 in this field, the first incident created is ncident number 100.

• The Event ID Starting No. control enables administrators to define an event ID starting number.

• The Invoice ID Starting No. control enables administrators to define an invoice ID starting number.

• The Support Plan ID Starting No. control enables administrators to define a support plan ID starting number.

5.2.3 Making Projects Active or Inactive

Project administrators to make projects active or inactive using the Active Project control in the Project Properties page.

• Active projects may be accessed by ServiceWise project members through the ServiceWise clients.

• Inactive projects cannot be accessed by ServiceWise project members and may be deleted by a system administrator.

5.2.4 Enabling Web Uploading

Project administrators may enable uploading and downloading in ServiceWise projects using Support Web Uploading control in the the Project Properties page.

The Support Web Uploading control enables ServiceWise Web users to upload files to the ServiceWise Document Server.

5.2.5 Enabling the Employee Web Portal

Project administrators may enable support for the Employee Web Portal using the Enable Employee Web Portal control in the the Project Properties page.

The Employee Web Portal enables user-defined employees to submit, view, and edit ServiceWise incidents through the Internet.

5.2.6 Support Knowledge Building in ServiceWise Web

Project administrators may enable project members to “ build” knowledge using the Enable Knowledge Building using the Web control in the the Project Properties page.

If the knowledge building feature is enabled, internal project members may add, edit, and delete knowledge items in the knowledge base using their ServiceWise Web clients.

5.2.7 Enabling Web Conversions

Project administrators may enable support for web conversations using the Enable Web Conversation control in the Project Properties page. Web conversation enables support project members and employees to communicate about incidents using text chat-like interface through the Web.

5.2.8 Defining the Display Format of Names

Project administrators may define how the names of project members are displayed in the client GUI using the Name Display Format controls in the Project Properties page.

The names of project members may be displayed using one of two formats:

• First name Last name

• Last name, First name

The names of project members and employee contacts are displayed using the selected format in the User dropdown list and the Incident, Event, and Employee List windows.

The First name Last name format:

Figure 5-2: First Name Last Name Format

The Last name, First name format:

Figure 5-3: Last Name, First Name Format

5.2.9 Defining Incident Description Field Sizes

Project administrators may define the size of the Description field displayed in the Incident page. The number entered determines the maximum number of characters that may be entered into this field using WebEditPro through the Web.

The default size is 10K.

5.2.10 Defining Project Time Zones

Project administrators may define the time zones for individual projects using the Select Time Zone and Date Format Setting manager in the Project Properties page.

The Project Time Zone tab enables the project administrator to define the default time zones for project members and employees in a project and to enable daylight savings adjustments and other options.

Time zone settings may be defined both at the system-level and at the project-level. System administrators may mandate that all project members and employees use administrator-defined time zone settings.

To define project time zone settings: 

1Click the Time Zone and Date Format Setting button in the Project Properties page.

The Select Time Zone and Date Format Setting manager appears.

2Select the Project Time Zone tab.

3Select an option in the Default Time Zone for Team dropdown list.

4To allow for daylight savings time, select the Adjust for Daylight Savings Changes check box.

5Select an option in the Default Time Zone for Employees dropdown list.

6To allow for daylight savings time, select the Adjust for Daylight Savings Changes check box.

7Select a time zone option for project team members in the Time Zone Option area.

Project members may choose between three options for project members:

• Enforce all team members to use system time zone

• All Team members within this project use the project time zone

• Team members can use own time zone preference

8To enable employees to define their own time zone settings, select the Employees Can Use Own Time Zone Preference check box.

9Click the OK button.

5.2.11 Defining Date and Time Formats

Project administrators may define project-specific time zone and date formats using the Time Zone & Date Format Setting control in the Project Properties page.

Date and time formats may be defined both at the system-level and at the project-level. System administrators may mandate that all project members and employees use administrator-defined system date and time formats.

Date Formats

Project administrators may choose between 13 different date formats:

• M/d/yy

• MM/dd/yyyy

• yy/MM/dd

• yyyy/MM/dd

• yyyy-MM-dd

• dd-MMM-yy

• dd/MMM/yyyy

• dd/MM/yy

• dd/MM/yyyy

• dd.MM.yy

• dd.MM.yyyy

• dd-MM-yy

• dd-MM-yyyy

Time Formats

• h:mm:ss am/pm

• hh:mm:ss am/pm

• H:mm:ss

• HH:mm:ss

To define project date and time formats:

1Click the Time Zone and Date Format Setting button in the Project Properties page.

The Select Time Zone and Date Format Setting manager appears.

2Select the Project Date/Time Format tab.

Note:Any changes made to the date format require that is be stopped and restarted for the change to be visible in the ServiceWise Web clients.

3Define date and time formatting for project members.

• Select a formatting option from the Date Format dropdown list.

• Select a formatting option from the Time Format dropdown list.

4Define date and time formatting for employees

• Select a formatting option from the Date Format dropdown list.

• Select a formatting option from the Time Format dropdown list.

5Select time and date format options for project team members in the Date/Time Format Option area.

Project members may choose between three options for project members:

• Enforce all team members to use system time zone

• All team members within this project use the project Date/Time Format

• Team members can use own time format preference

6To enable employees to define their personal time and date format preferences, select the Employees Can Use Own Time Format Preference check box.

7Click the OK button.

5.2.12 Managing ServiceWise Windows Client Sessions

Project administrators may define rules for logging off inactive project members using the Windows Client Session controls in the Project Properties page.

Project administrators may define the amount of time that a project member is idle before that user is automatically logged off the project. The minimum setting is 15 minutes.

To enable and define ServiceWise Windows client session logoff settings, select the Automatically Log Out User check box and define the idle time.

5.2.13 Defining List View Refresh Options

Project administrators may define how the List window is refreshed in the ServiceWise Windows client using controls in the List View Refresh Option page.

Project administrators may choose between three options;

• Always auto refresh

• Always manual refresh

• Based on user preference

Project administrators may also define list view refresh options for project Web clients in the List View Refresh Option page.

5.2.14 Defining Employee Quick Search Settings

Project administrators may define quick searches of employees using controls in the List View Refresh Option page.

Employee Quick Search enables project members to locate employees based on six employee properties:

• ID {Employee ID}

• Employee Name

• SLA plan ID (s=)

• Asset No. (a=)

• Employee phone (p=)

• Contact e-mail (e=)

To enable quick searches, select the Enable Employee Quick Search radio button in the Employee Quick Search Option area of the List View Refresh Option page.

5.2.15 Defining Incident Quick Search Settings

Project administrators may enable project members to launch quick searches for incidents using controls in the client tool bar.

Incident Quick Search enables project members to locate incidents based on four incident properties:

• Incident ID (default)

• Incident name

• SLA plan ID (s=)

• Asset No. (a=)

To enable quick searches, select the Enable Incident Quick Search radio button in the incident Quick Search Option area of the List View Refresh Option page.

5.3 Managing Optional Project Features

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.

5.3.1 Enabling or Disabling Optional Features

Administrators may use tools in the Optional Features page of the General Project Settings folder to enable or disable optional features in ServiceWise projects.

• Enabling a feature displays the system page that is required to configure the feature in the Admin Tree window of ServiceWise Admin. The project administrator may configure the feature and it may be used in the project.

• Disabling a feature hides the system page that is required to configure the feature in the Admin Tree window of ServiceWise Admin. The project administrator may not configure the feature and it cannot be used in the project.

Note:TechExcel recommends that optional features that are not in use be disabled so that project settings or workflow rules are not inadvertently defined or overwritten.

To enable optional features:

1Select an optional feature.

2Click the Edit button.

The Optional Feature dialog box appears.

3Select the check box.

4Click the OK button.

The Optional Feature dialog box closes.

5Click the Refresh Tree button.

The page needed to configure the optional feature is displayed in the Admin Tree window.

5.3.2 Understanding Optional Features

• Many optional features are only available in the ServiceWise Enterprise Edition.

• Many optional features require the purchase of separate modules, licenses, or consulting services.

• Some optional features may only be defined in a base project.

Certain folders and pages may be added or removed to the ServiceWise client GUI based on administrator-defined configurations.

• Advanced E-mail Integration

• Advanced Event Workflow

• Advanced Time Tracking and Professional Service Management

• Auto Escalation

• Auto Routing

• Employee-specific Web Announcement

• DownloadPlus Integration

• Enable Quick Web Links

• Incident Priority Management

• FormWise Standard Forms

• TechExcel Search Engine

• Subproject Support

• Support KnowledgeWise External Knowledge

5.4 Managing Project Administrators

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.

5.4.1 Adding and Removing Project Administrators

Project administrators may add other project members as project administrators within ServiceWise projects using tools in the Project Administrator page of the General Project Settings folder.

• To add a project administrator to the current project, select the project member in the Available Project Administrators list and click the Add button.

• To remove a project administrator from the current project, select the project member in the Project Administrators for Current Project list and click the Remove button.

Click the Support Member Manager button to open the Support Member Manager.

Project administrators may assign project administrator account types to project members in the Project Administrators page.

5.5 Managing Account Types

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.

5.5.1 Understanding Account Types

Project administrators are responsible for creating all of the account types that are used in their project, defining the privileges associated with those account types, and assigning these account types to each project members based on the role and responsibilities that user performs in the project.

The account type that is assigned to a user determines the role that the user may play within the project. All privileges and responsibilities assigned to a user within a project are based on their account type.

• Account types represent specific roles and responsibilities in ServiceWise projects

• Account types determine the privileges that may be granted to individual project members

• Account types determine which project members may own or manage incidents during project workflow

• Account types provide security within the project

5.5.1.1 Account types and privileges

TechExcel ServiceWise supports two types of account types: regular account types and light account types.

• Regular account types are for TechExcel ServiceWise project members that are assigned with single or suite licenses.

• Light account types are for project members that are assigned a light license and have a limited role in the project.

5.5.1.2 Account types and workflow

Account types are foundation of workflow in ServiceWise projects.

Incidents are assigned to project members based on their account type. The ability of individual project members to own or manage incident in a particular progress state is also based on their account type.

5.5.1.3 Account types and project security

Account types are the foundation of all security in ServiceWise projects. An account type represents a set of privileges that enable users to perform tasks in the ServiceWise client.

The ability of a ServiceWise user account to access projects, views, folders, and pages depend on the account type that they are assigned in a project.

When a user account is assigned an account type that user inherits all of the privileges and responsibilities that are assigned to that account type. Every user account added to a project by a project administrator must be assigned an account type.

Because each ServiceWise user may belong to multiple projects, a user can be assigned a different account type for each project based on the role that the user plays in each project.

5.5.2 Understanding Light Account Types

Light account types may be assigned to project members who have a limited role in a project such as an assistant assigned to enter incidents into a support project but does not work on the incidents.

A light account type has fewer privileges than a regular account type. A user with a light license (and therefore assigned to a light account type) cannot own incidents:

The following privileges are not available for a light account type:

• Assign incidents within own group

• Assign incidents to members of all groups

• Close incidents

• Reopen incidents

• Import and delete

• Define public query

• Perform inter-project copy

• Edit linked incidents from other projects

Project member assigned a light account type cannot perform any of the knowledge-related operations. A light user may only view public knowledge items, search for knowledge, and link knowledge items to an incident for incident resolution.

5.5.3 Creating Account Types

Project administrators may use controls in the Account Type page of the General Project Settings folder to create all of the account types that may be assigned to users in a ServiceWise project.

To create an account type: 

1Click the New button in the Account Type page. The New Account Type dialog box appears.

2Select the type of account to be assigned to the account type.

TechExcel ServiceWise supports two types of account types: regular account types and light account types.

• Regular account types are for TechExcel ServiceWise project members that are assigned with single or suite licenses.

• Light account types are for project members that are assigned a light license and have a limited role in the project.

3Enter a name in the Name field.

4Click the OK button.

Note:Project administrators cannot add user accounts to a project until they have created account types. Each user must be assigned an account type before being added to a project.

5.5.4 Editing Account Types

Project administrators may use the Edit button in the Account Type page to rename project account types.

Project administrators may not change the type of the account type. Once an account type is defined as a regular account type or a light account type, that account remains that type of account.

To edit an account type:

1Select an account type in the Account Type list in the Account Type page.

2Click the Edit button.

The Edit Account Type dialog box appears.

3Enter a name in the Name field.

4Click the OK button.

5.5.5 Deleting Account Types

Project administrators may use the Delete button in the Account Type page to delete project account types.

To rename an account type: 

1Select an account type in the Account Type list in the Account Type page.

2Click the Delete button.

The Delete Account Type warning appears.

3Click the OK button.

5.6 Managing Account Access Controls

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.

5.6.1 Assigning Privileges to Account Types

To define incident-related privileges for an account type, select the account type and navigate to the Incident tab.

5.6.2 Understanding Incident Management Access Controls

To define incident-related privileges for an account type, select the account type and navigate to the Incident tab.

 Chapter 6 Incident Administration

6.1 Understanding Support Incident Administration

In CustomerWise, all customer incidents are managed and tracked assupport incidentsin the incident view of the CustomerWise 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 CustomerWise, support incidents are managed and tracked in the incident view of the CustomerWise 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.

6.1.1 Understanding Support Incidents

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 CustomerWise client applications.

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

• Create employee pages and custom controls.

6.1.2 Understanding Incident View GUI Customization

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

The CustomerWise 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 CustomerWise client to support and manage their business processes.

Figure 6-1: The CustomerWise Windows Client

The incident view of the CustomerWise 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.

6.2 Configuring General Support Incident Properties

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 CustomerWise client applications.

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

• Create employee pages and custom controls.

6.2.1 Renaming Support Incidents

In CustomerWise, all customer support incidents are managed and tracked as support incidents. The term incident is used throughout the CustomerWise Admin, Windows, and Web clients.

CustomerWise 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 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 CustomerWise. The text entered in this edit box is displayed in instead of the word incident throughout the TechExcel CustomerWise Windows and Web client.

6.2.2 Defining the Status Control as Read-only

In the CustomerWise client, the Status control in the Current Status page enables project members to manage and track the incident workflow states of a support incident.

CustomerWise enables project administrators to designate the Status control as read-only in each work project. To designate the Status control as read-only select the Set the Status Field as Read Only in the Current Status Page check box in the General Setting page.

6.2.3 Enabling Co-owner Events

Co-owner events enable support teams to define multiple owners for a single CustomerWise incident. Generally, incident workflow rules mandate that only one project member may own an incident at any one time during the incident life cycle.

Using a co-owner events, support teams may temporarily assign incident ownership to multiple project members in a single incident workflow state.

To enable co-owner events in a work project, select the Support Co-owner Events check box in the General Setting page.

Once co-owner events are enabled, administrators may define co-owner event settings in the Event Management folder.

6.2.4 Configuring Employee Access to Support Incidents

In CustomerWise, employees belonging to the appropriate employee type may view or even edit support incidents in the Employee Web Portal.

Employee access to support incidents may be restricted on a state-by-state basis or on an incident-by-incident basis.

Project administrators may define how employees access to support incidents are defined in each support project using controls in the in the General Setting page. Employee access may be restricted by one of three methods:

The Based on the Incident Status Definition Only option: If the Based on Incident Status Only option is selected, project administrators may define employee access rules on a state-bystate basis.

The Based on the Incident Status and Allow per Incident Simplified Access Control option: If the Based on Incident Status with per Incident Simplified Access option is selected, project administrators may define employee access rules on a state-bystate basis and enable simplified access on an incident-by-incident basis.

The Based on the Incident Status and Allow per Incident Full Access Control option: If the Based on Incident Status with per Incident Simplified Access option is selected, project administrators may define employee access rules on a state-bystate basis and enable full access on an incident-by-incident basis.

6.2.5 Customizing the Incident List Panel

In the CustomerWise clients, the incident list panel displays high-level data about multiple support incidents in a tabular format. Every row in the incident list panel represents a single support incident. Every column represents an administrator-defined incident property.

Project administrators may customize the title of the columns displayed in the incident list using controls in CustomerWise Admin.

To customize the column names, double-click the column headers and update the column name in the dialog box.

• Incident ID

• Status

• Current Owner

All other column titles (Title, Product Line, Date Assigned) may be customized by retitling the corresponding control in the Description page or Current Status page. For more information see See “Defining Control Labels” on page 131. For example, to rename the Title column, change the name of the Title field on the Description page.

Note: Project members may personalize the incident list that is displayed in the their client to display the columns that are useful to them. The list defined here is the default list view for users who have not customized their incident list.

6.3 Administering Controls

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

The CustomerWise 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 CustomerWise client to support and manage their business processes.

Figure 6-1: The CustomerWise Windows Client

The incident view of the CustomerWise 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.

6.3.1 Administering System Controls

CustomerWise is a tool for collecting, managing, and tracking incident, asset, and employee data. All data is managed and tracked in the CustomerWise client using data-entry controls.

System fields are predefined fields that represent core object properties. System fields are predefined data-entry controls that are designed to collect and track specific kinds of incident data. Many system controls incorporate CustomerWise business logic and are required to manage tools.

Many system fields are linked to other fields or to other CustomerWise features, and are therefore not fully customizable. Project administrators may change the title of system controls and, in some instances, restrict access to those controls.

Every system field consists of four properties:

• Field ID

• Field name

• Control title

• Control type

The field ID and field name of system fields are fixed in CustomerWise and cannot be changed. These properties enable administrators to identify fields across projects and facilitate integration and interproject configurations.

The control title and the control type of system controls may be customized in CustomerWise projects. But system field customizations are relatively limited when compared to the customizations that may be made to custom controls.

The following system controls may be displayed in CustomerWise system or customer pages.

Table 6-1: CustomerWise System Field Controls

6.3.2 Administering Custom Controls

Custom fields are administrator-defined data-entry controls that may be used to collect and track incident data.

Project administrators may enable and customize up to 220 custom data-entry controls using the five custom field database pages that may be displayed in the Field Design subfolder of the Incident View folder.

Data collected in custom fields may be imported or exported, searched, and used to run reports.

The number of custom data-entry controls that an administrator may define and customize in a CustomerWise project depends on the number of custom field database pages that the administrator has enabled in the Field Design Settings page.

The first step towards enabling custom controls in a CustomerWise project is to select the number of custom field database pages that are displayed in the Field Design subfolder. Project administrators may create custom controls based on six different control types:

Table 6-2: Custom Control Types

Project administrators may enable up to five custom field database pages in each project. Each custom field database page enables administrators to define up to 44 different custom controls.

To enable custom field database pages:

1 Click the Change button in the Field Design Settings page of the Field Design subfolder within the Incident folder.

The Increase Total DB Pages for Custom Data dialog box appears.

2 Select an option from the dropdown list.

Project administrators may enable up to five custom field database pages in each CustomerWise project.

3 Click the OK button.

6.3.3 Understanding Control Types

All controls are defined by their control type. A control type represents a class of GUI elements that share the same functionality. The control type defines how the data tracked in the control is managed by the user.

CustomerWise supports eight different control types: combo boxes, data grids, date-time controls, dropdown lists, edit boxes, multiple selection controls, and multiple line edit boxes.

6.3.4 Understanding Control Customization Options

In CustomerWise, project administrators may define and customize the controls displayed in each page of the incident detail panel of the CustomerWise client.

The control type defines how the data tracked in the control is managed by the user.

• Selection controls—represented by the autogrow combo box, combo box, dropdown list, and multiple selection control types— enable users to select an option from an administrator-defined list of options.

• Input controls—represented by the single-line text box, multiple-line text box— enable users to input a value.

• Combination controls—the autogrow combo box and the combo box—enable users to choose between selecting a predefined option or entering a value.

Control customizations include the definition of control field labels, field access rules, and selectable options.

Table 6-3: Control Customizations

The customizations that may be made to a control depend on two factors: the control category and the control type.

• In CustomerWise, every control belongs to one of two control categories: system controls or custom controls.

• CustomerWise supports eight different control types: combo boxes, data grids, date-time controls, dropdown lists, edit boxes, multiple selection controls, and multiple line edit boxes.

The following customizations may be made to controls based on their control type:

Table 6-4: Custom Control Types

6.3.5 Defining Control Labels

A label is a GUI element that identifies an adjacent control. All controls in the CustomerWise client are accompanied by labels.

Project administrators may retitle all system and custom controls.

6.3.6 Defining the Control Type of Custom Controls

To customize the control type of custom controls: 

1 Select a custom control in one of the five Custom Fields DB page that may be displayed in the Field Design subfolder in the Incident View folder.

2 Click the Define button.

The Edit dialog box appears.

3 Select a control type from the Field Type dropdown list and click the OK button.

Project administrators may change the control type of 28 custom controls in each Custom Fields DB page.

• The 8 FieldShortText fields may be defined as either Combo Box controls or Edit Box controls.

• The 8 FieldLongText fields may be defined as either Combo Box controls or Edit Box controls.

The 12 FieldInteger fields may be defined as Check Box, Dropdown List, or Edit Box controls.

6.3.7 Defining Team Member Access Rules

In CustomerWise, incident form pages—the Description page, the Current Status page, custom pages, and others—and the controls displayed in those pages may be made accessible to company employees through the Employee Web Portal.

Team access rules enable project administrators to restrict project member access to the data managed in system and custom controls.

Each control is defined by one of four employee access rules:

Table 6-5: Team Member Access Rules

6.3.8 Defining Employee Access Rules

In CustomerWise, incident form pages—the Description page, the Current Status page, custom pages, and others—and the controls displayed in those pages may be made accessible to company employees through the Employee Web Portal.

Employee access rules enable project administrators to restrict employee access to the data managed in system and custom controls.

Each control is defined by one of four employee access rules:

Table 6-6: Employee Access Rules

6.3.9 Defining Options in Selection List Controls

Selection list controls—autogrow combo boxes, combo boxes, dropdown lists, and multiple selection controls— enable users to select an option from a predefined list of options.

Using controls in the List Setup dialog box, project administrators may add, edit, or delete the options displayed in selection list controls, define the order of options in those lists, and merge control options.

6.3.10 Defining Parent-Child Relationships Between Controls

In CustomerWise, parent-child relationships may be defined between two selection controls—autogrow combo boxes, combo boxes, dropdown lists, and multiple selection controls.

In a parent-child relationship, the option selected in the parent selection control determines the options that are available for selection in the child selection control.

6.3.11 Customizing Autogrow Combo Box Controls

An autogrow combo box combines a dropdown list with a text box to enable users to either type a value directly into the control or to select a value from an existing list of options.

Every value entered into the text box is added to the dropdown list and displayed to subsequent users.

Figure 6-2: Autogrow Combo Box Control

No system fields may be defined using the autogrow combo box control type. All autogrow combo boxes are custom controls.

Customizations include:

• Title

• Team Access

• Employee Access

• Options

• Parent-Child

To add or remove an option to an autogrow combo box control:

1 Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder.

2 Click the Design button.

The CustomerWise dialog box appears.

3 Click the Setup button.

The List Setup dialog box appears.

4 Add or remove field values to the selection control.

• To add field values to the selection control, select the field value in the Inactive Selection list and click the Left Arrow button.

• To remove field values from the selection control, select the field value in the Active Selection list and click the Right Arrow button.

5 Click the OK button.

The List Setup dialog box closes.

6 Click the OK button.

The CustomerWise dialog box closes.

6.3.12 Customizing Combo Box Controls

A combo box combines a dropdown list with a single-line text box to enable users to choose between inputting a value directly into the control or to select a value from an existing list of options.

Figure 6-3: Combo Box Control

Customizations include:

• Title

• Team Access

• Employee Access

• Options

• Parent-Child

To add or remove options to selection controls: 

1 Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder.

2 Click the Design button.

The CustomerWise dialog box appears.

3 Click the Setup button.

The List Setup dialog box appears.

4 Add or remove field values to the selection control.

• To add field values to the selection control, select the field value in the Inactive Selection list and click the Left Arrow button.

• To remove field values from the selection control, select the field value in the Active Selection list and click the Right Arrow button.

5 Click the OK button.

The List Setup dialog box closes.

6 Click the OK button.

The CustomerWise dialog box closes.

6.3.13 Customizing Dropdown List Controls

A dropdown list enables users to select a value from a list of predefined options.

Figure 6-4: Dropdown List Control

Other features of selection controls include the definition of parent-child relationships between selection controls.

Customizations include:

• Title

• Team Access

• Employee Access

• Options

• Parent-Child

To add or remove options to selection controls: 

1 Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder.

2 Click the Design button.

The CustomerWise dialog box appears.

3 Click the Setup button.

The List Setup dialog box appears.

4 Add or remove field values to the selection control.

• To add field values to the selection control, select the field value in the Inactive Selection list and click the Left Arrow button.

• To remove field values from the selection control, select the field value in the Active Selection list and click the Right Arrow button.

5 Click the OK button.

The List Setup dialog box closes.

6 Click the OK button.

The CustomerWise dialog box closes.

6.3.14 Ordering Options in Selection List Controls

CustomerWise enables support organizations to manage and track incident, employee, and asset data in three types of selection controls: autogrow combo boxes, combo boxes, and dropdown lists.

Selection list controls present users with a predefined list of options from which the user may choose a single value.

By default, the options in the list are displayed in alphabetical order. Project administrators may define the order of options in the list.

To order options in a selection control: 

1 Select a selection control in the System Fields list of the System Field Design page in the Field Design subfolder of the Incident View folder.

2 Click the Design button.

The CustomerWise dialog box appears.

3 Click the Setup button.

The List Setup dialog box appears.

4 Move field values up or down in the selection control:

• To move field values up in the selection control list, select the field value in the Active Selection list and click the Up Arrow button.

• To remove field values down in the selection control list, select the field value in the Active Selection list and click the Down Arrow button.

5 Click the OK button.

The List Setup dialog box closes.

6 Click the OK button.

The CustomerWise dialog box closes.

6.3.15 Customizing Multiple Selection Controls

A multiple selection control is GUI element control type that enables users to select multiple values from a predefined list of options.

Figure 6-5: Multiple Selection Control

In CustomerWise, all multiple selection controls are custom controls that have been created and defined by a project administrator. Custom controls may be added to system pages and custom pages that are displayed in the CustomerWise client.

Project administrators may create and name multiple selection controls in the Multiple Selection Control page in the Field Design subfolder of the Incident View folder. The following customizations may be made to multiple selection controls:

Customizations include:

• Title

• Team Access

• Employee Access

• Options

• Parent-Child

To create a multiple selection control:

1 Click the Add button in the Multiple Selection Control page in the Field Design subfolder of the Incident View folder.

The Add Multiple Selection Control dialog box appears.

2 Input the title of the control in the Display Name text box.

3 Click the OK button.

The Add Multiple Selection Control dialog box closes.

The multiple selection control is displayed in the Multiple Selection Control list.

6.3.16 Customizing Data Grid Controls

A data grid is GUI element control type that presents data in a tabular list of rows and columns A project administrator may create one data grid control in each project and display that control in the Description page.

Figure 6-6: Data Grid Control

The data grid is visually comparable to a worksheet in a spreadsheet application consisting of multiple columns and rows. Every column in the data grid bears an administrator-defined title. The rows may optionally be titled as well.

Project administrators may define the control type and data type of each column in the data grid. CustomerWise supports five options:

Edit box (text):A single-line text box enables users to input a single line of text.

Edit box (int):An integer text box enables users to input a single line of text.

Edit box (float):A float text box enables users to input a single line of text.

Dropdown list:A dropdown list enables users to select a value from a list of predefined options.

Date-time field:A date-time control enables users to select a specific date in a popup calendar.

Project administrators may make the following customizations to the data grid control:

• Customize the title of the data grid control.

• Add columns to the data grid control.

• Add rows to the data grid control.

• Define column header titles.

• Define team access rules: the data grid control may be defined as Visible and Editable, Not visible, Visible and Read-only, Read-only but Editable at Submit.

• Define employee access rules

6.3.17 Customizing Single-line Text Box Controls

A single-line text box enables users to input a single line of text.

Customizations include:

• Title

• Team Access

• Employee Access

6.3.18 Customizing Multiple-line Text Box Controls

A multiple-line text box enables users to input multiple lines of text.

Multiple-line text box controls, also called memo fields, are data-entry controls that enable support organizations to conduct extended discussions about incidents, events, employees and other business objects tracked in work projects. Common multiple-line text box controls include:

• Description

• Close Note

• History

• Incident Notes

• Link Comments

• Event Description

• All custom-defined multiple-line text controls

Text managed in multiple-line text box controls is searchable using the TechExcel Search Engine. For more information see See “Administering the TechExcel Search Engine”.

Customizations include:

• Title

• Team Access

• Employee Access

• Time stamping may be enabled for three multiple-line text box system controls: the Description control, the Work Description control, and the Notes control.

6.3.19 Enabling Multiple-line Text Box Time Stamping

A time stamp is a signature that is concatenated to text entered in the data-entry field. CustomerWise time stamps log the exact date and time of the entry, the name of the project member entering the data, and the action that accompanied the work description entry.

The Description control, Work Description control, and Note control support the time stamping of all data entered into the control.

To enable a multiple-line text box time stamping: 

1 Select a system page or custom page.

2 Click the Setup button.

The GUI Layout Setup dialog box appears.

3 Select the multiple-line text box control in the control list.

Time stamping may be enabled for the Description control, the Work Description control, and the Note control.

4 Click the Design button.

The CustomerWise dialog box appears.

5 Select the Description with Time Stamp button.

6 Click the OK button.

The CustomerWise dialog box closes.

6.3.20 Customizing Check Box Controls

A check box enables the user to choose between two mutually exclusive options: selected (true) or clear (false).

Customizations include:

• Title

• Team Access

• Employee Access

6.3.21 Customizing Date-Time Controls

A date-time control enables users to select a specific date in a popup calendar.

In its inactive state the control looks like a text box with a small button (the ellipsis button). Clicking the ellipsis button displays the popup calendar that enables the user to browse and select the date.

Customizations include:

• Title

• Team Access

• Employee Access

6.3.22 Defining Team Member Access Rules

To define team member access rules: 

1 Select a system page or custom page.

2 Click the Setup button.

The GUI Layout Setup dialog box appears.

6.3.23 Defining Employee Access Rules

To define employee access rules: 

1 Select a system page or custom page.

2 Click the Setup button.

The GUI Layout Setup dialog box appears.

6.3.24 Defining Field Dimensions

To field dimensions: 

1 Select a system page or custom page.

2 Click the Setup button.

The GUI Layout Setup dialog box appears.

3 Select the multiple-line text box control in the control list.

4 Click the Design button.

The CustomerWise dialog box appears.

5 Select an option from the Width dropdown list control.

6 Select an option from the Height dropdown list control.

7 Click the OK button.

8 The CustomerWise dialog box closes.

6.4 Administering System Pages

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

6.4.1 Customizing the Incident Detail Panel

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

Project administrators may define the display order system pages and custom pages in the incident detail panel.

6.4.2 Adding the Link Page to the Incident Detail Panel

To enable the Link system page and display that page in the incident detail panel, select the Show Link Page check box in the Incident Detail Page page of the System Pages subfolder in the GUI Design folder.

6.4.3 Customizing the Description System Page

In the CustomerWise client, the Description page is the primary page for defining and tracking core incident properties. The Description page is displayed in the incident detail panel and in the incident manager dialog boxes including the New Incident manager, the Forward Incident manager, and the Close Incident manager.

Key incident properties tracked in the Description page include the incident title and description as well as other properties that identify the incident.

Project administrators may use controls in the Description system page to add and remove system, custom, and multiple-selection controls to the Description page, customize the layout of controls in the page, and define the tab order.

All controls are selected, added, and ordered using controls in the GUI Layout Setup manager.

6.4.4 Customizing the Current Status Page

Project administrators may add or remove system controls, custom controls, and multiple-selection controls to the Current Status page using controls in the Current Status system page.

All of the fields on the Current Status page, including the page title, may be customized in some fashion.

The Progress Status control, Assigned By control, Substatus control, and Work Description control are all mandatory in the Current Status page. Project administrators may not remove these controls from the page.

6.4.5 Customizing the History Page

In the CustomerWise client, the History page provides project members with a read-only audit log of all changes.

The only control that may be customized in the History page is the page title field label.

6.5 Administering Custom Pages

In CustomerWise, all customer support incidents are managed and tracked as support incidents. The term incident is used throughout the CustomerWise Admin, Windows, and Web clients.

CustomerWise 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 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 CustomerWise. The text entered in this edit box is displayed in instead of the word incident throughout the TechExcel CustomerWise Windows and Web client.

6.5.1 Creating Custom Pages

Project administrators may create up to five custom pages in each work project.

6.5.2 Defining Employee Access to Custom Pages

• Not visible

• Visible and editable

• Visible and read-only

• Read only but editable at submit

Adding and Removing Controls to Custom Pages

Project administrators may add and remove system, custom, and multiple-selection controls to custom pages, customize the layout of controls in the page, and define their the tab order using the GUI Layout Setup manager.

All controls are selected, added, and ordered using controls in the GUI Layout Setup manager.

Figure 6-7: GUI Layout Setup Page

6.6 Administering Function Pages

In the CustomerWise client, the Status control in the Current Status page enables project members to manage and track the incident workflow states of a support incident.

CustomerWise enables project administrators to designate the Status control as read-only in each work project. To designate the Status control as read-only select the Set the Status Field as Read Only in the Current Status Page check box in the General Setting page.

6.6.1 Customizing the All Activities Page (All Activities Function Page)

The All Activities page shows the incidents and events related to a particular incident.

Project administrators may make three customizations to the All Activities page:

• Display or hide the All Activities page.

• Provide access to data in other projects.

To display data access to other projects:

Incidents and events from other work projects which are related to a particular incident may be displayed in the All Activities page.

6.6.2 Customizing the New Incident Manager (New Function Page)

In the CustomerWise client, the New Incident manager is a form page that enables project members to define incident properties when they submit a new support incident.

Project administrators may add and remove system, custom, and multiple-selection controls to the New Page function page, customize the layout of controls in the page, and define the tab order in the GUI Layout Setup manager.

All controls are selected, added, and ordered using controls in the GUI Layout Setup manager.

6.6.3 Customizing the Forward Page (Forward Incident Manager)

In the CustomerWise client, the Forward Incident manager is a form page that enables project members to define incident properties when they reassign (forward) a support incident to another owner.

Project administrators may add and remove system, custom, and multiple-selection controls to the Forward Page function page, customize the layout of controls in the page, and define the tab order in the GUI Layout Setup manager.

Project administrators may rename the page title and edit the Forward To, Substatus, and Forward Note controls. Customization of Forward Incident manager controls is restricted:

• The Forward To control: customize the label only.

• The Sub-status control: customize the label, change the field attributes (visible, mandatory), and define dropdown values. Additionally, the Sub-status field can be set up as a child of the Progress Status field, and can be used as a reason field for each progress state (similar to a parent/child relationship). For example, perhaps if an incident is forwarded to a Researching state, applicable sub-statuses, or reasons, could be Requires analysis or Replicate bug. The field is also on the New dialog box. Any changes made to the field here will be reflected on this page. This field can help increase communication between team members.

• The Forward Note control: customize the label and specify if the field is mandatory.

All other fields are retitled by customizing the related field on the Description page.

6.6.4 Customizing the Close Incident Manager (Close Function Page)

In the CustomerWise client, the Forward Incident manager is a form page that enables project members to define incident properties when they reassign (forward) a support incident to another owner.

Project administrators may add and remove system, custom, and multiple-selection controls to the Forward Page function page, customize the layout of controls in the page, and define the tab order in the GUI Layout Setup manager.

Project administrators may rename the page title and edit the Forward To, Substatus, and Forward Note controls. Customization of Forward Incident manager controls is restricted:

• The Forward To control: customize the label only.

• The Sub-status control: customize the label, change the field attributes (visible, mandatory), and define dropdown values. Additionally, the Sub-status field can be set up as a child of the Progress Status field, and can be used as a reason field for each progress state (similar to a parent/child relationship). For example, perhaps if an incident is forwarded to a Researching state, applicable sub-statuses, or reasons, could be Requires analysis or Replicate bug. The field is also on the New dialog box. Any changes made to the field here will be reflected on this page. This field can help increase communication between team members.

• The Forward Note control: customize the label and specify if the field is mandatory.

All other fields are retitled by customizing the related field on the Description page.

 Chapter 7 Project Web Administration

7.1 Managing CustomerWise Web Settings

Project administrators may use controls in the List View Refresh Option page. to define how projects are displayed in the CustomerWise Web client. Administrators may define separate project settings for the Windows client and the Web client.

7.1.1 Defining CustomerWise Web List Window Refresh Options

Project administrators may define how the Incident List window is refreshed in the CustomerWise Web client using controls in the List View Refresh Option page.

Project administrators may choose between three options;

• Always autorefresh

• Always manual refresh

• Based on user preference

Project administrators may also define list view refresh options for project Windows clients in the List View Refresh Option page. For more information see “Defining List View Refresh Options” .

7.1.2 Defining Maximum Number of Tabs Displayed in CustomerWise Web

Project administrators may define the maximum number of tabbed pages that may be displayed in the Detail window of the Incident, Event, and Customer views using controls in the List View Refresh Option page.

• To define the maximum number of tabs displayed in the Incident Detail window, enter a number in the Incident Detail text field.

• To define the maximum number of tabs displayed in the Incident Detail window, enter a number in the Event Detail text field.

• To define the maximum number of tabs displayed in the Incident Detail window, enter a number in the Customer Detail text field.

Administrators may also enable the Detail window of the CustomerWise Web client to display multiple rows of tabs.

To enable multiple rows to be displayed in a view, select the Support Multiple Rows check box next to the appropriate view.

7.1.3 Defining CustomerWise Web Customer Quick Search Fields

Project administrators may define which customer fields project members may use to search for customers using the Customer Quick Search in the CustomerWise Web client.

Administrators may add or delete customer fields using controls in the List View Refresh Option page.

Project administrators may add up to 12 customer properties to the Customer Quick Search:

• Customer ID

• Customer ID (External ID)

• Company Name

• Main Phone

• Incident #

• Asset#

• SLA Plan ID

• Contact's First Name

• Contact's Last Name

• Contact's Phone

• Customer Scope

• Industry Type

7.2 Managing the Internal Team Web

Project administrators may define how the Incident List window is refreshed in the CustomerWise Web client using controls in the List View Refresh Option page.

Project administrators may choose between three options;

• Always autorefresh

• Always manual refresh

• Based on user preference

Project administrators may also define list view refresh options for project Windows clients in the List View Refresh Option page. For more information see “Defining List View Refresh Options” .

7.2.1 Defining the Project Runtime Keys

A runtime key is comparable to an administrator-defined password that control access to CustomerWise projects through the CustomerWise Web client. Project administrators may define project runtime keys in the Internal Team Web page of CustomerWise work projects.

Project runtime keys are represented by a string of up to 20 characters that is appended to CustomerWise project URLs. Once a project administrator defines a project runtime key, project members may only access the CustomerWise project Login page if the project runtime key passed in the URL matches the project runtime saved in the TechExcel CustomerWise database.

Project runtime key do not replace the need to log into a project with a user name and password, but provide an additional level of protection to CustomerWise projects. After a project member passes the appropriate runtime key, user authentication is still required to access a project.

Project administrators may define a unique runtime key for each CustomerWise project. Project members must add both the project ID number and the runtime key to access the project Login page.

The URL for a CustomerWise work project (marketing, sales and support) would use the following format:

…\CustomerWise.dll?ProjectID=XX&Runtimekey=YY

Customers accessing the same project would be required to enter the following URL:

…\CLogin.dll?ProjectID=XX&Runtimekey=YY

Note:Administrators may access the project ID for each CustomerWise project using Open Project manager in the CustomerWise Admin client. The project ID is displayed next to the name of each project.

7.2.2 Project runtime keys and system runtime keys

Companies that maintain several CustomerWise projects and who wish to restrict access to certain projects may use a system login key in combination with the project runtime key to add an additional level of security to their projects. In CustomerWise sites where administrators have defined a system runtime key and individual project runtime keys, project members may access CustomerWise through two different URLs, each with the appropriate level of access.

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 CustomerWise projects. For more information system runtime keys see See “Defining the System Runtime Key” .

Note:If no system or project runtime keys are defined, each project members may access TechExcel CustomerWise Web using the default URLs..

7.2.3 Reloading CustomerWise Web Settings

For performance reasons, all TechExcel CustomerWise Web settings are cached in the TechExcel CustomerWise Web Server. Any changes that an administrator makes to a the project Web settings, must be reloaded to the CustomerWise Web Server.

To reload CustomerWise Web settings, click the Reload Web Settings button in the Internal Team Web page of a CustomerWise work project. A dialog box confirms that the project Web settings were successfully reloaded.

Project members cannot see project changes in their CustomerWise Web clients until the administrator reloads those changes to the CustomerWise Web Server.

Note:TechExcel recommends that administrators stop their web server while they make changes to a production project in TechExcel CustomerWise Admin. The web server should be restarted only after changes have been completed and tested.

.

7.2.4 Customizing the Team Login Page

Customize some basic Web features for users accessing the current project on the Team Login Page tab.

7.2.5 Defining Web Login Titles and Messages at the Project Level

Project administrators may define project-specific login page title and welcome messages that are displayed to CustomerWise Web client users using controls in the Internal Team Web page.

To define Web Login Titles, enter the appropriate HTML text in the title and message text areas.

• The title displays above the user login fields.

• The message will display below the user login fields.

CustomerWise Login page titles and welcome messages may be defined at both the system level and the project level. Project Login page titles and welcome messages are only displayed if the user passes the project ID in the URL.

The syntax for passing the project ID in the URL:

…\CustomerWise.dll?ProjectID=XX

If the project ID is not passed in the URL, the CustomerWise client automatically loads the system title and welcome message. For more information on system titles and welcome messages seeSee “Defining Web Login Titles and Messages at the System Level” .

7.2.6 Defining CustomerWise Web Logo URLs

Project administrators may define a URL that is linked to the logo displayed in the CustomerWise Web client using controls in the Internal Team Web page.

CustomerWise Web client by default displays the TechExcel CustomerWise logo in the upper right hand corner of the browser window.

Figure 7-1: CustomerWise Web Client GUI (Detail)

Project members may click the TechExcel CustomerWise logo to access the URLs linked to that logo. Project administrators may make any internet or intranet page accessible through this link. CustomerWise Web logo URLs may be defined for each CustomerWise project.

Note:The default target of the logo ishttp:// www.techexcel.com..

To define the URL that may be accessed by clicking this logo, enter a URL in the URL linked to Support Team Web Logo text field in the Internal Team Web page.

7.2.7 Customizing CustomerWise Web Logos

Project administrators may customize the graphical user interface displayed in the CustomerWise Web client and Customer Web Portal to display the logo of their company.

The TechExcel CustomerWise logo that is displayed in the upper right hand corner of the browser window may be replaced with another graphic of the same dimensions. The TechExcel CustomerWise logo is namedfrontofficelogo.gif and is stored in beneath the root directory of the web server:

C:\Inetpub\wwwroot\SWiseWeb\Images

To replace the TechExcel CustomerWise logo with another logo, save the customized logo as a GIF file (120 pixels wide by 25 pixels high) to the image folder. The custom logo must be renamed frontofficelogo.gif.

To customize the logo displayed in the Customer Web Portal, save the custom logo as a GIF file named frontofficelogo_cust.gif to the same directory. For more information on customizing the Customer Web Portal see “Understanding the Customer Web Portal”.

7.2.8 Managing Knowledge Base Virtual Directories

Project administrators may enable support for external knowledge indexing services using controls in the Knowledge Base tab of the Internal Team Web page.

TechExcel CustomerWise currently supports integration with the Microsoft Index Server for external document searching from within the TechExcel CustomerWise knowledge view.

The Microsoft Index Server is designed so that the indexing process occurs behind the scenes, requiring no user input and minimizing demands on system resources. Setting up searchable files and Web pages are easy and can be performed using the Microsoft Internet Information Server.Zero maintenance is required once the searchable scope of documents and Web pages are setup.

The Index server automatically updates when documents are changed, added, or deleted. Once you have setup the searchable virtual directories for the Index Server, you may further select one or multiple virtual directories for more specific searching.

The Microsoft Index Server must be installed on the same TechExcel CustomerWise Web server computer. The type of external documents supported by the Microsoft Index Server include HTML files, Web sites, text documents, Word, Excel, Power Point presentations, and other Microsoft Office documents.

Searchable documents include Microsoft office documents, text files, and HTML pages. TechExcel CustomerWise knowledge searching can be performed within the TechExcel CustomerWise Web application or be integrated with your company Web site.

By default, TechExcel CustomerWise searches the entire Microsoft Index Server. You can define sub categories of the Index Server so that only portions of the Index Server knowledge topics and key words are searched.

TechExcel CustomerWise also supports external knowledge base solutions.

To define virtual directories for external documents:

1Install the Microsoft Index Server.

Microsoft Index Server builds an index of your Web server that can be easily searched from any Web browser using the sample query forms. Indexing maps specific words to individual documents, and to locations within the document.

2Select the Microsoft Index Server option in the KB Support Type dropdown list of the Knowledge Base tab in the Internal Team Web page.

3Select the Support Microsoft Index Server check box.

The check box Support Microsoft Index Server is for enabling/disabling the Index Server support feature.

4Click the New button.

The Virtual Directory for External Documents dialog box appears.

5Define the name.

6Define the virtual path.

Please note that these virtual directories must be created in the Microsoft Internet Information Server, and must be pointing to the physical directory on the TechExcel CustomerWise Web server computer.

Note:To set up an Index Server sub directory, you will need to specify the virtual directory name of the corresponding sub group of documents. For detailed discussions on using MS Index Server, please refer to MS Index Server user guide or its online help.

7To enable options select the check boxes.

The Available to Customers The Available to Other Projects

8Describe the virtual directory.

9Click the OK button.

Once the Index Server service is enabled on your TechExcel CustomerWise Web server computer, you can manage the MS Index Server via the Microsoft Internet Information Server.

7.2.9 Defining Team IP Addresses

Project administrators may identify the IP addresses of project team members in the The Team IP Addresses tab of the Internal Team Web page.

CustomerWise tracks the IP address for every user login and Web Click recorded for each CustomerWise Web site (the CustomerWise internal team project and the Customer Web Portal). The IP addresses enable organizations track customer interest and help qualify leads in TechExcel MarketingWise.

The IP addresses defined in the Team IP Addresses tab (usually those of project team members) are not tracked by the CustomerWise system. Organizations may want to exclude the IP addresses of support or sales team members who frequently use or test the Customer Web Portal or Web Clicks features.

If the last number in the specified IP address is 0, then all the IP addresses with the other three numbers are excluded. If the last two numbers in the specified IP address are 0s, then all the IP addresses with the other two numbers are excluded.

7.2.10 Removing Team Login and Web Clicks Histories

Project administrators may identify the IP addresses of project team members in the The Team IP Addresses tab of the Internal Team Web page.

CustomerWise tracks the IP address for every user login and Web Click recorded for each CustomerWise Web site (the CustomerWise internal team project and the Customer Web Portal). The IP addresses enable organizations track customer interest and help qualify leads in TechExcel MarketingWise.

The IP addresses defined in the Team IP Addresses tab (usually those of project team members) are not tracked by the CustomerWise system. Organizations may want to exclude the IP addresses of support or sales team members who frequently use or test the Customer Web Portal or Web Clicks features.

If the last number in the specified IP address is 0, then all the IP addresses with the other three numbers are excluded. If the last two numbers in the specified IP address are 0s, then all the IP addresses with the other two numbers are excluded.

 Chapter 8 Advanced Incident Administration

8.1 Administering Incident Linking

In CustomerWise, 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.

8.1.1 Understanding Incident Linking

CustomerWise 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 CustomerWise client. All incident linksbidirectional: project members may view and track detailed information about either incident by accessing the linked incident in the CustomerWise client.

Whenever a project member creates a link between two incidents in the CustomerWise 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 CustomerWise projects, between support incidents in CustomerWise and CustomerWise projects, or between CustomerWise support incidents and DevTrack development issues. For more information see See “Understanding Interproject Copying and Linking”.

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

8.1.2 Defining Referential Link Types

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 status 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 CustomerWise 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.

8.1.3 Defining Parent-Child Link Types

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 Incident:The 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 Closed:The 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 Closed:The 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 Closed:The 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 Closed:The 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 Closed:The 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 CustomerWise 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.

8.2 Managing the Web Conversation Page

CustomerWise 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 CustomerWise client. All incident linksbidirectional: project members may view and track detailed information about either incident by accessing the linked incident in the CustomerWise client.

Whenever a project member creates a link between two incidents in the CustomerWise 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 CustomerWise projects, between support incidents in CustomerWise and CustomerWise projects, or between CustomerWise support incidents and DevTrack development issues. For more information see See “Understanding Interproject Copying and Linking”.

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

8.3 Administering Incident Workflow State Display Order

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 status 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 CustomerWise 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.

8.4 Managing Incident Priority

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 Incident:The 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 Closed:The 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 Closed:The 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 Closed:The 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 Closed:The 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 Closed:The 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 CustomerWise 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.

8.4.1 Understanding the Incident Prioritization Page

Project administrators may use controls in the Incident Prioritization page of the Advanced Project Settings folder in CustomerWise Admin to enable and define incident priority management in CustomerWise projects.

Figure 8-1: Incident Prioritization page

The Incident Prioritization page consists of three tabbed pages:

• The General Setting page enables administrators to enable incident prioritization features.

• The Prioritization Weight page enables administrators to define weights for prioritizing incidents in a project.

• The Privilege page enables administrators to grant privileges to project members based on their account type.

8.4.2 Enabling Incident Prioritization

Project administrators may use controls in the General Settings tab of the Incident Prioritization page to enable incident prioritization management in CustomerWise projects.

Project administrators may enable incident prioritization management for managers and enable prioritization calculations.

• The Support Prioritization Order Assignment by Managers option enables prioritization order numbers to be displayed to project members in their CustomerWise clients. Every incident is associated prioritization order number which project members may view or edit in the Prioritization list. Incident prioritization order numbers do not change unless manually adjusted by a user with the appropriate privileges.

• The Support Prioritization Value Calculation option enables prioritization values to be displayed to project members in their CustomerWise clients. Every incident is associated prioritization value which project members may view in the Prioritization list.

8.4.3 Defining Priority Value Management

Project administrators may use controls in the Incident Prioritization page of the Advanced Project Settings folder in CustomerWise Admin to enable and define priority value management in CustomerWise projects.

When a project team uses priority value management the priority value of an incident is automatically calculated based on an administrator-defined formula. The formula that calculates the priority value of each incident is based on two primary factors: incident property definitions and time factors.

Incident property definitions

Project administrators may define select which data-entry controls are applicable for determining incident priority values and assign weights to the options displayed in each applicable field.

Incident time factors

Time factor priority values are based on the number of days that an incident remains open and the weight that the administrator assigns to the factor. Project administrators may enable up to three time factors and assign a weight for each time factor. Time factors include the number of days that the incident has been open, the number of days since the incident was last modified, or the number of days the incident is past due. For each time factor the administrator-defined weight is multiplied by the number of days the incident has remained open to arrive at a value.

To define priority value management settings:

1Select the Incident Prioritization page in the Advanced Project Settings folder of the Admin Tree window.

2Select the General Setting tab

3Select the Support Priority Value (Severity Number) tab.

4Select options in the Applicable Fields for Priority Value field.

Project administrators may define priority weights for the options available in all selected applicable controls.

5Enable one or more time factor option by selecting the appropriate check boxes.

6Define a weight for each selected time factor option.

CustomerWise multiples the weight by a number of days to arrive at a time factor.

• The Days Open option represents the number of days that the incident is open. If an incident was created twenty days previously, the weight is multiplied by twenty to arrive at the time factor.

• The Days Since Modified option represents the number of days since an incident was last modified. If an incident was modified ten days previously, the weight is multiplied by ten to arrive at the time factor.

• The Days Past Due option represents the number of days since an incident was last modified. If the deadline for an incident passed three days previously, the weight is multiplied by three to arrive at the time factor

7Select the Priority Weight tab.

8Select an option in the Field list.

Only those fields selected in the Applicable Fields for Priority Value list of the General Setting tab are displayed in the Field list.

9Select an option in the Choice list.

The Choice list displays all of the options displayed in the selected multiple choice list control.

10Enter a value in the Weight field.

The weight value of each choice represents the relative weight assigned to that field choice.

8.4.4 Granting Incident Prioritization Access Controls

Project administrators may grant two priority order management privileges to each account type.

• The Can Edit Own Priority Order privilege

• The Can Edit All Priority Order privilege

Project members may not change the priority value of incidents. Priority order management privileges are granted to project account types. Project members inherit all privileges assigned to their account type.

To grant incident prioritization privileges:

1Select the Privilege tab.

2Select an account type in the Account Type list.

3Select privilege options for the selected account type.

8.5 Administering the Change Log

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 e-mail 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 E-mail option

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

 Chapter 9 Interproject Copying and Linking

9.1 Understanding Interproject Copying and Linking

CustomerWise interproject management 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.

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

• An interproject copy is a procedure by which a CustomerWise project member may copy a support incident to other CustomerWise projects, CustomerWise or DevTrack projects from a CustomerWise client.

• An interproject link 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 CustomerWise 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 CustomerWise 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 CustomerWise project.

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

9.1.1 Administrating Standard Interproject Actions and Linking

Standard interproject action and linking administration is a seven 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. Everylink 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.

9.2 Enabling and Configuring Interproject Copying and Linking

Standard interproject action and linking administration is a seven 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. Everylink 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.

9.2.1 Enabling Target Projects

Atarget projectis a CustomerWise, ServiceWise, 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 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.

9.2.2 Enabling Interproject Copying

Interproject copying enables project members to duplicate support incidents in the current work project and submit copies of those incidents to other CustomerWise, ServiceWise or DevTrack projects.

To enable interproject copying between the current CustomerWise project and another CustomerWise, ServiceWise, or DevTrack project, select the target project in the project list and select the Enable Interproject Copying check box in the General Setting tab of the Interproject Copying page of the Advanced Settings folder.

9.2.3 Enabling Interproject Linking

Interproject linking enables project members to create links between support incidents in the current work project and support incidents or development issues in other CustomerWise, ServiceWise or DevTrack projects.

To enable interproject linking between the current CustomerWise project and another CustomerWise, ServiceWise or DevTrack project, select the target project in the project list and select the Enable Interproject Copying check box in the General Setting tab of the Interproject Copying page of the Advanced Settings folder.

9.2.4 Enabling Workflow Status Editing

Interproject workflow state editing rules enable project members to update the incident workflow state of linked support incidents in other projects.

To enable the management of incident workflow states between the current CustomerWise project and another CustomerWise, ServiceWise or DevTrack project, select the target project in the project list and select the Can Edit Progress Status check box in the General Setting tab of the Interproject Copying page of the Advanced Settings folder.

9.2.5 Enabling Incident Owner Editing

Interproject incident owner editing rules enable project members to update the ownership status of linked support incidents in other projects.

To enable the management of incident owners between the current CustomerWise project and another CustomerWise, ServiceWise or DevTrack project, select the target project in the project list and select the Can Edit Owner check box in the General Setting tab of the Interproject Copying page of the Advanced Settings folder.

9.2.6 Defining Default Owners in Target Project

In CustomerWise,default incident owner rulesdetermine which project member or group folder is defined the default owner of incidents copied to that project.

Any user account, group folder, or the{autoassign} variable may be defined as the default owner of the incident in the target project.

• If a user account is selected, that project member is defined as the default owner of all incidents copied between the two projects.

• If a group folder is selected, that group folder is defined as the default owner of all incidents copied between the two projects.

• If the {autoassign} variable is selected, administrator-defined routing rules determine how the incident is assigned in the target project. For more information on incident routing rules see See “Administering Incident Routing”.

The selected project member or group folder is the default owner of all incidents submitted or copied to that project by an interproject action.

To define the default owners in a target project:

1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder.

All interproject action rules are defined on a project-by-project basis and onlyapply to the selected target project. A target project is enabled for interproject actions when a red check mark appears next to the project title.

2Select an option in the Default Folder/Member to be Assigned dropdown list.

The Default Folder/Member to be Assigned dropdown list displays the group folders and project members in the target project as well as the{autoassign} variable.

9.2.7 Work Description Editing Rules

Interproject workflow description editing rules enable project members to edit work descriptions of linked support incidents in other projects.

To define the default owners in a target project:

1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder.

All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title.

2Select an option from the Work Description and Other Properties dropdown list.

The Title and Description dropdown list displays three options:

• Edit with Timestamp

• Freely edit

• Read-only

9.2.8 Title and Description Editing Rules

Interproject workflow description editing rules enable project members to edit the title and description of linked support incidents in other projects.

To define the default owners in a target project:

1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder.

All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title.

2Select an option from the Title and Description dropdown list.

The Title and Description dropdown list displays three options:

• Edit with Timestamp

• Freely edit

• Read-only

9.2.9 Defining Concatenated Incident Title Prefixes

In CustomerWise, a title prefix is an administrator-defined text string that is automatically concatenated to the title of incidents copied across projects.

By default, incidents copied to the target project share the same title as the original incident. Thus, an incident titledCannot login to accounting web clientin the original project would be titledCopied East Coast: Cannot login to accounting web clientin the target project if the title prefix is “Copied East Coast: “.

Concatenated title prefixes enable support organizations to quickly identify, filter, and sort incidents that have been added to their projects using interproject actions.

To define concatenated incident title prefixes:

1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder.

All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title.

2Enter a text string in the Title Prefix Concatenated text box.

9.2.10 Defining Default Account Type Access Rules

In CustomerWise, default account type access rulesdefine which project members may access linked incidents in other projects based on their account type.

Default account type access rules enable users of a particular account type to access and manage support incidents in other projects even though they are not members of those projects.

To define default account type access rules:

1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder.

All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title.

2Select an option from the Default Account Type dropdown list.

The default account type enables project members that are not members of the target project to submit, copy, or link incidents between their CustomerWise project and the target project.

9.2.11 Defining Default Subprojects

In CustomerWise, default subproject interproject copying rules define the subproject to which incidents are copied to in the target project using an interproject action.

To define default subprojects:

1Select an enabled target project in the project list in the General Setting tab of the Interproject Copying page in the Advanced Features folder.

All interproject action rules are defined on a project-by-project basis and only apply to the selected target project. A target is enabled for interproject actions when a red check mark appears next to the project title.

2Click the ellipsis button and select a subproject in the Subproject dropdown list.

3Click the OK button.

9.3 Mapping Incident Property Fields

Interproject actions enable project members to copy the incidents managed in one CustomerWise project and submit copies of those incidents to other CustomerWise, ServiceWise 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 CustomerWise 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.

9.3.1 Manually Mapping Incident Fields

The mapping of incident property fields between CustomerWise projects, or between a CustomerWise project and a TechExcel DevTrack or TechExcel CustomerWise project, enables project members to submit or copy incidents between heterogeneous projects.

The Map button enables administrators to manually map CustomerWise pages and fields on a field by field basis.

Project administrators may map incident fields between two CustomerWise projects or between a CustomerWise project and a TechExcel CustomerWise or TechExcel DevTrack project controls in the Field Map tab of the Interproject Settings page.

To manually map incident fields between projects:

1Select a project in the project list of the Interproject Copy page.

The project must be enabled for the administrator to define incident mapping. A project is enabled for interproject actions when a red check mark appears next to the project title.

2Enable and define incident copying settings.

The administrator must enable interproject copying using controls in the General tab.

3Select the Field Map tab.

The Map Fields list displays the page title and field title for every field (data-entry control) used to define incident properties in the current project. Project administrators may identify the corresponding page and field for each incident property setting.

4Select a field in the Map Fields list.

5Click the Map button.

The Field Map dialog box appears.

6Select page and field options from the Page dropdown list and the Field dropdown list.

7Click the OK button.

The Map Fields list displays the field mapping settings. For each multiple choice control (for example, dropdown lists) mapped the administrator may map the options displayed in the multiple choice controls in each project.

9.3.2 Automatically Mapping Incident Fields

Automatic interproject field mapping is the fastest way for project administrators to map fields in two CustomerWise projects, or a CustomerWise project and a TechExcel CustomerWise project or a TechExcel DevTrack project.

The Auto Map button enables project administrators to instantly map CustomerWise fields to fields in the linked project.

Incorrectly mapped fields may be edited or unmapped.

Project administrators may map incident fields between two CustomerWise projects or between a CustomerWise project and a TechExcel CustomerWise or TechExcel DevTrack project controls in the Field Map tab of the Interproject Settings page.

To automatically map fields between projects:

1Click the Auto Map button in the Field Map tab.

The fields in the CustomerWise project are mapped to fields in the target project.

2Ensure that the fields mapped together are appropriate.

3To edit or unmap mapped fields, select the field in the Map Fields list and click the Map button.

• Select an appropriate page and field or select theoption.

• Click the OK button.

For each multiple choice control (for example, dropdown lists) mapped the administrator may map the options displayed in the multiple choice controls in each project.

9.3.3 Defining Mapped Field Choices

Project administrators may use the Field Choice Map tab in the Interproject Settings page to map the options that are displayed in mapped multiple-selection controls in linked incidents.

For each multiple selection control that the administrator mapped in the Field Map tab, the administrator may now map the options displayed in the control in the CustomerWise project to options displayed in the control of the target project.

The Field Choice Map tab is divided into two main areas:

• The Mapped Field with Multiple Choice list displays every mapped multiple choice control that are mapped between the current project and the target project. Project administrators may map fields using controls in the Field Map tab.

• The Map Field Choice Map list displays the options displayed in a selected multiple choice control in the current project. Project administrators may map the field choice to a field choice belonging to the mapped multiple choice control displayed in the target project.

Project administrators may map the field choices for each multiple choice control that is mapped in the Field Map tab.

To map incident fields between projects:

1Select a project in the project list of the Interproject Copy page.

The project must be enabled for the administrator to define incident mapping. A project is enabled for interproject actions when a red check mark appears next to the project title.

2Enable and define interproject copying settings.

The administrator must enable copying using controls in the General tab.

3Map the fields that are used to define incident properties in each project.

Project administrators must map the multiple selection controls in the Field Map tab before they can map the field choices belonging to those controls.

4Select the Field Choice Map tab.

5Select a mapped multiple choice control in the Mapped Field with Multiple Choice list.

The Mapped Field with Multiple Choice list displays every selection control in the current project that is mapped to a multiple choice control in the target project. The selection control selected determines the options that are displayed in the Map Field Choice Map list.

6Double-click a field choice in the Map Field Choice Map list.

The Choice Map dialog box appears.

7Select an option from the Map To dropdown list.

The options displayed in the Map To dropdown list represent the list options displayed in the mapped multiple choice control in the target project.

8Click the OK button.

The Choice Map dialog box closes.

9.3.4 Defining Default Field Values for Unmapped Fields

To define a default field value or unmapped fields:

1Select a project in the project list of the Interproject Copy page.

The project must be enabled for the administrator to define incident mapping. A project is enabled for interproject actions when a red check mark appears next to the project title.

2Define interproject field mappings.

3Define field value mapping for mapped interproject fields.

4Select field mapping in the Mapped Field with Multiple Choices list.

The Mapped Field with Multiple Choices list displays the title and field ID numbers of multiple choice controls (such as dropdown lists and combo boxes) in the current project and the corresponding controls in the target project.

5Select the Enable Field Value for Unmapped Field Choice check box.

6Select an option from the Field Value dropdown list.

The Field Value dropdown list displays the values that define the mapped field in the target project.

9.4 Administering Linked Issue Customer Web Portal Settings

Atarget projectis a CustomerWise, ServiceWise, 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 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.

9.4.1 Displaying Linked Issue Info in the Customer Web Portal

To display information about DevTrack development issues that are linked to support incidents in the Customer Web Portal, select the Display Linked Info in the Customer Web Portal check box.

In each Employee Web Portal, a project administrator must determine which development issues are displayed to company employees. For more information see “Displaying DevTrack Project Development Issues”.

9.4.2 Displaying Linked Issue Info in the Web Conversation Page

To display information about DevTrack development issues that are linked to support incidents in the CustomerWise client Web Conversation page, select the Display Linked Info in the Web Conversation check box.

9.4.3 Defining Applicable Incident Workflow States

To define applicable incident workflow states, select one or more incident workflow states in the Applicable Incident State list box. An incident workflow state is defined as applicable when a red check mark is displayed adjacent to its title.

9.4.4 Defining Applicable Link Types

To define applicable link types, select one or more incident link types in the Applicable Link Type list box. A link type is defined as applicable when a red check mark is displayed adjacent to its title.

9.4.5 Defining Title for Linked Issue Data

To define a title of linked development issue data in the Customer Web Portal and CustomerWise client Web Conversation page, enter a name in the Linked Issue Info Section Title edit box.

9.4.6 Adding Linked Issue Information Fields

To define a title of linked development issue data in the Customer Web Portal and CustomerWise client Web Conversation page, enter a name in the Linked Issue Info Section Title edit box.

 Chapter 10 Workflow Administration

10.1 Understanding CustomerWise Project Workflow

TechExcel CustomerWise delivers a flexible workflow model that enables project administrators to replicate and enforce their marketing, sales, and support processes in CustomerWise projects.

Project administrators may define workflow rules, autorouting rules, and escalation rules to ensure that every incident managed in a project is handled in an efficient manner.

• Project workflow determines the life cycle of CustomerWise incidents. Administrators may define workflow settings once in TechExcel CustomerWise Admin, all project members will manage incidents and opportunities according to your existing processes.

• Graphical workflow

• Incident autorouting 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 autoescalation 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. Administrators may also enable e-mail notifications for all autoescalations.

By combining administrator-defined workflow, autorouting, and autoescalation rules, TechExcel CustomerWise enables administrators to define flexible and powerful process management tools

10.1.1 Understanding CustomerWise Project Workflow

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 CustomerWise enables each project administrator to define a unique set of workflow rules to manage the incidents in that project. Each marketing project, sales project, and support project is managed by its own unique workflow rules.

In all CustomerWise projects, project members may submit, update, forward and close incidents.

• A project member submits a incident to a project by defining incident properties, assigning the incident to an applicable owner, and sending the incident to an appropriate workflow state.

• The second project member updates incident properties and assigns the incident to another owner.

• The third project member forwards the incident to another workflow state and assigns it to an applicable owner.

• The fourth project member closes the incident by sending the incident to a closed workflow state.

10.1.2 Understanding Sales Project Workflow

Project administrators may define workflow rules to manage the sales opportunities created in sales projects using tools in the Sales Workflow folder of the CustomerWise Admin Tree window.

Figure 10-1: Sales Project Workflow Chart

The Sales Workflow folder contains two system pages: the Workflow Design page and the Workflow Setting page.

• The Workflow Design page enables project administrators to define project workflow states and transitions using graphical workflow tools.

• The Workflow Settings page enables project administrators to define workflow rules for states and transitions.

The sample sales project manages sales opportunities using 11 distinct workflow states: a new state, a closing state, and nine intermediary states.

• New

• NewOpportunity

• Sales Qualified

• Sales Disqualified

• Quoted

• Sales Lost

• Order Received

• Purchase Pending

• Purchased/Payment Pending

• Purchased/Payment Received

• Closed

10.1.3 Understanding Support Project Workflow

Project administrators may define workflow rules to manage the support incidents created in support projects using tools in the Incident Workflow folder of the CustomerWise Admin Tree window.

Figure 10-2: Support Project Workflow Chart

The Incident Workflow folder contains two system pages: the Workflow Design page and the Workflow Setting page.

• The Workflow Design page enables project administrators to define project workflow states and transitions using graphical workflow tools.

• The Workflow Settings page enables project administrators to define workflow rules for states and transitions.

The sample support project manages incidents using eight distinct workflow states: a new state, a closing state, and six intermediary states.

• New

• New Incident

• In Level-1 Support

• Resolved

• In Level-2 Support

• In Development

• Resolved - Notify Customer

• Closed

10.1.4 Understanding Marketing Project Workflow

Project administrators may define workflow rules to manage the marketing tasks created in marketing projects using tools in the Incident Workflow folder of the CustomerWise Admin Tree window.

Figure 10-3: Marketing Project Workflow Chart

The Incident Workflow folder contains two system pages: the Workflow Design page and the Workflow Setting page.

• The Workflow Design page enables project administrators to define project workflow states and transitions using graphical workflow tools.

• The Workflow Settings page enables project administrators to define workflow rules for states and transitions.

The sample marketing project manages incidents using seven distinct workflow states: a new state, a closing state, and five intermediary states.

• New

• Planning

• In Progress

• Cancelled

• Delayed

• Completed

• Closed

10.2 Administrating Incident Workflow

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 CustomerWise enables each project administrator to define a unique set of workflow rules to manage the incidents in that project. Each marketing project, sales project, and support project is managed by its own unique workflow rules.

In all CustomerWise projects, project members may submit, update, forward and close incidents.

• A project member submits a incident to a project by defining incident properties, assigning the incident to an applicable owner, and sending the incident to an appropriate workflow state.

• The second project member updates incident properties and assigns the incident to another owner.

• The third project member forwards the incident to another workflow state and assigns it to an applicable owner.

• The fourth project member closes the incident by sending the incident to a closed workflow state.

10.2.1 Defining the Project Workflow Model

Administrators may use controls in the Workflow Settings page to select the workflow model that is used to define manage incidents in CustomerWise 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 CustomerWise 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 CustomerWise, 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.

• In the no workflow model project members may update the status of incidents by directly changing the workflow state to any other workflow state. Administrators may not define workflow rules that restrict the flow of incidents in a project.

• In the state-dependent workflow model project members may update the status of incidents by directly changing the workflow state to any applicable subsequent state. All workflow rules in the state-dependent workflow model are state-based.

• In the transition-dependent workflow model project members update the status of incidents by performing actions. Actions represents the transitions between workflow states. All workflow rules in the transition-dependent workflow model are state-based.

Note:Workflow models should not be confused with workflow rules. Administrator-defined workflow rules restrict the changes that project members may make to incidents based on the current state. Administrators define workflow rules for each state in the incident life cycle regardless of the workflow type (state-dependent workflow, or transition-dependent workflow).

To select a project workflow model:

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

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

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

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

10.2.2 Enabling Workflow Rule Options

Project administrators may use controls in the Workflow Settings page to enable and define optional workflow rules in CustomerWise projects. Workflow rules determine which project members may manage incidents in each workflow state and what changes they may make to those incidents.

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

•NextStaterules determine the sequence of workflow states in the incident life cycle.

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

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

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

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

• 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.

10.2.3 Creating, Editing, and Deleting Workflow States

Administrators may create, edit, or delete workflow states using controls in the Progress States area of the Workflow Setting page.

Every workflow state defined in a CustomerWise project is displayed in theProgressStatelist.

A workflow state represents a distinct stage in the life cycle of an incident. The workflow states that an administrator defines within a project depend on the project type (marketing project, sales project, or support project), the incident types managed in that project, and the scope of the project.

Administrators may define six distinct properties whenever they create or edit a workflow state:

• The Name control enables the administrator to define or edit the name of the workflow state.

• The Can be anInitialStatecontrol enables the administrator to designate the workflow state as an opening state in the incident life cycle. Newly created incidents may be forwarded to initial states.

• The Can be Closed at this State control enables the administrator to designate the workflow state as a closing state in the incident life cycle. Project members may close incidents in this workflow state.

• The Can be Reopen to this State control enables the administrator to designate the workflow state as a reopening state in the incident life cycle. Project members may reopen closed incidents to this workflow state.

• The Customer Access to the Incident control enables administrators to grant access customers access to incidents in the current workflow state. Administrators may grant three levels of access to customers: full access, read access, and no access.

• The Comments control enables the administrator to add a brief note to the incident that describes its purpose in project workflow.

Note:Workflow progress states may be created, edited, or deleted in both the Workflow Settings page and in the Workflow Design page.

10.2.4 Defining Applicable Owner Workflow Rules

Project administrators may enable and define Applicable Owner workflow rules in the Workflow Settings page of the Incident Workflow folder.

Applicable Owner rules determine which project members, groups, or group folders may own incidents in each workflow state. Administrators may define a different set of applicable owners for each workflow state in the incident life cycle.

Administrators may use Applicable Owner workflow rules to ensure that only appropriate project members may own incidents in particular workflow states. For example, administrators may not want Level I Support Engineers (an account type) to own incidents in the Development workflow state of the support incident life cycle. Administrators may wish to restrict ownership of incidents in that workflow state to Level II Support Engineers.

Administrators may restrict incident ownership based on nine different options:

• The Account Type option enables the administrator to define any user of this account type as a potential owner of incidents in the selected workflow state.

• The Team Group option enables administrators to designate a group of project members as potential owners of incidents in the selected workflow state.

• The autoassignment option allows administrators to enable autoassignment of incidents based on administrator-defined autorouting rules.

• The Primary Support option enables administrators to designate the primary support engineer for associated customers of incidents as potential owners in the selected workflow state.

• The Sales Person option enables the administrator to designate sales persons for the associated customer of incidents as potential owners in the selected workflow state.

• The Submitter option enables administrators to define the original submitters of incidents as potential owners of those incidents in the selected workflow state.

• The Unassigned option enables the administrator to allow incidents in the selected workflow state to be assigned to the Unassigned variable. The Unassigned system variable enables project members to designate incidents as having no owner in a workflow state.

• The Group Folder option enables the administrator to define a workflow rule that allows incidents in the selected state be to assigned to the selected group folders.

• The User option enables the administrator to designate selected project members as potential owners of incidents in the selected workflow state.

To define Applicable Owner workflow rules:

1Select the Support Applicable Owners check box in the Support Options area of the Workflow Settings page.

The Applicable Owners option enables administrators to define the project members, account types, and groups that may own incidents in each workflow state.

2Select a workflow state in theProgressStatelist.

3Select one or more applicable owners in the Applicable Owner tab.

The Applicable Owner tab displays the project members, groups, group folders, and system variables that may potentially own incidents in the selected workflow state.

10.2.5 Defining Who Can Change Workflow Rules

Project administrators may enable and define Who Can Change workflow rules in the Workflow Settings page of the Incident Workflow folder.

Who Can Change workflow rules determine which project members, groups, or group folders may change the workflow state of incidents based on workflow states or the transitions between workflow states.

Administrators may choose one of three options for defining Who Can Change rules in CustomerWise projects:

• The No Support option disables Who Can Change workflow rules in the project. Administrators may not restrict the ability of project members to change incident statuses.

• The Based onCurrentStateoption enables administrators to define state-based Who Can Change workflow rules in the project. Administrators may restrict the ability of project members to change the status of incidents in each workflow state. Who Can Change rules are based entirely on workflow states.

• The Based on Transition option enables administrators to define both state-based and transition-based Who Can Change workflow rules in the project. Administrators may restrict the ability of project members to change the status of incidents in each transition and each workflow state. Who Can Change rules may be based on either transitions or workflow states.

For each state define the users that can change the highlighted state to the next state:

• The Account Type option enables any user of this account type can change the highlighted state.

• Team group option enables any user in this team group can change the highlighted state.

• The Primary Support option enables the primary support engineer for the associated customer of an opportunity/incident may change the highlighted state.

• The Sales Person option enables the sales person for the associated customer of an opportunity/incident may change the highlighted state.

• Submitter – the original submitter of an opportunity/incident can change the highlighted state.

• The Group Folder option enables any user that has forward privileges for the select group folder can change the highlighted state.

• The User option enables the selected user can change the highlighted state.

To define Who Can Change workflow rules:

1Select an option from the Who Can Change dropdown list in the Support Options area of the Workflow Settings page.

Who Can Change workflow rules may be based on one of three options:

• No Support

• Based onCurrentState

• Based on Current Transition

2Select a workflow state in theProgressStatelist.

3If the Based on Current Transition option was enabled, select a transition in the State list.

4Select one or more options in the Who Can Change tab.

The Who Can Change tab displays the project members, groups, group folders, and system variables that may own incidents in the selected workflow state.

Note:If the No Support option is selected in the Who Can Change dropdown list, Who Can Change rules are disabled in the project and the Who Can Change tab is read-only in the Workflow Settings page.

10.2.6 Defining Read-Only Field Workflow Rules

Project administrators may enable and define Read-only Field workflow rules in the Workflow Settings page of the Incident Workflow folder.

Read-only Field workflow rules determine which fields (data-entry controls) are editable in the Description page, Current Status page, and customer pages for each workflow state.

Read-only fields may be viewed, but not edited. Unlike Read-Only privilege settings, read-only workflow rules apply to all project members regardless of account type.

Administrators may define a unique set of read-only fields for each workflow state in the incident life cycle.

To define Read-Only Field workflow rules:

1Select the Support Read-Only Fields check box in the Support Options area of the Workflow Settings page.

The Support Read-Only Fields option enables administrators to define data-entry controls as read-only in each workflow state.

2Select a workflow state in theProgressStatelist.

3Select one or more options in the Read-only Fields tab.

The Read-Only Fields tab displays the names of data-entry controls displayed in the Description page, Current Status page, and custom pages in the client GUIs.

10.2.7 Defining the Mandatory Field Workflow Rules

Project administrators may enable and define Mandatory Field workflow rules in the Workflow Settings page of the Incident Workflow folder.

Mandatory Field workflow rules determine which fields must be populated in each workflow state before the incident may progress to the next state in the incident life cycle.

Administrators may choose one of three options for defining Mandatory Field workflow rules in CustomerWise projects:

• The Based on Field Level Only option disables Mandatory Field workflow rules and renders the Mandatory Fields tab read-only in the Workflow Settings page. Project administrators may not define Mandatory Field workflow rules in the project.

• The Based onCurrentStateoption enables administrators to define state-based Mandatory Field workflow rules in the project. Administrators may mandate that project members define specific incident properties in each workflow state. Mandatory Field workflow rules are based entirely on workflow states.

• The Based on Transition option enables administrators to define both state-based and transition-based Mandatory Field workflow rules in the project. Administrators may mandate that project members define specific incident properties in each workflow state or transition. Mandatory Field workflow rules may be based on either transitions or workflow states.

To define Mandatory Field workflow rules: 

1Select an option from the Mandatory Field dropdown list in the Support Options area of the Workflow Settings page.

Mandatory Field workflow rules may be based on one of three options:

• Based on Field Level Only

• Based onCurrentState

• Based on Transition

2Select a workflow state in theProgressStatelist.

3If the Based on Transition option was enabled, select a transition in the State list.

4Select one or more options in the Mandatory Field tab.

The Mandatory Fields tab displays the names of data-entry controls displayed in the Description page, Current Status page, and custom pages in the client GUIs.

10.2.8 Defining Default Submission States

Project administrators may enable and define default state on submission settings for the incidents created in CustomerWise projects in the Workflow Settings page of the Incident Workflow folder.

TheDefaultStateon Submission dropdown list displays every workflow state defined in the current project. The workflow state selected by the administrator from theDefaultStateon Submission dropdown list is the default workflow state for all incidents submitted to that project.

10.2.9 Enabling Closed Event Restriction

All child events must be closed before an incident can be closed – select this option to ensure all events for an incident are in a Closed state before an opportunity/incident can progress to the next state

10.3 Designing CustomerWise Graphical Workflow

Project administrators may define workflow rules to manage the sales opportunities created in sales projects using tools in the Sales Workflow folder of the CustomerWise Admin Tree window.

Figure 10-1: Sales Project Workflow Chart

The Sales Workflow folder contains two system pages: the Workflow Design page and the Workflow Setting page.

• The Workflow Design page enables project administrators to define project workflow states and transitions using graphical workflow tools.

• The Workflow Settings page enables project administrators to define workflow rules for states and transitions.

The sample sales project manages sales opportunities using 11 distinct workflow states: a new state, a closing state, and nine intermediary states.

• New

• NewOpportunity

• Sales Qualified

• Sales Disqualified

• Quoted

• Sales Lost

• Order Received

• Purchase Pending

• Purchased/Payment Pending

• Purchased/Payment Received

• Closed

10.3.1 Workflow Design flowchart Workflow Design tool bar

The Workflow Design tool bar displays seven command buttons that enable project administrators to manage and customize flowcharts.

10.3.2 Understanding Workflow Design Flowcharts

A flowchart is a graphical representation of a process. CustomerWise graphic flowcharts enable project administrators to map out their business processes to any level of detail, to analyze their processes, and to optimize their workflow.

In TechExcel CustomerWise project workflow is organized into workflow states and the transitions. Workflow states represent the various stages that an incident may pass through during its life cycle. Transitions link together workflow states. Incidents may only pass from one workflow state to another if a transition exists between those two states.

In the Workflow Design page administrators may define project workflow graphically by creating workflow states and transitions.

• Workflow states are represented by state nodes in the Workflow Design flowchart.

• Transitions are represented by transition lines in the Workflow Design flowchart.

10.3.3 State nodes

Every Workflow Design flowchart displays at least three state nodes: a beginning state, an ending state, and an intermediary state. Workflow states (and state nodes) represent a specific stage in the life cycle of an incident. All workflow processes must begin in a New workflow state (represented by the New state node) and end in a Closed workflow state (represented by the Close state node).

Each workflow state is represented by a state node in the Workflow Design flowchart. Workflow states may be represented by three different types of state nodes:

• New} states are represented by a hexagon (six-sided polygon)

• {Close} states are represented by a square (four-sided polygon)

• Intermediary states are represented by a square.

Note:Administrators may use controls in the State manager to customize the appearance of state nodes in the Workflow Design flowchart. Administrators may define the size and color of state node bodies and borders.

10.3.4 Transitions

Transition lines represent the transitions between workflow states in project workflow.

Administrators may indicate that incidents may pass from one workflow state to another workflow state by drawing a transition line between the corresponding state nodes in the Workflow Design page.

• Transitions may not be drawn between the New state and the Closed states. Administrators must create at least one intermediary state, and link the beginning and end of workflow processes to this state.

• Multiple transitions may be defined between the same two workflow states.

Note:Administrators may use controls in the Transition manager to customize the appearance of transition lines in the Workflow Design flowchart. Administrators may change the style, color, and text orientation of transition lines. For more information see See “Customizing Transition Lines” .

10.3.5 Adding and Editing State Nodes

Administrators may add workflow states to project workflow by drawing state nodes in the Workflow Design page.

TheAddStatemanager enables project administrators to define the name of the workflow state and add brief comments describing the purpose of the state in project workflow.

Administrators may only define the name of the workflow state and add a brief description of the state in the Workflow Design page. All other workflow state properties must be defined in the Workflow Settings page. For more information see See “Administrating Incident Workflow” .

Administrators may also use the Add a State manager to define the color of the state node body and its border. For more information see See “Customizing State Nodes”.

To add a state node:

1Select the Add a State command.

Project administrators may access theAddStatecommand by two methods:

• Select the State Mode button in the Workflow Design tool bar and place the cursor in flowchart. Drag the cursor across the screen to draw the state node. Lift the cursor to complete the drawing.

• Right-click in the Workflow Design page and select the Add a State command in the shortcut menu.

The Add a State manager appears.

2Enter a name for the workflow state in the State Name field.

3Enter a brief description of the state in the Comments field.

4To define graphic properties, select options in the State Node Settings area.

5Click the OK button.

The state node is displayed in the Workflow Design flowchart.

Note:Administrators may define workflow rules for the state in the Workflow Settings page.

To edit a state node:

1Select the Add a State command.

Project administrators may access theAddStatecommand by two methods:

• Double-click a state node in the Workflow Design flowchart.

• Right-click in the Workflow Design page and select the Edit a State command in the shortcut menu.

The Edit a State manager appears.

2Update the workflow state name, comments, and appearance.

3Click the OK button.

DeletingWorkflowStateNodes

Administrators may delete workflow states from project workflow by deleting state nodes in the Workflow Design page.

TheAddStatemanager enables project administrators to define the name of the workflow state and add brief comments describing the purpose of the state in project workflow.

Administrators may only define the name of the workflow state and add a brief description of the state in the Workflow Design page. All other workflow state properties must be defined in the Workflow Settings page. For more information see “Administrating Incident Workflow”.

Administrators may also use the Add a State manager to define the color of the state node body and its border. For more information see“Customizing State Nodes”.

To add a state node:

1Select the Add a State command. Project administrators may access theAddStatecommand by two methods:

• .Select the State Mode button in the Workflow Design tool bar and place the cursor in flowchart. Drag the cursor across the screen to draw the state node. Lift the cursor to complete the drawing.

• Right-click in the Workflow Design page and select the Add a State command in the shortcut menu. The Add a State manager appears.

2Enter a name for the workflow state in the State Name field.

3Enter a brief description of the state in the Comments field.

4To define graphic properties, select options in the State Node Settings area.

5Click the OK button.

The state node is displayed in the Workflow Design flowchart.

Note:Administrators may define workflow rules for the state in the Workflow Settings page.

To edit a state node:

1Select the Add a State command. Project administrators may access theAddStatecommand by two methods:

• Double-click a state node in the Workflow Design flowchart.

• Right-click in the Workflow Design page and select the Edit a State command in the shortcut menu.

The Edit a State manager appears.

2Update the workflow state name, comments, and appearance.

3Click the OK button.

10.3.6 Deleting Workflow State Nodes

Administrators may delete workflow states from project workflow by deleting state nodes in the Workflow Design page.

When a workflow state is deleted all incidents in that state must be reassigned to another workflow state. The Merge To dialog box enables project administrators to select a target workflow state that will inherit the incidents that formerly belonged to the deleted state.

To delete a state:

1Right-click a state node the Workflow Design page and select the Delete command from the shortcut menu.

The Merge dialog box appears.

2Select an option from the Merge To dropdown list.

Incidents in the current workflow state are merged into the target workflow state when the current state is deleted.

3Click the OK button.

10.3.7 Creating and Editing Transition Lines

Administrators may add transitions to project workflow by drawing transition lines between two state nodes in the Workflow Design page.

The Add a Transition manager enables project administrators to define the name of the transition and its properties. All other transition properties must be defined in the Workflow Settings page. For more information see See “Administrating Incident Workflow”.

To create a transition line:

1.Select the Transition Mode button in the Workflow Design tool bar.

2Place the cursor in a state node in the Workflow Design flowchart and drag the cursor to the target state node.

A transition line is drawn between the two state nodes.

3Lift the cursor from the flowchart to complete the line.

The Add a Transition manager appears.

4Enter a name for the transition in the Transition Name field.

5To define graphic properties, select options in the Transition Link Settings area.

6Click the OK button.

The transition line is displayed in the Workflow Design flowchart. The target state connected to the original workflow state is designated as a potentialNextState. Project members may forward incidents from the original workflow state to the target state through the transition.

10.3.8 Understanding the Graph Properties Manager

Project administrators may use controls in the State Node tab of the Graphic Properties manager to define the appearance of state nodes in the Workflow Design flowchart.

The Graph Properties Manager consists of two tabbed pages: the State tab and the Transition tab.

Figure 10-5: Graph Properties Manager

Customizing State Nodes

Project administrators may use controls in the State Node tab of the Graphic Properties manager to define the appearance of state nodes in the Workflow Design flowchart.

State node graphic properties do not affect or define the workflow rules defined for the corresponding workflow state. Graphic properties merely enable the administrator to represent graphically the purpose of the state represented by the state node in the flowchart.

All state nodes are defined by five different properties that the project administrator can define in the Graphic Property Manager.

State node properties include:

• The Draw Style property enables project administrators to choose from two different styles: Solid or Dash,

• The Draw Width property enables project administrators to choose from five different widths of lines.

• The Color property enables project administrators to choose from sixteen different colors.

• The Color property enables project administrators to choose from sixteen different colors.

10.3.9 Customizing Transition Lines

Project administrators may use controls in the Transition Link tab of the Graphic Properties manager to define the appearance of transition lines in the Workflow Design flowchart.

Transition line graphic properties do not affect or define the workflow rules defined for the corresponding transition. Graphic properties merely enable the administrator to represent the purpose or importance of the transition within project workflow.

• Transition lines may be color coded based on the account types or team members that have the privileges to forward incidents using those transitions.

• Transition lines may be color coded to distinguish primary and subworkflow processes.

All transition links are defined by five different properties that the project administrator may define in the Graphic Properties Manager.

Transition link properties include:

• The Line Style property enables project administrators to choose from three different styles: Polyline option, Bezier option, Spline option.

• The Color property enables project administrators to choose from sixteen different colors.

• The Text Orientation property enables project administrators to choose from two different styles: Orientated, Horizontal.

• The Draw Width property enables project administrators to choose from five different line widths.

10.3.10 Magnifying and Reducing Workflow Flowcharts

Administrators may use the Zoom In button or the Zoom Out button in the Workflow Flowchart Command area to magnify or reduce the size of the flowchart diagrams presented in the Workflow Flowchart area.

The Zoom In button and the Zoom Out button enable administrators to choose from six different magnification settings to view details of the flowchart.

10.3.11 Saving Workflow Flowcharts

Administrators may use the Save button to save copies of the flowchart diagrams presented in the Workflow Flowchart area.

Workflow flowcharts are saved as portable network graphics (PNG) files.

To save workflow flowcharts: 

1Click the Save button in the Workflow Flowchart tool bar.

The Save the Graph dialog box appears.

2Choose a destination directory in the Save In dropdown list.

3Choose a destination folder in the Folder list.

4Enter a name for the file in the File Name field.

5Click the Save button.

10.4 Administrating Incident Autorouting

Project administrators may define workflow rules to manage the support incidents created in support projects using tools in the Incident Workflow folder of the CustomerWise Admin Tree window.

Figure 10-2: Support Project Workflow Chart

The Incident Workflow folder contains two system pages: the Workflow Design page and the Workflow Setting page.

• The Workflow Design page enables project administrators to define project workflow states and transitions using graphical workflow tools.

• The Workflow Settings page enables project administrators to define workflow rules for states and transitions.

The sample support project manages incidents using eight distinct workflow states: a new state, a closing state, and six intermediary states.

• New

• New Incident

• In Level-1 Support

• Resolved

• In Level-2 Support

• In Development

• Resolved - Notify Customer

• Closed

10.4.1 Enabling incident Autorouting

Autorouting is an optional feature that enables administrators to define rules for autorouting CustomerWise incidents to project members based on administrator-defined escalation rules. The Zoom Out button The Zoom In button.

CustomerWise analyzes incident properties and assigns incidents to the most appropriate person based administrator-defined autorouting rules. Using controls in the Autorouting page, administrators may define the multiple rules for routing incidents based on incident properties and determine the criteria that is used to assign those incidents to CustomerWise project members.

Auto-routed incidents may be assigned to CustomerWise project members based on one of three sets of criteria:

• Based on project member workloads.

• Based on project member skill levels

• Based on a formula that is based on the workload and the skill level of potential targets

Autorouting administration is a five step process:

U:Enable autorouting. The administrator must enable autorouting in the project.

V:Select an autorouting property. Administrators may define autorouting rules based on one of three options: The Based on Workload option, the Based on Skill Level Option, and the Based on Formula option.

W:Define a default recipient using the Default Target if No Criteria is Met dropdown list. The administrator defines a default recipient.

X:Define autorouting rules.

The administrator defines autorouting criteria in the Autorouting Criteria section of the Autorouting page. The autorouting criteria determines which incidents are subject to autorouting rules based on incident properties.

Y:Define recipients of auto-routed incidents. The administrator must define which project members receive incidents routed based on autorouting rules.

 Chapter 11 Team Assignment Administration

11.1 Managing Team Assignment

TechExcel CustomerWise team assignment enables project administrators to ensure that customers are always assigned to appropriatesystem team groupsandproject membersin CustomerWise projects.

Using controls in the Sales/Support Team Assignment folder, sales and support project administrators may designate one or more system team groups asapplicablein a project as well as one or more sales managers, support engineers, and inside sales representatives. A system team group or project member must be applicable or customers cannot be assigned to it in a project.

Applicable system team groups and applicable project members may bemanually assignedto customers by project members orautomatically assignedbased on administrator-defined autoassignment rules.

• Project members may manually assign customers to a system team group, sales manager, support engineer, and inside sales representative in the Team tab displayed in the Customer Detail window of sales and support projects.

• Team autoassignment rules may automatically assign customers to appropriate system team groups, sales managers, support engineers, and inside sales representatives based on geography, or any other administrator-defined criteria.

Although the administrator may define multiple system team groups, sales managers, support engineers, and inside sales representatives as applicable in a project, only one system team group, one sales manager, one support engineer, and one inside sales representative is assigned to each customer.

Note:Project administrators may define team assignment rules in the Sales/ Support Team Assignment folder of sales projects and support projects. Sales and Support Team Assignment is an optional feature that must be enabled by a project administrator in the Optional Features page of the General Project Settings folder. For more information see “Managing Optional Project Features”.

11.1.1 Understanding Team Assignment Groups

The team members are drawn from key business areas so that all aspects of marketing, sales, and support are provided to that customer.:

• System team groups

• Sales managers

• Support engineers

• Inside sales person

Team assignment means that customers are always assigned to a system team group, sales manager, support engineer, and inside sales representative and those teams and project members may be held responsible for that customer account.

11.1.2 Understanding Manual Team Assignment

Project members may manually assign a customer to a team of up to three project members and one system team group whenever they create a new customer in the customer base project or update an existing customer in a sales or support project.

Project members may assign customers to system team groups and project members in the New Customer manager of a based project and the Team tab of sales and support projects.

• The New Customer manager enables base project members to assign a customer to one system team group, one sales manager, one support engineer, and one inside sales representative whenever they create a new customer in a base project.

• The Team tab displayed in the Customer Detail window of sales and support work projects enable project members to update team assignment options. The customer may only be assigned one system team group, one sales manager, one support engineer, and one inside sales representative.

The New Customer manager and Team tab display four administrator-defined dropdown list controls that enable project members to define how customers are assignment to appropriate teams.

• The Group Assigned To dropdown list displays the{autoassign} system option, the *Unassigned system option, and the names of all applicable system team groups.

• The Support Engineer dropdown list displays the {autoassign} system option, the *Unassigned system option, and the names of all applicable project members.

• The Sales Manager dropdown list displays the {autoassign} system option, the *Unassigned system option, and the names of all applicable project members.

• The Inside Sales Rep dropdown list displays the {autoassign} system option, the *Unassigned system option, and the names of all applicable project members.

Project administrators define which system team groups and account types are displayed in the dropdown list controls. Only system team groups and project members deemed applicable by the administrator are available for selection in the client projects. If the administrator does not define the group or account type, it is not available for selection in these controls.

11.2 Defining Team Assignment Rules

The team members are drawn from key business areas so that all aspects of marketing, sales, and support are provided to that customer.:

• System team groups

• Sales managers

• Support engineers

• Inside sales person

Team assignment means that customers are always assigned to a system team group, sales manager, support engineer, and inside sales representative and those teams and project members may be held responsible for that customer account.

11.2.1 Defining System Team Group Assignment Rules

Project administrators may use controls in the General Settings page of the Support/ Sales Team Assignment folder to define system team group assignment rules.

Project administrators may

• Display or hide the System Team Group dropdown list that is displayed in the Team page.

• Enable team autoassignment for system team groups.

• Determine in which project applicable system team groups may be defined.

System team groupsare administrator-defined groupings of users that organize users into distinct categories. System team groups may represent any internal structure within a company (product division, geographic division, or any other body that is appropriate to a business.). For more information on creating and editing system team groups, see “Administrating System Team Groups”.

Note:In a future release you will be able to define if the group defined here refers to the system team groups defined in the Support Member Manager (available to all work projects) or the project team groups defined on the Team Groups page (specific to each work project). Currently the project team group option is not available...

To define system team group assignment rules:

1Display or hide the System Team Group dropdown list in the New Customer manager.

The Visible control enables the administrator to display or hide the System Team Group dropdown list in the Team pagel. Project members use this control to assign a customer to a system team group. If the control is not displayed in the Team page, customers cannot be assigned to system team groups.

Note:Project administrators may define the same setting in the Team system page settings in the Customer View folder.For more informaiton see “Customizing the Team Page” .

If the System Team Group dropdown list control is defined as visible in the Team system page, the Visible control is selected here as well.

2To enable team autoassignment, select the autoassignment for System Team Group check box.

Team autoassignment enables a customer to be to be automatically assigned to an appropriate system team group based on administrator-defined autoassignment rules.

3Define how applicable sales managers are defined.

• To enable project administrators to define applicable system team groups in thecurrent project, select the Current Project option in the Defined In dropdown list.

• To enable project administrators to define applicable system team groups inanother project, select the the project in the Defined In dropdown list.

4 (Optional)To enable a project administrator in another work project to define the applicable system team groups for the current project, select an option from the Linked With dropdown list.

Note:Only projects that share the same customer base project can have synchronized team information.

11.2.2 Defining Sales Manager Assignment Rules

Project administrators may use controls in the General Settings page of the Support/ Sales Team Assignment folder to define sales manager assignment rules. Project administrators may

• Display or hide the System Team Group dropdown list that is displayed in the Team page.

• Enable team autoassignment for sales managers.

• Determine in which project applicable sales managers may be defined.

To define sales manager assignment rules:

1Display or hide the System Team Group dropdown list in the New Customer manager.

The Visible control enables the administrator to display or hide the System Team Group dropdown list in the New Customer manager Project members use this control to assign a customer to a system team group. If the control is not displayed in the New Customer manager, customers cannot be assigned to system team groups.

Note:Project administrators may define the same setting in the Team system page settings in the Customer View folder.For more informaiton see “Customizing the Team Page” .

If the WHICH control is defined as visible in the was made visible in the Team system page, the Visible control is selected here as well.

2To enable team autoassignment, select the autoassignment for System Team Group check box.

Team autoassignment enables system team groups to be automatically assigned to new customers.

If the system team group autoassignment rule is enabled, project members may select the autoassign option in Group/Team Member dropdown list of the Team page, and TechExcel CustomerWise will use the support team autoassignment rule to assign a system team group to the customer.

3Define how applicable system team groups are defined.

• To enable project administrators to define applicable sales managers in thecurrent project, select the Current Project option in the Defined In dropdown list.

• To enable project administrators to define applicable sales managers inanother project, select the the project in the Defined In dropdown list.

4 (Optional)To enable a project administrator in another work project to define the applicable sales managers for the current project, select an option from the Linked With dropdown list.

Note:Only projects that share the same customer base project can have synchronized team information..

11.2.3 Defining Support Engineers Assignment Rules

Project administrators may use controls in the General Settings page of the Support/ Sales Team Assignment folder to define support engineer assignment rules.

Project administrators may

• Display or hide the System Team Group dropdown list that is displayed in the Team page.

• Enable team autoassignment for support engineers.

• Determine in which project applicable support engineers may be defined.

To define support engineer assignment rules:

1Display or hide the Support Engineer dropdown list in the New Customer manager.

The Visible control enables the administrator to display or hide the Support Engineer dropdown list in the New Customer manager Project members use this control to assign a customer to a support engineer. If the control is not displayed in the New Customer manager of Team tab, customers cannot be assigned to support engineers.

Note:Project administrators may define the same setting in the Team system page settings in the Customer View folder.For more informaiton see “Customizing the Team Page” .

If the Support Engineer dropdown list is defined as visible in the Team system page, the Visible control is selected here as well.

2To enable team autoassignment, select the autoassignment for Support Engineer check box.

Team autoassignment enables support engineers to be automatically assigned to new customers.

If the support engineer autoassignment rule is enabled, project members may select the autoassign option in Group/Team Member dropdown list of the Team page, and TechExcel CustomerWise will use the team autoassignment rule to assign a system team group to the customer.

3Define how applicable support teams are defined.

• To enable project administrators to define applicable support teams in thecurrent project, select the Current Project option in the Defined In dropdown list.

• To enable project administrators to define applicable support teams inanother project, select the the project in the Defined In dropdown list.

4 (Optional)To enable a project administrator in another work project to define the applicable system team groups for the current project, select an option from the Linked With dropdown list.

Note:Only projects that share the same customer base project can have synchronized team information.

11.2.4 Defining Inside Sales Representative Assignment Rules

Project administrators may use controls in the General Settings page of the Support/ Sales Team Assignment folder to define inside sales representative assignment rules.

Project administrators may

• Display or hide the System Team Group dropdown list that is displayed in the Team page.

• Enable team autoassignment for inside sales representatives.

• Determine in which project applicable inside sales representatives may be defined.

To define inside sales representative assignment rules:

1Display or hide the System Team Group dropdown list in the New Customer manager.

The Visible control enables the administrator to display or hide the Inside Sales Representative dropdown list in the New Customer manager Project members use this control to assign a customer to a inside sales representative. If the control is not displayed in the New Customer manager, customers cannot be assigned to inside sales representatives.

Note:Project administrators may define the same setting in the Team system page settings in the Customer View folder.For more informaiton see “Customizing the Team Page” .

If the Inside Sales Representative control is defined asVisiblein the Team system page, the Visible control is selected here as well.

2To enable team autoassignment, select the autoassignment for Inside Sales Representative check box.

Team autoassignment enables inside sales representatives to be automatically assigned to new customers.

If the inside sales representative autoassignment rule is enabled, project members may select the autoassign option in Group/Team Member dropdown list of the Team page, and TechExcel CustomerWise will use the inside sales representative autoassignment rule to assign a inside sales representative to the customer.

3Define how applicable system team groups are defined.

• To enable project administrators to define applicable inside sales representatives in thecurrent project, select the Current Project option in the Defined In dropdown list.

• To enable project administrators to define applicable inside sales representatives inanother project, select the the project in the Defined In dropdown list.

4 (Optional)To enable a project administrator in another work project to define the applicable system team groups for the current project, select an option from the Linked With dropdown list.

Note:Only projects that share the same customer base project can have synchronized team information.

11.3 Defining Applicable Team Members

Project members may manually assign a customer to a team of up to three project members and one system team group whenever they create a new customer in the customer base project or update an existing customer in a sales or support project.

Project members may assign customers to system team groups and project members in the New Customer manager of a based project and the Team tab of sales and support projects.

• The New Customer manager enables base project members to assign a customer to one system team group, one sales manager, one support engineer, and one inside sales representative whenever they create a new customer in a base project.

• The Team tab displayed in the Customer Detail window of sales and support work projects enable project members to update team assignment options. The customer may only be assigned one system team group, one sales manager, one support engineer, and one inside sales representative.

The New Customer manager and Team tab display four administrator-defined dropdown list controls that enable project members to define how customers are assignment to appropriate teams.

• The Group Assigned To dropdown list displays the{autoassign} system option, the *Unassigned system option, and the names of all applicable system team groups.

• The Support Engineer dropdown list displays the {autoassign} system option, the *Unassigned system option, and the names of all applicable project members.

• The Sales Manager dropdown list displays the {autoassign} system option, the *Unassigned system option, and the names of all applicable project members.

• The Inside Sales Rep dropdown list displays the {autoassign} system option, the *Unassigned system option, and the names of all applicable project members.

Project administrators define which system team groups and account types are displayed in the dropdown list controls. Only system team groups and project members deemed applicable by the administrator are available for selection in the client projects. If the administrator does not define the group or account type, it is not available for selection in these controls.

11.3.1 Understanding the Applicable Teams Page

Project administrators may define sales managers, support engineers, inside sales representatives, and system team groups as applicable the Applicable Teams page of the Support/Sales Team Assignment folder.

Project members may only assign cusotmers to applicable project members in CustomerWise projects. Applicable project members are defined in the Applicable Teams page.

Figure 11-2: Applicable Teams Page

The Applicable Teams page is divided into four primary areas representing the four groups which may be defined as applicable teams in the current project: system groups, sales managers, support engineers, and inside sales representatives.

Note:System team groups are shared across all projects that share the same base project..

• Group Assigned To list enables project administrators to select one or more system team groups. The list displays all of the system groups defined in the project.

• The Sales Manager list list enables project administrators to select one or more of sales managers. The list displays all of the sales managers defined in the current work project.

• The Support Engineers list list enables project administrators to select one or more of groups. The list displays all of the support engineers defined in the current work project.

• The Inside Sales list list enables project administrators to select one or more of groups. The list displays all of the inside sales representatives defined in the current work project.

Note:Administrators may define applicable team members within the current project only if they selected the Current Project option in the Defined In dropdown list in the General Settings page. If another project is selected in Defined In dropdown list, the applicable groups, sales managers, support engineers, or inside sales representatives are defined in the project selected and the team list is read-only in the current project.

11.3.2 Defining Applicable System Team Groups

Project administrators may define which system team groups may be assigned customers in a project in the Applicable Teams page.

Applicable system team groups may be manually assigned to customers by project members or automatically assigned to customers based on administrator-defined autoassignment rules.

System team groupsare administrator-defined groupings of users that organize users into distinct categories. System team groups may represent any internal structure within a company (product division, geographic division etc.)

For more information on creating and editing system team groups, see “Administrating System Team Groups” .

To define system group applicable teams:

1Define system team groupp assignment rules in the General Settings page of the Sales/Support Team Assignment folder.

Administrators must define system team group assignment rules before they can designate system team groups as applicable to those rules

Note:Team assignment general settings determine whether applicable team assignment may be defined in the current work project. For step-by-step instructions see See “Defining Team Assignment Rules” on page 196..

2Select one or more system groups in the System Group list of the Team Assignment page of the the Sales/Support Team Assignment folder.

If the System Group list is read-only (grayed out), another project was selected in the Defined In dropdown list in the General Settings page. The applicable system group must be defined in the project selected.

11.3.3 Defining Applicable Sales Managers

Project administrators may define which sales managers may be assigned customers in a project in the Applicable Teams page.

Applicable sales managers may be manually assigned to customers by project members or automatically assigned to customers based on administrator-defined autoassignment rules.

Administrators may also mandate that the sales managers assigned to the customer be a member of the system team group assigned to the customer by selecting the From Assigned Group Only check box.

To define applicable sales managers

1Define sales manager assignment rules in the General Settings page of the Sales/ Support Team Assignment folder.

Administrators must define inside sales manager rules before they can designate sales managers as applicable to those rules.

Note:Sales managers determine whether the administrator may define the applicable sales managers in the current current work project. For step-by-step instructions see See “Defining Team Assignment Rules” on page 196.

2To mandate that all applicable sales managers are members of an applicable system team group, select the From Assigned Group Only check box.

3Select one or more sales managers in the System Group list of the Team Assignment page of the the Sales/Support Team Assignment folder.

If the Sales Managers list is read-only (grayed out), another project was selected in the Defined In dropdown list in the General Settings page. Applicable sales managers must be defined in the project selected.

11.3.4 Defining Applicable Support Engineers

Project administrators may define which support engineers may be assigned customers in a project in the Applicable Teams page.

Applicable support engineers may be manually assigned to customers by project members or automatically assigned to customers based on administrator-defined autoassignment rules.

Administrators may also mandate that the support engineers assigned to the customer be a member of the system team group assigned to the customer by selecting the From Assigned Group Only check box.

To define applicable support engineers:

1Define support engineer assignment rules in the General Settings page of the Sales/Support Team Assignment folder.

Administrators must define support engineer assignment rules before they can designate support engineers as applicable to those rules.

Note:Support engineer assignment rules determine whether the administrator may define the applicable support engineers in the current current work project. For step-by-step instructions see See “Defining Team Assignment Rules” ..

2To mandate that all applicable support engineers are members of an applicable system team group, select the From Assigned Group Only check box.

3Select one or more support engineers in the System Group list of the Team Assignment page of the the Sales/Support Team Assignment folder.

If the Support Engineer list is read-only (grayed out), another project was selected in the Defined In dropdown list in the General Settings page. Applicable support engineers must be defined in the project selected.

11.3.5 Defining Applicable Inside Sales Representatives

Project administrators may define which inside sales representatives may be assigned customers in a project in the Applicable Teams page.

Applicable inside sales representatives may be manually assigned to customers by project members or automatically assigned to customers based on administrator-defined auto assignment rules.

Administrators may also mandate that the inside sales representative assigned to the customer be a member of the system team group assigned to the customer by selecting the From Assigned Group Only check box.

To define applicable inside sales representatives:

1Define inside sales rep assignment rules in the General Settings page of the Sales/ Support Team Assignment folder.

Administrators must define inside sales rep assignment rules before they can designate inside sales representatives as applicable to those rules.

Note:Inside sales assingment rules determine whether the administrator may define the applicable inside sales representatives in the current current work project. For step-by-step instructions see See “Defining Team Assignment Rules” on page 196.

2To mandate that all applicable sales representatives are members of an applicable system team group, select the From Assigned Group Only check box.

3Select one or more inside sales representatives in the System Group list of the Team Assignment page of the the Sales/Support Team Assignment folder.

If the Inside Sales Representative list is read-only (grayed out), another project was selected in the Defined In dropdown list in the General Settings page. Applicable inside sales representatives must be defined in the project selected.

11.4 Managing Customer Territories, Customer Types, and Territory Regions

Administrators may define the rules that determine how customers are assigned to system team groups, sales managers, support engineers, and inside sales representatives in the General Settings page of the Sales/Support Team Assignment folder.

Project administrators may

• Display or hide the System Team Group dropdown list that is displayed in the Team page.

• Enable team autoassignment for system team groups.

• Determine in which project applicable system team groups may be defined.

The General Settings page consists of four basic areas that represent the system team

Figure 11-1: Team Assignment General Settings Page

group and project members that may be assigned customers in CustomerWise projects: system team groups, sales managers, support engineers, and inside sales representatives.

If the system team group autoassignment rule is enabled, project members may select the {autoassign} system variable option in Group/Team Member dropdown list of the Team page, and the system will use the support team autoassignment rule to assign the customer to an appropriate system team group.

Note:The controls displayed in the Team page are project-specific and are fully customizable. Project administrators may rename the field label of any control using tools in the Team system page of the Customer View folder. Because the controls are project-specific, the controls may represent different groups of project members in different projects.

TechExcel CustomerWise allows multiple work projects (marketing, sales, and support) to share a common customer base project so that team information that is defined in one work project may be visible in all other work projects that share the same base project.

General team autoassignment tasks include:

Note:Only projects that share the same customer base project can have synchronized team information

• Defining System Team Group Assignment Rules

• Defining Sales Manager Assignment Rules

• Defining Support Engineers Assignment Rules

• Defining Inside Sales Representative Assignment Rules

 Chapter 12 E-mail Integration Administration

12.1 Understanding CustomerWise E-mail Integration

E-mail integration enables CustomerWise support teams to better manage project incidents, events, and employees by automating and tracking communication conducted by e-mail.

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

CustomerWise e-mail integration is a prerequisite for the following features:

•E-mail event trackingenables support teams to track every e-mail sent to and received from employees through the CustomerWise client asevents. All e-mail events are based on administrator-defined e-mail received or e-mail sent event templates.

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

•E-mail autoreplyenables support teams to define rules for automatically sending predefined e-mail to employees whenever an e-mail is received from that employee.

•Incident autosubmissionenables project members and employees to submit incidents to CustomerWise projects by e-mail. CustomerWise automatically creates new incidents based on the content of the subject line and body of the e-mail.

•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 E-mail Notification page of the Advanced Settings folder.

12.1.1 Understanding System-Level E-mail Integration

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

System administrators are responsible for installing the CustomerWise E-mail Server service, the CustomerWise E-mail Retrieval service, and configuring the CustomerWise environment to operate properly. System administrators are also responsible for defining e-mail error handling rules.

System administrators must install the CustomerWise E-mail Server and start the e-mail notification service to enable project administrators to implement incident notification in CustomerWise projects.

System administrators may install the CustomerWise E-mail Server on any Windows server machine. Once installed, the CustomerWise Mail Server service is shown running in the Windows services.

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

• CustomerWise Database Server and CustomerWise Application Server must be installed before CustomerWise E-mail Server can execute properly.

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

When the CustomerWise E-mail Server is initially installed, it talks to the CustomerWise Application Server to get the database username and password for accessing the CustomerWise Database Server.

The CustomerWise E-mail Server communicates with the CustomerWise Database Server and sends e-mail messages through a POP3 or SMTP mail server:

• The CustomerWise E-mail Server then talks to the CustomerWise Database Server and queries the CustomerWise database for e-mail messages that must be sent.

• When the CustomerWise E-mail Server finds e-mail messages to be sent, it talks to a POP3/SMTP mail server and send out the e-mails through that mail server.

• After it has sent the e-mail messages, the CustomerWise Mail Server resets flags in CustomerWise Database.

• The CustomerWise E-mail service continues to query the CustomerWise database for new e-mail messages that need to be delivered.

12.1.2 Understanding E-mail Events and Event Templates

E-mail event tracking enables support teams to track every e-mail sent to and received from employees through the CustomerWise client as events.

All e-mail events are based on administrator-defined e-mail received or e-mail 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 e-mail notification and escalation rules.

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

• E-mail received event templates combine administrator-defined workflow rules with system-defined business rules for managing e-mail received events.

• E-mail sent event templates combine administrator-defined workflow rules with system-defined business rules for managing e-mail sent events.

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

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

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

• An e-mail sent event based on an e-mail sent event template is automatically created whenever a CustomerWise project member sends an e-mail to an employee.

12.2 Managing Incoming Mail Server Settings

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

System administrators are responsible for installing the CustomerWise E-mail Server service, the CustomerWise E-mail Retrieval service, and configuring the CustomerWise environment to operate properly. System administrators are also responsible for defining e-mail error handling rules.

System administrators must install the CustomerWise E-mail Server and start the e-mail notification service to enable project administrators to implement incident notification in CustomerWise projects.

System administrators may install the CustomerWise E-mail Server on any Windows server machine. Once installed, the CustomerWise Mail Server service is shown running in the Windows services.

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

• CustomerWise Database Server and CustomerWise Application Server must be installed before CustomerWise E-mail Server can execute properly.

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

When the CustomerWise E-mail Server is initially installed, it talks to the CustomerWise Application Server to get the database username and password for accessing the CustomerWise Database Server.

The CustomerWise E-mail Server communicates with the CustomerWise Database Server and sends e-mail messages through a POP3 or SMTP mail server:

• The CustomerWise E-mail Server then talks to the CustomerWise Database Server and queries the CustomerWise database for e-mail messages that must be sent.

• When the CustomerWise E-mail Server finds e-mail messages to be sent, it talks to a POP3/SMTP mail server and send out the e-mails through that mail server.

• After it has sent the e-mail messages, the CustomerWise Mail Server resets flags in CustomerWise Database.

• The CustomerWise E-mail service continues to query the CustomerWise database for new e-mail messages that need to be delivered.

12.2.1 Enabling E-mail Autoretrieval in CustomerWise Projects

CustomerWise projects use the TechExcel CustomerWise Mail Retrieval Server, an NT service, to retrieve e-mail from an e-mail server using the POP3 or MAPI protocol.

To enable and execute e-mail autoretrieval in a CustomerWise project, two administrative tasks must be completed:

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

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

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

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

To enable e-mail autoretrieval in the current project, select the Support E-mail Autoretrieval check box in the Incoming Mail tab of the E-mail Notification page in the Advanced Settings folder.

Note:The Support E-mail Autoretrieval check box is grayed out if advanced e-mail integration is not enabled in the project. For more information see“Managing Optional Project Features”.

12.2.2 Enabling Multiple Team E-mail Accounts

CustomerWise advanced e-mail integration enables projects to support multiple incoming e-mail servers and team e-mail accounts.

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

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

• Each team e-mail account has a uniquee-mail address, and the e-mail address assigned to a team e-mail account may indicate the product, service, or location served by that e-mail account.

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

• Each team e-mail account represents two administrator-defined event templates: an e-mail received event template and an e-mail sent event template. E-mail messages sent to or from a team e-mail account automatically create e-mail events based on the corresponding e-mail received or e-mail 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 E-mail Notification page in the Advanced Settings folder.

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

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

12.2.3 Defining Team E-mail Accounts

A team e-mail account bundles together a POP3 or MAPI e-mail account (an incoming e-mail server, e-mail address, user name, and password) with two administrator-defined e-mail event templates.

A project administrator may define one or more team e-mail accounts in each CustomerWise project.

• If standard e-mail integration is used in a CustomerWise project, the project administrator defines a single team e-mail account that connects to a single incoming e-mail server. All support engineers in the project share a common team e-mail address: for example,support@abcsoft.com.

• If advanced e-mail integration is used in a CustomerWise project, the project administrator may define multiple team e-mail accounts that connect to many different incoming e-mail servers. Support engineers may be defined different team e-mail accounts based on their expertise, job role, location, or any other criteria that makes sense to the business.

Project administrators may define team e-mail accounts using Edit E-mail Property manager in the Incoming Mail tab of the E-mail Integration page of the Advanced Settings folder.

The e-mail address represented by the team e-mail account is only used when project members reply to e-mail messages send by employees that have not been assigned team e-mail accounts. Employees may be assigned team e-mail accounts based on their employee type. For more information see See “Defining Reply To E-mail Addresses based on Employee Types”.

To create team e-mail accounts:

1 Optional: To define multiple team e-mail accounts, select the Support Multiple Team E-mail Account check box in the Incoming Mail tab of the E-mail Integration page.

2Click the New button in the Team E-mail Accounts area of the Incoming Mail tab of the E-mail Integration page.

The Edit E-mail Property manager appears.

3Choose an e-mail protocol for communicating with the incoming e-mail server.

CustomerWise supports two protocols for retrieving e-mail from the server: POP3 and MAPI.

• To use the POP3 protocol, select the POP3 Protocol to Receive Mails radio button and define POP3 server settings. For step-by-step instructions see “Defining POP3 E-mail Server Settings”.

• To use the Microsoft MAPI protocol, select the Microsoft MAPI Protocol to Receive Mails radio button and define the MAPI profile. For step-by-step instructions see “Defining MAPI E-mail Server Settings” .

4Select a default e-mail received event template in the Default Event Template for E-mail Received dropdown list.

The Default Event Template for E-mail Received dropdown list displays all of the event templates created in the project that are based on the E-mail Received event type.

E-mail sent to the team e-mail address automatically create events based on the selected event template.

Note:Project administrators must define at least one e-mail received event template for CustomerWise e-mail integration to work. For more information on the e-mail received event type see See “Project administrators may create multiple event templates based on the E-mail Received event type in the Event Templates page of the Event Management folder in the ServiceWise Admin client.”.

5Select a default e-mail sent event template in the Default Event Template for E-mail Sent dropdown list.

The Default Event Template for E-mail Sent dropdown list displays all of the event templates created in the project that are based on the E-mail Sent event type.

E-mail sent from the team e-mail address automatically create events based on the selected event template.

Note:Project administrators must define at least one e-mail sent event template for CustomerWise e-mail integration to work.

6Click the OK button.

12.2.4 Defining POP3 E-mail Server Settings

Project administrators may define unique POP3 e-mail account whenever they create a team e-mail account in CustomerWise.

Each team e-mail account bundles together POP3 e-mail protocol settings (an incoming e-mail server, e-mail address, user name, and password) with two administrator-defined e-mail event templates.

To create POP3 team e-mail accounts:

1 Optional: To define multiple team e-mail accounts, select the Support Multiple Team E-mail Account check box in the Incoming Mail tab of the E-mail Integration page.

2Click the New button in the Team E-mail Accounts area of the Incoming Mail tab of the E-mail Integration page.

The Edit E-mail Property manager appears.

3Select the POP3 Protocol to Receive Mails radio button.

4Define the name of the incoming mail server in the Incoming Mail Server edit box control.

5Define POP 3 account information of the incoming team e-mail address.

The Account Information requires a predefined e-mail account along with its matching password for the mail server.

• E-mail address

• account name

• user name

• password

6Define the event templates.

7Define the default reply to address.

12.2.5 Defining MAPI E-mail Server Settings

MAPI, theMessaging Application Programming Interface, is the proprietary protocol used by the Microsoft Outlook client to communicate with the Microsoft Exchange Server.

The TechExcel Mail Retrieval Server (a Microsoft NT service) may use MAPI profiles to retrieve project e-mail from a Microsoft Exchange Server. Each MAPI profile represents a set of user information (user name and e-mail address), e-mail server information, and login information (user name and password) that are defined and stored in a domain.

To configure CustomerWise e-mail retrieval using the MAPI protocol, project administrators must define MAPI profiles on the e-mail server machine and identify those MAPI profiles in appropriate project team e-mail accounts.

All team e-mail accounts are defined in the Incoming E-mail tab of the E-mail Notification page. Team e-mail accounts bundle together an e-mail protocol (POP3 or MAPI) with two administrator-defined e-mail event templates (an e-mail received event template and an e-mail sent event template).

To define MAPI e-mail server settings for team e-mail accounts:

1Create a MAPI profile in the domain.

• Enable the MAPI profile to connect to Microsoft Exchange Server.

• Define user information including a user name and an e-mail address.

• Define the server information.

• Define login information including the user name and password.

2Install a Microsoft Outlook client (or another MAPI-compliant e-mail client) on the same machine as the one running the TechExcel E-mail Retrieval Server service.

The e-mail client is only used to create the MAPI profiles.

3Log into the Microsoft Exchange Server using the MAPI profile and set up the Microsoft Outlook e-mail client.

4Log into the Microsoft Outlook client using the MAPI profile.

5Ensure that the MAPI profile may send and receive e-mail using the Microsoft Outlook client.

6Create a team e-mail account in the CustomerWise Admin client.

The TechExcel E-mail Retrieval Server uses the MAPI profile identified by the team e-mail account to log into the Microsoft Exchange Server and retrieve incoming e-mail.

12.2.6 Defining the Reply To Address of Outgoing E-mail

Project administrators may define an e-mail address as the default “reply to” address for all incoming project e-mail.

To define the default “reply to” e-mail address for e-mail sent from the CustomerWise project, select an option from the Default Team E-mail Address dropdown list in the Incoming Mail tab of the E-mail Integration page in the Advanced Settings folder.

The Default Team E-mail Address dropdown list displays every administrator-defined team e-mail account created in the project.

The default e-mail address for e-mail reply is the “reply to” address that is used if no other e-mail address is acceptable.

The sending address for these replies to employee e-mail may be one of three e-mail addresses: the “reply to” address of the project member, the “reply to” address of the employee, or the default “reply to” address.

• In most circumstances the sending address used for replies to incoming e-mail is the “reply to” designated in the team e-mail address that is assigned to the project member.

• The sending address used for replies to incoming e-mail may be based on “reply to” designated in the team e-mail address assigned to the employee that sent the original e-mail. Employees may be assigned team e-mail accounts based on their employee type. For more information see “Defining Reply To E-mail Addresses based on Employee Types”.

• The default “reply to” address is only used if two conditions are met: The default e-mail address defined in the General Settings tab of the E-mail Integration page is set to the Team E-mail Address Based on Employee Type option and the employee sending the incoming e-mail has not been assigned a team e-mail account.

12.2.7 Defining Reply To E-mail Addresses based on Employee Types

In CustomerWise projects, project members may quickly reply to all project e-mail sent by employees regarding CustomerWise incidents.

The sending address of reply e-mails may be based on one to three administrator-defined e-mail addresses: the “reply to” address of the project member, the “reply to” address of the employee, the default “reply to” address.

The employee “reply to” address is used when the following criteria is met:

• The e-mail address defined in the General Settings tab of the E-mail Integration page is set to the Team E-mail Address Based on Employee Type option.

• The employee that sent the original e-mail (the e-mail that the project member is replying to) is assigned a team e-mail address based on their account type.

In this configuration, the “reply to” address displayed in the e-mail sent to employees is not based on the team e-mail address assigned to the project member, but the team e-mail address assigned to the employee type of the employee receiving the e-mail.

To define team e-mail addresses based on employee types:

1Click the Team E-mail Addresses for Customers button in the Incoming Mail tab of the E-mail Integration page in the Advanced Settings folder.

The Team E-mail Addresses for Customers dialog box appears.

2Double-click an employee type in the Employee Type list.

The Define E-mail Address for Employee Type dialog box appears.

3Select an administrator-defined team e-mail account and click the OK button.

The e-mail address is assigned to the employee type.

4Click the OK button.

12.3 Managing Project Sending and Reply To Addresses

E-mail event tracking enables support teams to track every e-mail sent to and received from employees through the CustomerWise client as events.

All e-mail events are based on administrator-defined e-mail received or e-mail 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 e-mail notification and escalation rules.

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

• E-mail received event templates combine administrator-defined workflow rules with system-defined business rules for managing e-mail received events.

• E-mail sent event templates combine administrator-defined workflow rules with system-defined business rules for managing e-mail sent events.

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

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

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

• An e-mail sent event based on an e-mail sent event template is automatically created whenever a CustomerWise project member sends an e-mail to an employee.

12.3.1 Enabling Team Reply To Addresses

Project administrators may enable the use of team addresses as the “reply to” e-mail address in project e-mail in the General Settings tab of the E-mail Integration page of the CustomerWise Admin client.

A team e-mail account address is a standard e-mail address that is used by all support engineers assigned to a particular team e-mail account. Every project member may be assigned the team e-mail account that best represents their role in the project. Project administrators may create multiple team e-mail accounts to represent different groups, locations, products, titles, or any other criteria they choose. A typical team e-mail address issupport@abcsoft.com.

Team e-mail addresses may be based on two different options:

• The Team E-mail Account Assigned To Project Member option identifies the team e-mail account assigned to the project member as the default “reply to” address for project e-mail.

• The Team E-mail Address Based on Employee Type option identifies the team e-mail account assigned to the employee as the default “reply to” address for project e-mail based on their employee type.

12.3.2 Enabling Personal E-mail Addresses as Reply To Addresses

In CustomerWise, a personal e-mail address represents the personal e-mail address of a CustomerWise user as defined and managed in the base project by a system administrator.

Project administrators may enable personal e-mail addresses to be used as “reply to” e-mail addresses in the General Settings tab of the E-mail Integration page of the CustomerWise Admin client.

“Reply to” addresses may be based on four different factors: personal e-mail accounts, personal e-mail aliases, team e-mail accounts assigned to support engineers, or team e-mail accounts assigned to employees based on their employee type.

To enable personal e-mail address reply to addresses:

1Enable advanced e-mail settings in the Optional Settings page of the General Project Settings folder.

If Advanced E-mail Integration has not been enabled, the advanced e-mail settings controls are grayed out in the General Settings tab of the E-mail Integration page. For more information see See “Managing Optional Project Features”.

2Select the Support Personal E-mail Address check box in the General Settings tab of the E-mail Integration page.

If the Support Personal E-mail Address option is not enabled, all e-mail sent to employees from within the CustomerWise client uses a team e-mail account as the “reply to” address.

3Select the Project Member E-mail Address Defined in Support Member Manager option from the Default Reply E-mail Address dropdown list.

The Project Member E-mail Address Defined in Support Member Manager option defines the e-mail sending address as the personal e-mail address of the project member as defined in the Support Member manager.

Project administrators may define project member account types, team e-mail address, and personal e-mail address in the Project Member Properties dialog box of the CustomerWise Members page. For more information see See “Understanding Project Member E-mail Addresses”.

12.3.3 Enabling Personal E-mail Aliases as Reply To Addresses

Project administrators may enable the use of personal e-mail aliases as the reply to e-mail addresses in project e-mail in the General Settings tab of the E-mail Integration page of the CustomerWise Admin client.

A personal e-mail address represents the personal e-mail address of a support engineer or an e-mail alias that is displayed as a personal address in e-mail (for example, pmiller@abcsoft.com), but which is actually a standard team address (support@abcsoft.com.).

To enable personal aliases as reply to addresses:

1Enable advanced e-mail settings in the Optional Settings page of the General Project Settings folder.

If Advanced E-mail Integration has not been enabled, the advanced e-mail settings controls are grayed out in the General Settings tab of the E-mail Integration page. For more information see See “Managing Optional Project Features” .

2Select the Support Personal E-mail Address check box in the General Settings tab of the E-mail Integration page of the Advanced Settings folder.

If the Personal E-mail Address (Alias) option is not enabled, all e-mail sent to employees from within the CustomerWise client use the project member’s team e-mail address as the reply to address. Project administrators may define a project members account type, team e-mail address, and personal e-mail address in the Project Member Properties dialog box within the CustomerWise Members page. For more information see See “Understanding Project Member E-mail Addresses” .

3Select the Personal E-mail Address Defined in this Project option from the Default Reply E-mail Address dropdown list.

The TechExcel CustomerWise Personal E-mail Address (Alias) option identifies the project member personal e-mail address (alias) as the reply e-mail address. The project members personal e-mail address in TechExcel CustomerWise is defined as an alias of the team e-mail address. The TechExcel CustomerWise Personal E-mail Address (Alias) option is only displayed in the Default Reply E-mail Address dropdown list if advanced e-mail integration is enabled in a project.

12.3.4 Enabling Personalized E-mail Reply Name

To enable project members to define a personalized name for replies to project e-mail, select the Enable Personalized E-mail Reply Name check box.

12.3.5 Enabling Project Members to Choose Reply Addresses

Project administrators may enable project members to choose whether the e-mail they send to employees from within the CustomerWise client include the standard team e-mail address assigned to them or their personal e-mail address.

To enable project members to choose whether to use their team e-mail account address or their personal e-mail address as the “reply to” address for e-mail sent to employees, select the Allow Project Members to Choose Reply Address when Sending E-mails check box in the General Settings tab of the E-mail Integration page.

If the Allow Project Members to Choose Reply Address when Sending E-mails check box is not selected, the default reply address is used.

12.3.6 Defining E-mail Notification Send From Properties

Project administrators may define the name of the sender and the sending address of e-mail notification messages using controls in the General Settings tab of the E-mail Integration page.

• The From Address field enables the administrator to define the address that is displayed in the e-mail client as the originating address of all e-mail notifications.

• The From Name field enables the administrator to define the name that is displayed in the e-mail client as the sender of all e-mail notifications.

12.4 Managing the Outgoing Mail Server

Incoming e-mail settings determine how e-mail sent to project team e-mail accounts are handled by the CustomerWise system. Incoming e-mail are e-mail messages sent to the team e-mail accounts defined in a CustomerWise project.

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

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

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

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

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

12.5 Managing E-mail Templates for Manual E-mail Messages

CustomerWise projects use the TechExcel CustomerWise Mail Retrieval Server, an NT service, to retrieve e-mail from an e-mail server using the POP3 or MAPI protocol.

To enable and execute e-mail autoretrieval in a CustomerWise project, two administrative tasks must be completed:

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

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

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

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

To enable e-mail autoretrieval in the current project, select the Support E-mail Autoretrieval check box in the Incoming Mail tab of the E-mail Notification page in the Advanced Settings folder.

Note:The Support E-mail Autoretrieval check box is grayed out if advanced e-mail integration is not enabled in the project. For more information see“Managing Optional Project Features”.

12.5.1 Managing the Incident E-mail Template

The Incident E-mail e-mail template is a predefined e-mail messages that support engineers may use to create incident e-mail messages in the CustomerWise client applications.

Project administrators may define an Incident E-mail e-mail template in the E-mail Integration page of the Advanced Settings folder in the CustomerWise Admin client.

Project administrators may add system variables to the subject, body header, body, and signature of the Incident E-mail template that represent various incident properties.

Whenever an e-mail is created based on the Incident E-mail e-mail template, appropriate incident property values are substituted for the system variables in the body of the e-mail message.

Incident property variables include:

Project NameTitle (101)

Description (102)Problem Type (103)

Problem Detail (104)Database (105)

Next State (490)Attach (499)

Progress Status (601)Work Description (605)

Customer access (614)Customer Priority (15)

Support Plan (615)Response time options (617)

SLA details (618)Data Grid (630)

Work Around (12)Satisfaction Level (13)

Request Type (14)Multiple Selection Control (2123)

[Incident Change Summary][Recipient List]

[Knowledge and Notes][Incident History]

[Web Conversation][Customer Information]

[Primary Contact][Incident Contact]

Note:The numbers in parenthesis represent the field number of the control represented by each incident property variable.

To customize the incident e-mail template:

1Click the Incident E-mail button in the in the E-mail Integration page of the Advanced Settings folder in the CustomerWise Admin client.

The E-mail Notification manager appears.

2Define the default title of the e-mail template.

3Define a header for the e-mail body of the e-mail template.

4Define the body of the e-mail template.

5Define the signature of the e-mail template.

The E-mail Signature control enables administrators to define a standard signature to attach to all e-mails sent from the current project.

6Click the OK button.

12.5.2 Managing the Resend E-mail Template

The Resend e-mail template is a predefined e-mail message that serves as a template for creating resend e-mail messages in the CustomerWise client applications.

Project administrators may customize the resend e-mail template in the E-mail Integration page of the Advanced Settings folder in the CustomerWise Admin client.

Project administrators may customize the e-mail body header and e-mail signature of the resend e-mail template.

To customize the resend e-mail template:

1Click the E-mail Resend button in the in the E-mail Integration page of the Advanced Settings folder in the CustomerWise Admin client.

The Header and Signature manager appears.

2Define a header for the e-mail body of the e-mail template.

3Define the signature of the e-mail template.

4Click the OK button.

12.5.3 Managing the Reply E-mail Template

The Reply e-mail template is a predefined e-mail message that serves as a template for creating reply e-mail messages in the CustomerWise client applications.

Project administrators may customize the reply e-mail template in the E-mail Integration page of the Advanced Settings folder in the CustomerWise Admin client.

Project administrators may customize the e-mail body header and e-mail signature of the reply e-mail template.

To customize the reply e-mail template:

1Click the E-mail Reply button in the in the E-mail Integration page of the Advanced Settings folder in the CustomerWise Admin client.

The Header and Signature manager appears.

2Define a header for the e-mail body of the e-mail template.

3Define the signature of the e-mail template. 4 Click the OK button.

12.6 Administering E-mail Incident Submission Settings

CustomerWise advanced e-mail integration enables projects to support multiple incoming e-mail servers and team e-mail accounts.

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

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

• Each team e-mail account has a uniquee-mail address, and the e-mail address assigned to a team e-mail account may indicate the product, service, or location served by that e-mail account.

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

• Each team e-mail account represents two administrator-defined event templates: an e-mail received event template and an e-mail sent event template. E-mail messages sent to or from a team e-mail account automatically create e-mail events based on the corresponding e-mail received or e-mail 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 E-mail Notification page in the Advanced Settings folder.

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

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

12.6.1 Defining Employee Groups

An e-mail incident submission rule defines the rules that enable a group of employees to submit support incidents to a CustomerWise project by sending an e-mail messages to an applicable team e-mail account.

An employee group represents a set of e-mail incident submission rules that are defined for a specific group of employees. Every employee group is defined by a employee type, one or more applicable team e-mail accounts, and optional incident autocreation and incident field mapping rules.

Project administrators may enable optional incident autocreation rules for each employee group. If this option is enabled, the CustomerWise Mail Retrieval Server parses the e-mail and automatically converts the message into an CustomerWise incident based on administrator-defined rules.

To define a employee group:

1Click the Add New button in the E-mail Integration page of the Advanced Settings folder in a work project.

The Employee Group to be Autosubmitted dialog box appears.

2Define the name of the employee group in the Group edit box control.

3Select an employee type option in the Employee dropdown list.

The Employee dropdown list displays every employee type created in the parent base project and the {None} and {Unregistered} system variables.

4Define one or more applicable team e-mail addresses in the E-mail Addresses edit box control.

A team e-mail account represents an administrator-defined e-mail account and an e-mail event template. For more information see “Defining Team E-mail Accounts”.

Note:To enter multiple team e-mail addresses, add the comma character and a space after each e-mail address added.

5 Optional:To enable incident autocreation from e-mail incident submissions.

E-mail auto submission automatically create incidents based on e-mail received from applicable employees.

6To enable e-mail field mapping, select this to enable the E-mail mapping button.

Project administrators may define detailed field mappings to more clearly define incident date.

12.6.2 Enabling E-mail Field Mapping

In CustomerWise, project members and employees may submit support incidents to work projects by sending structured e-mail messages to a defined e-mail address. CustomerWise automatically creates new support incidents based on the content of the subject line and body of the e-mail.

To enable e-mail field mapping:

1Add or edit an employee group in the E-mail Auto Submit tab of the E-mail Integration page of the Advanced Settings folder.

2Define a employee group in the Employee Group to be autosubmitted manager.

Only project members that belong to an administrator-defined e-mail incident submission group may submit incidents by e-mail.

3Select the Support E-mail Field Mapping check box in the Employee Group to be Autosubmitted dialog box.

12.6.3 Defining E-mail Field Mappings

In CustomerWise, project members and employees may submit support incidents to work projects by sending structured e-mail messages to a defined e-mail address.

CustomerWise automatically creates new support incidents based on the content of the subject line and body of the e-mail. Incident submission e-mail messages may incident custom e-mail submission tags that represent incident property variables.

All e-mail submission tags may be customized. Project administrators may define field mappings between incident fields and e-mail submission tags and the field delimiters that are used to identify those tags in the body of the e-mail submission message.

Project administrators may map incident fields to customized e-mail tags in the E-mail Field Mapping manager and define the field delimiters that are used to identify those tags in incident submission e-mail messages.

To edit the name of custom e-mail tags:

1Select the E-mail Mapping button.

The E-mail Field Mapping dialog box appears.

2Select an incident field in the E-mail Field Mapping list.

3Click the Edit button.

The CustomerWise Field dialog box appears.

4Define the name of the custom e-mail tag in the Mapped Name text box.

5Click the OK button.

The CustomerWise Field dialog box closes.

To define custom e-mail tag field delimiters:

1Select the E-mail Mapping button.

The E-mail Field Mapping dialog box appears.

2Click the Change Field Delimiter button.

3The Define Field Delimiter for Auto Submit dialog box appears.

4Enter a field delimiter in the the Field Delimiter text box.

CustomerWise e-mail incident submission supports four different characters as field delimiters for custom e-mail tags:

• chevrons:

• braces: {FIELDNAME}

• brackets: [FIELDNAME]

• parentheses: (FIELDNAME)

5Click the OK button.

6The Define Field Delimiter for Auto Submit dialog box closes.

12.6.4 Managing E-mail–Incident Field Mapping

In CustomerWise, project members and employees may submit support incidents to work projects by sending structured e-mail messages to a defined e-mail address.

CustomerWise automatically creates new support incidents based on the content of the subject line and body of the e-mail. Incident submission e-mail messages may incident custom e-mail submission tags that represent incident property variables.

All e-mail submission tags may be customized. Project administrators may define field mappings between incident fields and e-mail submission tags and the field delimiters that are used to identify those tags in the body of the e-mail submission message.

Project administrators may map incident fields to customized e-mail tags in the E-mail Field Mapping manager and define the field delimiters that are used to identify those tags in incident submission e-mail messages.

To edit the name of custom e-mail tags:

1Select the E-mail Mapping button.

The E-mail Field Mapping dialog box appears.

2Select an incident field in the E-mail Field Mapping list.

3Click the Edit button.

The CustomerWise Field dialog box appears.

4Define the name of the custom e-mail tag in the Mapped Name text box.

5Click the OK button.

The CustomerWise Field dialog box closes.

To define custom e-mail tag field delimiters:

1Select the E-mail Mapping button.

The E-mail Field Mapping dialog box appears.

2Click the Change Field Delimiter button.

3The Define Field Delimiter for Auto Submit dialog box appears.

4Enter a field delimiter in the the Field Delimiter text box.

CustomerWise e-mail incident submission supports four different characters as field delimiters for custom e-mail tags:

• chevrons:

• braces: {FIELDNAME}

• brackets: [FIELDNAME]

• parentheses: (FIELDNAME)

5Click the OK button.

6The Define Field Delimiter for Auto Submit dialog box closes.

 Chapter 13 Incident Notification & Escalation Administration

13.1 Administering Incident Notifications and Escalations

CustomerWise 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 customers.

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 CustomerWise 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 CustomerWise 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.

13.1.1 Push and pull notification subscriptions

TechExcel CustomerWise 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.

13.2 Administering the CustomerWise Mail Service

TechExcel CustomerWise 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.

13.2.1 Reloading Settings to CustomerWise Mail Service

The CustomerWise 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.

13.2.2 Defining Incident Notification Activity Dates

The incident notification activity date identifies the beginning date for all incident notifications in a CustomerWise 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.

13.3 Administering Incident Notifications

The CustomerWise Mail Service enables support organizations to integrate CustomerWise workflow, incident notification, event scheduling, and incident escalation with the convenience of e-mail.

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

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

13.3.1 Enabling Incident Notification in a CustomerWise Project

Incident notification is an optional CustomerWise 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.

13.3.2 Defining Incident Notification Rules

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

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

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

To define an incident notification rule:

1Select Advanced Features > Incident Notifications.

2Click the New button. The Add Notification Rule dialog box appears.

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

A unique name and note that describe the logic of the incident notification rule enables project administrators to save time when they review or update incident 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 incident notification rule is defined by a single notification trigger.

Notification conditions

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

The Condition dropdown list displays all administrator-defined conditions.

Custom notification conditions may be defined in the Notification & Escalation Conditions window.

6Click the OK button.

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

Notification actions

7Define 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 appropriate internal (team member) and external (customer) 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.

Potential recipients

8Define potential recipients in the Potential Recipient tab.

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

Potential recipient subscription rules

9Define subscription rules in the Subscription Option tab.

Potential recipient subscription rules define whether a potential recipient can, cannot, or must subscribe to an incident 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 incident notifications.

Subscribers

10Define subscriptions in the Potential Recipient tab.

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

To rename an incident notification rule:

To rename an incident 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 incident notification rule: 

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

13.3.3 Administering Incident Notification Triggers

In CustomerWise, an incident notification trigger is anaction—such as the creation, edit, or deletion of an incident—that prompts the CustomerWise Mail Service to deliver a notification message to a list of incident stakeholders.

An incident notification is sent every time that the triggering action is performed. If the action is not performed, the incident notification rule is not triggered and the notification message is not sent.

CustomerWise supports bothsystem triggersandcustom triggers.

13.3.3.1 System triggers

CustomerWise system triggers prompt the CustomerWise Mail Service to send notification messages whenever an incident management task is performed on incidents meeting the conditions of the incident notification rule.

CustomerWise supports six system triggers:

On Submit:The On Submit trigger generates an incident notification whenever a new support incident is created in a project.

On Forward:The On Forward trigger generates an incident notification whenever a support incident is forwarded to another project member or workflow state.

On Close:The On Close trigger generates an incident notification whenever a support incident is closed in a project.

On Reopen:The On Reopen trigger generates an incident notification whenever a support incident is reopened in a project.

On New Note:The New Note trigger generates an incident notification whenever a note is added to a support incident.

On Status Change:The On Status Change trigger generates an incident notification whenever the workflow state of an incident is changed.

On Owner Change:The On Owner Change trigger generates an incident notification whenever the owner of an incident is changed.

On Customer Request:The On Customer Request trigger generates an incident notification whenever a customer requests that an incident be reopened.

On Support Response:The On Support Response trigger generates an incident notification whenever a project team member responds to a customer request.

13.4 Administering Incident Escalations

The CustomerWise 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.

13.4.1 Administering Incident Escalation Rules

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.

An incident escalation rule is defined by anescalation trigger, one or more notification actions, andescalation subscription rules. Optional incidentescalation conditionslimit the scope of the rule to a subset of support incidents. Any number of notification rules may be defined in a project.

To create incident escalation rules:

1Select Advanced Features > Incident Escalations.

2Click the New button.

The Add Escalation Rule dialog box appears.

3Provide a name and description for the incident escalation rule.

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

Escalation triggers

4Select an option from the Trigger dropdown list.

The Trigger dropdown list displays four system-defined triggers: Open Too Long, No Progress, On Start Date, and On Finish Date.

Escalation conditions

5 Optional: To limit the scope of an escalation rule, select an incident escalation condition in the Condition dropdown list.

The Condition dropdown list displays all administrator-defined conditions.

Custom escalation conditions may be defined in the Notification & Escalation Conditions window.

6Click the OK button.

The Add Escalation dialog box closes and the incident escalation rule is displayed in the Escalation Rules list.

Escalation actions

An escalation action is defined by anescalation schedule, anescalation method(email, pager, or mobile phone) and anescalation message.

7Define the escalation schedule.

Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number.

• To define the escalation wait period, enter the number of hours and minutes in the Start Escalation controls.

• To define the repeat schedule, enter the number of hours and minutes in the Repeat Escalation controls.

• To define the repeat number, enter a digit in the Repeat Number text box.

8Select an appropriate notification message for each notification method:

• To define an email notification action, select the Notify By Sending Email option and select appropriate internal and external 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.

Distinct email messages may be identified for the last notification sent by each method.

Custom notification messages may be defined in the Define Email window.

Incident reassignment actions

9 Optional: To enable support incidents to be automatically forwarded to a different workflow state or owner if no action is taken on that incident, define incident reassignment rules.

Incident reassignment actions may be defined in the Escalation Action window.

Potential recipients

10Define potential recipients in the Potential Recipient tab.

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

Potential recipient subscription rules

11Define subscription rules in the Subscription Option tab.

Potential recipient subscription rules define whether a potential recipient can, cannot, or must subscribe to an incident 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 incident notifications.

Subscribers

12Define subscriptions in the Potential Recipient tab.

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

Project administrators may use controls in the Email Escalations page to rename, incident escalation rules.

13.4.2 Understanding Incident Escalation Triggers

In CustomerWise, all incident escalation triggers are “time triggers” which prompt the CustomerWise Mail Service to send notification messages to incident stakeholders at key points in the incident lifecycle—for example, its start and finish dates—or when insufficient progress is made on a support incident.

Anescalation triggeridentifies theunperformedtask that triggers an administrator-defined action (incident notification or incident re-assignment). Unlike incident notification triggers which represents specific acts performed on an incident, incident escalation triggers represents acts thatare notperformed on an incident.

CustomerWise supports four incident escalation triggers:.

Open Too Long:The Open Too Long escalation trigger prompts escalation actions when an incident remains open beyond the period defined in the escalation schedule.

No Progress:The No Progress escalation trigger prompts escalation actions when there is no change in ownership or status beyond the period defined in the escalation schedule.

On Start Date:The On Start Date trigger prompts escalation actions when work on an incident has not started within the period defined in the escalation schedule.

On Finish Date:The On Finish Date trigger prompts escalation actions when work on an incident has not ended within the period defined in the escalation schedule.

In CustomerWise, every escalation rule is defined by a single trigger. The scope of the escalation rule may be limited by one or more escalation conditions which limit the number of support incidents that are subject to it.

13.4.3 Administering Incident Escalation Actions

Incident escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers (email, pager, or mobile phone), the message delivered by the notification, and the number of times that notification are sent before an escalated incident is reassigned to another project team member.

An escalation action is defined by anescalation schedule, anotification methodand, optionally, anincident reassignment action.

13.4.3.1 Escalation schedules

All escalation triggers are “time triggers”. CustomerWise executes an escalation action when the “state” defined by the escalation trigger remains unchanged for the period defined in theescalation schedule.

An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications are sent, and the time between notifications.

13.4.3.2 Notification methods

A notification method defines the method by which subscribers are notified that an incident has been escalated.

CustomerWise supports three incident escalation notification methods:

Email Notification:Email notification actions notify subscribers by email whenever an incident notification rule is triggered.

Page Notification:Pager notification actions notify subscribers by pager whenever an incident notification rule is triggered.

Mobile Phone Notification:Mobile phone notification actions notify subscribers by mobile phone whenever an incident notification rule is triggered.

A different email message may be sent for every notification method.

13.4.3.3 Incident reassignment actions

An incident reassignment action defines rules for routing escalated support incidents to specific workflow states or project team members at the end of the incident escalation schedule.

Incident reassignment actions are an optional feature that must be enabled and defined in each incident escalation rule.

13.4.4 Administering Incident Escalation Schedules

An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications may be sent, and the time between each notification.

All escalation triggers are “time triggers”. CustomerWise executes an escalation action when the “state” defined by the escalation trigger remains unchanged for the escalation wait period.

Using controls in the Escalation Action window, project administrators may define an escalation wait period, an escalation schedule, and a repeat number for each incident escalation rule.

Figure 13-1: Schedule Area of the Add Escalation Action Dialog Box

Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number.

• The escalation wait period defines the time that must pass before the subscribers are notified of the incident escalation. The escalation wait period is defined in hours and minutes.

• The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes.

• The repeat number defines the number of times that incidents may be escalated before the incident is reassigned or the incident expires.

After the final escalation action is performed, escalated incidents may be automatically reassigned to another project member, group, or group folder based on administrator-defined reassignment settings.

To define an escalation schedule: 

1Define an incident escalation rule, escalation trigger and trigger conditions in the Incident Escalations page.

2Click the Add button in the Action tab.

Escalation actions may be defined whenever you create or edit an incident escalation rule.

The Escalation Action window appears.

3Define the escalation wait period in the Start Escalation if Incident Remain Open After text box.

The escalation wait period defines the time that must pass before the subscribers are notified of the incident escalation. The escalation wait period is defined in hours and minutes.

4Define the escalation repeat schedule in the Repeat Escalation Every text box.

The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes.

5Define the repeat number in the Repeat Number text box.

The repeat number defines the number of times that incidents may be escalated before the incident is reassigned or the incident expires.

13.4.5 Administering Incident Reassignment Actions

An incident reassignment action defines rules for routing escalated support incidents to specific workflow states or project team members at the end of the incident escalation schedule.

If incident reassignment is enabled, the escalated incident is reassigned and its workflow state is changedonly afterevery scheduled escalation action is performed.

Using controls in the Escalation Action window, project members may enable incident reassignment and routing rules, designate a project team member or group folder as the incident owner, and define workflow state changes for each incident escalation rule.

Figure 13-2: Edit Escalation Action Window (Detail)

The target incident owner of an incident reassignment action may be identified by user account, group folder, or the {Submitter} user variable.

To enable incident reassignment:

1Define incident escalation actions in the Actions tab of the Incident Escalation page.

Incident reassignment actions may be defined whenever you create or edit incident escalation actions in the Actions tab of the Incident Escalation page.

2Select the Do Re-assignment After the Actions Above check box.

Incident reassignment actions must be specifically enabled for each incident escalation rule.

3Select an option in the Re-assign To dropdown list.

The Re-assign To dropdown list displays all user accounts, account types, team group and group folders as well as multiple user variables:

{Submitter}

{Auto Assigned}

{Current Owner}

{Primary Support Engineer}

Salesperson}

4 Optional: To apply routing rules, click the Apply Auto Routing Rules check box.

5Select an incident workflow state in the Change Progress Status dropdown list.

The Change Progress Status dropdown list displays all administrator-defined workflow states as well as the {No Change} state variable.

13.5 Administering Incident Notification and Escalation Conditions

The incident notification activity date identifies the beginning date for all incident notifications in a CustomerWise 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.

13.6 Administering Incident Notification and Escalation Actions

In CustomerWise, 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.

13.6.1 Defining Notification Action Email Addresses

CustomerWise enables project administrators to define incident notification rules that automatically notify many different subscribers of the status of CustomerWise incidents.

Incident notification email may be sent to project members, customer contacts, and administrator-defined email address lists.

The email addresses of incident notification subscribers are managed in different tools in CustomerWise applications.

• Project member email addresses, pager addresses, and mobile phone addresses are all managed in the User Manager. Project member addresses must be defined in the User Manager for project members to receive incident notifications. All CustomerWise project members addresses are managed at the system level.

• Project administrators may create a unique list of email addresses for each notification rule. The email addresses on that list are notified automatically whenever the incident notification rule is triggered.

13.6.2 Defining Email Notification Actions

To define email notification actions:

1Select an email notification rule in the Notification Rule list of the Incident Notifications page.

2Select the Actions tab.

3Select the By Sending Email check box.

Project administrators must enable email notification.

4Select an option from the Email Format dropdown list.

Project administrators may select the email format used to send email notifications to (internal) project members.

The Email Format dropdown list displays all of the email formats defined in the Email Format manager. Project administrators may define new email formats by clicking the Setup button.

5Select an option from the Email Format for Customer dropdown list.

Project administrators may select the email format used to send email notifications to (external) customers.

The Email Format for Customer dropdown list displays all of the email formats defined in the Email Format manager. Project administrators may define new email formats by clicking the Setup button.

13.6.3 Defining Pager and Mobile Phone Notifications

Pager and mobile phone notifications are automatically sent to the number recorded for that project team member in the system. All pager and mobile phone numbers are defined at the site-level in the System Settings project.

To define a pager or mobile phone notification:

1Define an incident escalation rule, escalation trigger and trigger conditions.

2Click the Add button in the Action tab.

Escalation actions may be defined whenever you create or edit an incident escalation rule.

The Escalation Action window appears.

3Click the Pager & Mobile Phone Notification button.

The Pager & Mobile Phone Notification window appears.

4 Optional: To define an incident escalation pager action, select the Enable Pager Notification check box and select an email message in the Pager dropdown list.

5 Optional: To define an incident escalation mobile phone action, select the Enable Pager Notification check box and select an email message in the Mobile Phone dropdown list.

The option selected in the Email Format identifies the email message that is sent to rule subscribers when an incident is first escalated and for every subsequent notification prior to the final notification.

13.6.4 Defining Incident Email Notifications

Pager and mobile phone notifications are automatically sent to the number recorded for that project team member in the system. All pager and mobile phone numbers are defined at the site-level in the System Settings project.

To define a pager or mobile phone notification:

1Define an incident escalation rule, escalation trigger and trigger conditions.

2Click the Add button in the Action tab.

Escalation actions may be defined whenever you create or edit an incident escalation rule.

The Escalation Action window appears.

3Click the Pager & Mobile Phone Notification button.

The Pager & Mobile Phone Notification window appears.

4 Optional: To define an incident escalation pager action, select the Enable Pager Notification check box and select an email message in the Pager dropdown list.

5 Optional: To define an incident escalation mobile phone action, select the Enable Pager Notification check box and select an email message in the Mobile Phone dropdown list.

The option selected in the Email Format identifies the email message that is sent to rule subscribers when an incident is first escalated and for every subsequent notification prior to the final notification.

 Chapter 14 Subproject Administration

14.1 Understanding Subprojects

CustomerWise 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 CustomerWise 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 CustomerWise support projects may be managed using a combination of subprojects, incidents, and events.

• Subprojects are groups of incidents that are organized together 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.

• Incidents are 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.

14.1.1 Administering Subprojects

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

Administrator-defined subproject settings define how project members may manage subprojects in a CustomerWise 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 CustomerWise site.

14.2 Defining General Subproject Settings

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

Administrator-defined subproject settings define how project members may manage subprojects in a CustomerWise 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 CustomerWise site.

14.2.1 Customizing Subproject Terminology

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

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

14.2.2 Enabling Subprojects in Work Projects

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

To enable support for subprojects in a CustomerWise work project, select an option from the Subproject dropdown list in the General Settings page of the Subproject folder in a CustomerWise 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 andSupport 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.

14.2.3 Enabling Employee Assignment to Subprojects

To enable employees to be assigned to subprojects, select an option from the Subproject Employee Assignment dropdown list in the General Settings page of the Subproject folder in a CustomerWise work project.

The Subproject Employee Assignment dropdown list displays three options:

All Employees are Applicable:If the All Employees are Applicable option is selected, all employees are applicable to subprojects in the project.

No Employees Can Be Assigned:If the No Employees Can Be Assigned option is selected, employees are not applicable to subprojects in the project.

Define Applicable Employees:If the Define Applicable Employees option is selected, project members may define which employees are applicable to subproject in the CustomerWise client. When project members submit incidents to a subproject, only applicable employees are displayed as options in the Subproject Employee control.

14.2.4 Enabling Subproject Applicable Owner Controls

In the CustomerWise client, project members may define which project members may own the incidents managed in that subproject in the Applicable Owners tab of the Subproject manager. Only those project members that are defined asapplicableto a subproject may be assigned support incidents managed in that subproject.

Subproject team assignment is an optional CustomerWise feature. Project members may only define applicable incident owners if the Applicable Owners tab is displayed in the CustomerWise client.

To display the Applicable Owner tab in the CustomerWise client, select the Enable Team Assignment for Subproject check box in the General Settings page of the Subproject folder in a CustomerWise work project.

14.2.5 Restricting Incident Ownership to Subproject Members

To restrict the ownership of incidents in a subproject to project members that have been designed subproject team members, select the Apply Subproject Project Member Restriction to Incident Owner check box in the General Settings page of the Subproject folder in a CustomerWise work project.

Subproject team assignment must be enabled before the project administrator can define subproject incident ownership rules. The Apply Subproject Project Member Restriction to Incident Owner check box is read-only if the Enable Team Assignment for Subproject is not selected.

14.2.6 Restricting Event Ownership to Subproject Members

To restrict the ownership of events in a subproject to project members that have been designed subproject team members, select the Apply Subproject Project Member Restriction to Event Owner check box in the General Settings page of the Subproject folder in a CustomerWise work project.

Subproject team assignment must be enabled before the project administrator can define subproject event ownership rules. The Apply Subproject Project Member Restriction to Event Owner check box is read-only if the Enable Team Assignment for Subproject is not selected.

14.2.7 Enabling Subproject Workflow Controls

In the CustomerWise client, project members may define which incidents may be assigned to each subproject based on incident workflow states in the Workflow tab of the Subproject manager.

To display the Workflow tab in the CustomerWise client, select the Support Subproject Specific Incident Status check box in the General Settings page of the Subproject folder in a CustomerWise work project.

14.2.8 Enabling Subproject Cost Budgets Controls

In the CustomerWise client, project members may define the planned internal costs and track actual internal costs of the subproject in the Cost Budget tab of the Subproject manager.

To display the Cost Budget tab in the CustomerWise client, select the Support Subproject Cost Budget Control check box in the General Settings page of the Subproject folder in a CustomerWise work project.

14.2.9 Defining Default Subprojects

To define the default subproject, select a subproject in the Default Subproject dropdown list of the General Settings page of the Subproject folder in a CustomerWise work project.

14.3 Administering Subproject Status Definitions

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

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

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

14.3.1 Understanding Subproject Status Criteria

The subproject status of a subproject is based on one of four factors: its subproject workflow state, the incident workflow state of its highest ranked incident, or the incident workflow state of its lowest ranked incident.

To define the method that is used to define the subproject status of subprojects in a CustomerWise work project, select an option from the Subproject Status Option dropdown list in the Subproject Status page of the Subprojects folder in a CustomerWise work project.

The Subproject Status Option dropdown list displays four options:

Independent of its Incidents:The Independent of its Incidents option enables administrators to define a set of subproject workflow states.

Derived from the Highest-ranked Incident Status: The Derived from the Highestranked Incident Status option links subproject status to the status of the highest-ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents.

Derived from the Lowest-ranked Incident Status:The Derived from the Lowestranked Incident Status option links the subproject status to the lowestranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents.

Linked to Incident Status Definition option:The Linked to Incident Status Definition option links the applicable subproject workflow states to the incidents workflow states.

14.3.2 Defining Independent Subproject Status Settings

To define independent subproject status settings:

1Select the Independent of its Incidents option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project.

2Define one or more subproject status.

3Define ranks for each subproject status.

The lower the number, the higher the ranking – for example, a status with a rank of one is ranked higher than a status with a rank of five. The incident with the highest-ranking status determines the status of the subproject.

14.3.3 Defining Derived from Highest Ranked Incident Status Settings

The Derived from the Highest-ranked Incident Status option links subproject status to the status of the highest ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents.

To base subproject priorities on the incident status of the highest ranked incident in a subproject, select the Derived from the Highest-ranked Incident Status option in the Subproject Status Option dropdown list of the Subproject Status page in the Subproject folder of a work project.

14.3.4 Defining Derived from Lowest Ranked Incident Status Settings

The Derived from the Lowest-ranked Incident Status option links the subproject status to the lowest ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents.

To base subproject priorities on the incident status of the lowest ranked incident in a subproject, select the Derived from the Lowest-ranked Incident Status option in the Subproject Priority Status dropdown list of the Subproject Status page in the Subproject folder of a work project.

14.3.5 Defining Linked to Incident Status Settings

To define independent subproject status settings:

1Select the Linked to Incident Status Definition option in the Subproject Status Option dropdown list of the Subproject Priority page in the Subproject folder of a work project.

2Select an incident property in the Link to Status dropdown list control.

The Link to Priority dropdown list displays multiple properties that define incidents in the work project. For example the Change Type property, the Location property, or the CustomerWise Priority property.

3Define ranks for each subproject status.

The lower the number, the higher the ranking – for example, a status with a rank of one is ranked higher than a status with a rank of five. The incident with the highest-ranking status determines the status of the subproject.

14.4 Defining Subproject Priorities

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

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

14.4.1 Understanding Subproject Priority Criteria

To define the method that is used to define the subproject status of subprojects in a CustomerWise work project, select an option from the Subproject Status Option dropdown list in the Subproject Status page of the Subprojects folder in a CustomerWise work project.

The Subproject Status Option dropdown list displays four options:

Independent of its Incidents:The Independent of its Incidents option enables project administrators to define a set of subproject priorities. The subproject priority of a subproject is manually defined by project members in the CustomerWise client.

Derived from the Highest-ranked Incident Priority:The Derived from the Highestranked Incident Status option links subproject status to the status of the highest-ranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents.

Derived from the Lowest-ranked Incident Priority:The Derived from the Lowestranked Incident Status option links the subproject status to the lowestranked incident within the subproject. If this option is selected the available states for subproject status are the same as the available states for incidents.

Linked to Incident Priority Definition option:The Linked to Incident Status Definition option links the applicable subproject workflow states to the incidents workflow states.

14.4.2 Defining Independent Subproject Priority Settings

To define independent subproject priority settings: 

1Select the Independent of its Incidents option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project.

2Define one or more subproject priorities.

3Define ranks for each subproject priority.

The lower the number, the higher the ranking – for example, a priority with a rank of one is ranked higher than a priority with a rank of five. The incident with the highest-ranking priority determines the priority of the subproject.

14.4.3 Defining Derived from Highest Ranked Incident Priority Settings

To base subproject priorities on the incident priority of the highest ranked incident in a subproject, select the Derived from the Highest-ranked Incident Priority option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project.

14.4.4 Defining Derived from Lowest Ranked Incident Priority Settings

To base subproject priorities on the incident priority of the lowest ranked incident in a subproject, select the Derived from the Lowest-ranked Incident Priority option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project.

14.4.5 Defining Linked to Incident Priority Settings

To define independent subproject priority settings: 

1Select the Independent of its Incidents option in the Subproject Priority Option dropdown list of the Subproject Priority page in the Subproject folder of a work project.

2Define one or more subproject priorities.

3Define ranks for each subproject priority.

The lower the number, the higher the ranking – for example, a priority with a rank of one is ranked higher than a priority with a rank of five. The incident with the highest-ranking priority determines the priority of the subproject.

14.5 Defining Subproject Access Controls

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

To enable support for subprojects in a CustomerWise work project, select an option from the Subproject dropdown list in the General Settings page of the Subproject folder in a CustomerWise 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 andSupport 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.

 Chapter 15 Event Administration

15.1 Understanding CustomerWise Events

TechExcel CustomerWise 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 e-mail, or approval from management.

15.1.1 Events and incidents

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.

15.1.2 Understanding Event Administration

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.

15.1.3 Understanding Event Types

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 e-mail, and adding documents to the knowledge base all represent very different processes and are managed by distinct business rules in CustomerWise projects.

CustomerWise features nine different system-defined event types. Each event type represents a set of system-defined business rules.

CustomerWise features two different kinds of event templates: definable event types and system event templates.

Both definable and system event types represent a set of business rules designed manage events in a CustomerWise project.

• Definable event types may be used to create event templates. Project administrators may create many different event templates for each definable event type, and define a unique set of workflow rules for each event template.

• System event types may not be used to create event templates.

15.1.4 Definable event types

A definable event type is an event type that may be used to create event templates in a CustomerWise work project.

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.

e-mail announcement event type: The e-mail announcement event type defines a set of business rules for managing e-mail blasts.

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

e-mail sent event type: The e-mail received event type defines a set of business rules for managing e-mail sent from a team e-mail 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.

• The Incident File

• The Interproject Copied

• The Newly Registered User

• The Request for Password

15.2 Defining General Event Settings

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.

15.2.1 Renaming Events in CustomerWise Projects

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 CustomerWise projects.

The termeventis displayed throughout the CustomerWise Admin client and the CustomerWise 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 CustomerWise Admin client.

15.2.2 Enabling the Calendar View

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

Figure 15-1: Calendar View in the CustomerWise 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 CustomerWise client applications, select the Enable Event Calendar View check box in the General Settings page of the Event Management folder of the CustomerWise Admin client.

15.3 Managing System Event Templates

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.

15.4 Managing Definable Event Templates

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 e-mail, and adding documents to the knowledge base all represent very different processes and are managed by distinct business rules in CustomerWise projects.

CustomerWise features nine different system-defined event types. Each event type represents a set of system-defined business rules.

CustomerWise features two different kinds of event templates: definable event types and system event templates.

Both definable and system event types represent a set of business rules designed manage events in a CustomerWise project.

• Definable event types may be used to create event templates. Project administrators may create many different event templates for each definable event type, and define a unique set of workflow rules for each event template.

• System event types may not be used to create event templates.

15.4.1 Creating 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 e-mail 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

• e-mail announcement event type

• e-mail received event type

• e-mail 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:

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

The Add a New Event Template dialog box appears.

17Define 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.

18Enter 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.

19Select 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

• e-mail announcement event type

• e-mail received event type

• e-mail 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.

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

21Define event workflow states.

22Define applicable event owner rules.

23Define event start dates and due dates.

24Enable or disable employee access.

25Define the event scope.

26Define template identifier.

15.4.2 Deleting Event Templates

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

15.5 Administering General Event Template Properties

A definable event type is an event type that may be used to create event templates in a CustomerWise work project.

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.

e-mail announcement event type: The e-mail announcement event type defines a set of business rules for managing e-mail blasts.

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

e-mail sent event type: The e-mail received event type defines a set of business rules for managing e-mail sent from a team e-mail 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.

• The Incident File

• The Interproject Copied

• The Newly Registered User

• The Request for Password

15.5.1 Defining Start Dates and Due Dates

The start and due dates represent the beginning and ending of events. Project administrators may determine these settings may be defined, managed, and tracked for all events based on an event template.

Project administrators may define or update default values, offset times, and employee access settings for event template start and due dates in the Property tab of the Event Template page in the Event Management folder of the CustomerWise Admin client.

Project administrators may make six different customizations to each control:

• Define the field label that identifies the data-entry control.

• Enable default values to be entered in the data-entry controls based on the date that the event is created.

• Define day, hour, and minute offset settings.

• Define the data-entry controls as visible or invisible.

• Enable display of the time

• Define employee access to the data-entry controls. Each control may be defined as invisible, read-only, or editable for employees.

To customize Event Template date controls:

1Select an event template in the Event list control of the Event Templates page.

2Double-click the Start Date control or Due Date control in the Property tab. The Event Templates Edit Box appears.

3 Optional:To customize the field label that identifies the data-entry control, enter a unique name in the Field Label control.

4 Optional:To enable default values to be displayed in the data-entry control, select the Assign Default Value based on Current Time radio button in the Default Values area of the Property tab.

5 Optional:To define offset times for the days, minutes, and hours tracked in the data-entry controls, select an option in the Day, Hour, and Minute controls.

6 Optional:To define the data-entry control as visible to project members, select the Visible check box in the Field Attributes area.

7 Optional:To enable the data-entry control to display times to project members, select the With Time check box in the Field Attributes area.

8 Optional:To define employee access to the data-entry control, select an option in the Employee Access area.

• Select the Not Visible radio button to define the data-entry control as invisible to employees. Employees cannot view or edit control settings.

• Select the Read Only radio button to define the data-entry control as read-only to employees. Employees may view, but cannot edit control settings.

• Select the Edit radio button to define the data-entry control as editable to employees. Employees may view and edit control settings.

9Click the OK button.

15.5.2 Defining the Event Template Scope

The scope of an event determines when and how that event may be created in a CustomerWise project. Every CustomerWise event may be a general event or an incident-specific event.

• General events are not linked to support incidents.

• Incident-specific events are linked to a support incident at all times in project workflow.

To define the scope of an event template and the applicable event scope of all events based on that event template, select an option from the Event Scope dropdown list.

• If the General Event Templates option is selected, the event template may be used to create general events only.

• If the Incident-specific Event Templates option is selected, the event template may be used to create incident-specific events only.

• If the The Both Incident-specific and General Event Templates option is selected, the event template may be used to create both general events and incident-specific events.

15.5.3 Defining the Prefix and Help Notes

Project administrators may define help notes that are added when an event is submitted to a project and an event name prefix that identifies events in the Properties page.

• The Help Note

• The Prefix

15.5.4 Defining Event Number Restrictions

• Single open event – select if multiple events of the same event type can be open for an issue at the same time. Checking this option at the bottom of the page prevents more than one event of the same type from being open for each incident.

• Select if multiple events of the same event type can be open for an opportunity/ incident at the same time. Checking this option at the bottom of the page prevents more than one event of the same type from being open for each incident.

15.5.5 Defining Event Template Identifiers

Project administrators may define an identifying prefix that is appended to events in the Properties page. The Template identifier is used to identify the event template that was used to generate an event.

The template identifier is useful when working with events that have been imported from another project.

15.6 Administering Event Submission Access Controls

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

15.7 Administering Event Editing Access Controls

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 CustomerWise projects.

The termeventis displayed throughout the CustomerWise Admin client and the CustomerWise 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 CustomerWise Admin client.

15.7.1 Administering Event Deletion Access Controls

Event deletion access controls determine which project members and employees may delete events based on an event template.

Note:The Delete Event privilege overrides all view and edit access privileges. Project members that have the privileges to delete events, may view or edit that event as well, regardless of all other settings.

15.7.2 Enabling Employees to Delete Events

Project administrators may define which project members and employees may delete events based on administrator-defined event templates in the Who Can Delete page of the Event Template page.

Project administrators may choose one of three employee submission options for each administrator-defined event template:

• All Employees Can Edit

• Applicable Employee May Edit

• No Employee Can Edit

If the Applicable Employee May Edit option is selected in the Employee dropdown list, the administrator must enable each employee type to delete events based on the selected event template.

To enable employees to delete events:

1Select an event template in the Event Template list of the Event Template page.

2Select an option from the Employee dropdown list in the Who Can Delete tab of the Event Templates page. The Employee dropdown list displays four options:

• The All Employees Can Delete option enables all project members to delete events based on the event template.

• The Applicable Employees May Delete option enables the project administrator to define which employee types may delete events based on the event template.

• The Only Power User Employees Can Delete enables Power Users to delete events based on the event template.

• The No Employee Can Delete restricts employees from deleting events based on the event template.

3If the Applicable Employees May Delete option was selected in the Employee dropdown list, select one or more options in the Applicable Account Types list control.

The Applicable Account Types list control displays the all of the administrator-defined employee types in the project.

15.8 Administering Event Attachment Rules

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

Figure 15-1: Calendar View in the CustomerWise 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 CustomerWise client applications, select the Enable Event Calendar View check box in the General Settings page of the Event Management folder of the CustomerWise Admin client.

15.9 Managing Regular Event Templates

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 CustomerWise 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

15.9.1 Creating Regular Event Templates

To create and define regular event templates:

1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears.

2Define 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.

3Enter 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.

4Select the regular event type option the Event Type dropdown list control.

5Click the OK button. The Add a New Event Template dialog box closes.

15.9.2 Defining Closed Date Controls

In CustomerWise, project members may track the time and date that an event was closed in the Closed Date control. The Closed Date control is a read-only control that displays the time and date that an event was closed.

The Closed Date control is only displayed in the CustomerWise client or Employee Web Portal if it has been defined as Visible in the event template.

Defining Elapsed Time ControlsIn CustomerWise, project members may track the time and date that an event was closed in the Elapsed Time control. The Elapsed Time control is a read-only control that displays the time that has elapsed between the creation and closure of the event.

The Elapsed Time control is only displayed in the CustomerWise client or Employee Web Portal if it has been defined as Visible in the event template.

Defining Event Template ScopeThe event scope determines whether the event template may be used to create general events, incident-specific events, or both general events and incident-specific events.

15.10 Managing Asset Operation Event Type Event Templates

Everyeventcreated in a CustomerWise 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 CustomerWise projects: administrator-defined workflow rules and system-defined business rules.

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

• System-defined business rules determine how events are processed by theCustomerWise 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 e-mail 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 CustomerWise 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, E-mail Announcement Event event type, E-mail Received Event event type, E-mail 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.

15.10.1 Creating Asset Operation Event Templates

Project administrators may create multiple event templates based on the Asset Operation event type. Project members may use asset operation event templates to create asset operation events in the CustomerWise clients.

To create an asset operation event template:

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

The Add a New Event Template dialog box appears.

2Define 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.

3Enter 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.

4Select the Asset Operation Event Type option from the Event Type dropdown list control.

5Select an asset operation from the Asset Operation dropdown list.

The Asset Operation dropdown list displays eight different event type options:

• {Assign Asset}

• {Associate}

• {Disassociate}

• {{New Asset}

• New Employee Assets

• {Return Asset}

• {Update Status}

• {Upgrade}

6Click the OK button. The Add a New Event Template dialog box closes.

7Define event submission access controls in the Submitters tab of the Event Templates page.

8Define event editing access controls in the Who Can Edit tab of the Event Templates page.

9Define event deletion access controls in the Who Can Delete tab of the Event Templates page.

10Define event attachment rules in the Attachments tab of the Event Templates page.

15.10.2 Defining Asset Operations

The Asset Operation property defines an applicable asset operation for the event template. The Asset Operation property is only applicable to asset operation events.

Applicable assets include:

• {Assign Asset}

• {Exchange}

• {New Asset}

• {{Parts}

• {Reconcile}

• {Return Asset}

• {RMA Return with Exchange}

• {RMA Return}

• {Update Status}

• {Upgrade}

The Asset Operation dropdown list is only displayed in the Properties page if the event template is defined as an asset operation event in the Event Type dropdown list.

15.10.3 Defining Applicable Assets

Project administrators may associate one or more assets with an event template by selecting applicable assets in the Product list displayed in the Applicable Assets tab.

The Product list displays high-level information about the products managed in the project including the product name, category, and category ID number.

An asset is only applicable to the Asset Operation event template when a check mark appears next to the name of the product in the Product list.

15.10.4 Defining Event Template Applicable Asset Rules

Project administrators may define price schedules and applicable products for Asset Operation event templates in the Attachment page of the Event Template page.

Figure 15-3: Applicable Asset Tab in the Event Template Page

The applicable asset rules that the administrator defines for the Asset Operation event template are inherited by all Asset Operation events created in the client based on that event template.

The Applicable Asset tab consists of two controls:

• The Price Schedule dropdown list displays every price schedule defined in the current project.

• The Product list displays high-level information about the products managed in the project including the product name, category, and category ID number.

The Applicable Asset tab is only displayed in the Properties page if an Asset Operation event template is selected in the Event Template list.

15.10.5 Defining Price Schedules

Project administrators may define the price schedule used for assets associated with an event template by selecting a price schedule from the Price Schedule dropdown list.

The Price Schedule dropdown list displays every price schedule defined in the current project. Typical price schedules include:

• Educational Pricing

•EnterprisePricing

• Government Pricing

• Small Business Pricing

• Standard Pricing

15.11 Managing Autodiscovery Asset 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 e-mail 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

• e-mail announcement event type

• e-mail received event type

• e-mail 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:

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

The Add a New Event Template dialog box appears.

17Define 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.

18Enter 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.

19Select 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

• e-mail announcement event type

• e-mail received event type

• e-mail 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.

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

21Define event workflow states.

22Define applicable event owner rules.

23Define event start dates and due dates.

24Enable or disable employee access.

25Define the event scope.

26Define template identifier.

15.11.1 Understanding Asset Autodiscovery Event Asset Operations

Asset autodiscovery event asset operations

• The {Chat} asset operation

• {Detail Info} asset operation

• {File Transfer} asset operation

• {Remote Control} asset operation

• {Remote Execute} asset operation

15.11.2 Creating Asset Autodiscovery Event Templates

Project administrators may create asset autodiscovery event templates in the in the Event Templates page of the Event Management folder or the Event Template Setting page of the Asset Autodetection Integration folder in the Asset Management AssetWise folder.

Figure 15-4: Event Template Setting Page in the Asset Autodetection Integration Folder

To create autodiscovery event templates:

1Click the New button in the Event Template Setting page of the Asset Autodetection Integration folder in the Asset Management AssetWise folder.

All other event templates are created in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears.

2Define 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.

3Enter a brief description of the event template in the Description text edit box control. The Description property provides a brief description of the purpose and functionality of the event template.

The event template description is the default description for user-defined events that are based on the selected event template.

4Select the Asset Autodiscovery Asset Event option from the Event Type dropdown list control.

In the Event Template Setting page of the Asset Autodetection Integration folder on the Asset Autodiscovery Asset Event option is displayed.

5Select an asset operation:

• The {Chat} asset operation

• {Detail Info} asset operation

• {File Transfer} asset operation

• {Remote Control} asset operation

• {Remote Execute} asset operation

6Click the Submit button.

15.12 Managing E-mail Announcement Event Templates

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

15.12.1 Enabling Automatic Event Status Definition

Project administrators may enable the status of e-mail announcement events to be automatically defined whenever an e-mail is sent.

The Auto Set Status to when All E-mails Are Send dropdown in the Properties page displays the states. The option selected is defined as the default state for all default options.

Auto set statuses may be used to automatically close events after the all e-mail has been delivered.

The Auto Set Event Status To When All E-mails Are Sent dropdown list is only displayed in the Properties page if the event template is defined as a e-mail announcement event in the Event Type dropdown list.

The E-mail Announcement event type represents a set of business rules for managing e-mail announcement events.

15.12.2 Creating E-mail Sent Announcement Templates

To create and define e-mail announcement event templates:

1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears.

2Define 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.

3Enter 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.

4Select the e-mail announcement event type option the Event Type dropdown list control.

5Click the OK button. The Add a New Event Template dialog box closes.

6Define event submission access controls in the Submitters tab of the Event Templates page.

7Define event editing access controls in the Who Can Edit tab of the Event Templates page.

8Define event deletion access controls in the Who Can Delete tab of the Event Templates page.

9Define event attachment rules in the Attachments tab of the Event Templates page.

15.13 Managing E-mail Received Event Templates

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

15.13.1 Creating E-mail Received Event Templates

To create and define e-mail received event templates:

1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears.

2Define 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.

3Enter 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.

4Select the e-mail received event type option the Event Type dropdown list control.

5Click the OK button. The Add a New Event Template dialog box closes.

6Define event submission access controls in the Submitters tab of the Event Templates page.

7Define event editing access controls in the Who Can Edit tab of the Event Templates page.

8Define event deletion access controls in the Who Can Delete tab of the Event Templates page.

9Define event attachment rules in the Attachments tab of the Event Templates page.

15.14 Managing E-mail Sent Event Templates

The start and due dates represent the beginning and ending of events. Project administrators may determine these settings may be defined, managed, and tracked for all events based on an event template.

Project administrators may define or update default values, offset times, and employee access settings for event template start and due dates in the Property tab of the Event Template page in the Event Management folder of the CustomerWise Admin client.

Project administrators may make six different customizations to each control:

• Define the field label that identifies the data-entry control.

• Enable default values to be entered in the data-entry controls based on the date that the event is created.

• Define day, hour, and minute offset settings.

• Define the data-entry controls as visible or invisible.

• Enable display of the time

• Define employee access to the data-entry controls. Each control may be defined as invisible, read-only, or editable for employees.

To customize Event Template date controls:

1Select an event template in the Event list control of the Event Templates page.

2Double-click the Start Date control or Due Date control in the Property tab. The Event Templates Edit Box appears.

3 Optional:To customize the field label that identifies the data-entry control, enter a unique name in the Field Label control.

4 Optional:To enable default values to be displayed in the data-entry control, select the Assign Default Value based on Current Time radio button in the Default Values area of the Property tab.

5 Optional:To define offset times for the days, minutes, and hours tracked in the data-entry controls, select an option in the Day, Hour, and Minute controls.

6 Optional:To define the data-entry control as visible to project members, select the Visible check box in the Field Attributes area.

7 Optional:To enable the data-entry control to display times to project members, select the With Time check box in the Field Attributes area.

8 Optional:To define employee access to the data-entry control, select an option in the Employee Access area.

• Select the Not Visible radio button to define the data-entry control as invisible to employees. Employees cannot view or edit control settings.

• Select the Read Only radio button to define the data-entry control as read-only to employees. Employees may view, but cannot edit control settings.

• Select the Edit radio button to define the data-entry control as editable to employees. Employees may view and edit control settings.

9Click the OK button.

15.14.1 Creating E-mail Sent Event Templates

To create and define e-mail sent event templates:

1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears.

2Define 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.

3Enter 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.

4Select the e-mail sent event type option the Event Type dropdown list control.

5Click the OK button. The Add a New Event Template dialog box closes.

6Define event submission access controls in the Submitters tab of the Event Templates page.

7Define event editing access controls in the Who Can Edit tab of the Event Templates page.

8Define event deletion access controls in the Who Can Delete tab of the Event Templates page.

9Define event attachment rules in the Attachments tab of the Event Templates page.

15.15 Defining Knowledge Management Event Templates

The scope of an event determines when and how that event may be created in a CustomerWise project. Every CustomerWise event may be a general event or an incident-specific event.

• General events are not linked to support incidents.

• Incident-specific events are linked to a support incident at all times in project workflow.

To define the scope of an event template and the applicable event scope of all events based on that event template, select an option from the Event Scope dropdown list.

• If the General Event Templates option is selected, the event template may be used to create general events only.

• If the Incident-specific Event Templates option is selected, the event template may be used to create incident-specific events only.

• If the The Both Incident-specific and General Event Templates option is selected, the event template may be used to create both general events and incident-specific events.

15.15.1 Creating Knowledge Management Event Templates

To create and define knowledge management event templates:

1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears.

2Define 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.

3Enter 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.

4Select the knowledge management event type option the Event Type dropdown list control.

5Click the OK button. The Add a New Event Template dialog box closes.

6Define event submission access controls in the Submitters tab of the Event Templates page.

7Define event editing access controls in the Who Can Edit tab of the Event Templates page.

8Define event deletion access controls in the Who Can Delete tab of the Event Templates page.

9Define event attachment rules in the Attachments tab of the Event Templates page.

15.16 Defining Power User Event Templates

Project administrators may define help notes that are added when an event is submitted to a project and an event name prefix that identifies events in the Properties page.

• The Help Note

• The Prefix

15.16.1 Creating Power User Event Templates

To create and define power user event templates:

1Click the New button in the Event Templates page of the Event Management folder. The Add a New Event Template dialog box appears.

2Define 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.

3Enter 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.

4Select the power user event type option the Event Type dropdown list control.

5Click the OK button. The Add a New Event Template dialog box closes.

6Define event submission access controls in the Submitters tab of the Event Templates page.

7Define event editing access controls in the Who Can Edit tab of the Event Templates page.

8Define event deletion access controls in the Who Can Delete tab of the Event Templates page.

9Define event attachment rules in the Attachments tab of the Event Templates page.

15.17 Defining Quick Letter Event Templates

• Single open event – select if multiple events of the same event type can be open for an issue at the same time. Checking this option at the bottom of the page prevents more than one event of the same type from being open for each incident.

• Select if multiple events of the same event type can be open for an opportunity/ incident at the same time. Checking this option at the bottom of the page prevents more than one event of the same type from being open for each incident.

 Chapter 16 Event Notification & Escalation Administration

16.1 Administering Event Notifications and Escalations

CustomerWise 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 CustomerWise 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 CustomerWise 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.

16.1.1 Push and pull notification subscriptions

TechExcel CustomerWise 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.

16.2 Administering Event Notifications

TechExcel CustomerWise 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.

16.2.1 Enabling Event Notification in a CustomerWise Project

Event notification is an optional CustomerWise 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.

16.2.2 Defining Event Notification Rules

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(customer) 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.

16.2.3 Administering Event Notification Triggers

In CustomerWise, an event notification trigger is anaction—such as the creation, edit, or deletion of an event—that prompts the CustomerWise Mail Service to deliver a notification message to a list of event stakeholders.

An event notification is sent every time that the triggering action is performed. If the action is not performed, the event notification rule is not triggered and the notification message is not sent.

CustomerWise supports bothsystem triggersandcustom triggers.

System triggers

CustomerWise system triggers prompt the CustomerWise Mail Service to send notification messages whenever an event management task is performed on events meeting the conditions of the event notification rule.

CustomerWise supports six system triggers:

New:The New Event trigger generates an event notification whenever a new support event is created in a project.

Close:The Closed Event trigger generates an event notification whenever a support event is closed in a project.

Status Change:Status change triggers generate event notifications based on changes to the workflow state of support events.

Owner Change:Owner change triggers generate event notifications based on changes in event ownership.

16.3 Administering Event Escalations

In CustomerWise, 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.

16.3.1 Escalation triggers

Unlike event notifications (which are based on the changes that project members make to CustomerWise events), event escalation rules are based on changes that are not made to events.

Every event escalation rule is defined by one of four, system-definedescalation triggers: On New Event, On Close Event, On Status Change, and On Owner Change.

16.3.2 Escalation conditions

The scope of an escalation rule may be limited to support events that meet a set of criteria—theevent escalation condition.

An escalation condition is essentially a query that filters events by their event property values. For example, a condition may limit the scope of an escalation rule to events that have a High or Urgent status.

16.3.3 Escalation actions

All escalation triggers are “time triggers”. CustomerWise executes an escalation action when the “status” defined by the escalation trigger remains unchanged for the escalation wait period.

Event escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers (email, pager, or mobile phone), the message delivered by the notification, and the number of times that notification are sent before an escalated event is reassigned to another project team member.

16.3.4 Subscribers

CustomerWise enables administrators to manage both push email and pull email for each event escalation rule using subscription rules.

Project administrators may mandate that certain project members receive event escalation notifications for certain events while others may opt in or opt out of individual subscriptions. Project administrators may also mandate that certain project member never receive event escalation notifications based on event escalation rules.

16.3.5 Administering Event Escalation Rules

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.

An event escalation rule is defined by anescalation trigger, one or more notification actions, andescalation subscription rules. Optional eventescalation conditionslimit the scope of the rule to a subset of support events.

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

To create event escalation rules:

1Select Advanced Features > Event Escalations.

2Click the New button.

The Add Escalation Rule dialog box appears.

3Provide a name and description for the event escalation 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.

Escalation triggers

4Select an option from the Trigger dropdown list.

The Trigger dropdown list displays four system-defined triggers: the On New Event, On Close Event, On Status Change, and the On Owner Change triggers. For more information see “Understanding Event Escalation Triggers”.

Escalation conditions

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

The Condition dropdown list displays all administrator-defined conditions.

Custom escalation conditions may be defined in the Notification & Escalation Conditions window. For step-by-step instructions see “Administering Event Notification and Escalation 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 escalation rule is restricted to support events based on the selected regular and co-owner event templates.

7Click the OK button.

The Add Escalation dialog box closes and the event escalation rule is displayed in the Escalation Rules list.

Escalation actions

An escalation action is defined by anescalation schedule, anescalation method(email, pager, or mobile phone) and anescalation message.

8Define the escalation schedule.

Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number.

• To define the escalation wait period, enter the number of hours and minutes in the Start Escalation controls.

• To define the repeat schedule, enter the number of hours and minutes in the Repeat Escalation controls.

• To define the repeat number, enter a digit in the Repeat Number text box.

9Select an appropriate notification message for each notification method:

• To define an email notification action, select the Notify By Sending Email option and select appropriate internal and external 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.”.

Event reassignment actions

10 Optional: To enable support events to be automatically forwarded to a different workflow state or owner if no action is taken on that event, define event reassignment rules.

Event reassignment actions may be defined in the Escalation Action window. For step-by-step instructions see “Administering Event Escalation Reassignment Actions”.

Potential recipients

11Define 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

12Define 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

13Define 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.

Project administrators may use controls in the Email Escalations page to rename, event escalation rules.

16.3.6 Understanding Event Escalation Triggers

In CustomerWise, all event escalation triggers are “time triggers” which prompt the CustomerWise Mail Service to send notification messages to event stakeholders at key points in the event lifecycle—for example, its start and finish dates.

Anescalation triggeridentifies theunperformedtask that triggers an administrator-defined action (event notification or event re-assignment). Unlike event notification triggers which represents specific acts performed on an event, event escalation triggers represents acts thatare notperformed on an event.

CustomerWise supports four event escalation triggers:

On New Event

On Close Event

On Owner Change

On Status Change

In CustomerWise, every escalation rule is defined by a single trigger. The scope of the escalation rule may be limited by one or more escalation conditions which limit the number of support events that are subject to it.

16.3.7 Administering Event Escalation Actions

Event escalation actions define the time period that must pass before notifications are sent, the method used to notify subscribers (email, pager, or mobile phone), the message delivered by the notification, and the number of times that notification are sent before an escalated event is reassigned to another project team member.

An escalation action is defined by anescalation schedule, anotification methodand, optionally, anevent reassignment action:

Escalation schedules

An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications are sent, and the time between notifications.

Notification methods

A notification method defines the method by which subscribers are notified that an event has been escalated. CustomerWise supports three event escalation notification methods:

Email Notification:Email notification actions notify subscribers by email whenever an event notification rule is triggered.

Page Notification:Pager notification actions notify subscribers by pager whenever an event notification rule is triggered.

Mobile Phone Notification:Mobile phone notification actions notify subscribers by mobile phone whenever an event notification rule is triggered.

A different email message may be sent for every notification method.

Event reassignment actions

An event reassignment action defines rules for routing escalated support events to specific workflow states or project team members at the end of the event escalation schedule.

Event reassignment actions are an optional feature that must be enabled and defined in each event escalation rule.

16.3.8 Administering Event Escalation Schedules

An escalation schedule defines the time that must pass before notifications are delivered to escalation subscribers, the number of times that notifications may be sent, and the time between the delivery of each notification.

All escalation triggers are “time triggers”. CustomerWise executes an escalation action when the “state” defined by the escalation trigger remains unchanged for the escalation wait period.

Using controls in the Escalation Action window, project administrators may define an escalation wait period, an escalation schedule, and a repeat number for each event escalation rule.

Anescalation scheduleis defined by anescalation wait period, arepeat schedule, and arepeat number.

• The escalation wait period defines the time that must pass before the subscribers are notified of the event escalation. The escalation wait period is defined in hours and minutes.

• The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes.

• The repeat number defines the number of times that events may be escalated before the event is reassigned or the event expires.

After the final escalation action is performed, escalated events may be automatically reassigned to another project member, group, or group folder based on administrator-defined reassignment settings. For more information see “Administering Event Escalation Reassignment Actions”.

To define an escalation schedule:

1Define an event escalation rule, escalation trigger and trigger conditions in the Event Escalations page.

2Click the Add button in the Action tab.

Escalation actions may be defined whenever you create or edit an event escalation rule.

The Escalation Action window appears.

3Define the escalation wait period in the Start Escalation if Event Remain Open After text box.

The escalation wait period defines the time that must pass before the subscribers are notified of the event escalation. The escalation wait period is defined in hours and minutes.

4Define the escalation repeat schedule in the Repeat Escalation Every text box.

The escalation repeat schedule defines time between escalation actions. The escalation repeat period is defined in hours and minutes.

5Define the repeat number in the Repeat Number text box.

The repeat number defines the number of times that events may be escalated before the event is reassigned or the event expires.

16.3.9 Administering Event Escalation Reassignment Actions

An event reassignment action defines rules for routing escalated support events to specific workflow states or project team members at the end of the event escalation schedule.

If event reassignment is enabled, the escalated event is reassigned and its workflow state is changedonly afterevery scheduled escalation action is performed.

Using controls in the Escalation Action window, project members may enable event reassignment and routing rules, designate a project team member or group folder as the event owner, and define workflow state changes for each event escalation rule.

The target event owner of an event reassignment action may be identified by user account, group folder, or the {Submitter} potential recipient variable.

To enable event escalation reassignment:

1Define event escalation actions in the Actions tab of the Event Escalation page.

Event reassignment actions may be defined whenever you create or edit event escalation actions in the Actions tab of the Event Escalation page.

2Select the Do Event Re-assignment After the Actions Above check box.

Event reassignment actions must be specifically enabled for each event escalation rule.

3Select a project team member in the Re-assign To dropdown list.

The Re-assign To dropdown list displays all user accounts and group folders as well as the multiple potential recipient variables.:

{Submitter}

{Auto Assigned}

{Current Owner}

{Primary Support Engineer}

{Salesperson}

16.4 Administering Event Notification and Escalation Conditions

Event notification is an optional CustomerWise 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.

16.5 Administering Event Notification and Escalation Actions

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(customer) 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.

16.5.1 Identifying Notification Action Email Addresses

CustomerWise enables project administrators to define event notification rules that automatically notify many different subscribers of the status of CustomerWise events.

Event notification email may be sent to project members, customer contacts, and administrator-defined email address lists.

The email addresses of event notification subscribers are managed in different tools in CustomerWise applications.

• Project member email addresses, pager addresses, and mobile phone addresses are all managed in the User Manager. Project member addresses must be defined in the User Manager for project members to receive event notifications. All CustomerWise project members addresses are managed at the system level.

• Project administrators may create a unique list of email addresses for each notification rule. The email addresses on that list are notified automatically whenever the event notification rule is triggered.

16.5.2 Defining Event Email Notifications

Email notification actions send email notifications to project members and customers whenever an event notification rule is triggered.

Distinct notification messages may be sent to internal subscribers (project team members) and external subscribers (customers).

Using controls in the Escalation Action window, project administrators may define the email messages to be sent to rule subscribers whenever the event escalation rule is triggered.

Figure 16-2: Escalation Action Window (Detail)

Email notifications may also be sent to an administrator-defined list of email addresses and user-defined cc lists.

• The administrator may define a list of email addresses that receive all email notifications relevant to a specific event notification rule.

• Individual project members may define a cc list of email addresses for events that they subscribe to in the CustomerWise client. Project administrators must enable event specific cc lists for each event notification rule.

Email addresses are managed in different CustomerWise applications depending on the subscriber.

• Project member email addresses are managed in the User Manager in DevSuite Admin.

• Customer email addresses are managed in the Customer Manager of the CustomerWise Windows client.

To define an event escalation email notification:

1Define an event escalation rule, escalation trigger and trigger conditions.

2Click the Add button in the Action tab.

Escalation actions may be defined whenever you create or edit an event escalation rule. The Escalation Action window appears.

3Select an email message in the Email Format dropdown list.

4Select an email message in the Last Email Format dropdown list.

The Email Format and Last Email Format dropdown lists display all administrator-defined email messages.

• The option selected in the Email Format identifies the email message that is sent to rule subscribers when an event is first escalated and for every subsequent notification prior to the final notification.

• The option selected in the Last Email Format identifies the last email message that is sent to rule subscribers before the escalated event is reassigned.

To define email notification actions:

1Select an email notification rule in the Notification Rule list of the Event Notifications page.

2Select the Actions tab.

3Select the By Sending Email check box.

Project administrators must enable email notification.

4Select an option from the Email Format dropdown list.

Project administrators may select the email format used to send email notifications to (internal) project members.

The Email Format dropdown list displays all of the email formats defined in the Email Format manager. Project administrators may define new email formats by clicking the Setup button.

5Select an option from the Email Format for Customer dropdown list.

Project administrators may select the email format used to send email notifications to (external) customers.

The Email Format for Customer dropdown list displays all of the email formats defined in the Email Format manager. Project administrators may define new email formats by clicking the Setup button.

16.5.3 Defining Customer Email Notifications

Customers may be notified by email whenever an incident or event notificaiton rule (to which they are subscribed) is triggered. Customers cannot subscribe to incident escalation or event escalation rules.

All customer subscriptions are based on potential recipient variables. In CustomerWise, a potential recipient variable identifies potential subscribers basedon their relationship to an individual incident. If a project member or customer submitted or previously owned an incident that user may be designated as a potential recipient of notfication messages.

Distinct notification messages may be defined for internal (project member) and external (customer) incident and event notification subscribers.

To define a customer email notification action:

1Select an event notification rule in the Event Notification page.

Customers cannot subscribe to incident escalation or event escalation rules.

2Select the By Sending Email check box in the Actions tab.

3Select a notification message in the Email Format for Customer dropdown list.

The Email Format for Customer dropdown list displays all of the email formats defined in the Email Format manager. Project administrators may define new email formats by clicking the Setup button.

Every customer that is subscribed to the selected event notification rule is notified by email when the rule is triggered. Customers may be identified as subscribers based two potential recipient variables. For more information see “Customers as potential recipients”.

16.5.4 Defining Pager and Mobile Phone Notifications

Pager and mobile phone notifications are automatically sent to the subscribers pager or mobile phone address that is saved in the User Manager.

All pager and mobile phone numbers are defined at the site-level in the System Settings project.

To define a pager or mobile phone notification:

1Define an event escalation rule, escalation trigger and trigger conditions.

2Click the Add button in the Action tab.

Escalation actions may be defined whenever you create or edit an event escalation rule.

The Escalation Action window appears.

3Click the Pager & Mobile Phone Notification button.

The Pager & Mobile Phone Notification window appears.

4 Optional: To define an event escalation pager action, select the Enable Pager Notification check box and select an email message in the Pager dropdown list.

5 Optional: To define an event escalation mobile phone action, select the Enable Pager Notification check box and select an email message in the Mobile Phone dropdown list.

The option selected in the Email Format identifies the email message that is sent to rule subscribers when an event is first escalated and for every subsequent notification prior to the final notification.

16.6 Administering Potential Recipients and Subscriptions

In CustomerWise, an event notification trigger is anaction—such as the creation, edit, or deletion of an event—that prompts the CustomerWise Mail Service to deliver a notification message to a list of event stakeholders.

An event notification is sent every time that the triggering action is performed. If the action is not performed, the event notification rule is not triggered and the notification message is not sent.

CustomerWise supports bothsystem triggersandcustom triggers.

System triggers

CustomerWise system triggers prompt the CustomerWise Mail Service to send notification messages whenever an event management task is performed on events meeting the conditions of the event notification rule.

CustomerWise supports six system triggers:

New:The New Event trigger generates an event notification whenever a new support event is created in a project.

Close:The Closed Event trigger generates an event notification whenever a support event is closed in a project.

Status Change:Status change triggers generate event notifications based on changes to the workflow state of support events.

Owner Change:Owner change triggers generate event notifications based on changes in event ownership.

16.6.1 Identifying Potential Recipients of Notification Actions

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.

A project team member may be designated as a potential recipient based on his or her account type, team group, orrelationship with an event.In CustomerWise, these relationships are represented bypotential recipient variables.

Most potential recipients are identified by account type or team group membership.

16.6.2 Potential recipient variables

A potential recipient variable is a dynamic placeholder that represents an incident stakeholder—a project member or customer that has worked on an incident. For example, a user may be designated as potential recipients based on having submitted or previiously owned the support incident or event.

{Event Customer Contacts}{Event other contacts}

{Event Owner}{Event Parent Incident Customer Contacts}

{Event Submitter}{Incident Owner}

{Incident Submitter}{Linked Incident Owner}

{Linked Incident Submitter}{Parent Incident All Previous Owners}

{Parent Incident Last Previous Owner}{Primary Support Engineer}

{Salesperson}{User Defined Address}

The scope of most potential recipient variables may be further limited by account type.. Once defined, only project team members that belong to a specifc account type may be designated as potential recipients based on their relationship to the incident or event. For more information see “Defining the Scope of Potential Recipient Variables” .

16.6.3 Defining the Scope of Potential Recipient Variables

In CustomerWise, a potential recipient variable represents a project team member that may be designated as apotential recipientof an event notification or event escalation action based on their relationship with a support event or its parent incident.

Using one or more potential recipient variables, a project administrator may ensure that every event or incident stakeholder is kept up-to-date with their incidents and events.

The scope of potential recipient variables may be limited by account type or project:

• The scope of most potential recipient variables may be limited byaccount type. Only those project members that belong to the selected account types are defined as potential recipients of notification actions.

• The scope of the {Linked Event Submitter} and {Linked Event Owner} potential recipient variables may be defined by project. Only those project members that submitted or currently own a linked event in the selected projects are defined as potential recipients of notification actions.

To define the scope of a potential recipient variable by account type:

1Select an event notification rule.

2Double-click a user variable in the Potential Recipient tab.

The Email Notification/Escalation window appears.

3Select one or more account types in the Account Types list.

The Account Types list displays the name of every administrator-defined account type.

4Click the OK button.

To define the scope of a user variable by project:

1Select an event notification rule.

2Double-click a user variable in the Potential Recipient tab.

The Email Notification/Escalation window appears.

3Select one or more account types in the Account Types list.

The Account Types list displays the name of every project in the DevSuite site.

In an integrated DevSuite site CustomerWise support events may be linked to support events in other projects and to DevSpec requirements or specifications.

4Click the OK button.

16.6.4 Defining User-Defined Email Address List

The {User Defined Address} user variable represents an administrator-defined list of email addresses that may designated as potential recipients of email notification actions.

Email notifications are sent to every address on that list when the event notification rule is triggered.

Project administrators may add any number of email addresses to the User Define Email Addresses list. Each email address must be separated by a semicolon (;).

To define a list of email addresses:

1Select an event notification rule in the Notification Rules list of the Event Notifications page.

2Select the Potential Recipients tab.

3Double-click the {User Defined Address} option in the Potential Recipients list.

The User Defined Email Addresses dialog box appears.

4Enter email addresses separated by semi-colons in the field.

5Click the OK button.

16.6.5 Defining Potential Recipient Subscription Rules

The {User Defined Address} user variable represents an administrator-defined list of email addresses that may designated as potential recipients of email notification actions.

Email notifications are sent to every address on that list when the event notification rule is triggered.

Project administrators may add any number of email addresses to the User Define Email Addresses list. Each email address must be separated by a semicolon (;).

To define a list of email addresses:

1Select an event notification rule in the Notification Rules list of the Event Notifications page.

2Select the Potential Recipients tab.

3Double-click the {User Defined Address} option in the Potential Recipients list.

The User Defined Email Addresses dialog box appears.

4Enter email addresses separated by semi-colons in the field.

5Click the OK button.

 Chapter 17 Customer Administration

17.1 Understanding Customer Management

TechExcel CustomerWise enables businesses to define business processes that enable them to implement and manage their CustomerWise strategy.

All administrator-defined business entities are manifested in the Customer view of the CustomerWise client applications. TechExcel CustomerWise enables project administrators to define businesses entities, processes, and workflow rules that enable CustomerWise work project members to manage their customers effectively.

TechExcel enables businesses to manage customers through every step of the customer life cycle.

• TechExcel CustomerWise automates all customer-related business processes (marketing, sales, and customer support) and enables project members to view the complete history of customer interactions regardless of touch points.

• TechExcel CustomerWise business and workflow rules ensure that customers are effectively managed in each business area and seamlessly transition between touch points ensuring that customers do not fall through cracks.

• TechExcel CustomerWise provides businesses with tools for analyzing customer needs and behavior.

• TechExcel CustomerWise enables project members to effectively communicate and collaborate with customers by phone, e-mail, and the Customer Web Portal.

All CustomerWise work projects (marketing, sales, and support) share a commoncustomer base project. A customer base project enables project teams to share a common database of customers and customer contacts. All customer and customer contact data is stored in a customer base projects and tracked in the child marketing projects, sales projects, and support projects through the Customer view. For more information on customer base projects see “Creating CRM Base Projects”.

17.1.1 Understanding Customer Management Administration

TechExcel CustomerWise project administrators are responsible for defining the business entities and workflow rules that enable marketing, sales, and support project members to identify, track, communicate, and collaborate with customers and customer contacts.

Customer management administrative tasks fall into four broad categories:

• Customer view administration

• Customer support automation administration

• Customer Web Portal administration

• Web form administration

17.1.2 Customer view administration

All customer relationship management tasks are performed by project members in the Customer view of the CustomerWise client applications.

The Customer view enables project members to manage and track customers using administrator-defined business entities. Business entities such as customer types and customer statuses, access types and access privileges, and business types define the business rules that are used to manage customers and customer contacts within the Customer view.

Customer view administrative tasks are performed using tools in the Customer View folder of the CustomerWise Admin client. Customer view administrative tasks include:

• Enabling project members to define customers and customer contacts.

• Defining access types and access type privileges that enable customer contacts to work in the Customer Web Portal.

• Defining business types.

• Defining customer types and customer statuses.

• Customizing the Customer view to support customer management processes.

17.1.3 Customer support automation administration

TechExcel CustomerWise customer automation rules ensure that customers are effectively managed in each business area and seamlessly transition between touch points.

Administrator-defined customer status automation rules synchronize customer statuses across marketing, sales, and support projects. These rules may be based on product purchases or web activity.

For more information see “Customer Status Automation”.

17.1.4 Understanding Customer Entities and Business Rules

Project administrators may define business rules for managing customers and customer contacts in CustomerWise projects. All customer management rules are on system-defined or administrator-defined business objects.

TechExcel CustomerWise customer business objects include:

• Business types

• Customer types

• Customer statuses

• Life cycle statuses

TechExcel CustomerWise contact business objects include:

• Contact types

• Access types

The business objects assigned to customers determine how that customer is managed in CustomerWise projects. At any given time during the customer life cycle a customer account is assigned one and only one customer type, access types, business type, and customer status.

17.2 Understanding Customer View Administration

TechExcel CustomerWise project administrators are responsible for defining the business entities and workflow rules that enable marketing, sales, and support project members to identify, track, communicate, and collaborate with customers and customer contacts.

Customer management administrative tasks fall into four broad categories:

• Customer view administration

• Customer support automation administration

• Customer Web Portal administration

• Web form administration

17.3 Defining General Customer Settings

All customer relationship management tasks are performed by project members in the Customer view of the CustomerWise client applications.

The Customer view enables project members to manage and track customers using administrator-defined business entities. Business entities such as customer types and customer statuses, access types and access privileges, and business types define the business rules that are used to manage customers and customer contacts within the Customer view.

Customer view administrative tasks are performed using tools in the Customer View folder of the CustomerWise Admin client. Customer view administrative tasks include:

• Enabling project members to define customers and customer contacts.

• Defining access types and access type privileges that enable customer contacts to work in the Customer Web Portal.

• Defining business types.

• Defining customer types and customer statuses.

• Customizing the Customer view to support customer management processes.

17.3.1 Defining Customer Terminology

Project administrators may define the terms that are used to refer to customers in their projects using controls in the General Setting page.

Businesses may wish to refer to a customer as anassociate, orpartner, or by another name that is better suited to their business or more intuitive for their project members.

Organizations that use a word other thancustomermay define the new term in the Refer Customer As field. Once the new term is defined the wordcustomeris replaced by that term globally throughout the application.

To define a custom term for project customers, enter the term in the Refer Customer As field of the General Settings page.

17.3.2 Defining Customer Dropdown List Size Limits

Project administrators may limit the number of customers that are displayed in the Customer dropdown lists in the Incident, Event, and Report views using controls in the General Setting page.

Limiting the number of customers displayed in the Customer dropdown list may enhance the performance of the CustomerWise client applications. Businesses may maintain a customer base that includes thousands of customers, and loading all of their customers into the dropdown list in each view can deteriorate application performance.

To limit the number of customers loaded into the Customer dropdown list, enter a number in the Size Limit of the Customer Dropdown List text field in the General Setting page.

17.3.3 Enabling Customer Status Tracking for Each Product Line

In TechExcel CustomerWise all customers are tracked and managed based on their customer status. The customer status assigned to a customer indicates the current state of the customer within the customer life cycle.

Generally, a customer is assigned one-and-only-one customer status at any one time in the customer life cycle. The customer status tracking by product line feature enables project members to assign a differentcustomer statusto customers for eachproduct lineassociated with that customer.

• Customer statuses are administrator-defined customer entities that determine how customers are tracked and managed in CustomerWise projects. For a detailed discussion of customer status rules see See “Managing Customer Statuses”.

• Product lines are administrator-defined groups of assets that are tracked together in a project. Different business rules may be applied to assets based on their product line. For more information see “Managing Product Lines”.

Applicable projects and customer status automation rules (workflow rules) are based on the customer’s customer status. Businesses may wish to apply automation rules and access privileges to customers based for product line associated with that customer.

To enable support for tracking customers for each product line, select the Support Tracking Customer Status for Each Product Line check box.

In the CustomerWise Web client an additional Customer Status dropdown list control is displayed for each product line.

Figure 17-3: Customer Status for Product Line Controls in CustomerWise Web Client

17.3.4 Enabling Support for Login Aliases

Login aliases enable customer contacts to log into the Customer Web Portal using an alias that has been specifically created for them by a CustomerWise project member.

Customers may log into the Customer Web Portal using either an e-mail address or a login alias. If the Support Login Alias check box is not selected, customer contacts may only log into the Customer Web Portal using their e-mail address.

To enable support for login aliases, select the Support Login Alias check box in the General Setting page of the Customer View folder in the CustomerWise Admin client.

Project members may define individual login aliases for each customer contact in the Contact Info page of the CustomerWise clients. Project administrators may customize the Contact Info page GUI in the CustomerWise client application. For more information see See “Understanding Login Alias and Password Controls”.

17.3.5 Enabling Customer Contacts to Share E-mail Addresses

Project administrators may enable multiple customer contacts to share the same e-mail addresses using controls in the General Setting page.

To enable multiple customer contacts to share the same e-mail address, select the Multiple Users Can Share E-mail Address check box.

If two customer contacts share the same e-mail address, theymustbe assigned separate login aliases. Support for shared e-mail addresses is only available if the login alias feature is enabled.

17.3.6 Enabling and Defining Hot Prospects

Hot prospects are prospects (customer accounts) that sales project members have identified to be likely customers. The hot prospects designation enables businesses to identify and focus their efforts on the customer accounts that are most likely to become active customers.

Sales project members may display their hot prospects in the Home page in the Home page in the CustomerWise Web client. Each salesperson may define which customers qualify as hot prospects based on sales probability, sales amount, and other factors.

Project administrators may enable the TechExcel hot prospects feature and define hot prospect settings in the General Setting page of a marketing project or sales project.

Administrators may define two restrictions on hot prospect definition.

• If the Based on Active Customer Specific Web Announcement option is selected, a prospect is considered as a hot prospect if the sales team has sent a specific Web announcement to the prospect.

• If the Customer Specific Web Announcement Not Required is selected, no Web announcement is required to turn a prospect into a hot prospect.

Project administrators may enable and define hot prospect in marketing projects and sales projects only. The Hot Prospects controls are not displayed in base projects or support projects.

To enable and define the hot prospect feature:

1Select the Enable Hot Prospects Feature check box in the General Setting page.

2Select an option from the How to Define dropdown list.

The dropdown list displays two options:

• Customer Specific Web Announcement Not Required

• Based on Active Customer Specific Web Announcement

17.3.7 Enabling Business Types

Business typesare an optional feature that enable businesses to represent and manage eight different types of customers in their CustomerWise projects.

• direct customers

• resellers

• reseller’s customers

• partners, vendors

• parent customers

• child customers

• competitors.

The business rules used to manage a customer in a CustomerWise project are based on that customer’scustomer status. Every customer status is associated with one-and-only onelife cycle status. The life cycle status represents the particular state in the customer life cycle and determines how that customer is managed in CustomerWise projects. Customers inherit their life cycle status from their customer status.

Note:For more information on customer statuses see See “Managing Customer Statuses”.

The business type that a project member assigns to a customer restricts the customer statuses that may be assigned to a customer and, thus determines the business rules used to manage that customer in the project.

Business types are an optional feature in TechExcel CustomerWise and must be enabled by a project administrator in the General Setting pagebeforethey may be assigned to customers in the CustomerWise client applications.

Project administrators may enable seven different business types:

• TheReseller business typemay be used to represent resellers. Administrators may also enable customer-specific customer states to be assigned to resellers. For more information see See “Enabling Reseller-specific Customer States”.

• ThePartner business typemay be used to represent partners.

• TheInternal Company business typemay be used to represent internal companies. Project members may define a new customer as an internal company.

• TheParent Customer and Child Customer business typesenable a business to represent the subsites that belong to major customers. If the administrator enables support for Parent-Child business types, project members may define new customers as eitherparent business typesor child business types. Alternatively, project members may use the parent andchild business typesto distinguish between separate divisions within a single company office.

• TheCompetitor business typerepresents a business competitor. Administrators may enable project members to create and track business competitors.

• TheVendor business typerepresents a vendor. Administrators may enable project members to create and track vendors.

Note:Project administrators may rename each business type using controls in the Business Type Names area of the General Setting page. For more information see See “Defining Business Type Names”.

17.3.8 Enabling Reseller-specific Customer States

TechExcel CustomerWise business rules define how customers are managed in CustomerWise projects. Project administrators may define a unique set of business rules and customer statuses that are specifically designed to manage customers assigned the reseller business type.

To enable reseller-specific customer states, select the Support Reseller Specific Customer Status in the General Setting page of the Customer View folder.

Once this option is enabled, administrators may define customer statuses that are only applicable to customers assigned the reseller business type. For more information see See “Managing Customer Statuses”.

17.3.9 Defining Business Type Names

Business types represent the different kinds of customers that a company may track in their CustomerWise projects. CustomerWise may be used to track eight business types: direct customers, resellers, reseller’s customers, partners, vendors, parent customers, child customers, and competitors.

Businesses may wish to refer to business types using terms that are more suitable to their business processes or intuitive to their project members.

To define custom business type terms:

Project administrators may customize the terms that are used in CustomerWise project to refer to business types using controls in the General Setting page of the Customer View folder.

Enter the term in the text field control next to the appropriate business type. Once the new term is defined the name of the business type is replaced by that term globally throughout the application.

Six business types must be enabled by the project administrator before they may be used in a CustomerWise project. For more information see See “Enabling Business Types”.

17.4 Managing Customer First Contact Tracking Rules

TechExcel CustomerWise customer automation rules ensure that customers are effectively managed in each business area and seamlessly transition between touch points.

Administrator-defined customer status automation rules synchronize customer statuses across marketing, sales, and support projects. These rules may be based on product purchases or web activity.

For more information see “Customer Status Automation”.

17.4.1 Defining Marketing First Contact Rules

Project administrators may use controls in the Customer First Contact Dates page to define how new customers are identified and tracked in CustomerWise marketing projects.

Figure 17-4: Customer First Contact Dates Page Detail

Marketing first contact rules define which event updates constitute first contact for marketing projects. Administrators may define the applicable project, applicable event or events, and the applicable project members for marketing first contact rules.

To define marketing first contact rules:

1To enable this initial contact-tracking feature, navigate to the Customer First Contact Dates page in the Advanced Project Settings folder.

2Select an applicable project in the Based on Event Update in Project dropdown list.

The Based on Event Update in Project dropdown list displays all of the projects in the current CustomerWise implementation. Only updates to events in the selected project may represent the marketing first contact.

3To define one or more applicable event updates, click the Setup button and define the applicable event templates, and event states in the First Update Contact Option dialog box.

• Define all event templates as applicable or select event templates individually.

• Select applicable event states for each applicable event template.

4Select an option from the Team Member Update Option dropdown list. Administrators may choose between four options:

• The When Updated by any Team Member option

• The When Update by Sales Person option

• The When Updated by Primary Support Engineer option

• The When Updated by Inside Sales Rep option

By default, only the When Updated by any Project Member option is displayed in the Team Member Update Option dropdown list. To select any other option the administrator must enable these options to be displayed. For step-by-step instructions see See “Enabling Applicable First Contact Project Members”.

17.4.2 Defining Sales First Contact Rules

Project administrators may use controls in the Customer First Contact Dates page to define how new customers are identified and tracked in CustomerWise sales projects.

Figure 17-5: Customer First Contact Dates Page Detail

Sales first contact rules define which event updates constitute first contact for sales projects. Administrators may define the applicable project, applicable event or events, and the applicable project members for sales first contact rules.

To define sales first contact rules:

1To enable this initial contact-tracking feature, navigate to the Customer First Contact Dates page in the Advanced Project Settings folder.

2Select an applicable project in the Based on Event Update in Project dropdown list.

The Based on Event Update in Project dropdown list displays all of the projects in the current CustomerWise implementation. Only updates to events in the selected project may represent the marketing first contact.

3To define one or more applicable event updates, click the Setup button and define the applicable event templates, and event states in the First Update Contact Option dialog box.

• Define all event templates as applicable or select event templates individually.

• Select applicable event states for each applicable event template.

4Select an option from the Team Member Update Option dropdown list.

Administrators may choose between four options:

• The When Updated by any Team Member option

• The When Update by Sales Person option

• The When Updated by Primary Support Engineer option

• The When Updated by Inside Sales Rep option

By default, only the When Updated by any Project Member option is displayed in the Team Member Update Option dropdown list. To select any other option the administrator must enable these options to be displayed. For step-by-step instructions see See “Enabling Applicable First Contact Project Members”.

17.4.3 Defining Support First Contact Rules

Project administrators may use controls in the Customer First Contact Dates page to define how new customers are identified and tracked in CustomerWise support projects.

Figure 17-6: Customer First Contact Dates Page Detail

Support first contact rules define which event updates constitute first contact for customer support projects. Administrators may define the applicable project, applicable event or events, and the applicable project members for support first contact rules.

To define support first contact rules:

1To enable this initial contact-tracking feature, navigate to the Customer First Contact Dates page in the Advanced Project Settings folder.

2Select an applicable project in the Based on Event Update in Project dropdown list.

The Based on Event Update in Project dropdown list displays all of the projects in the current CustomerWise implementation. Only updates to events in the selected project may represent the marketing first contact.

3To define one or more applicable event updates, click the Setup button and define the applicable event templates, and event states in the First Update Contact Option dialog box.

• Define all event templates as applicable or select event templates individually.

• Select applicable event states for each applicable event template.

4Select an option from the Team Member Update Option dropdown list.

Administrators may choose between four options:

• The When Updated by any Team Member option

• The When Update by Sales Person option

• The When Updated by Primary Support Engineer option

• The When Updated by Inside Sales Rep option

By default, only the When Updated by any Project Member option is displayed in the Team Member Update Option dropdown list. To select any other option the administrator must enable these options to be displayed. For step-by-step instructions see See “Enabling Applicable First Contact Project Members”.

17.4.4 Enabling Applicable First Contact Project Members

Project administrators may use controls in the Customer First Contact Dates page to define how new customers are identified and tracked in CustomerWise marketing, sales, and support projects.

Administrators may define the applicable projects, event updates, and project members that may be used to identify first contact in each project type. By default, the Team Member Update Option dropdown list in the Customer First Contact Dates page displays a single option, the When Updated by any Project Member option.

Project administrators may enable three applicable project member options in the Support Team page of the Customer View folder and the General Settings page of the Sales Support Team Assignment folder in the CustomerWise Admin client.

• Define the Primary Support Engineer, Sales Person, and Inside Sales Rep dropdown lists as visible in the Support Team page of the Customer View folder. For more information see See “Customizing the Team Page”.

• Define the Primary Support Engineer, Sales Person, and Inside Sales Rep dropdown lists as visible in the Support Team page of the Customer View folder. For more information see See “Customizing the Contact Info Page”.

17.5 Customizing the Address Page

Project administrators may define business rules for managing customers and customer contacts in CustomerWise projects. All customer management rules are on system-defined or administrator-defined business objects.

TechExcel CustomerWise customer business objects include:

• Business types

• Customer types

• Customer statuses

• Life cycle statuses

TechExcel CustomerWise contact business objects include:

• Contact types

• Access types

The business objects assigned to customers determine how that customer is managed in CustomerWise projects. At any given time during the customer life cycle a customer account is assigned one and only one customer type, access types, business type, and customer status.

17.5.1 Customizing Address Page Controls

Project administrators may define what customer data is recorded and tracked in CustomerWise projects by customizing the data-entry controls displayed in the Address page.

• The Address page displays twenty system controls by default.

• The Address page displays no custom controls. Custom controls may not be added to the Address page.

The customizations that an administrator may make to each control depend on its control type and the business logic of the system control. The system controls displayed in the Address page fall into two categories: standard system controls and special system controls.

17.5.2 Standard Controls

The majority of the controls displayed in the Address page are standard system controls that may be customized to track different types of data.

17.5.3 Special Controls

Eight of the controls displayed in the Address page are designed to perform specific functions in CustomerWise projects and perform specific functions. Configuring these controls defines the business logic of the customer management processes:

• Customer ID

• Customer Type

• Customer Status

• Source_1

• Source_2

The data tracked in these controls are linked to other controls and drive CustomerWise business processes.

Address page control customizations

The table refers to Address page controls by the default control title. All controls may be renamed by the project administrator.

• A blank field indicates that the option is not applicable to the control.

• An X indicates that the option may be enabled for the control.

• A grey field indicates that the option is enabled for the control andcannotbe disabled.

Administrators may customize the name of every data-entry control displayed in the Address page.

Table 17-2: Address Page Customizations

Administrators may make the following customizations to data-entry controls displayed in the Address page:

•Visible: Administrators may define many data-entry controls as either visible or invisible in the Address page. The Company Name, Address, Customer ID, City,Zip, and Main Phone controls are always visible. Administratorsmay notdefine these controls as invisible in the Address page. All other controls may be defined as visible or invisible.

•Available in Customer Web Portal: Administrators may choose whether controls are displayed or not displayed in the Customer Web Portal. The Company Name control is always displayed in the Customer Web Portal. All other controls may or may not be displayed. For more information see “Understanding the Customer Web Portal”.

•Control Types: Administrators may customize the control type of eight different controls displayed in the Address page: the City, State, Phone_2, Source_1, Source_2, Cell Phone, Campaign, and Promotion controls. Four control types are available: the Dropdown List control, Edit control, Check Box control, and the Combo Box control.

•Parent-Child Relationships: Administrators may define parent-child relationships between the following controls displayed in the Address page: the Customer Type, Source_1, Source_2, Cell Phone, Campaign, and Promotion controls.

•Mandatory for Team: Administrators may define Address controls as mandatory fields for project members. The Name field is mandatory for both customers and project members.

•Mandatory for Customer: Administrators may define Address controls as mandatory fields for customers. The Name field is mandatory for both customers and project members.

•Mandatory on Submission: Administrators may define Address controls as mandatory fields whenever an incident is submitted. Project administrators may define the Customer ID and Customer Status controls as mandatory on submission.

17.5.4 Customizing the Customer ID Control

The Customer ID is a unique number that identifies each customer throughout a CustomerWise implementation. Customer IDs are tracked in the Customer ID control in the Address page of the Customer view.

Project administrators may customize the Customer ID control and define how customer IDs are generated in CustomerWise sites using controls in the Address page of the Customer view folder.

Administrators may enable two separate options to define customer IDs.

• The External Customer ID from 3rd Party Application option defines the Customer ID control as read-only in the CustomerWise clients and customer IDs are automatically generated using a third-party application. Third-party integration is managed through TechExcel CustomerWise LinkPlus.

•

• The Use This Field as External Customer ID option ensures that the values entered in the Customer ID control are unique. If the Use This Field as External Customer ID check box is not selected, multiple customers may share the same Customer ID number.

Project administrators may make six other customizations to the Customer Type dropdown list control:

• Rename the Customer Type control

• Define the control as visible or invisible

• Display the control in the Customer Web Portal

• Define the control as mandatory for on submission

17.5.5 Defining Customer Types

Customer types represent the different classes of customers that are managed in a project based on product lines, sales territories, or any other administrator-defined criteria.

Project members may assign a customer type to customer accounts by selecting an option from the Customer Type dropdown list displayed in the Address page of the CustomerWise client applications.

All customer types are defined by project administrators in the Customer Type manager. The customer types defined in the Customer Type manager are displayed as selectable options in the CustomerWise client applications.

To create customer types:

1Double-click the Customer Type control in the Address page of the Customer View folder in the CustomerWise Admin client.

The Customer Type manager appears.

2Click the New button in the Dropdown List Contents area.

The Add Item dialog box appears.

3Enter an item in the Name field and click the OK button.

The control type is added to the Dropdown List Contents list.

Customer types and business rules

Customer types may also be used to determine how customers are managed in CustomerWise projects.

Administrators may define auto-team assignment rules that assign customers to project members based on their customer type. For more information see “Defining Team Assignment Rules”

Project administrators may make six other customizations to the Customer Type dropdown list control:

• Rename the Customer Type control

• Define the control as visible or invisible

• Display the control in the Customer Web Portal

• Define the control as mandatory for project members

• Define the control as mandatory for customers

• Define parent-child relationship between the Customer Type dropdown list control and another control.

17.5.6 Defining Customer Statuses

Customer states represent different classes of customers managed in a project based their business type, customer life cycle status, and the projects to which they may be applied.

Customer states define the functionality available for each customer or used to trigger different actions in project workflow.

Administrators may customize the Customer Status control and define the customer states displayed as options in the Customer Status control in the Address page of the Customer view folder. For more information see See “Managing Customer Statuses”.

Every customer status consists of five properties:

• The Customer status name

• The Applicable business type

• The Customer life cycle status

• Applicable product lines

• One or more applicable projects

Project administrators may make six other customizations to the Customer Type dropdown list control:

• Rename the Customer Type control

• Define the control as visible or invisible

• Display the control in the Customer Web Portal

• Define the control as mandatory on submission

17.5.7 Customizing the Source_1 and Source_2 Controls

Administrators may customize the Source_1 and Source_2 controls and define the options displayed in these controls in the Address page of the Customer view folder.

• The Source_1 control is intended to identify the master marketing source of the customer. For example trade shows, or magazine advertisement.

• The Source_2 control is intended to be a child of the Source_1 field, and should identify the detailed marketing source of the customer. For example which trade show the company was originally located, or the specific magazine.

The Source_1 and Source_2 controls are two of the most customizable of the data-entry controls displayed in the Address page. Although no special business logic is built into either control, project administrators may configure these controls to support and manage complex business processes.

Project administrators may make six other customizations to the Customer Type dropdown list control:

• Rename the control

• Define the control type of the control: Dropdown list control, Edit control, Check Box control, or Combo Box control.

• Define the control as visible or invisible

• Display the control in the Customer Web Portal

• Define the control as mandatory for project members

• Define the control as mandatory for customers

• Define parent-child relationship between the Customer Type dropdown list control and another control.

• Define the options displayed in the control (if the control type is either Dropdown List or Combo Box).

17.6 Customizing the Contact Page

CustomerWise marketing, sales, and support projects belonging to the same base project share a common Customer view. Updates made to customer accounts in one work project are immediately apparent in all other work projects.

Project members may create, manage, and track customers and customer contacts in the customer view of the CustomerWise client applications.

Figure 17-1: Customer View in the CustomerWise Windows Client

The Customer view consists of two windows: the Customer List window and the Customer Detail window.

• The Customer List window displays high-level information about multiple customers in a tabular format.

• The Customer Detail window displays detailed information about a single customer in tabbed pages.

Administrators may use controls in the Customer View folder in the Admin Tree window of base and work projects to define customer management options, define project member access privileges, and customize the graphical user interface of the Customer view to support and manage the customer data.

The Customer View folder in CustomerWise displays 14 different system pages. Each system page displays multiple data-entry controls that enable the administrator to define project customer management processes.

• TheGeneral Settings pageenables project administrators to enable various customer management features and to define the terms that are used to refer to customer entities.

• TheCustomer First Contact Dates pageenables project administrators to define how new customers are managed in marketing projects, sales projects, and support projects.

• TheAddress pageenables project administrators to customize the data entry controls displayed in the Address page of the CustomerWise clients. The controls displayed in the Address page enable project members to track information about companies.

• TheContact pageenables project administrators to customize the data entry controls displayed in the Contact page of the CustomerWise clients. Project administrators may determine what information is tracked in the Contact page.

• TheContact Infopage enables project administrators to customize the data entry controls displayed in the Contact Info page of the CustomerWise clients.Project administrators may determine what information is tracked in the Contact Info page.

• TheCustomer Status pageenables project administrators to customize the data entry controls displayed in the Customer Status page of the CustomerWise clients. Project administrators may determine what information is tracked in the Customer Status page.

• ThePrivilege Control pageenables project administrators to create access types, define work project and base project privileges for each access type, and define the applicable projects for each access type.

• TheTeam pageenables project administrators to customize the data entry controls displayed in the Team page of the CustomerWise clients. The Team page may be managed in marketing work projects only. The Team page is not displayed in the Admin Tree window of base projects or sales and support projects.

• TheIncidents and Events pageenables project administrators to enable the Incidents and Events page, enable data access support to other work projects, and define the applicable work projects. Project members use the Incidents and Events page to track all activities in the applicable projects.

• TheCustom Page 1 pageenables project administrators to customize the data entry controls displayed in the Custom 1 page of the CustomerWise clients.

• TheCustom Page 2 pageenables project administrators to customize the data entry controls displayed in the Custom 2 page of the CustomerWise clients.

• TheCommon E-mail Addresses pageenables project administrators to define the domain of common e-mail addresses and define default settings for e-mail from that domain.

• TheAccess Control pageenables project administrators to determine which project member may edit pages and controls when they create or edit customers. Access privileges may be defined at the page level or control level for each account type and access type.

• TheQuick Web Links pageenables project administrators to create and add Quick Web Links.

17.7 Customizing the Contact Info Page

TechExcel CustomerWise enables businesses to customize their CustomerWise implementation to support and automate their business processes rather than changing business processes to suit the application.

One key is for businesses to use terms that are appropriate to their industry and familiar to their employees.

Many businesses may wish to use business terms that are specific to their industry or company and familiar to theIr employees. TechExcel CustomerWise enables project administrators to customize the terms that are used to refer to business entities and processes within the customer base.

Project administrators may enable and name business entities and business processes in the General Settings page in the Customer View folder of the CustomerWise Admin Tree window.

Figure 17-2: General Setting Page

Project configurations defined in the General Setting page are applied to the Customer view in every project within a CustomerWise site. General Customer view settings may be defined in the base project or any child work project regardless of the project type.

The General Setting page enables administrators to enable business processes and business entities and to define the names that are used for those processes and entities in that project.

The General Setting page also enables project administrators to enable and define key customer management features including:

• User login controls

• Hot prospects

• Business types

• Reseller-specific customer states

17.7.1 Customizing Contact Info Page Controls

The table refers to Contact Info controls by the default control title.

The table refers to Address page controls by the default control title. All controls may be renamed by the project administrator.

• A blank field indicates that the option is not applicable to the control.

• AnXindicates that the option may be enabled for the control.

• A grey field indicates that the option is enabled for the control andcannotbe disabled.

All controls may be renamed by the project administrator.

Table 17-3: Address Page Customizations

Administrators may make the following customizations to data-entry controls displayed in the Address page:

•Field Name: Administrators may customize the name of every data-entry control displayed in the Address page.

•Visible: Administrators may define many data-entry controls as either visible or invisible in the Address page. The Company Name, Address, Customer ID, City, Zip, and Main Phone controls are always visible. Administratorsmay notdefine these controls as invisible in the Address page. All other controls may be defined as visible or invisible.

•Available in Customer Web Portal: Administrators may choose whether controls are displayed or not displayed in the Customer Web Portal. The Company Name control is always displayed in the Customer Web Portal. All other controls may or may not be displayed.

•Mandatory for Team: Administrators may define Address controls as mandatory fields for project members.

•Mandatory for Customer: Administrators may define Address controls as mandatory fields for customers.

•Mandatory on Submission: Administrators may define Address controls as mandatory fields whenever an incident is submitted.

17.7.2 Customizing the Access Type Control

Project members may use the Access Type control in the Contact Info page of the Customer view to assign an administrator-defined access type to every customer contact.

Access types determine the projects that are accessible to contacts and the privileges that are granted to them in the Customer Web Portal. Administrators may define access types based on the contact’s role or title.

Administrators may define access types and access type privileges in the Access Type control manager or in the Privilege Control page of the Customer View folder.

Administrator-defined access privileges are granted to access types and not to customer contact accounts. Contact accounts inherit the privileges that are assigned to their access type. For more information see See “Defining Access Type Privileges”.

17.7.3 Customizing the Contact Type Control

Project members may use the Contact Type control in the Contact Info page to assign one or more contact types to a customer contact.

The Contact Type control is an optional multiple selection control that displays multiple, administrator-defined contact types.

Contact types represent the roles that a contact has with a customer. Each contact may be assigned multiple contact types.

17.7.4 Understanding Login Alias and Password Controls

Project members may define individual login aliases for each customer contact in the Contact Info page of the CustomerWise clients.

Login aliases enable customer contacts to log into the Customer Web Portal using a login alias that has been specifically created for them by a CustomerWise project member.

Customers may log into the Customer Web Portal using either an e-mail address or a login alias. If the Support Login Alias check box in the General Setting page is not selected, customer contacts may only log into the Customer Web Portal using their e-mail address. For more information see See “Enabling Support for Login Aliases” on.

17.8 Customizing the Team Page

Project administrators may define the terms that are used to refer to customers in their projects using controls in the General Setting page.

Businesses may wish to refer to a customer as anassociate, orpartner, or by another name that is better suited to their business or more intuitive for their project members.

Organizations that use a word other thancustomermay define the new term in the Refer Customer As field. Once the new term is defined the wordcustomeris replaced by that term globally throughout the application.

To define a custom term for project customers, enter the term in the Refer Customer As field of the General Settings page.

17.9 Customizing the Incidents and Events Page

Project administrators may limit the number of customers that are displayed in the Customer dropdown lists in the Incident, Event, and Report views using controls in the General Setting page.

Limiting the number of customers displayed in the Customer dropdown list may enhance the performance of the CustomerWise client applications. Businesses may maintain a customer base that includes thousands of customers, and loading all of their customers into the dropdown list in each view can deteriorate application performance.

To limit the number of customers loaded into the Customer dropdown list, enter a number in the Size Limit of the Customer Dropdown List text field in the General Setting page.

 Chapter 18 Customer Status Automation

18.1 Understanding Customer Status Automation

In every TechExcel CustomerWise work project customers are identified by acustomer status. Administrators may define customer life cycle automation rules based on customer statuses.

Customer status automation enables administrators to define automation rules to synchronize the customer status between marketing, sales, and support projects.

The customer status of a customer may be automatically changed based on one of two criteria:

•Web points earned: If a customer earns enough web points in a marketing project, they may be automatically copied to the sales project as a new lead and to the support project for pre-sale support.

•Products purchased:

Project administrators may also define customer status automation rules that enable customers to be copied to anotherbase projectbased on web points accrued or products purchased.

All customer statuses in TechExcel CustomerWise projects are administrator-defined. Project administrators may create new customer statuses in the Customer Status Info manager or in the Customer Status page within the Customer View in the CustomerWise Admin client. For more information see “Managing Customer Statuses” .

18.2 Enabling Customer Status Automation and Automation Features

Customer status automation is an optional feature in TechExcel CustomerWise. To enable and configure customer status automation, an administrator must perform two steps:

• Enable customer status automation in the Optional Features page of the General Project Settings folder.

• Enable support for customer status automation in the Properties page of the Customer Status Automaton folder.

Project administrators may also enable customer statuses to be automatically updated across CustomerWise implementations using controls in the Properties page of the Customer Status Automation folder.

18.2.1 Enabling Customer Status Automation

Customer status automation must be enabled by a project administrator in the Optional Features page of the General Project Settings folder.

The Customer Status Automation folder is not displayed in the Admin Tree window if customer status automation is not enabled. For more information see “Managing Optional Project Features”.

18.2.2 Enabling Customer Status Automation Support in a Project

Customer status automation must be enabled by a project administrator in the Properties page of the Customer Status Automation folder in the CustomerWise Admin client.

To enable customer status automation support in a project, select the Support Customer Status Automation check box in the Properties page.

The Customer Status Automation folder is not displayed in the Admin Tree window if customer status automation is not first been enabled in the Optional Features page of the General Project Settings folder.

18.2.3 Enabling Transfers Across Base Projects

Project administrators may also define customer status automation rules that enable customers to be copied to anotherbase projectbased on web points accrued or products purchased.

The Trusted Projects list in the Properties page displays a list of all other CustomerWise base projects. Project members may define one or more base projects as applicable to customer status automation rules defined in the CustomerWise project.

To enable automatic transfers across base projects:

1Select the Enable Customers to be Transferred to Other Base Projects check box in the Properties page of the Customer Status Automation folder.

2Select the applicable base projects.

18.3 Defining Customer Status Automation Rules

Customer status automation must be enabled by a project administrator in the Optional Features page of the General Project Settings folder.

The Customer Status Automation folder is not displayed in the Admin Tree window if customer status automation is not enabled. For more information see “Managing Optional Project Features”.

18.3.1 Creating Customer Status Automation Rules

To create a customer status automation rule:

1Select the Add button in the Automation Rules page of the Customer Status Automation folder.

The Customer Status Automation Rule dialog box appears.

2Define a descriptive name for the customer status automation rule.

3Define a brief description of the customer status automation rule.

4Select an option from the Type dropdown list.

TechExcel supports two types of automation triggers: web point triggers and purchase triggers:

• Web Point triggers

• Purchase triggers

The option selected determines the controls that are displayed in the dialog box.

5Define the automation trigger for the selected customer status automation rule type

18.3.2 Defining Web Point Triggers

Every administrator-defined customer status automation rule consists of two factors: an automation trigger and an automation action.

The automation trigger identifies the initiating event that triggers an automation action. TechExcel supports two types of automation triggers: web point triggers and purchase triggers. The triggering of an automation rule may result in multiple automation actions.

The Web Points Reach A Certain Number As Your rule type, define the Web points number. If your customer is in a marketing project or sales project and their Web points reach this number, the rule will be triggered.

18.3.3 Defining Purchase Triggers

Every administrator-defined customer status automation rule consists of two factors: an automation trigger and an automation action.

The automation trigger identifies the initiating event that triggers an automation action. TechExcel supports two types of automation triggers: web point triggers and purchase triggers. The triggering of an automation rule may result in multiple automation actions.

The New Purchase rule type s as your rule type you will need to choose a sales project from the Working Project dropdown list. This list will have all of the sales projects that were marked as trusted projects in the Properties page.

You will then need to define the product line from the Product line purchased dropdown list. When a customer purchases a certain product line from the specified project they will automatically be copied to another project, such as a support project.

18.3.4 Defining Automation Rule Actions

Every administrator-defined customer status automation rule consists of two factors: an automation trigger and an automation action.

The automation trigger identifies the initiating event that triggers an automation action. TechExcel supports two types of automation triggers: web point triggers and purchase triggers. The triggering of an automation rule may result in multiple automation actions.

The New Purchase rule type s as your rule type you will need to choose a sales project from the Working Project dropdown list. This list will have all of the sales projects that were marked as trusted projects in the Properties page.

You will then need to define the product line from the Product line purchased dropdown list. When a customer purchases a certain product line from the specified project they will automatically be copied to another project, such as a support project.

 Chapter 19 Customer Web Portal Administration

19.1 Understanding the Customer Web Portal

The TechExcel Customer Web Portal is a secure, interactive Web site through which customers and sales prospects may submit, and edit incidents and view information that is specifically tailored for them.

The Customer Web Portal enables customers and customer contacts to submit, view, and edit CRM incidents through the Internet.

• Customers may view their support incidents and events

• Customers may submit new incidents and edit existing incidents.

All customers and customer contacts are created and managed by CRM project members in the Customer view of the CRM clients.

The Customer Web Portal also serves as a communication center, enabling customers and prospects controlled entry into the sales processes and support processes.

The Customer Web Portal enables customers to access FAQs, upgrades and patch info, product documentation, and provides them with the power they need to avoid becoming part of the support process in the first place by providing helpful hints, upgrades, patch info or any other information you believe is relevant based on their customer type or products purchased.

• When a problem does arise, your customer can easily search the knowledge base for information that is specific to their particular incident saving your support team time and reducing your overall support cost.

• Customers may conduct Web conversations with support engineers.

• Customers may search the knowledge base, download documents or software, and read whatever news or announcements you have determined they should see based on their company and their role.

The Customer Web Portal is an opitonal feature in TechExcel CRM. Support for the Customer Web Portal must be enabled independently in each CRM work project. For more information see “Enabling the Customer Web Portal”.

19.1.1 Understanding Customer Web Portal Administration

Project administrators may customize the Customer Web Portal using controls in the Customer Web Portal folder of the CRM Admin client.

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

• Defining General Customer Web Portal Settings

• Managing Registration Controls

• Managing Web Style Themes

• Managing Field Access Controls

• Managing Page Style Customization

• Administrating Customer Web Portal Login Controls

• Customizing the Knowledge Portal • Managing Customer Web Portal Reports

• Defining Single Sign-on Access

19.1.2 Customer Web Portal access and security

Project administrators may restrict access to projects through the Customer Web Portal based on adminsitrator-defined customer and contact accounts.

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

All customer and customer contact privileges are assigned by project members in the Customer view of CRM projects. Project administrators may define customer types and contact types, assign access privileges to those customer types and contact types, and perform other administrative tasks using tools in the Customer Web Portal folder.For more information see “Customer Administration”.

19.1.3 Customer Web Portal GUI customization

Project administrators may completely customize the Customer 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.

19.1.4 Understanding Customer Web Portal and Project Types

Project administrators may enable and configure the Customer Web Portal for marketing projects, sales projects, and sales projects.

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

• Customers may only submit events to a sales project.

• Customers must pass the associated runtime key for that project in the URL to access a marketing or sales project the For more information see .See “Defining Runtime Keys” .

19.1.5 Understanding the Web Portal and the CRM Customer View

The Customer view in the CRM clients enables project members to create, manage, and track customers and customer contacts.

Customer and contact information is stored in a customer base project.The customer base project enables project teams to share a common database of customers and customer contacts. Each CRM project may be associated with one customer base project.

The customer base project is shared by multiple CRM work projects (marketing projects, sales projects, and support projects). All customers and customer contacts are shared across all three projects.

All CRM work projects (marketing, sales, and support) share a common customer base project. A customer base project enables project teams to share a common database of customers and customer contacts. All customer and customer contact data is stored in a customer base projects and tracked in the child marketing projects, sales projects, and support projects through the Customer view. For more information on customer base projects see “Creating CRM Base Projects”.

19.2 Defining General Customer Web Portal Settings

Project administrators may customize the Customer Web Portal using controls in the Customer Web Portal folder of the CRM Admin client.

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

• Defining General Customer Web Portal Settings

• Managing Registration Controls

• Managing Web Style Themes

• Managing Field Access Controls

• Managing Page Style Customization

• Administrating Customer Web Portal Login Controls

• Customizing the Knowledge Portal • Managing Customer Web Portal Reports

• Defining Single Sign-on Access

19.2.1 Enabling the Customer Web Portal

Project administrators may enable Customer Web Portal support in a work project by selecting the Enable Customer Web Portal check box in the General Settings page of the Customer Web Portal folder.

Administrators must enable the Customer Web Portal for administrator-defined configurations to be implemented.

Reloading Web SettingsProject administrators may reload Customer Web Portal settings by selecting the Reload Web Settings button in the General Settings page of the Customer Web Portal folder.

For performance reasons all TechExcel CRM Web settings are cached on the TechExcel CRM Web Server. Whenever an administrators makes any changes in CRM Admin, the administrator must reload the project Web settings to ensure that these changes are visible to users of the Web clients.

Note:Clicking the Reload Web Settings button resets the settings for the current project only. If an administrators makes multiple changes across multiple projects, the administrator must reload the Web settings in each project individulally.

19.2.2 Defining Default Work Projects

Project administrators may define the default work project in the Customer Web Portal by selecting an option from the Default Work Project dropdown list in the General Settings page of the Customer Web Portal folder.

Thedefault work projectrepresents the default project that customers access when they log into the Customer Web Portal using either the based project runtime key or no runtime key.

If a customer logs into the Customer Web Portal and passes a project ID or project runtime key, the customer accesses the associated project and the default project is ignored.

Administrators must define a single work project as the default work project for each base project. The default work project may be a support project or a sales project. The default work project value is stored in the base project.

• For a support project, customers may view, update, and submit support incidents and events.

• For a sales project, customers may view sales events and submit new sales events and general events.

Note:Administrators should not define marketing project as the default work project, as customers should not have access to your marketing campaign information.

19.2.3 Defining Runtime Keys

Runtime keys do not replace Web login processes; runtime keys provide an additional level of access control. After passing the appropriate runtime key, user authentication is still required to access a project. Runtime key configuration is an optional feature.

TechExcel CRM enables project IDs and runtime keys to be passed as part of the URL.

For example,

http://WebServer/scripts/texcel/SWise/Clogin.dll?Projec-tID=1&RunTimeKey=USAMarket

The TechExcel CRM administrator may define a runtime key for each project and restrict access to the project Web login page to a few targeted customers. TechExcel CRM checks to ensure the project ID and runtime key match the information stored in the database.

Unauthorized Web users who do not pass the specified project ID and runtime key cannot access the project login page.

Note:A runtime key must be used for a customer to login to a sales or marketing project. By design, users can log in to support projects without runtime keys but must pass a runtime key to access the login page for a sales or marketing projects..

TechExcel CRM uses three different types of runtime keys. Administrators also have the option of not defining a runtime key at all:

• System runtime keys

• Base project runtime keys

• Work project runtime keys

• No runtime key

System runtime keys

Thesystem runtime keyenables customers to access all TechExcel CRM work projects.

http://WebServer/scripts/texcel/SWise/CLogin.dll?RunTime- Key='SystemKey

Customers should not be given the system runtime key because there should be no need to log into all available CRM projects. In this case, all projects must have a project runtime key specified.

Base project runtime keys

Thebase project runtime keyenables customers to directly access the login page for the default work project.

Project administrator must define a default project for the Customer Web Portal.

Work project runtime keys

Work project runtime keyswhen used in conjunction with project IDs may enable customers to directly access work project login pages.

No runtime key

If no runtime key is defined, the project ID may still be passed to the URL, and the user may access the work project login page, with no run time key checking (by leaving the runtime key empty in TechExcel CRM Admin).

In this configuration, runtime key checking is not required.

The format will be as follows:

http://WebServer/scripts/texcel/SWise/Clogin.dll?Projec-tID=10

19.2.4 Customizing the Customer Web Portal Logos

Project administrators may customize the graphical user interface displayed in the Customer Web Portal to display the logo of their company.

The TechExcel CRM logo that is displayed in the upper right hand corner of the browser window may be replaced with another graphic of the same dimensions. The TechExcel CRM logo is namedfrontofficelogo.gif and is stored in beneath the root directory of the web server:

C:\Inetpub\wwwroot\SWiseWeb\Images

To replace the TechExcel CRM logo with another logo, save the customized logo as a GIF file (120 pixels wide by 25 pixels high) to the image folder. The custom logo must be renamedfrontofficelogo_cust.gif.

To customize the logo displayed to project members in the CRM Web client, save the custom logo as a GIF file namedfrontofficelogo.gifto the same directory. For more information see “Customizing CustomerWise Web Logos”.

19.2.5 Displaying Projects to Customer

If you want Customer Web Portal visitors to see content from other work projects when they log in to the current work project, you can define those projects in this section. Highlight the name of a project you wish to make visible and move it into the display order list box. You can also change the display order of the additional projects by highlighting a project and clicking the Up or Down button.

19.2.6 Enabling Customers to Attach Files

It is possible for customers to attach files when submitting new incidents through the Customer Web Portal. To enable this functionality, check the box labeled Enable customers to attach files to their incidents… and define a size limit for the files. A limit of 0 is considered no limit.

Specify a message for the size limitation. This message will display to the user if the user attempts to submit a file larger than the size limitation specified above.

If you want to prevent customers from attaching certain file types through the Customer Web Portal, check the Prevent files of certain file types from being downloaded option click the Define button to launch the Define File Types and Warning Message window. Type a comma-separated list of the 3-letter file extensions that should be prohibited from being attached. Specify the warning message that users will see when they do try to attach prohibited file types. Then, click the OK button to save and close the window, or the Cancel button to close the window without saving.

19.3 Managing Registration Controls

Project administrators may restrict access to projects through the Customer Web Portal based on adminsitrator-defined customer and contact accounts.

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

All customer and customer contact privileges are assigned by project members in the Customer view of CRM projects. Project administrators may define customer types and contact types, assign access privileges to those customer types and contact types, and perform other administrative tasks using tools in the Customer Web Portal folder.For more information see “Customer Administration”.

19.3.1 Enabling New Customer and Contact Self-Registration

New customers and contacts may self-register by clicking the New Customer button on the Customer Web Portal login page and completing the registration process.

Select one of the following settings for customer self-registration:

• Not enabled – No customers or contacts can self-register. The New customer button will not display.

• Enabled for all new customers and contacts – Any new customer or contact can self-register.

• Enabled but for existing customers only – Only contacts at customers that exist in the current TechExcel CRM customer base project can self-register. TechExcel CRM will only create a new account if the company entered during registration matches an existing company.

Note:If there are multiple projects to select from on the regular login page, the New Customer button is not displayed regardless of this setting. To ensure that the New Customer button is not displayed, limit Customer Web Portal access to one work project, or have your customers use runtime keys in the links to the login page. For more information see See “Defining Runtime Keys” .

19.3.2 Enabling New Customer Contacts To Become Active Immediately

This check box enables customers who self-register using the New Customer button to gain immediate access to the Customer Web Portal. If this box is unchecked, new customers will see a message when they complete the self-registration process that explains that before they can gain access to the Customer Web Portal they must be activated by either a Customer Web Portal administrator or another contact at their company who is already registered and has the authority to activate new contacts.

You can define the customer type that should be automatically assigned to customers who self-register. Administrators can define customer types by double-clicking on the Customer Type field found on the Address' page, found in the Customer View folder.

For more details on defining customer types see the respective section later in this chapter.

19.3.3 Defining Default Access Types

• You can define the access type that should be automatically assigned to customers who self-register. Administrators can define access types by double-clicking on the Access Type field found on the 'Contact Info' page, found in the Customer View folder. For more details on defining customer types see the respective section later in this chapter.

• You can define the access type that should be automatically assigned to the first contact who self-registers for a particular customer. If you plan to give customer contacts the ability to manage their own customer information, you might consider giving this privilege to only the first contact for a company. They would essentially serve as an administrator of their company’s contact information.

19.3.4 Defining Registration Methods

Specify if new users can access the customer Web portal immediately, or if they are first mailed a password to access the Customer Web Portal.

Select the Auto-send email for newly registered customer option to automatically send an email containing user name and password information to new users, regardless of the settings above.

19.4 Managing Web Style Themes

Project administrators may completely customize the Customer 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.

19.4.1 Defining Web Themes

TechExcel CRM enables project administrators to completely customize the Customer Web Portal graphical user interface.

The Customer Web Portal interface is based on an administrator-selected theme. Each web theme is a set of cascading style sheets that determine the colors, styles, and fonts of the web application. Once themes are created in TechExcel CRM Admin, project administrators may chnage web theme settings.

Project administrators may create web themes in the Web Style Themes page.

19.4.2 Customizing Web Themes

Expand each section under Customer Web Portal tree to edit different parts of the Customer Web Portal. When you highlight a Customer Web Portal part, the corresponding style and style definition will show up on the right together with the Help Note telling you exactly which part you will modify if you change the values at the top.

TechExcel recommends that administrators have a basic knowledge of how style-sheets work before attempting to modify any of these settings.

Each theme you created can be customized on the Theme Customization page. However, you can not customize default themes shipped by TechExcel.

Note: Many pages share the same style elements. Once you have edited an element in one page; other pages that have the same one would be affected as well. The reason for this is to keep the whole look and feel of CRM Web interface consistent. It is strongly recommended that you do an overall plan of what you want to do with the interface before you change any element..

To customize Web Themes: 

1Highlight a theme to display and edit its corresponding style sheet information.

2Go to Themes Customization under Web Style Setup

3Select a theme you want to customize in the Select a theme drop down list.

4Select a page from the page list; all the styles used in this page will appear on the right.

Example: Customer Web Portal -> Home -> Web Portal Home Page Select a style name from the style list.

5Edit its value in theStyle element valueinput box.

• Sample… button - to view the style element values from other themes

• Preview… button - to view the result you have made to the current page

19.4.3 Defining Theme Schedules

In TechExcel CRM Admin you can also define when certain themes should apply to users. Each theme can have a schedule that determines its availability. To define a theme schedule, navigate to the Theme Schedule page.

19.5 Managing Field Access Controls

Project administrators may enable and configure the Customer Web Portal for marketing projects, sales projects, and sales projects.

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

• Customers may only submit events to a sales project.

• Customers must pass the associated runtime key for that project in the URL to access a marketing or sales project the For more information see .See “Defining Runtime Keys” .

19.6 Managing Page Style Customization

The Customer view in the CRM clients enables project members to create, manage, and track customers and customer contacts.

Customer and contact information is stored in a customer base project.The customer base project enables project teams to share a common database of customers and customer contacts. Each CRM project may be associated with one customer base project.

The customer base project is shared by multiple CRM work projects (marketing projects, sales projects, and support projects). All customers and customer contacts are shared across all three projects.

All CRM work projects (marketing, sales, and support) share a common customer base project. A customer base project enables project teams to share a common database of customers and customer contacts. All customer and customer contact data is stored in a customer base projects and tracked in the child marketing projects, sales projects, and support projects through the Customer view. For more information on customer base projects see “Creating CRM Base Projects”.

19.6.1 Customizing the New Incident Page

Administrators may use tools in the New Incident Page page of the Page Style Customization folder to customize the New Incident Page displayed in the Customer Web Portal.

The New Incident page enables customers to submit new incidents to a project through the Customer Web Portal.

Administrators may configure the labels and the links associated with creating new incidents. These elements all accept both plain text and HTML code.

On the Customer Web Portal home page, between the Knowledge base quick search and the project incident list is a link to the form that customers use to create new incidents/incidents. This link is made up of three parts: a page title, header above the link, the link itself, and some descriptive text below the link. Customize each of these settings:

Page title

When a customer clicks on the new incident link the new incident page displays. Use the New incident page title field to customize the title of this new incident page. If this field is left blank, the new incident page will have the default title, New Incident.

New incident project selection header

Use the New incident project selection header field to create a header that appears above the link to the new incident form. For example, you could enter Submit a new support request as a header.

New incident HTML link title

Use the New incident HTML link title field to configure the words that make up the link itself. For example, you could enter Click here to create a new support incident as a link.

New incident submit help note

Use the New incident submit help note field to configure the descriptive text that will appear below the link to the new incident page. For example, you could enter Be sure to search the knowledge base for an answer to your questionbeforeclicking on the link above to create a new support incident.

New incident based on incident template

Use the Project incident list header input box to configure a header for the list of project incidents. The default value for this field (if left blank) will show the text Support Incident List followed by the project name.

Managing Incident List Windows

Administrators may use tools in the Incident Page List page of the Page Style Customization folder to determine which columns are displayed in the Incident List window of the Customer Web Portal.

The Incident List window displays high-level information about many different incidents in a tabular format. Each row represents a single incident. Each column represents an incident property.

Project administrators may define which columns are displayed in the Incident List window and their display order. Administrators may also define the heading displayed above the Incident List window, and the headers displayed for each column.

To add or remove columns to the Incident List window:

Project administrators may cusotmize the incident list to display controls from the Description page, Current Status page, or custom pages.

• To add a field to the incident list, select a field from the Data Fields list and click the right-arrow button.

• To remove a field from the incident list, select a field from the Incident List View Columns list and click the Left-arrow button. The Incident ID field cannot be removed from the Incident list.

The Incident List View Columns pane shows all data fields that are displayed the Incident list window.

To define headers for Incident List columns:

Administrators may change the headers for the Incident ID, Progress Status, Current Owner, and Customer columns.

Once these fields have been added to the view, simply highlight the field and edit the header label in the Edit Column Header text box. This input box will accept both plain text and HTML code.

The Progress Status field that is customized here is reflected on other pages, including the Current Status, New, and Search Dialog pages.

To change the order of Incident List window columns:

Click the Reset button to set the incident list view back to the default view: Incident ID, Title, Progress Status, Current Owner, Date Assigned, and Customer.

19.6.2 Customizing the Company Header

Administrators may use tools in the Other Pages page of the Page Style Customization folder to customize the company header, product logo, and bottom section content of the Customer Web Portal home page.

19.6.3 Customizing Customer Web Portal Headers and Footers

Administrators customize the company header, product logo, and bottom section content of the Customer Web Portal home page using tools in the Other Pages page of the Page Style Customization folder.

The Customer Web Portal is divided into three sections: the top, the body, and the bottom of the page. Administrators may customize the top and bottom of all Customer Web Portal pages.

• The top displays the header

• The bottom of the page displays

19.6.3.1 Customer Web Portal company header

Project administraotrs may customize the company header:

19.6.3.2 Customer Web Portal bottom section content

Project administraotrs may customize the company header

19.6.3.3 Customer Web Portal logo

Project administraotrs may customize the company header

19.6.3.4 Customizing CRM Web Logos

Project administrators may customize the graphical user interface displayed in the Customer Web Portal to display the logo of their company.

The TechExcel CRM logo that is displayed in the upper right hand corner of the browser window may be replaced with another graphic of the same dimensions.

To customize the logo displayed in the Customer Web Portal, save the custom logo as a GIF file namedfrontofficelogo_cust.gif to C:\Inetpub\wwwroot\SWiseWeb\Images directory.

19.7 Administrating Customer Web Portal Login Controls

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

19.7.1 Defining Password Validity

Administrators may use tools in the Define Valid Password page of the Login Control subfolder to define restrictions on Customer Web Portal passwords.

Administrators may define the minimum number of letters in the password, ensure that the password is not the same as the user name, and mandate that the password includes both alphabetic and numerical characters.

19.7.2 Defining Password Security Controls

Administrators may use controls in the Password Security Control page to enable password security controls and to define up to five different security questions for protecting user names and passwords.

Customers who fail to log into the Customer Web Portal because of a base user name or password may request that their user name and password be emailed to them.

Customers may only retrieve their user name and password if they successfully answer a security question. Administrators may use controls in the Password Security Control page to define and enable up to five security questions.

Typical security questions include:

• What is your pet's name?

• What is your mother's maiden name?

• Which city were you born in?

To edit a security question:

1Select an existing question in the Question list of the Password Security Control page.

2Click the Edit button.

The Question dialog box appears.

3Edit the question in the Question control.

4Select the Enable check box.

5Click the OK button.

19.7.3 Defining Auto Reset Password Messages

Project administrators may define email messages that are automatically sent to customer contacts when their passwords are set to be reset in the Auto Reset Password page of the Customer Web Portal folder.

The email contains a randomly generated password.

To enable the auto reset password messages, select the Enable Auto Reset Password via Email for Invalid Password control in the Auto Reset Password page of the Customer Web Portal folder.

Project administrators may then define the title and body of the email message that is delivered to the customer contact.

The default message sent to users who request a new password displays a temporary login email address and password, the autologin URL, and manual login URL.

Your password to TechExcel Customer Web Portal has been auto reset for security purpose. Your user name and temporary pass-word are below:

Login email:{Email Address}

Password:{Password}

Note that your password is case sensitive and your login name is your active email address.

To auto login, click (and bookmark) the URL link below:

{Auto Login}

To manually login, click (and bookmark) the URL link below:

{Manual Login}

19.7.4 Defining Request New Password Messages

If a customer cannot log into the Customer Web Portal login page because they provide an incorrect user name or password, they may request that their user name and password are emailed to them by selecting the password request control in the Customer Web Portal Login page.

To display the request new password check box, select the Allow Customer to Request New Password check box in the Request Password page of the Customer Web Portal folder.

Project administrators may then define the title and body of the email message that is delivered to the customer contact.

The default message sent to users who request a new password displays a temporary login email address and password, the autologin URL, and manual login URL.

Your password to TechExcel Customer Web Portal has been reset at your request. Your user name and temporary password are below:

Login email:{Email Address}

Password:{Password}

Note that your password is case sensitive and your login name is your active email address.

To auto login, click (and bookmark) the URL link below:

{Auto Login}

To manually login, click (and bookmark) the URL link below:

{Manual Login}

19.7.5 Managing Inactive Customer Contact Logins

Administrators may use controls in the Inactive User Login page to enable inactive users to log into the Customer Web Portal, to auto reset their passwords, and to send an administrator-defined welcome message to inactive users.

• The Enable Inactive User to Login and Become Active Automatically control enables administrators to allow all inactive users to log into the Customer Web Portal. Inactive users are automatically re-registered as active.

• The Auto Reset Password and Send the Email Below control enables administrators to automatically reset the password of inactive Customer Web Portal users and to send them a message by email. Administrators may define the title and body of the email message in the Inactive User Login page.

19.7.6 Defining Messages to Inactive Customer Contacts

Administrators may define the title and message body of email messages that are automatically sent to inactive members when they attempt to log into the Customer Web Portal using controls in the Inactive User Login page of the Login Control folder.

The default message sent to inactive customer contacts includes a temporary login email address and password, the autologin URL, and manual login URL.

Your password to TechExcel Customer Web Portal has been reset for security purpose. Your user name and temporary password are as below:

Login email:{Email Address}

Login email:{Email Address}

Password:{Password}

Note that your password is case sensitive and your login name is your active email address.

To auto login, click (and bookmark) the URL link below:

{Auto Login}

To manually login, click (and bookmark) the URL link below:

{Manual Login}

19.8 Customizing the Knowledge Portal

Project administrators may enable Customer Web Portal support in a work project by selecting the Enable Customer Web Portal check box in the General Settings page of the Customer Web Portal folder.

Administrators must enable the Customer Web Portal for administrator-defined configurations to be implemented.

Reloading Web SettingsProject administrators may reload Customer Web Portal settings by selecting the Reload Web Settings button in the General Settings page of the Customer Web Portal folder.

For performance reasons all TechExcel CRM Web settings are cached on the TechExcel CRM Web Server. Whenever an administrators makes any changes in CRM Admin, the administrator must reload the project Web settings to ensure that these changes are visible to users of the Web clients.

Note:Clicking the Reload Web Settings button resets the settings for the current project only. If an administrators makes multiple changes across multiple projects, the administrator must reload the Web settings in each project individulally.

19.8.1 Defining the Knowledge Portal Type

The Knowledge Portal Options area of the Knowledge Portal page displays three options:

• The Knowledge Search Only option enables the Knowledge Search and Browse tab to be dislayed in the Knowledge Portal. Customer contacts may log into the Knowledge Portal and search for knowledge items. If the Knowledge Search Only option is selected, the administrator cannot configure Knowledge Portal settings.

• The Standard Knowledge Portal option

• The Customized Knowledge Portal option enables project administrators to configure a customized knowledge portal. If the Customized Knowledge Portal option is selected, the administrator may select a predefined custom knowledge portal from the Select Knowledge Portal Configuration dropdown list.

19.8.2 Enabling Knowledge Portal Options

Project administrators may enable four knowledge base options and define their display order using controls in the the Knowledge Portal page in the Customer Web Portal folder.

The Customer Web Portal knowledge base displays

• The Knowledge Search and Browse option

• The CRM FAQ option

• The DevTrack FAQ option

• The External Knowledge Integration option

Project adminsitrators may only enable knowledge portal options if they selected either the Standare Knowledge Portal or Customized Knowlege Portal option in the Knowledge Portal Type area of the Knowledge Portal page.

19.8.3 Knowledge Search and Browse

Project administrators may enable the Knowledge Search and Browse option.

19.8.4 CRM FAQs

Project administrators may enable the CRM FAQ option.

19.8.5 DevTrack FAQs

Project administrators may enable the DevTrack FAQ option.

19.8.6 External Knowledge Integration Defining External Knowledge Layout

Project administrators may define how external knowledge is displayed in the Knowledge Portal using the External Knowledge Layout dropdown list in the Knowledge Portal page of the Customer Web Portal folder.

The External Knowledge Layout control displays three options:

• The As Separate Tabs option displays each FAQ topic as a tabbed page in the Knowledge Portal

• The As Part of Knowledge Tree option displays an FAQ folder appear as Knowledge Tree window.

• The As Both Tabs and Part of Knowledge Tree displays each FAQ topic as a tabbed page in the Knowledge Portal and an FAQ folder appear as Knowledge Tree window

Project administrators must enable the External Knowledge Layout option before they may configure external knowledge portal settings.

19.8.7 Defining CRM FAQ Layout

Project administrators may define how CRM FAQs are displayed in the Knowledge Portal using the FAQ Layout dropdown list in the Knowledge Portal page of the Customer Web Portal folder.

The FAQ Layout control displays three options:

• The As Separate Tabs option displays each FAQ topic as a tabbed page in the Knowledge Portal

• The As Part of Knowledge Tree option displays an FAQ folder appear as Knowledge Tree window.

• The As Both Tabs and Part of Knowledge Tree displays each FAQ topic as a tabbed page in the Knowledge Portal and an FAQ folder appear as Knowledge Tree window

19.8.8 Defining Knowledge Layout in the Knowledge Portal

Project administrators may define how knowledge items are structured and displayed in the Knowledge Portal using the Knowledge Display Format control in the Knowledge Portal page of the Customer Web Portal folder.

The Knowledge Display Format control displays three options:

• Display title of knowledge item

• Display title and summary of a knowledge item

• Display title and a short summary of a knowledge item.

19.8.9 Defining the Length of Knowledge Item Summaries

Project administrators may define the total length (in characters) of the summaries given for each knowledge item in the Knowledge Portal using the Summary Length control in the Knowledge Portal page of the Customer Web Portal folder.

Project administrators must enable display of the summary in the Knowledge Display Format control. If the Title Only option is selected the summary is not displayed in the Knowledge Portal.

19.8.10 Defining the Number of Knowledge Items Displayed

Project administrators may define the number of knowledge items that may be displayed at once the Knowledge Portal using the Number of Knowledge per Page control in the Knowledge Portal page of the Customer Web Portal folder.

To define the number of knowledge items displayed, enter a number in the Knowledge Items per Page control.

19.8.11 Defining Default Search Option

Project administrators may define default search features in the Knowledge Portal using the Default Search Option control in the Knowledge Portal page of the Customer Web Portal folder. The Default Search Option control displays two options: • The Title option • The Full Text option

19.9 Managing Customer Web Portal Reports

Project administrators may define the default work project in the Customer Web Portal by selecting an option from the Default Work Project dropdown list in the General Settings page of the Customer Web Portal folder.

Thedefault work projectrepresents the default project that customers access when they log into the Customer Web Portal using either the based project runtime key or no runtime key.

If a customer logs into the Customer Web Portal and passes a project ID or project runtime key, the customer accesses the associated project and the default project is ignored.

Administrators must define a single work project as the default work project for each base project. The default work project may be a support project or a sales project. The default work project value is stored in the base project.

• For a support project, customers may view, update, and submit support incidents and events.

• For a sales project, customers may view sales events and submit new sales events and general events.

Note:Administrators should not define marketing project as the default work project, as customers should not have access to your marketing campaign information.

 Chapter 20 Administrating Web Forms

20.1 Administrating FormWise Web Forms

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

•Web clicksenable project teams to record Customer Web Portal activity so that they may track customer interest in products and services.

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

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

•Customer profile questionsenable project teams to link form questions to customer data that is managed in CustomerWise 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 CustomerWise implementation.

Note:FormWise is an optional feature in CustomerWise 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 CustomerWise 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 e-mail announcements may be sent to customers based the answers given to form questions. Administrators may pre-schedule these e-mail announcements.

20.1.1 Enabling Web Activity Management (Web Clicks)

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

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

20.1.2 Enabling FormWise for Standard Forms

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 CustomerWise project members to publish forms.

20.1.3 Enabling Customer Profile Questions

When designing forms, project members may limit the range of customer profile questions based on one of three criteria:

• Only for those 100% confirmed customers

• Include customers based on e-mail addressed matched

• Never update customer profile for this form

To enable project teams to update or define customer profiles based on answers given to form questions, select the Support Customer Profile Questions check box in the General Settings page of the Web Activity and FormWise folder.

Customer profile questions are linked directly to customer account properties defined and managed within the CustomerWise client application. User-defined form dropdown lists may be mapped to CustomerWise properties and display incident property values as selectable options.

20.1.4 Defining the FormWise URL

To define the root folder for all project forms, enter a URL in the FormWise URL text box in the General Settings page of the Web Activity and FormWise folder.

The default URL for FormWise forms is:

http://www.yourdomain.com/FormWise 

By default the name of the FormWise root is namedFormWise. Administrators may give any name they choose to this directory, but the name must match the alias given to the QuickInfo folder stored in the IIS server.

The default directory for storing all FormWise forms: inetpub\wwwroot\QuickInfo. Administrators must share the QuickInfo folder and define an appropriatealiasto make the form available.

20.1.5 Administrating Web Points

Web points are automatically generated for users that execute tasks in the a web form in the Customer Web Portal (answering profile questions) or Download Plus (downloading knowledge items or applications).

Businesses may target potential or existing customers based on the number of points they have earned while surfing their Customer Web Portal.

Project administrators may enable web points and define web point settings for their projects using controls in the n the General Settings page of the Web Activity and FormWise folder.

Administrators may define rules for identifying leads based on web points:

• Enabling web points

• Defining the applicable date range for auto-calculating web points

• Defining the applicable point range for searching out customers

• Displaying the TCP/IP address of web points

• Defining the number of web points earned for logging into the Customer Web Portal and Download Plus

To administrate web points:

1Select the Support Web Activity points check box in the General Settings page of the Web Activity and FormWise folder.

Project administrators must enable web point support in a project for TechExcel CustomerWise to track and calculate new web points.

2To define the applicable date range for auto-calculating web points, select the Number of Days to Autocalculate Web Points for Customers and Contacts check box.

CustomerWise calculates customer web points based on web activity (web clicks) within an administrator-defined time period. By limiting the date range of web point calculation, project teams may ensure that only fresh data is considered when identifying new leads.

The default setting is 30 days.

3To define the applicable point range for customer accounts, define a low and high number in the Default Web Points for Searching Active Users area.

• The low number represents the lowest number of web points that a customer must earn to be returned by a search.

• The high number represents the highest number of web points that a customer must earn to be returned by a search.

4To display TCP/IP address for customer web activity, select the Show TCP/IP Address for Customer Web Activity check box.

5To display the Web Activity Points page, select the Show Web Activity Points Page check box.

6To define the number of web points assigned to a customer for logging into the Customer Web Portal, select the Assign Customer Web Portal Login with Web Points check box.

7To define the number of web points assigned to a customer for logging into DownloadPlus, select the Assign DownloadPlus Login with Web Points check box.

20.1.6 Defining Web Points Privileges

Project administrators may grant web point management privileges to project members using controls in the Privileges page of the Web Activity and FormWise folder.

Web point privileges enable project members to manage web points and web clicks in CustomerWise projects based on their account type. All CustomerWise privileges are granted to account types rather than directly to project members.:

Table 20-1: FormWise Privileges

20.2 Administrating FormWise E-mail Auto-Reply

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

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

20.2.1 Understanding the FormWise Information Schema

Targeted email may be sent to customers based on administrator-defined FormWise auto-reply rules.

Enabling Email Auto Reply

To enable TechExcel CustomerWise to automatically send email announcements to customers based on data collected in web forms, select the Enable Email Auto Reply check box in the Outgoing Mail Setup page of the Web Activity and FormWise folder.

Defining Server Information

To define the outgoing mail server:

1Define the outgoing mail server in the Outgoing Mail (SMTP) Server field.

The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service.

2To define the return email address, enter the address and the user name of the addressee in the fields provided.

All replys to the CustomerWise generated email notifications are automatically addressed to the email address and the user name defined.

3If the email server requires authentication, select the My Email Server Requires Authentication check box and define the account name and password in the fields provided.

 Chapter 21 Knowledge Administration

21.1 Understanding CustomerWise Knowledge Management

TechExcel CustomerWise 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 CustomerWise projects, and control customer and project member access to knowledge items based on administrator-defined privileges.

Knowledge management tasks may be performed in the Knowledge view of the CustomerWise clients and through the Customer Web Portal. CustomerWise enables project members and customers 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 enable 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 your system and maintenance costs.

• Internal teams and external customers can search the knowledge base for selfservice content based on administrator-defined privileges.

• CustomerWise 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 e-mail announcement settings.

• Enable and define dynamic FAQ settings.

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

• Enable and configure the CustomerWise Knowledge Portal.

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

• Enabling and configuring the CustomerWise Search Engine.

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

Note:The TechExcel CustomerWise 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.

21.1.1 Understanding the CustomerWise Knowledge Base

In CustomerWise, project team members of multiple projects may access a centralized repository of information from within the CustomerWise client. The CustomerWise knowledge view, powered by TechExcel KnowledgeWise, provides customer support and sales organizations with a tool for collecting and organizing information. All ideas, both formal and informal are collected and managed in the same, centralized knowledge base.

TechExcel KnowledgeWise is a key component in the TechExcel Service Suite of CRM products. KnowledgeWise provides project managers, support engineers, and sales and marketing departments with a secure repository for all project documents—the project plan,business requirements, functional and technical specifications, risk management documents, and corporate standards and guidelines may be managed in one knowledge base that is shared by the entire business.

• A centralized knowledge base increases efficiency, prevents the loss of information, helps to reduce system and maintenance costs, and facilitates collaboration by distributed teams.

• Access to knowledge items is protected by privilege-based access controls. The ability of project members to view, edit, lock, check out, and check in protected files is defined by their role in the project.

• Built-in version control tools ensure that all project development and testing teams (no matter where they are in world) always have access to the most up-to-date documents.

CustomerWise knowledge projects provide testing teams with central repository for all information collected throughout the business. Common access to the a knowledge project (through the knowledge view) enables project members to exchange information between projects. Knowledge project administrators may restrict access to the knowledge view or the ability to create knowledge items in all child template projects and work projects. Project teams may build knowledge base adding existing knowledge documents and Web pages, and by publishing knowledge items from resolved support incidents.

The knowledge base benefits all project members.

• Sales and marketing teams can store important documents for common use with strict security controls at project level, folder level, or even item level to control read, write, and viewing access.

• KnowledgeWise enhances your customer 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 CustomerWise client applications.

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

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

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

21.1.2 Understanding Knowledge Items

CustomerWise 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.

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

Announcements:Announcements are predefined e-mails that are created in the TechExcel CustomerWise client, and are then delivered to one or multiple customers also through the client.

HTML links:HTML links enable 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.

Topics:Topics are 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.

Attachments:Attachments are 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.

21.1.3 Administering Knowledge View Privileges

In CustomerWise, a privilege is a right to perform a task that is granted to project members based on their account type. Every project member is assigned an account type when they join a project. Project member roles, responsibilities, access rights, and privileges are defined by their account type.

Knowledge management privileges enable project members to build, publish, and manage knowledge items in TechExcel CustomerWise projects based on their account type.

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

Can Build Public Knowledge:The privilege enables project members to create knowledge documents in a knowledge folder that enables public access (public folders).

Can Publish Public Knowledge:The privilege enables project members to publish knowledge items from public folders, such as knowledge topics, documents, HTML links, and announcements.

Can Build Protected Knowledge:The privilege enables project members to create knowledge documents in a protected knowledge folder.

Can Publish Protected Knowledge:The privilege enables project members to publish knowledge items from protected knowledge folders, such as knowledge topics, documents, HTML links, and announcements.

Can Read Protected Knowledge:The privilege enables project members to obtain a knowledge document from a protected knowledge folder.

Can Delete Knowledge Items:The privilege enables project members to delete a knowledge file.

Can Set Up Knowledge Tree and its Access Controls:The privilege enables project members to create knowledge folders and documents within the folders, as well as assign privileges.

Can Build Knowledge Documents through a Web Browser:The privilege enables project members to create knowledge folders and documents through a Web browser. The user can also assign privileges.

Can E-mail Blast Knowledge Announcement:The privilege enables project members to create an e-mail in the knowledge view and e-mail it (blast it) to a group of recipients.

Can Check In/Out Documents:The privilege enables project members to check out a knowledge document and check it back in with modifications.

Can Lock/unlock Documents:The privilege enables project members to place a temporary restriction on other users accessibility to checking out a document (other users may still obtain a read-only copy). The user can also release the restriction on a locked document.

Can Close Documents:The privilege enables project members to close any file. When a file is closed it can only be accessed with the proper privileges.

Can Reopen Documents:The privilege enables project members to reopen a closed file.

Project members assigned a light account typecannotperform any of the knowledge-related operations.

21.2 Administering Editing Tools

In CustomerWise, project team members of multiple projects may access a centralized repository of information from within the CustomerWise client. The CustomerWise knowledge view, powered by TechExcel KnowledgeWise, provides customer support and sales organizations with a tool for collecting and organizing information. All ideas, both formal and informal are collected and managed in the same, centralized knowledge base.

TechExcel KnowledgeWise is a key component in the TechExcel Service Suite of CRM products. KnowledgeWise provides project managers, support engineers, and sales and marketing departments with a secure repository for all project documents—the project plan,business requirements, functional and technical specifications, risk management documents, and corporate standards and guidelines may be managed in one knowledge base that is shared by the entire business.

• A centralized knowledge base increases efficiency, prevents the loss of information, helps to reduce system and maintenance costs, and facilitates collaboration by distributed teams.

• Access to knowledge items is protected by privilege-based access controls. The ability of project members to view, edit, lock, check out, and check in protected files is defined by their role in the project.

• Built-in version control tools ensure that all project development and testing teams (no matter where they are in world) always have access to the most up-to-date documents.

CustomerWise knowledge projects provide testing teams with central repository for all information collected throughout the business. Common access to the a knowledge project (through the knowledge view) enables project members to exchange information between projects. Knowledge project administrators may restrict access to the knowledge view or the ability to create knowledge items in all child template projects and work projects. Project teams may build knowledge base adding existing knowledge documents and Web pages, and by publishing knowledge items from resolved support incidents.

The knowledge base benefits all project members.

• Sales and marketing teams can store important documents for common use with strict security controls at project level, folder level, or even item level to control read, write, and viewing access.

• KnowledgeWise enhances your customer 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 CustomerWise client applications.

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

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

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

21.2.1 Choosing an Editor

CustomerWise supports four text 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)

21.2.2 Defining HTML Editor Folder

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

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

21.3 Administering E-mail Announcements

CustomerWise 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.

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

Announcements:Announcements are predefined e-mails that are created in the TechExcel CustomerWise client, and are then delivered to one or multiple customers also through the client.

HTML links:HTML links enable 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.

Topics:Topics are 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.

Attachments:Attachments are 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.

21.3.1 Defining E-mail Blast Announcement Settings

Administrators may define basic e-mail announcement settings including SMTP outgoing mail server settings, e-mail reply names, and e-mail reply addresses in the E-mail Announcement page of CustomerWise work projects.

Administrators may define the name and e-mail address of the sender of the e-mail. All replies to the e-mail are automatically directed to the administrator-defined reply address.

For example, announcement blast e-mail messages may be sent to customers fromABC Software Newsat the addresssales@abcsoftware.com.

To define e-mail blast announcement mail server:

1Enter a name in the Reply Name field of the E-mail Announcement page.

For example,ABC Software News

2Enter a name in the Reply Name field of the E-mail Announcement page.

For example,sales@abcsoftware.com.

3Define the name of the SMTP server in the Outgoing Mail (SMTP) Server Name field.

Administrators may enter the mail server name or IP address.

4If the mail server requires authentication, select the My Mail Server Requires Authentication check box and enter the user name and password.

The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service.

21.3.2 Defining Criteria for Redundant E-mail Announcements

Project administrators may define rules that ensure that customers to not receive multiple copies of the same e-mail blast announcement with a set time period.

Depending on the e-mail blast announcement rules defined by project members in the CustomerWise clients, customers may be schedule to receive e-mail announcements based on several different triggers. For example, a contact may receive an e-mail announcement for having downloaded a particular product or because their company owns a particular asset.

The Time Period (Days) control in the E-mail Announcement page enable administrators to ensure that the same e-mail is not delivered during the time period assigned by the administrator.

21.3.3 Enabling and Defining E-mail Announcement Engine Settings

The E-mail Announcement Engine checks e-mail announcement rules on regular, administrator-defined intervals and checks to see if a e-mail announcement rules has been triggered.

The CustomerWise E-mail Announcement Engine is an optional feature that requires a separate purchase from TechExcel.

To define e-mail announcement engine settings:

1Select the Enable E-mail Announcement Engine for Handling Scheduled Announcements check box.

The e-mail announcement engine must be enabled for project team member to send e-mail blast announcements.

2Define the interval between e-mail blasts in the E-mail Announcement Engine Interval Time (in Minutes) control.

Administrators may define interval settings for numbers between 1 and 30.

21.3.4 Defining Customer Subscription Options

Administrators may enable project members to unsubscribe to future e-mail announcements.

To define customer subscription options:

1Select the Enable Customers to Define E-mail Announcement Preference check box.

2Select an option from the Stop E-mail Method dropdown list.

Project members may use one of two methods to unsubscribe:

• The Via FormWise email subscription forms option enables customers to customers subscribe and unsubscribe to your email lists.

• The Via email reply with keywords option enables customers to unsubscribe by replying to the email announcement with any of the keywords specified below in the email subject.

3Define the keyword in the Keyword in Subject field.

Administrators may define the keyword that must be in the subject line of the reply email to cancel the subscription. For example,UNSUBSCRIBEorREMOVE.

4To use the default message, click the Default button. If the Default button is selected, the Define the Message field displays the message:

If you would like to be removed from the mailing list, simply reply to this e-mail with word 'REMOVE' in the subject.

5Define the Message

Specify the instructional message to be displayed in the email. This message should instruct customers how to unsubscribe from the email list and will be automatically included in mass emails sent to customers.

21.4 Defining Dynamic FAQs

In CustomerWise, a privilege is a right to perform a task that is granted to project members based on their account type. Every project member is assigned an account type when they join a project. Project member roles, responsibilities, access rights, and privileges are defined by their account type.

Knowledge management privileges enable project members to build, publish, and manage knowledge items in TechExcel CustomerWise projects based on their account type.

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

Can Build Public Knowledge:The privilege enables project members to create knowledge documents in a knowledge folder that enables public access (public folders).

Can Publish Public Knowledge:The privilege enables project members to publish knowledge items from public folders, such as knowledge topics, documents, HTML links, and announcements.

Can Build Protected Knowledge:The privilege enables project members to create knowledge documents in a protected knowledge folder.

Can Publish Protected Knowledge:The privilege enables project members to publish knowledge items from protected knowledge folders, such as knowledge topics, documents, HTML links, and announcements.

Can Read Protected Knowledge:The privilege enables project members to obtain a knowledge document from a protected knowledge folder.

Can Delete Knowledge Items:The privilege enables project members to delete a knowledge file.

Can Set Up Knowledge Tree and its Access Controls:The privilege enables project members to create knowledge folders and documents within the folders, as well as assign privileges.

Can Build Knowledge Documents through a Web Browser:The privilege enables project members to create knowledge folders and documents through a Web browser. The user can also assign privileges.

Can E-mail Blast Knowledge Announcement:The privilege enables project members to create an e-mail in the knowledge view and e-mail it (blast it) to a group of recipients.

Can Check In/Out Documents:The privilege enables project members to check out a knowledge document and check it back in with modifications.

Can Lock/unlock Documents:The privilege enables project members to place a temporary restriction on other users accessibility to checking out a document (other users may still obtain a read-only copy). The user can also release the restriction on a locked document.

Can Close Documents:The privilege enables project members to close any file. When a file is closed it can only be accessed with the proper privileges.

Can Reopen Documents:The privilege enables project members to reopen a closed file.

Project members assigned a light account typecannotperform any of the knowledge-related operations.

21.4.1 Enabling and Defining Dynamic FAQ Email Server Settings

To define dynamic FAQ email server settings: 

1Select the Enable Dynamic FAQ Feature check box.

2Enter a name in the Reply Name field of the Email Announcement page.

For example,ABC Software News

3Enter a name in the Reply Name field of the Email Announcement page.

For example,sales@abcsoftware.com.

4Define the outgoing mail server in the Outgoing Mail (SMTP) Server field.

Administrators may enter the mail server name or IP address.

5If the mail server requires authentication, select the My Mail Server Requires Authentication check box and enter the user name and password.

The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service.

21.5 Customizing the Knowledge View

Project administrators may enable text and HTML editing tools using controls in the General Settings page of the Knowledge view folder. TechExcel CustomerWise enables project members to create e-mail announcements and knowledge items using advanced HTML and text editing tools.

21.5.1 Customizing the Description Page

The Description page tracks general information about a knowledge item. Administrators may make only limited customizations to most of the controls displayed in the Description page: administrators may customize the titles of all detail pages and the field labels for all data-entry controls.

The Products control and the Modules controls may be customized. Administrators may

• Customize the field label used to identify the data tracked in the control.

• Define the control as visible or invisible in the project.

• Define the values displayed as options in the dropdown list control by linking the control to an incident property or by manually defining the values.

The values displayed in the dropdown list may be linked to one of five different fields or manually define the values displayed in the control:

• Product Line

• Priority

• Database

• Priority

• Response Time

Administrators may optionally select the {None} option and manually define the values displayed in the control.

21.5.2 Customizing the History Page

The History page is used for knowledge document version control. The History page will display all versions of a selected document as well as a project members notes for that revision.

Administrators may customize the page title and column field labels. No other customizations may be made to this page.

21.5.3 Customizing the Resolution Page

The Resolution page is used strictly for knowledge topics and is used to describe a common knowledge topic in more detail.

Administrators may customize the page title and control field labels. No other customizations may be made to this page.

21.6 Administering the CustomerWise Knowledge Portal

CustomerWise supports four text 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)

21.6.1 Selecting the Knowledge Portal Type

Administrators may choose to build a custom knowledge portal and define its attributes in the Knowledge Portal page in the Customer Web Portal folder.

Administrators may choose between three knowlege portal type options:

• Knowledge search only

• Standard knowledge portal

• Customized knowledge portal

21.6.2 Enabling Knowledge Portal Options

Project administrators may enable four Knowledge Portal options for standard and customized knowledge portals.

• Knowledge Search and Browse

• CustomerWise FAQ

• DevTrack FAQ

• External knowledge integration

If the Knowledge Search Only knowledge portal type was selected in the Knowledge Portal Type area, the options displayed in the Knowledge Portal Option area are read-only and cannot be defined.

21.6.3 Defining a Customized Knowledge Portal

Project administrators may use controls in the Knowledge Portal page in the Customer Web Portal folder to customize the Knowledge Portal.

To define a customized Knowledge Portal:

1Select the Customized Knowledge Portal option in the Knowledge Portal page of the Customer Web Portal folder.

2Open the Knowledge Portal page in the Knowledge View folder.

3Click the Setup button,

The Knowledge Portal configuration page appears.

Administrators may customize the Knowledge Portal:

• Add new - to add a new knowledge portal

• Submit - to save your configuration

• Delete - to delete a knowledge portal

• Preview - to preview a configured knowledge portal

• Access key - Every web portal is associated with a unique access key

• Project for access privilege/Account type - In a knowledge portal, different knowledge folder and different knowledge items are associated with different access privileges. Some knowledge folders belong to a certain project and are not allowed to access from other projects. Different account types have different privileges to access the knowledge items. By using project for access privileges and account types together, you can have a better control of what kinds of knowledge items you want to display on a certain knowledge portal

• Edit method - edit via text control (support plain HTML), or edit via web edit control.

4Click the Knowledge Portal Customization tab to directly edit HTML code of the knowledge portal:

Using the new Knowledge Portal, you will be able to do simple search, advance search, print, or email a certain knowledge item conveniently.

21.7 Defining External Knowledge Integration

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

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

21.8 Backing up the Document Files

E-mail announcements are predefined e-mails that are created in the TechExcel CustomerWise client, and are then delivered to one or multiple customers also through the client. E-mail announcements are very useful to manage e-mail campaigns and other marketing purposes, but can be used effectively in all project types.

In TechExcel CustomerWise project members that have been granted the Can E-mail Blast Knowledge Announcement privilege may create a knowledge announcement in the Knowledge view and blast the customized e-mail to all customers with a single click.

Project administrators may use controls in the E-mail Announcements page of the Knowledge view folder to enable e-mail announcement support and e-mail announcement settings in TechExcel CustomerWise projects. E-mail announcement settings are defined on a work project by work project basis. Administrators may not define e-mail announcements in base projects.

Project administrators may configure e-mail announcement properties using controls in the E-mail Announcement page of the Knowledge view folder.

Note:The TechExcel CustomerWise E-mail Server programs must be installed for this feature to work correctly. The e-mail retrieval service must be installed to process incoming e-mails, and the e-mail notification service must be installed to process outgoing e-mails.

21.9 Administering the TechExcel Search Engine

Administrators may define basic e-mail announcement settings including SMTP outgoing mail server settings, e-mail reply names, and e-mail reply addresses in the E-mail Announcement page of CustomerWise work projects.

Administrators may define the name and e-mail address of the sender of the e-mail. All replies to the e-mail are automatically directed to the administrator-defined reply address.

For example, announcement blast e-mail messages may be sent to customers fromABC Software Newsat the addresssales@abcsoftware.com.

To define e-mail blast announcement mail server:

1Enter a name in the Reply Name field of the E-mail Announcement page.

For example,ABC Software News

2Enter a name in the Reply Name field of the E-mail Announcement page.

For example,sales@abcsoftware.com.

3Define the name of the SMTP server in the Outgoing Mail (SMTP) Server Name field.

Administrators may enter the mail server name or IP address.

4If the mail server requires authentication, select the My Mail Server Requires Authentication check box and enter the user name and password.

The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service.

21.9.1 Installing the CustomerWise Search Engine

Administrators may install the CustomerWise Search Engine to enhance the searching capabilities of project members in CustomerWise projects.

The CustomerWise Search Engine runs as a service and may be managed using the Services manager in Administrative Tools of a Windows operating system.

• The CustomerWise search service must be installed on the machinebeforea project may enable CustomerWise Search Engine support and index the searchable fields in the project.

• The CustomerWise Search Engine should be installed on the same computer as the CustomerWise Document Server.

To install the CustomerWise Search Engine: 

1Run the SearchSetup executable.

The CustomerWise Search Server Installation wizard installs the CustomerWise Search Engine.

2During the installation the administrator must:

• Accept the license agreement.

• Ensure that the CustomerWise Search Engine can connect to the CustomerWise Application Server.

3The TechExcel CustomerWise Search Engine Configuration dialog box appears.

4Define the name of the current CustomerWise Search Engine in the Referred as Service Name field.

Each CustomerWise Search Engine installed in a CustomerWise site may have its own name. Administrators may choose which search engine is used for each CustomerWise project. Multiple projects may use the same search engine. Naming search engines enable administrators to identify search engines in the system.

5Define the location of the index directory.

6Click the OK button.

7Click the Finish button.

21.9.2 Defining Search Engine Settings

Administrators may enable CustomerWise Search Engine support, select an appropriate CustomerWise Search Engine for a project, and index the memo fields in that project using controls in the Search Engine Setting page.

To define CustomerWise Search Engine settings:

1Select the Search Engine Setting page in the KnowledgeWise Feature folder of the CustomerWise Admin Tree window.

2Select the Enable Knowledge Fields Search via Search Engine check box.

3Click the Select a Search Engine button.

The Select a Search Engine dialog box appears.

4Select a search engine option in the Search Engine list.

Administrators may install multiple CustomerWise Search Engines in their CustomerWise site. Each CustomerWise project may have its own Search Engine or multiple projects may share the same CustomerWise Search Engine.

5Click the Select button.

The Select a Search Engine dialog box closes.

21.9.3 Indexing the CustomerWise Search Engine

Administrators may enable CustomerWise Search Engine support, select an appropriate CustomerWise Search Engine for a project, and index the memo fields in that project using controls in the CustomerWise Search Engine page.

The search engine performs search indexing on memo fields. The first time an administrator indexes a large database, the process may take hours. Subsequent indexing of project memo fields is only performed on newly added records and the execution time is significantly reduced.

To index project memo fields: 

1Select the Search Engine page in the Enterprise Edition Features folder of the CustomerWise Admin Tree window.

2Click the Index Now button.

The Initialization of Search Index dialog box appears.

3Click the Start button.

The Initialization of Search Index dialog box closes.

The Current Status control displays the current status of the indexing process. When indexing is complete the Current Status control displays the text Indexing process finished.

21.10 Administering Knowledge Recommendations

Project administrators may define rules that ensure that customers to not receive multiple copies of the same e-mail blast announcement with a set time period.

Depending on the e-mail blast announcement rules defined by project members in the CustomerWise clients, customers may be schedule to receive e-mail announcements based on several different triggers. For example, a contact may receive an e-mail announcement for having downloaded a particular product or because their company owns a particular asset.

The Time Period (Days) control in the E-mail Announcement page enable administrators to ensure that the same e-mail is not delivered during the time period assigned by the administrator.

21.10.1 Expert keywords and expert keyword points

KnowledgeWise increases the accessibility of the knowledge items stored in project knoweldge bases with CustomerWise knowledge recommendation.

CustomerWise may recommend knowledge items to CustomerWise users (customers and project members) based on three different factors: the expert points assigned to user-defined keywords (expert keywords) that are assigned to knowledge items, user-defined relevance rankings (customer ranking pointsandteam member ranking points), and system-generatedclicking points.

CustomerWise weighs the relative weight of these three factors to determine which knowledge items are recommended to project members and cusotmers based on the keywords they used for their knowledge search. Administrators may configure CustomerWise knowledge recommendation engine to determine the relative weight given to each factor.

knowledge recommendation is an optional feature that must be enabled by a project administrator in the CustomerWise Admin client. CustomerWise may automatically recommend knowledge items to customers and to project members.

• Knowledge items may be recommended to customers searching for knowledge items in the Customer Web Portal.

• Knowledge items may be recommended to project members submitting incidents through email.

The relevance of knowledge items to knowledge searches is based on the keywords that the customer or project member defines for that search. Three factors determine the relevance of those keywords to knowledge items:

• Expert keywords and expert keyword points

• Customer and team member ranking points

• Clicking points

 Chapter 22 Product Catalog Administration

22.1 Understanding Product Catalog Administration

TechExcel CustomerWise, HelpDesk, and AssetWise each use an administrator-defined product catalog 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 CustomerWise the product catalog defines company products and assets for sales and asset management purposes. CustomerWise sales and asset management projects may share the same product catalog: the products sold to customers and tracked in SalesWise may automatically become the customer assets that are managed in AssetWise.

Note:In this document all administrator-defined products and assets.

Every asset is based on an administrator-defend asset template.Project administrators may configure the product catalog in three CustomerWise projects:

• Base projects

• Sales projects

• Support projects

Note:The CustomerWise Admin client displays a Product Catalog folder for each project. The product catalog is shared across all CustomerWise projects. Any customization made in the sales project is manifested in the support project and vice versa. The Product Catalog folder is not displayed in marketing projects.

22.1.1 Understanding the Product Catalog

The product catalog 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.

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 CustomerWise and AssetWise projects.

The product catalog may display four system pages and up to ten custom pages. Administrators may customize each of these pages by adding, removing, or customizing system-defined and custom controls.

• The Description tab enables 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.

• The Value tab displays 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.

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

• The Subassets page enables administrators to define any number of subassets for each asset template. All subassets are defined at the template level.

• The custom pages enables administrators to create custom data-entry controls to track administrator-defined asset properties. Administrators may add up to ten custom pages to the client applications.

22.1.2 Understanding Asset Definition and GUI Customization

Administrators may add, remove, or customize system-defined and custom controls to the product catalog at three different levels: the system level, the category level, and the template level.

Product catalog 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 properties are 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 and cannot be overridden by category-level definitions or template-level definitions. System-level properties are generally rare.

• Category-level asset properties represent properties that are shared 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 properties represent 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 CustomerWise. 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. Administrators may make customizations to the product catalog at each level. But not every customization can be made at every level:

Table 22-1: Asset Description Page Customizations

22.1.3 Understanding System-Level Asset Properties

System-level asset properties are shared by every asset managed in a 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.

22.1.4 Understanding Category-Level Asset Properties

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

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 product catalog 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 22-1: Asset Categories and Asset Templates

Every asset in the product catalog 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. 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.

22.1.5 Understanding Template-Level Properties

Template-level asset properties represent the properties of the actual assets managed in the product catalog. 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 CustomerWise or AssetWise project is based on an administrator-defined asset template.

Asset templates inherit customizations made to the product catalog at the parent category level. Administrators must define asset categories before they can define the child asset templates.

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

Two pages in the product catalog may only be defined at the template level: subassets and asset breakdowns are always specific to each asset template.

• The Subassets page enables administrators to define any number of subassets for each asset template. Administratrix may only define subassets at the template level.

• The Breakdown page enables administrators to define any number of breakdowns for each asset template. Administratrix may only define breakdowns at the template level.

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.

22.1.6 Understanding Product Catalogs in Support Projects

Project administrators may define the product catalog using controls in the Product Catalog folder of CustomerWise support projects.

The Product Catalog folder in support project displays seven system pages that enable the administrator to customize the product catalog for the current CustomerWise site.

Product lines cannot be customized in support projects. The Support Line system page is only displayed in the Product Catalog folder of base and sales projects.

Note:The product catalog is shared by every project in a CustomerWise site. Customizations made to the product catalog in a support project are manifested in every sales project that shares the same base project, as well as the base project itself.

22.1.7 Understanding Product Catalogs in Sales Projects

Sales projects may use the product catalog to display assets on sales quotes and sales orders.: If the Annual Service Agreement With Asset Integration option is enabled, a sales purchase can automatically generate the following operations:

• Products purchased become customer assets.

• Support plans purchased become service agreements and are automatically displayed in the support project.

The Annual Service Agreement with Asset Integration option may be selected as the service type for service agreement templates. The Annual Service Agreement with Asset Integration option is used for plans that are based on annual support arrangement that is directly related to the assets purchased or owned by a company, including hardware and software licenses. The AssetWise add-on module must be purchased for this feature to work.

22.2 Customizing the Description Page

The product catalog 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.

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 CustomerWise and AssetWise projects.

The product catalog may display four system pages and up to ten custom pages. Administrators may customize each of these pages by adding, removing, or customizing system-defined and custom controls.

• The Description tab enables 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.

• The Value tab displays 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.

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

• The Subassets page enables administrators to define any number of subassets for each asset template. All subassets are defined at the template level.

• The custom pages enables administrators to create custom data-entry controls to track administrator-defined asset properties. Administrators may add up to ten custom pages to the client applications.

22.2.1 Managing System Controls in the Description Page

System controlsare system-defined controls that have a designated use in the project and are integrated with other TechExcel CustomerWise or AssetWise features. Project administrators may add, remove, or customize ten system controls in the Description page of the product catalog.

All customizations made to Description page controls at the system level are inherited by all asset categories and asset templates.

• System controls added to the Description page at the system level may not be removed at the category or template level.

• System controls removed from the Description page at the system level may not be added at the category or template level.

Administrators may make only limited customizations to system controls. Every system control displayed in the Description page belongs to the dropdown list control type. The values displayed as options in these system controls are drawn from the CustomerWise database and cannot be customized by the administrator.

Administrators may customize the field labels associated with each control and define the control as mandatory, but cannot change the content tracked in those controls.

The ten predefined system controls are:

• The Name text field control

• The Description memo field control

• The Asset No. text field control

• The Serial No. text field control

• The Edition dropdown list control

• The Part No. dropdown list control

• The Location dropdown list control

• The Unit Price dropdown list control

• The Inventory Location dropdown list control

• The Breakdown dropdown list control

• The Inventory Location control

22.2.2 Managing Custom Controls in the Description Page

Custom controlsare administrator-defined controls that are fully customizable. Administrators may define appropriate field labels, control types, and defined values for each control.

Administrators may add up to twelve custom controls to the Description page. Custom controls may be added to the Description page at the system level, category level, or template level. Custom controls defined at the system level are inherited by all asset categories and asset templates.

Administrator-defined customizations include:

• Defining the field label titles for controls

• Choosing an control type for the control.

• Defining whether a control is mandatory or visible in the client.

• Defining default values for controls

• Defining selectable options displayed in dropdown list controls

For step-by-step instructions see See “Adding Asset Definition Custom Controls”.

22.2.3 Defining Usage And Quantity Tracking

Administrators may classify assets by their tracking requirements in the Description page.

The Track Usage and Quantity controls in the template-level Description system page enables administrators to choose how that asset is tracked in the project: as an individual item, by is use and quantity, or not at all.

Figure 22-2: Track Usage and Quantity Controls

Administrators may choose one of three options for each asset template. Asset tracking requirements may be defined at thetemplate level only.

• The Track Individual Asset Item option is used for assets that are tracked by a model number as well as a manufacturer serial number. For example, notebook computers and cellular phones.

• The Track Usage and Quantity option is used for assets that are tracked only by an asset number and quantity, but not by a manufacturer serial number. For example, tracking the usage of software with a fixed number of licenses.

• The No Track option is used for assets that are tracked by association with other assets, but not tracked individually. For example, screws for a notebook computer.

22.3 Customizing the Value Page

Administrators may add, remove, or customize system-defined and custom controls to the product catalog at three different levels: the system level, the category level, and the template level.

Product catalog 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 properties are 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 and cannot be overridden by category-level definitions or template-level definitions. System-level properties are generally rare.

• Category-level asset properties represent properties that are shared 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 properties represent 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 CustomerWise. 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. Administrators may make customizations to the product catalog at each level. But not every customization can be made at every level:

Table 22-1: Asset Description Page Customizations

22.4 Customizing the Support Plan Page

System-level asset properties are shared by every asset managed in a 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.

22.5 Managing Asset Custom Pages

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

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 product catalog 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 22-1: Asset Categories and Asset Templates

Every asset in the product catalog 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. 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.

22.5.1 Adding and Removing Custom Pages

To add or remove custom pages:

Administrators may choose the number of custom pages displayed in product catalog by selecting an option from the Number of Custom Pages dropdown list in the General Settings page of the Product Catalog folder.

Administrators may add up to ten custom pages.

Custom pages are only displayed in the product catalog if the administrator has defined them as visible in the Specify Custom Page Captions and Visibilities manager.

22.5.2 Adding Custom Controls to Custom Pages

Administrators may add up to twelve custom controls to each custom page. All fields can be made visible and mandatory on submission.

• The first eight fields are fully customizable like the fully customizable fields on the Description page.

• The last four custom fields are a date/time fields. Specify if each field will show the date only, or the date and time.

22.5.3 Adding Asset Definition Custom Controls

Administrators may add and define custom controls to system pages and custom pages using the Add Custom Control manager.

Figure 22-3: Add Custom Field Manager

The Add Custom Control manager enables administrators to define seven different properties for each custom control:

• The Field Label property

• The Field Type property

• The Visible property

• The Mandatory property

• The If Unique property

• The Field Level property

22.5.3.1 The Field Type attribute

The Field Type attribute enables the administrator to define the control type of the custom control. The control type of the data-entry control determines the how the asset property represented in that control is defined and tracked. Administrators may choose between eight different control types.

• Check Box control type

• Combo Box control type

• Date - Time control type

• Double Edit Box control type

• Drop Down List control type

• Integer Edit Box control type

• Multiple Selection control type

• Text Edit Box control type

22.5.3.2 Field Level attribute

The Field Level dropdown list is read-only in the UI Field manager.

Custom controls may be added to the Description system page and all custom pages at the system-level, category-level, and template-level. The Field Level dropdown list displays the level (system, category, or template) at which the selected custom control was added to the page.

• Custom controls defined at the system level are fixed for all categories and inherited by all assets and products managed in the project.

• Custom controls defined at the category level are inherited by every asset template that belongs to that category.

• 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.

For more information see See “Understanding Asset Definition and GUI Customization”

22.6 Managing Asset Template Subassets

Template-level asset properties represent the properties of the actual assets managed in the product catalog. 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 CustomerWise or AssetWise project is based on an administrator-defined asset template.

Asset templates inherit customizations made to the product catalog at the parent category level. Administrators must define asset categories before they can define the child asset templates.

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

Two pages in the product catalog may only be defined at the template level: subassets and asset breakdowns are always specific to each asset template.

• The Subassets page enables administrators to define any number of subassets for each asset template. Administratrix may only define subassets at the template level.

• The Breakdown page enables administrators to define any number of breakdowns for each asset template. Administratrix may only define breakdowns at the template level.

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.

22.7 Managing Asset Template Breakdowns

Project administrators may define the product catalog using controls in the Product Catalog folder of CustomerWise support projects.

The Product Catalog folder in support project displays seven system pages that enable the administrator to customize the product catalog for the current CustomerWise site.

Product lines cannot be customized in support projects. The Support Line system page is only displayed in the Product Catalog folder of base and sales projects.

Note:The product catalog is shared by every project in a CustomerWise site. Customizations made to the product catalog in a support project are manifested in every sales project that shares the same base project, as well as the base project itself.

22.8 Managing Product Upgrade Rules in the Product Catalog

Sales projects may use the product catalog to display assets on sales quotes and sales orders.: If the Annual Service Agreement With Asset Integration option is enabled, a sales purchase can automatically generate the following operations:

• Products purchased become customer assets.

• Support plans purchased become service agreements and are automatically displayed in the support project.

The Annual Service Agreement with Asset Integration option may be selected as the service type for service agreement templates. The Annual Service Agreement with Asset Integration option is used for plans that are based on annual support arrangement that is directly related to the assets purchased or owned by a company, including hardware and software licenses. The AssetWise add-on module must be purchased for this feature to work.

22.8.1 Defining Asset Upgrade Rules

Project administrators may define new asset upgrade rule properties in the Asset Template Upgrade manager

Figure 22-5: Asset Template Upgrade Manager

Every asset upgrade rule is defined by eight different properties:

• The Upgrade To property defines the asset template that defines the upgraded asset. Administrators define the upgrade asset template by selecting an asset template in the Asset Template tree window.

• The Track Method represents the tracking method defined for the current asset template. The tracking method for each asset template is defined in the

Description system page. For more information see See “Defining Usage And Quantity Tracking” on page 415.

• The Upgrade Name defines the name of the upgrade rule. Each asset template may be associated with multiple upgrade rules. A unique and descriptive name enables administrators to distinguish between these rules.

• The Note memo field control

• The Upgrade Method dropdown list

• The Old Asset Option dropdown list

• The Old Asset Must Exist In Order To Perform This Upgrade check box

• The Update Asset Properties Based On Default Values Of The New Template check box

• The Upgrade From control Click the Add button to add upgrade rules for the highlighted asset.

To upgrade an asset template:

1Select an asset template in the Asset Template Tree window of the Product Upgrade page.

The asset template selected represents the asset template that defines the new, upgraded asset.

2Click the Add button.

The Asset Template Upgrade manager appears,

3Define a unique name and add a brief description of the upgrade rule.

• The Upgrade Name control enables the administrator to define a unique name for the upgrade rule.

• The Note control enables the administrator to add a brief description of the upgrade rule and how it is used in the project. Every asset template may be associated with multiple upgrade rules.

4Select an option from the Upgrade Method control.

Administrators may choose between three methods for upgrading assets:

• Convert the old asset to the new asset

• Create a new asset with the same asset number

• Create a new asset with a new asset number

5Select an option from Old Asset Option control.

Administrators may choose between three options for handing old assets:

• Delete the old asset

• Set the old asset as inactive

• Keep the old asset active

6To ensure that the upgrade rule is only used to upgrade existing assets, select the Old Asset Must Exist In Order To Perform This Upgrade control.

7To automatically update asset properties based, select the Update Asset Properties Based On Default Values Of The New Template control

8To associate one or more asset templates with the upgrade rule, click the Add button and define the Upgrade From asset template.

The asset templates added to the Upgrade From list represent the asset templates that defined the original asset.

9Click the OK button.

The Asset Template Upgrade manager closes

22.8.2 Editing Asset Upgrade Rules

To edit or delete asset upgrades, highlight the upgrade rule and click the Edit or Delete buttons..

22.9 Managing Product Lines

In the AssetWise and CustomerWise clients project members use the Description page to define, view, and manage asset properties. Administrators may customize the data-entry controls displayed in the Description page to track data that represents the assets managed in the project.

Administrators may customize the Description page at the system level, category level, and template level. The customizations that administrators may make to the Description page are different at each level.

Project administrators may make the following customizations to the Description page.

• Add or Delete system controls to the Description page. (System-level only)

• Add custom controls to Description page.

• Customize system control labels (system level only)

• Define system controls as mandatory or optional (system level only)

• Define system controls as visible or invisible

• Define system control default values

• Define usage and quantity tracking settings.

• Define Asset No. system control default values (template level only)

• Define Asset No. system control values types and prefixes (template level only)

The primary customization that administrators may make to the Description page is to addsystem controlsorcustom controls. The Description page may display ten system controls and up to twelve custom controls:

•System controlsare system-defined controls that have a designated use in CustomerWise and AssetWise. Administrators may make limited customizations to these controls. The system control include the Name, Description, Asset No., Serial No., Edition, Part No., Location, Unit Price, Inventory Location, and Breakdown controls. System controls be added or deleted to the Description page at the system level. These controls cannot be added or deleted at the category or template level.

•Custom controlsare administrator-defined custom controls that may be added to the page. Administrators may define appropriate field labels, control types, and defined values for each control.

22.9.1 Adding and Defining Product Lines

To add and define a product line:

1Click the Add button in the Product Line page of the Product Catalog in a base project.

2The Product Line dialog box appears.

3Define the name of the product line, provide a brief description, and click the OK button.

The name and description of the product line may be edited in the General tab.

4Define a short name for the product line in the Short Name control.

The product line short name is displayed in list column headers.

5Select a default sales template in the Sales Template dropdown list.

22.9.2 Selecting Applicable Products

To select applicable products: 

1Select a product line in the Sales Product Lines list.

2Click the Applicable Products tab.

3Select an option from the Primary Product Line dropdown list.

4Select a product in the Product list.

If the select product has been associated with more than one product line, the Message Box dialog box appears. The dialog box displays all of the product lines that the selected product has been assigned to.

Note:TechExcel recommends one product is assigned to one product line. Assigning one item to only one product line may help you to achieve better accounting integration, which you may need now or in the future.

5Select the OK button.

22.10 Managing Purchase Price Schedules

System controlsare system-defined controls that have a designated use in the project and are integrated with other TechExcel CustomerWise or AssetWise features. Project administrators may add, remove, or customize ten system controls in the Description page of the product catalog.

All customizations made to Description page controls at the system level are inherited by all asset categories and asset templates.

• System controls added to the Description page at the system level may not be removed at the category or template level.

• System controls removed from the Description page at the system level may not be added at the category or template level.

Administrators may make only limited customizations to system controls. Every system control displayed in the Description page belongs to the dropdown list control type. The values displayed as options in these system controls are drawn from the CustomerWise database and cannot be customized by the administrator.

Administrators may customize the field labels associated with each control and define the control as mandatory, but cannot change the content tracked in those controls.

The ten predefined system controls are:

• The Name text field control

• The Description memo field control

• The Asset No. text field control

• The Serial No. text field control

• The Edition dropdown list control

• The Part No. dropdown list control

• The Location dropdown list control

• The Unit Price dropdown list control

• The Inventory Location dropdown list control

• The Breakdown dropdown list control

• The Inventory Location control

22.10.1 Adding Purchase Price Schedules

To add a purchase price schedule:

1Click the Add button in the Purchase Price Schedule page of the Product Catalog in a base project.

The Purchase Price Schedule dialog box appears.

2Define the name of the price schedule.

3To copy settings from a previously defined price schedule, select the Copy the Purchase Price Schedule check box and select an option from the dropdown list control.

4To copy only a percentage of the selected price schedule, enter a number in the Percentage of the Price to be Applied control.

5Define the applicable product lines.

Administrators may ensure that certain price schedules are only available for certain product lines.

• To select all product lines, select the Select All Product Lines check box.

• To select one or more product lines, select the check boxes in the Product Line list. The price schedule is only applicable to the selected product lines.

22.10.2 Defining Purchase Templates

To add a purchase price schedule:

1Click the Add button in the Purchase Price Schedule page of the Product Catalog in a base project.

The Purchase Price Schedule dialog box appears.

2Define the name of the price schedule.

3To copy settings from a previously defined price schedule, select the Copy the Purchase Price Schedule check box and select an option from the dropdown list control.

4To copy only a percentage of the selected price schedule, enter a number in the Percentage of the Price to be Applied control.

5Define the applicable product lines.

Administrators may ensure that certain price schedules are only available for certain product lines.

• To select all product lines, select the Select All Product Lines check box.

• To select one or more product lines, select the check boxes in the Product Line list. The price schedule is only applicable to the selected product lines.

 Chapter 23 Service Agreement Administration

23.1 Administrating Service Agreements

In real world business environments, support is often a very complicated aspect of the customer relationship. Different customers may receive different levels of service, guaranteed response times may be different based on the incident type, the service may be charged to the customer per the incident or per the hour.

Typically, the services delivered to customers are based on aservice agreementor aservice level agreement. Each service agreements defines the type of service the customer is entitled to and also include a predefined support cost calculation and corresponding invoice methods. Customers may be assigned multiple service agreements across multiple product lines.

Using controls in the Service Agreement folder of the CustomerWise Admin client, project administrators may defineservice agreement templatesto represent these contracts in the CustomerWise system. Templates enable the administrator to define a template that represents applicable properties. Project members may quickly define particular service agreements and service level agreement for customers by using and adopting administrator-defined templates.

Note:Administrators must define service agreement templates before they can define service level templates.

All service agreements are tracked in CustomerWise projects using the Service Agreement Manager. Service Agreement Manager is a comprehensive service level agreement solution that enables businesses to easily configure, sell, and administer the service plans that are available to customers.

Service Agreement Manager tracks all service plan charges, generates appropriate invoices, and tracks all payment and renewal history. It also allows one customer to have 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 this time is exceeded.

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

• Based on the incident properties, TechExcel CustomerWise 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.

Note:To define and manage service agreements in TechExcel CustomerWise projects requires the purchase of TechExcel Service Agreement Manager.

23.2 Defining Service Agreement General Properties

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

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

• The Service Agreement page is displayed in the Customer view of the CustomerWise clients applications.

• 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 sales or support project. Service agreements are not supported in marketing projects. The Service Agreement folder is not displayed in the Admin tree window of customer base projects.

23.2.1 Enabling Service Agreement Support

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

Service agreement support cannot be enabled in CustomerWise marketing projects.

23.2.2 Defining Service Agreement Privileges

Sales and service project members may manage service agreements in the Service Agreement page of the Customer detail window in the CustomerWise clients.

Project administrators may determine which project members are eligible to view, assign, and edit service agreements by granting service agreement privileges to project account types in the General Settings page of the Service Agreement folder in the CustomerWise Admin client.

Figure 23-1: Service Agreement General Settings Page

Project administrators grant service agreement privileges to account types rather than to project members directly. Project members inherit service agreement privileges from the account type assigned to them in a CustomerWise project.

Sales and support project administrators must define service agreement privileges separately for their projects.

Project administrators may grant six different privileges to each account type in their project.

Table 23-1: Service Template Privileges

23.3 Managing Support Schedules

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

Service agreement support cannot be enabled in CustomerWise marketing projects.

23.3.1 Adding Support Schedules

To add a support schedule:

1Click the Add button.

The Add New Support Schedule dialog box appears.

2Define the name, time zone, and brief description for the support schedule.

3Click the OK button.

The Add New Support Schedule dialog box closes.

23.3.2 Deleting Support Schedules

To delete a support schedule:

1Select a support schedule in the Support Schedules list of the Company Support Schedule page in the Service Agreement folder.

2Click the Delete button.

A warning dialog box appears.

3Click the Yes button.

The support schedule is deleted.

23.3.3 Defining Support Schedule Support Times

Support times represent companybusiness hours, the days and time periods during which customers may expect services based on their service agreement.

Figure 23-3: Company Support Schedule Page

The support periods and break periods are expressed in the hours for the time zone that is applicable to the support schedule.

To define support schedule support times:

1Select a support schedule in the Support Schedules list of the Company Support Schedule page in the Service Agreement folder.

2Select a day of the week in the Support Time tab.

3Click the Edit button.

The Support Schedule Settings dialog box appears.

4Select an option from the Support Schedule Settings dropdown list.

The Support Schedule Settings dropdown list displays three options:

• The Limited Hours Support on this Day option

• The No Support on this Day option

• The 24 Hours Support on this Day option

5Select the starting and ending times in Work Period area.

6Define the break in the Break area.

7To apply the current settings to every day of the week, select the Apply these Settings to other Working Days check box.

8Click the OK button.

The Support Schedule Settings dialog box closes.

23.3.4 Managing Support Schedule Holidays

Schedule holidays represent the days and time periods during which customers cannot expect services based on their service agreement.

Project administrators may define the name, date, and the amount of time off for the holiday in the Holidays tab of the Company Support Schedule page in the Service Agreement folder in the CustomerWise Admin client.

Figure 23-4: Holidays Tab in Company Support Schedule Page

To add a holiday:

1Select a support schedule in the Support Schedules list of the Company Support Schedule page in the Service Agreement folder.

2Click the Add button in the Holiday tab.

The Support Holiday Settings dialog box appears.

3Select an option from the Support Holiday Settings dropdown list.

4Define the holiday name, date, and the number of days off for the holiday.

5To define the number of hours off for partial holidays, select the beginning and ending times for the work day in the Start Time and End Time dropdown list.

23.4 Managing Shipping and Payment Methods in Service Agreements

Sales and service project members may manage service agreements in the Service Agreement page of the Customer detail window in the CustomerWise clients.

Project administrators may determine which project members are eligible to view, assign, and edit service agreements by granting service agreement privileges to project account types in the General Settings page of the Service Agreement folder in the CustomerWise Admin client.

Figure 23-1: Service Agreement General Settings Page

Project administrators grant service agreement privileges to account types rather than to project members directly. Project members inherit service agreement privileges from the account type assigned to them in a CustomerWise project.

Sales and support project administrators must define service agreement privileges separately for their projects.

Project administrators may grant six different privileges to each account type in their project.

Table 23-1: Service Template Privileges

23.4.1 Defining Service Agreement Shipping Methods

Project administrators may define shipping methods and shipping rates in the Payment/Shipping page in the Service Agreement folder.

Figure 23-5: Shipping Methods Tab in the Payment/Shipping Page

Shipping methods defined in the Shipping Methods tab may be added to sales quotes and sales orders and appropriate rates are reflected in the sales quote.

Project administrators must define shipping methods before they can define service templates or sales templates.

To define shipping methods:

1Click the New button in the Shipping Methods tab of the Payment/Shipping page.

The Shipping Methods dialog box appears.

2Enter the name of the shipping method in the Method control.

3Enter the cost of the shipping method in the Cost control.

4Click the OK button.

23.4.2 Defining Service Agreement Payment Methods

Project administrators may define the payment methods that are accepted in the sales project the Service Agreement folder.

Figure 23-6: Payment Methods Tab in the Payment/Shipping Page

Typical payment methods includeVISA, MasterCard, Lease, Cash,orCheck. Project administrators must define payment terms before they can define service templates sales templates in a project. • Payment methods defined in the Payment Methods tab are presented as options in the sales quotes and sales orders created in the CustomerWise client.

To define payment methods:

1Click the New button in the Payment Methods tab of the Payment/Shipping page.

The Payment Methods dialog box appears.

2Enter the name of the payment method in the Methods control.

3Click the OK button.

23.4.3 Defining Service Agreement Payment Terms

Project administrators may define the various payment terms that are available to customers in the Payment Terms tab of he Payment/Shipping page in the Service Agreement folder.

Figure 23-7: Payment Terms Tab in the Payment/Shipping Page

Payment term properties are used to autopopulate the payment due date on service agreement invoices.

Note:If you are also using SalesWise, the payment terms defined here are reflected in sales settings as well on the Shipping/Payment page located in the Sales Settings folder.

Payment terms consist of five basic properties: payment term name, activity status, net due, discount percents, discount eligibility period.

Project administrators must define payment terms before they can define sales templates in a sales project.

To define payment methods:

1Click the New button in the Payment Terms tab of the Payment/Shipping page.

The Sales Payment Term dialog box appears.

2Define a unique name for the payment term in the Payment Term control.

3To define the payment term as active, select the Term is Active check box.

Only active terms may be applied to sales quotes or sales orders. Inactive payment terms are not available in the TechExcel CustomerWise client.

4Define the net due date in the Net Due In control.

The number of days from the invoice date before payment is due.

5Define the percentage of the discount offered for early payment in the Discount percentage control.

6Define the number of days in which payment must be received to receive a percentage discount in the Discount if Paid Within control.

7Click the OK button.

The Sales Payment Term dialog box closes.

23.5 Defining Service Agreement Statuses

A support schedule defines the dates, days, and times that support services are offered to customers.

TechExcel CustomerWise enables project administrators to define multiple support schedules within each sales project or support project to identify the different levels of service that may be offered to customers based on their support plan.

Each support schedule is distinguished by its time zone, support times, and its holidays:

• Time zones settings define the location of the team members responsible for delivering services to customers. The time zone selected determines how the dates, days, and business hours defined in the support schedule are represented to the customer.

• Support times represent companybusiness hours, the days and time periods during which customers may expect services based on their service agreement.

• Schedule holidays represent the days and time periods during which customerscannotexpect services based on their service agreement.

Project administrators may create, edit, and delete support schedules in the Company Support Schedule page of the Service Agreement folder in the CustomerWise Admin client.

Figure 23-2: Company Support Schedule Page

The Company Support Schedule page display three tabs:

• The General tab

• The Support Time tab

• The Holidays tab

23.5.1 Adding Service Agreement Statuses

To add a service agreement status:

1Click the Add button in the Service Agreement Status page.

The Status dialog box appears.

2Define the name of the status.

3Click the OK button.

The Status dialog box closes.

23.5.2 Defining Service Agreement Status Actions

To define a service agreement status:

1Select a service agreement status in the Status list of the Service Agreement Status page.

2Make a service agreement status active or inactive in the General tab.

3Define properties in the General tab. Administrators may define basic service agreement status properties in the General tab.

• Define a unique name for the service agreement status in the Status Name edit box control.

• Define a brief description of the service agreement status.

4Select the Action tab.

5To display the message to the customer and support engineer, select the Display Message to Customer and Support Engineer check box

6Define the message displayed to the customer and support engineer.

• Customer message

• Support engineer message

23.6 Managing Service Agreement Templates

To add a support schedule:

1Click the Add button.

The Add New Support Schedule dialog box appears.

2Define the name, time zone, and brief description for the support schedule.

3Click the OK button.

The Add New Support Schedule dialog box closes.

23.6.1 Creating Service Agreement Templates

Project administrators may create, delete, and define service agreement templates in the Service Agreement Template page of the Service Agreement folder in the CustomerWise Admin client.

Each service agreement template is identified by its service agreement type and an applicable support project.

The service agreement type determines how the service agreement that are based on that template are managed in CustomerWise projects.

• The Annual Service Agreement service agreement type represents plans that are used for software trial periods and free support.

• The Per Incident Service Agreement service agreement type represents plans that are based on a per incident basis.

• The Free Service Agreement service agreement type represents plans that are based on annual support arrangements.

• The Annual Service Agreement with Asset Integration service agreement type represents plans that are based on annual support arrangements directly related to the assets purchased or owned by a company, including hardware and software licenses. Requires the purchase of TechExcel AssetWise.

To create service agreement templates:

1Click the New button.

2Define a unique name for the service agreement template in the Name edit box control.

3Define a brief description of the service agreement template in the Description control.

4Select a support type from the Support Type dropdown list control.

The Support Type dropdown list displays five different options:

• Annual Service Agreement

• Per Incident Service Agreement

• Free Service Agreement

• Annual Service Agreement with Asset Integration

5Select an applicable support project from the Support Project dropdown list control.

6Click the OK button.

23.6.2 Deleting Service Agreement Templates

To delete a service agreement template, highlight the template and click the Delete button.

23.6.3 Defining General Service Agreement Template Settings

Project administrators may define general settings for service agreement templates using controls in the General tab of the Service Agreement page in the Service Agreement Settings folder in the CustomerWise Admin client.

General Settings tab enables project administrators to general service agreement template properties for the service agreement template.

To create service agreement templates:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the General tab.

3Define a unique name for the service agreement template in the Name edit box control.

4Define a brief description of the service agreement template in the Description control.

5Select a support type from the Support Type dropdown list control.

The Support Type dropdown list displays five different options:

• Duration (days) – the default duration of the plan.

• Grace days – the number of days support is provided after the plan is expired.

• Payment net term – the number of days before payment of the invoice is due.

6Select an option from the Default Status dropdown list control.

The Default Status dropdown list control displays administrator-defined service agreement statuses. Project administrators may define service agreement statuses in the Service Agreement Status page of the Service Agreement folder.

7Select an option from the Support Schedule dropdown list control.

The Support Schedule dropdown list control displays administrator-defined support schedules. Project administrators may define support schedules in the Company Support Schedule page of the Service Agreement folder. For more information see “Managing Support Schedules”.

8Define the response time.

The response time defines the number of hours and minutes in which project members must respond to an incident in the selected support plan.

• Response Hours

• Response Minutes

9Define the resolve time.

The resolve time defines the number of hours and minutes in which incidents must be resolved in the selected support plan.

• Resolve Hours

• Resolve Minutes

10Define the Support Plan Identifier in the Support Plan Identifier edit box control.

23.6.4 Managing Service Agreement Pricing

Project administrators may define service agreement pricing in the Pricing tab in the Service Agreement Template page of the Service Agreement folder in the CustomerWise Admin client.

Figure 23-9: Pricing Tab the Service Agreement Template Page

To define service pricing in service agreement templates:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the Pricing tab.

3To define the services covered by the service agreement template as taxable, select the This Support Plan Is Taxable check box control.

4Select an administrator-defined product line in the Product Line dropdown list control.

The Product Line dropdown list control displays administrator-defined product lines. The product line selected determines which products may be defined as applicable to the service agreement template.

Project administrators may define product lines in the Product Line page of the Product Catalog folder or the Product Line page of the Service Settings (CustomerWise) folder. For more information see “Managing Product Lines”.

5Select a system-defined cost method in the Cost Method dropdown list control.

The Cost Method dropdown list control displays three system-defined methods for determining the price of the products covered in the service agreement template.

• Percentage Based on Sales Price

• Purchase Price

• Percentage Based on Fixed Support Price

6Select a system-defined quantity calculation methods in the Quantity Calculation Method dropdown list control.

The Quantity Calculation Method dropdown list control displays two system-defined methods for calculating the quantity of products covered in the service agreement template.

• Accumulate

• Not accumulate

7To use the same expiration date for all products covered by the service agreement, select the Enforce Same Plan Expiration Data for all Products check box control.

8To use the same cost percentage for all products covered by the service agreement, select the Enforce Same Support Cost Percentage for all Products check box control and enter a number in the Percentage edit box control.

9Select one or more product check boxes in the Applicable Products list.

The Applicable Products list displays products belonging to the product line selected for the service agreement template.

A black check mark in the check box control indicates that a product is applicable to the current service agreement template, and that service agreements based on this template may cover the selected products.

23.6.5 Defining the Price of Products Applicable to Service Templates

Project administrators may define the price of products defined as applicable to a service agreement template in the Service Agreement Template page of the Service Agreement folder in the CustomerWise Admin client.

To define the price of applicable products:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the Pricing tab.

3Select a product in the Applicable Products list.

4Click the Define Price button.

The Product Price dialog box appears.

5Define the product as applicable or non-applicable to the service agreement template.

• To define the product as applicable to a service agreement template, select the Is Applicable Product for this Support Plan check box control.

• To define the product as non-applicable to a service agreement template, deselect the Is Applicable Product for this Support Plan check box control.

6Define how the support costs for the selected product are calculated in the Support Cost area of the Product Price dialog box.

• To calculate support costs based on a percentage of the product cost, select the Percentage radio button control and enter a number in the Percentage edit box control.

• To calculate support costs based on a fixed price, select the Fixed Price radio button control and enter a number in the Fixed Price edit box control.

Note:If the Enforce Same Support Cost Percentage for all Products check box is selected in the Pricing tab of the Service Agreement Template page, the Percentage edit box is defined as a read-only control.

7To enable volume pricing, select the Enable Volume Pricing check box control.

8Click the OK button.

23.6.6 Setting the Price of Products Applicable to Service Templates

Project administrators may set the price of products defined as applicable to a service agreement template in the Service Agreement Template page of the Service Agreement folder in the CustomerWise Admin client.

To set the price of applicable products:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the Pricing tab.

3Select a product in the Applicable Products list.

4Click the Set Price button.

Note:If the Enforce Same Support Cost Percentage for all Products check box is selected in the Pricing tab of the Service Agreement Template page, the Set Price button is grayed out and cannot be selected.

The Set Price From dialog box appears.

5Select an administrator-defined service agreement template in the Service Agreement Template dropdown list control.

The Service Agreement Template dropdown list displays administrator-defined service agreement templates. Project administrators may define service agreement templates in the Service Agreement Template page. For more information see “Creating Service Agreement Templates”.

6Enter a number in the Percentage to be Applied edit box control.

7Click the OK button.

23.6.7 Defining Service Agreement Upgrade Costs

Project administrators may define the costs associated with upgrading service agreements using controls in the Service Agreement Template page.

To define service agreement upgrade costs:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the Pricing tab.

3Select a product in the Applicable Products list.

4Click the Define Upgrade Cost button.

5The Upgrade Cost dialog box appears.

6To enable a service agreement to be upgraded, select the Support Upgrade check box.

If this option is enabled, all service templates based on the service agreement template may be upgraded.

7Define the number of days that a support plan remains active after it has expired in the Number Of Days A Support Plan Becomes Inactive edit box control.

8Define the fee charged to customers if a support plan must be reactivated in the Support Plan Reactivation Cost edit box control. specify.

9Define the percentage of the cost of the product sales price in the Support Plan Upgrade Cost Percentage edit box control.

10Click the OK button.

23.6.8 Defining Service Agreement Renewal Schedules

Project administrators may define service agreement renewals in the Renewal tab in the Service Agreement Template page of the Service Agreement folder in the CustomerWise Admin client.

Figure 23-10: Renewal Tab in the Service Agreement Template Page

To define service agreement renewals:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the Renewal tab.

3To enable the TechExcel CustomerWise to automatically contact the customer and remind them to renew their support plan, select the Enable Auto Support Renewal check box.

If enabled a renewal incident is created.

4To enable annual support plans to be renewed, select the Enable Annual Support Renewal check box.

5To define the number of days prior to the expiration of a service agreement that a renewal incident is created, enter a number in the Number Of Days for Auto renewal edit box control.

6To define the number of days prior to the expiration of a service agreement that a renewal message is displayed to project members and customers, select the Prompt for Renewal if the Remaining Valid Period is less than (Days) edit box control.

7Select a sales project in the Linked Sales Project dropdown list control.

The Linked Sales Project dropdown list displays the sales projects that share the same base project as the current support project.

The renewal incident that the administrator enabled by selecting the Enable Auto Support Renewal is created in the sales project selected.

8Select a manual renewal method option in the Manual Renewal Method dropdown list control.

The Manual Renewal Method dropdown list displays three options:

• Sales Project Only

• Support Project Only

• Both Sales and Support Project

9Select an autorenewal option in the Autorenewal Project dropdown list control.

The Autorenewal Project dropdown list displays two options:

• Sales Project

• Support Project

10Select a sales template in the Sales Order Templates dropdown list control.

The Sales Order Templates dropdown list displays sales templates that are linked to the selected sales project.

11Select a sales status in the Renewal Sales Status dropdown list control.

The Renewal Sales Status dropdown list displays sales statuses that are linked to the selected sales project. The sales status selected is applied to the sales order.

12Select an event in the Renewal Event dropdown list control.

The Renewal Event dropdown list displays the event templates that are linked to the selected sales project.

The event template selected is automatically created in the autorenewal project when a renewal is within the number of days selected in the Prompt for Renewal if the Remaining Valid Period Is Less Than (Days) control.

23.6.9 Defining Service Agreement Renewal Messages

Project administrators may define autorenewal e-mail messages in the Renewal tab in the Service Agreement Template page of the Service Agreement folder in the CustomerWise Admin client.

Project members may enable autorenewal of service agreements, enable reminder e-mail messages, and define the project in which the corresponding incident is created in the Renewal tab.

The Define Message dialog box enables administrators to define the e-mail messages that are delivered to customers when their service agreements are about to expire.

Project administrators may define three different e-mail messages.

• Message to customers to purchase the Service Agreement

• Message to customers to renew the Service Agreement

• Dialog window message to support team

To define service agreement renewal messages:

To define service agreement renewals:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the Renewal tab.

3Click the Renewal Message button.

4The Define Message dialog box appears.

5Enable and define a message to customers to purchase the service agreement.

6Enable and define a message to customers to renew the service agreement.

7Define the message that is displayed to project members.

8Click the OK button.

23.6.10 Managing Service Agreement Time Tracking

Project administrators may define autorenewal e-mail messages in the Renewal tab in the Service Agreement Template page of the Service Agreement folder in the CustomerWise Admin client.

Project members may enable autorenewal of service agreements, enable reminder e-mail messages, and define the project in which the corresponding incident is created in the Renewal tab.

The Define Message dialog box enables administrators to define the e-mail messages that are delivered to customers when their service agreements are about to expire.

Project administrators may define three different e-mail messages.

• Message to customers to purchase the Service Agreement

• Message to customers to renew the Service Agreement

• Dialog window message to support team

To define service agreement renewal messages:

To define service agreement renewals:

1Select a service agreement template in the Service Agreement tree menu of the Service Agreement Template page.

2Select the Renewal tab.

3Click the Renewal Message button.

4The Define Message dialog box appears.

5Enable and define a message to customers to purchase the service agreement.

6Enable and define a message to customers to renew the service agreement.

7Define the message that is displayed to project members.

8Click the OK button.

 Chapter 24 Service Agreement Manager

24.1 Understanding Time and Service Management

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

• General Setting

• Work Type

• Standard Rate

• Privileges

• Work Order

• Budget Control

• Service Template

• Access Control

• Event Service Template

24.1.1 Understanding Standard and Advanced Features

Time and service management features fall into two categories:

• Standard time and service management features

• Advanced time and service management features

Standard features

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

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.

Advanced features

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. For more information see “Managing Optional Project Features” .

24.2 Enabling General Time and Service Management Settings

Time and service management features fall into two categories:

• Standard time and service management features

• Advanced time and service management features

Standard features

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

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.

Advanced features

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. For more information see “Managing Optional Project Features” .

24.3 Defining Work Types

Administrators may enable time tracking and service management settings in the General Setting page.

Figure 24-1:

• Enable time tracking – allows project members to track the time spent to complete an incident.

• Enable cost tracking – allows project members to track the outgoing costs paid to complete an incident.

• Enable sales tracking – allows project members to track the money received for each opportunity/incident.

• Support service template – allows project members to use the service templates that are defined in the Service Template section, discussed later in this chapter.

• Record time usage when an incident is forwarded or closed – select to automatically launch a time and cost tracking entry window each time an incident is forwarded or closed. This feature is used to remind project members to enter any time or cost information before assigning it elsewhere.

• If show the check box of Billable to customer

24.4 Defining Standard Hourly Rates

Project administrators may create, edit, and delete service and work types and default hourly rates in the Work Type page.

Figure 24-2:

To add a work type, click the Add button, define the work type and default hourly rate for that work type, and click OK.

To edit or delete a work type, highlight the work type and click the Edit or Delete button.

24.4.1 Defining Account Type Hourly Rates

To change the hourly rate for an account type, just double click on the account type or highlight it and select the Edit button. An Account hourly rate dialog box will open where you can modify the rate of each work type for the selected account type.

24.4.2 Defining Project Member Hourly Rates

The difference is that the changes are made for each user. If changes are made in the Account Hourly Rate section, those changes will be reflected in the Member Hourly Rate section based on the members account type. The changes will not affect the members rate if it has been previously modified. If you are updating the hourly rates you should verify that the rates are also correct in the Members Hourly Rate section.

24.5 Defining Time and Service Management Privileges

Project administrators may edit and customize the default hourly rate for each account type and each project in the Standard Rate page.

This is useful if you wish to charge a higher or lower amount depending on the technician.

The Standard Rate page displays two tabbed pages: the Account Hourly Rate page and the Member Hourly Rate page

Figure 24-3: Standard Rate System Page (Detail)

• The Account Hourly Rate tab allows you to define a different default hourly rate for each account type. The hourly rate is set to the default amount, and no changes are necessary if want to use the default values.

• The Member Hourly Rate tab allows you to make hourly rate modifications for each user.

24.6 Defining Project Work Order Reports

To change the hourly rate for an account type, just double click on the account type or highlight it and select the Edit button. An Account hourly rate dialog box will open where you can modify the rate of each work type for the selected account type.

24.7 Defining Project Budget Controls

The difference is that the changes are made for each user. If changes are made in the Account Hourly Rate section, those changes will be reflected in the Member Hourly Rate section based on the members account type. The changes will not affect the members rate if it has been previously modified. If you are updating the hourly rates you should verify that the rates are also correct in the Members Hourly Rate section.

24.8 Managing Service Templates

The Privileges page enables project administrators to define time and service management privileges for project account types. Administrators may grant six different privileges to each account type.

Table 24-1: Service and Time Tracking Privileges

24.8.1 Defining Service Template Properties

The Properties tab is where you will define most of the basic functionality of the Service Template. Below is a list of the fields and a brief description:

• Name – The name or label of the Service template. Initially defined during the add function, can be edited from this tab.

• Description field for the service template.

• Work Type – A dropdown list of the Work Types that were created in the Work Types section (earlier in this chapter). This allows you to tie the Service Template you are creating to a predefined Work Type and the hourly rates associated with the Account Types and the project members.

• Cost Method – This defines the method for cost tracking for the selected Service Template. There are three hard coded selections: Based on actual quantity, Based on predefined quantity, Fixed cost amount

• Sales Amount method – This defines the method for sales amount tracking for the selected Service Template. There are three hard coded selections: Based on actual quantity, Based on predefined quantity, Fixed cost amount

• Time tracking method – This defines the method for time tracking in the selected Service Template. There are four hard coded selections: Edit time directly, through start/end time, through time clock, Edit time or through time clock

• Limit maximum quantity – Allows you to set a limit on the maximum number of units that your company will spend for this Service Template on an incident.

• Maximum quantity – Integer field for maximum quantity. Activated if the Limit maximum quantity check box is checked.

• Limiting maximum quantity invoiced – Allows you to set the maximum number of units that can be charged to a customer. If your service template is time based and the units are in hours, then this field would allow you to define the maximum number of hours that could be invoiced to your customer.

• Maximum invoice – Integer field for maximum quantity invoiced. Activated if the Limit maximum quantity invoiced check box is checked.

• Sales rate – the amount you will be charging per unit invoiced. Activated if Based on actual quantity or Based on predefined quantity is selected for the Sales amount method

• Standard quantity – Allows you to set a standard quantity for a service template. If you created a service template called Three days training then you would set the Unit name to days, and the Standard quantity to 3.

• Fixed cost – The fixed cost amount that defines the cost your company would pay out for this service. Activated if Fixed cost amount is selected for the Cost method. (Applicable if you have enabled Support cost control at incident level under the Budget Control page.

• Fixed sales amount – The fixed cost amount that defines the amount you would charge a customer. Activated if Fixed sales amount is selected for the Sales amount method.

• Unit name – If the service template is non-time related then this will appear as a edit box so you can give a label for the units, such as feet if you provided a service that charged by the number of feet of cable that you installed for a customer. If the service template is time related then this will appear as a dropdown list with three hard coded selections: Hours, Hours/minutes, Days

• Maximum copies – The maximum number of copies that the service template can be generated for an incident or event.

• Is taxable – A service item that is created form this Service Template is taxable.

• Bill customer – If the service template is a billable item to your customers.

• Is applicable at incident level – The service template can be created and attached to an incident. A service template can also be created and attached to an event that is associated with an incident, see the section on Event Service Template.

• Support time rounding – Enables the time that you worked on an incident to be rounded to a time interval that you bill out at.

Note:The Work Order page is displayed in the Time/Service Management folder only if the Advanced Time Tracking and professional service management feature is enabled on the Optional Features page. For more information see “Managing Optional Project Features”

24.8.2 Enabling and Defining Time Routing

This button brings up a pop up dialog box to define your time rounding. There are two areas that need to be configured to define the time rounding:.

• Rounding – This field defines the time interval you want to round up to.

• Minimum rounding – This field defines what time interval that triggers the rounding to the next time interval.

Example – if your company billed out on fifteen-minute intervals and anything over five minutes triggered the billing cycle to the next interval, you would set the rounding field to 15 minutes, and the minimum-rounding field to 5 minutes. In this example, if a support project member worked on an incident for 1 hour 22 minutes, then the time would be rounded to 1 hour 30 minutes.

24.8.3 Enabling and Defining Service Template Work Codes

The Work code tab allows you to define and use Work codes with your service templates. Work codes can be used within the service template to define different rates that you pay out in costs or charge your customers..

Figure 24-5:

Figure 24-6:

Suppose you provide a service in which you charge an hourly rate, you may have a different rate if a customer requests this service on the weekends or after normal operating hour. You could then create three Work Codes to define these rates, such as Regular Rate, Weekend Rate, and Overtime Rate. Below is brief description of the fields for setting up a Work Code:

• Support work code – a check box that enables the use of Work Codes for the selected Service Template.

• Default work code for services with support plan – lets you choose the default work code that will populate the Work Code field for services that are associated with a support plan. This list will include the Work Codes that have the Support plan settings of With support plan only and Not related to support plan.

• Default work code for services without support plan – lets you choose the default work code that will populate the Work Code field for services that are not associated with a support plan. This list will include the Work Codes that have the Support plan settings of Without support plan only and Not related to support plan.

Below is a brief description of the fields that need to be configured when adding or editing a Work code:

• Code – The name of the Work Code.

• Cost price – The price that

• Sales price – The price that you will charge your customer when this Work Code is used with the selected Service Template.

• Note – A field to put a detailed description of the Work Code.

• Support plan – There are three choices available for this dropdown list:

• With support plan only – the Work Code is only applicable when the Service Template is used in a Support Plan.

• Without support plan only – the Work Code is only applicable when the Service Template is used without a Support Plan.

• Not related to support plan – the Work Code is applicable at any time the Service Template is used.

24.8.4 Enabling and Defining Service Template Volume Pricing

The Volume price tab allows you to support volume pricing for a service template. If you want to charge different rates for ranges of time you would check the Support volume pricing check box at the top of this page. You can then define the volume pricing properties in the Volume Price section, such as if you offered training as a service and you billed one to three days out at $1000 per day and four to ten days at $850 per day. In this scenario if your customer purchased six days of training they would be billed out $5100 (6 X 850) for the training. .

Figure 24-7:

24.9 Defining Service Template Access Controls

The Work Order page enables administrators to define the statement and invoice report files. .

In TechExcel CustomerWise the Statement Report File and Invoice Report File are automatically predefined as WOStatement.rpt and WOInvoice.rpt respectively. These reports are standard in TechExcel CustomerWise.

Administrators may create custom reports in an application such as Crystal Reports and define those files in the Work Order page.

Note:The Work Order page is displayed in the Time/Service Management folder only if the Advanced Time Tracking and professional service management feature is enabled on the Optional Features page. For more information see “Managing Optional Project Features” .

24.10 Defining Event Service Templates

The Budget Control page allows you to manually set limits on the amount of money you are spending or charging to solve an incident. While there are settings in the Service Templates that can populate some fields for budget control, most are manually set for each incident to allow you the flexibility of managing the budget for each incident

There are three properties that can be defined:

• Support cost control at incident level – if selected, you can set a limit to the amount that can be spent on each incident. Controls the outgoing costs to complete an incident.

• Support sales budget at incident level – if selected, you can set a limit on the amount that can be charged to a customer for each incident.

• Support budget control at event level – if selected, you can set a limit on the amount that can be charged to a customer for each event.

Note:The Work Order page is displayed in the Time/Service Management folder only if the Advanced Time Tracking and professional service management feature is enabled on the Optional Features page. For more information see “Managing Optional Project Features” .

 Chapter 25 Outlook Sync Administration

25.1 TechExcel Outlook Sync Overview

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

25.2 Feature Summary

Chapter Outlook Emails

Incoming and outgoing Outlook emails may be selected and linked with the appropriate customer in CustomerWise CPM with a single click. Or, more detailed Customer and Contact 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 CustomerWise CRM information based on matching email addresses. Sales and support teams link new and existing emails with leads, contacts, opportunities, or support incidents while adding Outlook emails to CustomerWise. If no match is found, users may also choose to perform a search of CustomerWise CRM data from within Outlook.

Online/Offline Customer Contact Support

Search the CustomerWise CRM customer 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 usersmay access and update information while offline. All updates made locally will be synchronized with the CustomerWise CRM server when online.

Customer and Contact Manager

Add new customer or contacts to CustomerWise directly from Outlook at the same time you add an email, task, or appointment.

Create Outlook Tasks and Activities From CustomerWise Events

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

25.3 Requirements

Server Requirements

• TechExcel CustomerWise 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

25.4 System Administration Configuring TechExcel CustomerWise for use with Outlook Sync

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 CustomerWise 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.

25.4.1 Save Emails as Events Tab

End users may save emails from Microsoft Outlook to TechExcel CustomerWise 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.

25.5 User Configuration – Configuring TechExcel Outlook Sync

End users may save emails from Microsoft Outlook to TechExcel CustomerWise 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.

25.6 Using TechExcel Outlook Sync

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 CustomerWise menu option, and selecting Configuration.

2. Press User Login

Enter your TechExcel CustomerWise 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 CustomerWise Administrator to request permission to use

Outlook Sync.

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

Contact your CustomerWise 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 DB. Or, you may select the Setup Local DB item 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 CustomerWise 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 DB with the correct tables and synchronize data from live CustomerWise 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 CustomerWise Administrator.

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

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

CustomerWise database.

25.6.1 Add an Outbound Email to CustomerWise

When sending an email, you may now choose to save the email to TechExcel

CustomerWise 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 CustomerWisebutton (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 customer and contact will be selected automatically based on the

matching email information from TechExcel CustomerWise.

• You may add customers or contacts using theNew…buttons next to Customer and Contact fields.

• You may search customers using theicon next to the Customer

field.

• You may edit the existing information using any of theEditbuttons for Customer or Contacts.

Please Note:Creating/editing customer and contact 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 CustomerWise database when a connection becomes available.

6.Choose the related incident or sales opportunity to associate the email event.

7.Choose theEvent templateandEvent statusused to track this email activity in TechExcel CustomerWise.

8.You will now see this Email event and message from within TechExcel

CustomerWise.

Please Note: An email can only be saved to one event. Once saved, the ‘Save email to CustomerWise’ button will be disabled for that email.

25.6.2 Add a Sent or Received Email to CustomerWise

Emails already in your Microsoft OutlookInboxorSent Itemsfolders may also be saved to TechExcel CustomerWise retroactively. The steps are similar to those above and the Save Event dialog is the same.

1.Select any email you have received or sent within Microsoft Outlook .

2.Press theSave Email to CustomerWisebutton from the CustomerWise toolbar.

3.Complete the Save Event dialog. Again, you may use this dialog to associate the email with the correct customer, contact, incident, and CustomerWise event. You may also create new customer and contact information from this dialog.

Please Note: An email can only be saved to one event. Once saved, the ‘Save email to CustomerWise’ button will be disabled for that email.

25.6.3 Add an Outlook Task or Outlook Appointment to CustomerWise

You may choose to sync an appointment/task to a CustomerWise event. To do so, you

will be required to specify the customer and event information using the CustomerWise toolbar visible whenever an Outlook task or appointment is opened.

25.6.3.1 Understanding the CustomerWise Outlook Toolbar

The toolbar shown below becomes visible whenever an Microsoft Outlook task or

appointment is opened:

•By default, the toolbar is grayed out for a new appointment/task, indicating it

will not be synced to a CustomerWise event.

•The tool bar includes three fields that display the current Project, Customer

and Event information.

•The toolbar includes two ellipses (…) buttons you may use to change the

associated Customer and Event Info.

•Clicking either ellipses (…) button will bring up the dialog below:

25.6.3.2 Synchronizing Events and Appointments

1.If “Sync to CRM” is not checked, all other fields on the dialog will be

disabled. This appointment/task will not sync to a CustomerWise event.

2.To specify the customer/event information, check the ‘Sync to CRM’

checkbox:

3.When a customer is selected the customer and contact information will be

displayed.

4.Clicking the ‘New’ or ‘Edit’ buttons will begin the create/edit a

customer/contact dialog shown in the image below.

Please Note:Creating/editing customer and contact 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 CustomerWise database when a connection becomes available.

5.A quick search dialog is provided for searching customers.

6.You may choose to associate the event to the incident or opportunity. Only

incidents related to the selected customer are displayed.

7.Select the event template and status in the Event Info frame. The events

available are based on the status of the related incident selected. If you are

using event workflow you will only see events that are applicable to the state

of the incident. If no incident is selected, all the event templates will be

listed.

8.The default event owner will be set to the user using Outlook Sync. You maychange it to another team member.

Please Note: If you create or change the ownership of an appointment/task to

another project member it will no longer be available for you to once it is

synced to CustomerWise.

9.You must specify a customerandan event template if you want to sync the

appointment/task to a CustomerWise event.

10.When an appointment is synced to a CustomerWise event the subject and

content will become Event Title and Event Description. The start time and

end time of the Outlook appointment/task will become the CustomerWise

Event start date and end date.

25.6.4 Synchronize CustomerWise Events to Outlook Appointments/Tasks

This operation happens automatically and there is no user interface involved in this

function. When Microsoft Outlook is opened, the TechExcel Outlook Sync begins to

compare the live CustomerWise database with your local database. If there are

synchronizations required they occur automatically.

If there are any changes in the Administration settings or incidents/customers/contacts, the sync service will also sync them to local DB. Therefore the settings for the Outlook integration will be up-to-date as long as there is an interment connection.

25.7 APPENDIX: Installing TechExcel Outlook Sync

 Chapter 26 Smart Screen Administration

26.1 TechExcel Smart Screen Overview

Smart Screen helps you manage the many different types of requests a help desk or IT team encounterincluding: incident requests, change requests,service requests, safety reports, and evennon-technical requests and workorders. Specifically, Smart Screen enables you to configure each form with a different layout and different fields so you capture therequired information for the type of request.

Smart Screen allows administratorsto design each form for a specific need and presentend users with a clearly defined form and structure.It is easier for end users because theforms may be simplified to includeonly necessary fields which will also improve thecorrect categorization rate of submitted issues.

26.2 Feature Summary and Benefits

New Incident Type Field

The Incident Type field is a new System Level drop-down field. The labelIncident Typemay be renamed. This special drop-down field determines which layout is presented tothe user. Therefore, each UI page the user encounters including the New page, Current Status page, Forward page, Custom pages, and others may be customizedto displayinformation relevant to the Incident Type selected.

The Incident Type field is similar to other fieldsand may be used to create escalation,notification, andSLAauto-apply conditionsfor automating incident management. Usersmay also add the Incident Type fieldto their List View and Reports.

Form Visibility – Public or Private

Each Incident Type may be configured for use byteam members only or for both teammembers and as an available option within the self-service portal.

Overwrite Pages

Overwrite pages allow Administrators to design the UI of different Incident Types. An unlimited number of Overwrite pages may be definedallowing for countless layouts andform designs. Each Overwrite page is then linked with an Incident Type. When users select an Incident Type choice, the correct Overwrite page layout is displayed automatically.

26.3 Smart Screen System Administration

Requirements

•Smart Screen is available in TechExcel ServiceWise or CustomerWise 8.0 orabove.

Configuring Smart Screens

TechExcel System Administrators must enable and configure Smart Screens using the Admin Client. The form fields and layout the user will see is determined by the selection of theIncident Typedrop-down field. When a selection is made in the Incident Type field the layout and fields will change immediately based on the user selection.

Follow these simple step-by-step instructions to setup multiple forms for your project.

Step 1: Determine your “Incident Types”

Do you deal with multiple types of requests and want gather different informationbased on what type of request it is?

If so, Smart Screen may be beneficial to your organization. The first step is todetermine the different types of requests your team handles, and if the information required is significantly different for each type of request.

Example Scenarios:

o Create a different layout for Incident Requests and Enhancement Requests

o Create a different layout for Incident Requests and Service Requests

o Create a Document Request layout with unique fields and layout

Step 2: Create Incident Types in the Smart Screen settings configuration screen

Once you have determined the types of forms you will create them as yourIncident Typevalues using the Smart Screen Settings page in the Admin client.

Smart Screen settings are available in the Incident View folder.

The values defined will become a drop-down list available to users andtechnicians.

•Check theSupport definable screens based on incident typecheckbox toenable Smart Screens.

•Press the New button, and enter your Incident Type name and visibility.

•You may always Edit or Delete any Incident Type form configured at alater time.

•Set the Default Incident Type for team members and customers using theself-service portal.

As with other fields in TechExcel, you may change theIncident Typelabel toyour own terminology. This is done when adding the Incident Type field to theactual form (see next step).

Step 3: Change the Incident Type Label (Optional)

You may customize the Incident Type label to use your town terminology. To doso, on the System Field Design page, select the Incident Type field and press theDesign Button. Change the Label.

Step 4: Time Saving Tip - Setup the Default Page Layout Before the Overwrite Page Layouts

In general, it is easier to setup the default page prior to creating your Overwritepages because Overwrite pages inherit initial page layout and settings from thedefault page.

You should configure the default page to includefields and layout common toall Overwrite pages. This will help you save time customizing each Overwritepage later because common fields and layout are inherited automatically.

For example, in the image below an Administrator may want to configure thedefault New page (A.) before each Overwrite page (B.)

Step 5: Create the form layouts using the Overwrite feature

Next, create your page layouts by adding Overwrite pages and customizing each page tomeet your needs. You may create Overwrite layouts for each page including the Newpage, Description page, Current Status page, any Custom page, and any Function page(New, Reopen, Close, Forward).

•Choose a page you want to create a different layout for and right-click the Overwrite folder.

•Select Add Page

•Name the Overwrite Page by double-clicking the page title as shown below.

•Customize each Overwrite page. Customizing the Overwrite pages is similar to page customization available in previous versions. See the Admin guide for more details on page customization.

Step 6: Associate the Overwrite Page with the Incident Type

After creating Overwrite pages for different page layouts, you must now associate the layout with the Incident Type choice. When a user selects an Incident Type, the correct Overwrite layout will be displayed.

A. On the default page enable Overwrites by selecting theCan Overwriteradiobutton.

B. Incident Types you have defined will be displayed in the type column.

C. For each Incident Type you may choose which Overwrite page to display using the Page Name drop-down.

Please Note: Overwrite pages may be reused, and apply to more than one Incident Type choice.

Step 7: Setup Account Type Privileges

Administrators may configure which account types have permission to change the Incident Type field after the initial submission. A new account type Incident privilegeCan change incident typeis available.

This is privilege controlled because changing the Incident Type after submission may change the layout, and possibly the categorization, of the incident.

Step 8: Optional – Link your Incident Type Layouts with Templates

If using Templates for incident submission, you may now choose to use Incident Type field in conjunction with template design. Since Incident Type is available as a predefined field you may automatically set he layout of the submission screen by choosing an Incident Type choice in your template.

Using Smart Screen

To the end-user, Smart Screen may appear as just an additional field: Incident Type.

However, whenever a selection is made in the Incident Type field, the form will be

automatically updated.

26.4 Using Smart Screen

To the end-user, Smart Screen may appear as just an additional field: Incident Type. However, whenever a selection is made in the Incident Type field, the form will be automatically updated.