Service Basics

Purpose: Basic information on Services

UCS makes use of a model in which customers are associated with any number of Services. Services are composed of any number of States, and States can in turn be composed of any number of Tasks. This three-level structure provides a flexible vocabulary by which organizations store the history of the services that they provide to customers. A Service may also be divided directly into tasks: file:serviceStateTask.jpg Services are defined by association to Service Types that you create as Business Attributes in the Configuration Layer. States may be used to represent components of customer service, such as:

• Customer identification
• Assigning a service agent (automated or live)
• Service identification
• Waiting for a service agent
• Offering another service while waiting for an agent
• Offering callback
• Waiting for customer input

For more information on this point, see this page in the Context Services Developer's Guide. Services, States and Tasks exist over some application-defined lifecycle. Upon completion, applications may specify a Disposition. For example, the offering of a new product or service might be recorded as a State of type Offer another service. The Disposition might be set to show whether the customer accepted or declined the offer. Information on past declined or accepted offers could then be used to calculate the likelihood that the customer might be interested in the offer at some point in the future. Note: This Service Model can be used by any component that can access UCS/CS’s HTTP interface. It is not limited to use in Conversation Manager.