Difference between revisions of "Service Contract"
m |
|||
| (20 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
| + | [[Category:Configuration]] | ||
| + | {{Global Header}} | ||
| + | {{Global Announcement}} | ||
| + | |||
| + | == Overview == | ||
This article provides a detailed analysis of the Service Contract feature that was introduced in r11.x. | This article provides a detailed analysis of the Service Contract feature that was introduced in r11.x. | ||
| − | Service Contracts are associated with a user via their | + | Service Contracts are associated with a user via their Organization or by Contact Mapping in the Service Contract. ''See Step 3 for contact mapping.'' |
| − | When creating a ticket and it is determined by the system that a Service Contracts applies, many default system functionalities are superseded by the contract, such as [[Service Type|Service Types]] and | + | When creating a ticket and it is determined by the system that a Service Contracts applies, many default system functionalities are superseded by the contract, such as [[Service Type|Service Types]] and Request Area listings. |
| − | == Step 1. Create Service Contract == | + | == Procedures == |
| + | === Step 1. Create Service Contract === | ||
The only field required when initially saving a new Service Contract is a Name. | The only field required when initially saving a new Service Contract is a Name. | ||
| Line 21: | Line 27: | ||
| IT representative | | IT representative | ||
|- | |- | ||
| − | | Client | + | | Client Contact |
| − | | The client representative. This is typically an | + | | The client representative. This is typically an End User who serves as the point of contact with IT with regards to this Contract. This person could likely be the recipient of [[Notifications|notifications]] such as those regarding a violation of an [[SLA]]. |
|- | |- | ||
| Expiration | | Expiration | ||
| Identifies when the contract expires. If a contract exceeds it's expiration, the contract is voided by the system and the default system behaviors are applied. | | Identifies when the contract expires. If a contract exceeds it's expiration, the contract is voided by the system and the default system behaviors are applied. | ||
|- | |- | ||
| − | | Assigned to | + | | Assigned to Organization(s) |
| − | | Lists all | + | | Lists all Organizations to which this Service Contract is applied. To add to this list, access the Organization's Detail page and add the appropriate Service Contract. |
|- | |- | ||
|} | |} | ||
| − | |||
| − | == Step 2. Create | + | === Step 2. Create Private Service Types === |
Service Contacts can ''only'' use [[Service Type|Service Types]] that are created specifically for that Service Contract. These exclusive [[Service Type|Service Types]] are referred to as [[Private Service Type|Private Service Types]]. A [[Private Service Type]] can ''only'' be created from the "[[Private Service Type]]" tab on the Service Contract Details page. | Service Contacts can ''only'' use [[Service Type|Service Types]] that are created specifically for that Service Contract. These exclusive [[Service Type|Service Types]] are referred to as [[Private Service Type|Private Service Types]]. A [[Private Service Type]] can ''only'' be created from the "[[Private Service Type]]" tab on the Service Contract Details page. | ||
| Line 41: | Line 46: | ||
*There is no supported method of converting a [[Service Type]] to a [[Private Service Type]]. | *There is no supported method of converting a [[Service Type]] to a [[Private Service Type]]. | ||
| − | Once a [[Private Service Type]] has been created it can be used as a default [[Service Type]] for | + | Once a [[Private Service Type]] has been created it can be used as a default [[Service Type]] for Contacts, CIs, and Priorities or as the Organization's [[Service Type]]. |
| − | ''Note: The | + | ''Note: The Organization's [[Service Type]] is always applied to any ticket opened for the identified Organization(s).'' |
| − | ''Note: The default [[Service Type|Service Types]] for | + | ''Note: The default [[Service Type|Service Types]] for Contacts, CIs, and Priorities will be applied to any listed Contact, CI, or Priority that is not mapped to a specific [[Service Type]].'' |
| − | + | === Step 3. Map Contacts & CIs === | |
| − | == Step 3. Map Contacts & CIs == | + | |
Mapping Contacts & CIs fulfills two objectives. | Mapping Contacts & CIs fulfills two objectives. | ||
First, it allows the Service Contract to apply to Contacts and CIs that do not belong to any of the Organizations associated with it. | First, it allows the Service Contract to apply to Contacts and CIs that do not belong to any of the Organizations associated with it. | ||
| − | Second, it provides a means of specifying Private Service Types to individual Contacts and CIs. | + | Second, it provides a means of specifying [[Private Service Type|Private Service Types]] to individual Contacts and CIs. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ''Note: Mapped Contacts and CIs that are not associated to a specific [[Private Service Type]] are serviced by the default [[Service Type]] if one is identified.'' | |
| − | + | ||
| + | === Step 4. Map Priorities === | ||
| + | Priority mapping allows for identifying Priority related Servicing. This works exactly like the default system behavior of using Priority to determine the [[Service Type]]. If no individual mapping is done, then the default [[Service Type]] is applied. | ||
| − | == Step 5. Create Request Areas & Change/Issue Categories == | + | === Step 5. Create Request Areas & Change/Issue Categories === |
| − | When a user is subject to a Service Contract, only the | + | When a user is subject to a Service Contract, only the Area and Categories identified in the contract will appear as options when creating a ticket for that user. If the Service Contract has been created with no Areas or Categories, then none will be listed when creating the ticket. |
| − | + | ||
Latest revision as of 04:11, 27 July 2008
To discuss or ask questions about this article, select the discussion tab above.
Overview
This article provides a detailed analysis of the Service Contract feature that was introduced in r11.x.
Service Contracts are associated with a user via their Organization or by Contact Mapping in the Service Contract. See Step 3 for contact mapping.
When creating a ticket and it is determined by the system that a Service Contracts applies, many default system functionalities are superseded by the contract, such as Service Types and Request Area listings.
Procedures
Step 1. Create Service Contract
The only field required when initially saving a new Service Contract is a Name.
| Field Name | Description |
|---|---|
| Contract Number | An alternate identification |
| Client Advocate | IT representative |
| Client Contact | The client representative. This is typically an End User who serves as the point of contact with IT with regards to this Contract. This person could likely be the recipient of notifications such as those regarding a violation of an SLA. |
| Expiration | Identifies when the contract expires. If a contract exceeds it's expiration, the contract is voided by the system and the default system behaviors are applied. |
| Assigned to Organization(s) | Lists all Organizations to which this Service Contract is applied. To add to this list, access the Organization's Detail page and add the appropriate Service Contract. |
Step 2. Create Private Service Types
Service Contacts can only use Service Types that are created specifically for that Service Contract. These exclusive Service Types are referred to as Private Service Types. A Private Service Type can only be created from the "Private Service Type" tab on the Service Contract Details page.
- Private Service Types can only be created from a Service Contract.
- Private Service Types cannot be shared by multiple Service Contracts.
- Service Contracts only use Private Service Types.
- There is no supported method of converting a Service Type to a Private Service Type.
Once a Private Service Type has been created it can be used as a default Service Type for Contacts, CIs, and Priorities or as the Organization's Service Type.
Note: The Organization's Service Type is always applied to any ticket opened for the identified Organization(s).
Note: The default Service Types for Contacts, CIs, and Priorities will be applied to any listed Contact, CI, or Priority that is not mapped to a specific Service Type.
Step 3. Map Contacts & CIs
Mapping Contacts & CIs fulfills two objectives.
First, it allows the Service Contract to apply to Contacts and CIs that do not belong to any of the Organizations associated with it.
Second, it provides a means of specifying Private Service Types to individual Contacts and CIs.
Note: Mapped Contacts and CIs that are not associated to a specific Private Service Type are serviced by the default Service Type if one is identified.
Step 4. Map Priorities
Priority mapping allows for identifying Priority related Servicing. This works exactly like the default system behavior of using Priority to determine the Service Type. If no individual mapping is done, then the default Service Type is applied.
Step 5. Create Request Areas & Change/Issue Categories
When a user is subject to a Service Contract, only the Area and Categories identified in the contract will appear as options when creating a ticket for that user. If the Service Contract has been created with no Areas or Categories, then none will be listed when creating the ticket.
