A quick overview of Genesys iCFD (Intelligent Customer Front Door) since Charlie Isaacs (@charlieisaacs) was Tweeting a bit about it …
iCFD is a solution that spans across Genesys products – specifically Genesys Voice Platform (GVP) 8.1.2+ and Universal Contact Server (UCS) 8.0.3+ with Composer as the IDE.
Context Services are part of Universal Contact Server (UCS) 8.0.x. Context Services is an optional set of features supporting the management and retrieval of data concerning customer service, enabling real-time service personalisation and service continuity. This set of capabilities is the foundation of iCFD and Conversation Manager.
In the future, a Genesys Rules System will be added to Conversation Manager to allow use of rules to control customer treatment:
At the core of the solution is concept of “Customer Centric Routing” based on maintaining the context of a conversation spanning multiple interactions across multiple channels:
Clients connect to Context Services (UCS) and send requests, to which UCS responds. Clients communicate with UCS via RESTful web services, using HTTP request methods that are based on the GET, POST, PUT, and DELETE methods.
Clients of Context Services may include Orchestration Server, Genesys Voice Platform (GVP), agent desktops, or any third party application that makes use of real-time customer service information. JSON is used for object serialisation.
Context Services (UCS) uses a flexible schema that allows each application to easily define its own custom attributes – at any time an application can add attributes.
In short, Context Services delivers an extensible framework for identifying, modifying and updating customer profile, service history, and other customer attributes.
Typical usage scenarios of Context Services include:
- Customer identification
- Service resumption
- Customer profile (retrieval and management)
- Callback offers
- Service resumption with an agent
- Proactive notification
- Schedule callback with enhancement multimedia confirmation
One of the primary features of the Context Services API is the ability to identify customers based on one or more attributes of the customer, known as Identification Keys. Each identification key consists of one or more attributes of the core customer profile, or of any defined extension.
Customer profiles are built on top of legacy UCS Contact Attributes. The operation “Identify Customer” enables an application to retrieve customer profiles based on a few attribute values passed in as parameters, without specifying the customer ID.
Context Services 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.
Services are customer commitments defined by the business application (IVR, Orchestration, Agent Desktop, etc.) which interacts with the customer. Each service potentially spans multiple interactions over a variety of media channels and should link to a Customer profile as soon as it is created or retrieved through identification operations. In some ways, Services can be considered as workflows.
Services are defined by association to Service Types that are created as Business Attributes in CME. States may be used to represent components of customer service.
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.
An anonymous service is a service which is assigned to an anonymous customer.
Services are started using the “POST /services/start” operation. The following specific business attribute fields are validated against specified mapped Business Attributes in CME:
When a customer starts interacting with a service, the application creates a new service resource to manage the service’s context data, and then nested state and task resources to manage further states and tasks’ context data.
A service, state, or task is active if a customer is still interacting with it. In that case, the service, state, or task is started, but not complete. Once the resource is completed, it is no longer part of the active list, but part of the completed list.