NextGen Consulting

IT Consulting CRM BSS OSS

About Smart Client Script Player


Background

A Smart Client form can define a Launch Action to allow manually launching another form in the workspace.

For automated processes, Smart Client infrastructure provides three alternate actions which allow automating the selection of the next form to be launched;

  • Process Driven UI Action (PDUI)
       
  • Service Driven UI Action (SDUI)
         
  • Client Process Driven UI Action (CPDUI)

 

Process Driven UI Action (PDUI)

This action is used if the form launch is based on a process running on the server. This is typical to a Wizard Form which requires the process state to be maintained and communicated to either the launching form (or other forms subsequently posted) that might continue the process. The Order Management process is a good example for process driven UI.

 

Service Driven UI Action (SDUI)

This action is used if the next form to be posted depends on a UI driving service.

 

Client Process Driven UI Action (CPDUI) – Script Player

This action is used to drive a client side script player.  The process that maintains the state and drives the next form to be posted is a client side light weight process. The client who runs this light weight process is Amdocs Process Manager (APM) client.

Amdocs Process Manager (APM) Design tool is used to define the Script metadata. APM Client interacts with APM Server to get the metadata to the client and maintain the state.

The Client Process Driven UI (CPDUI) Action interacts with APM Client to launch Smart Client forms in the client workspace. These forms can be either dynamically constructed forms (E.g., Question and Answer script forms) or standard Smart Client forms already created at design time. These pre-designed Smart Client forms are invoked by a special script step known as Show page step)

The CPDUI Action communicates with APM client, to either start or proceed with a client process. Whenever the CPDUI needs user interaction, it yields back to itself and pass required inputs (process variables). The action processes the inputs and dynamically generates and posts a ‘script form’ for user response.

The target form can have another CPDUI action, which collects and validate user inputs associated with the action and submit the details back to the APM client.

To facilitate communication between the APM client and the CPDUI action, the process variables in the APM client are mapped (at design time) to the Data models in the next launched (target) form.

When APM client is running along with Smart Client, APM client interacts with APM server (via Smart Client and Smart Server) to get Light Weight Process metadata or to invoke a service (AIF service or any other service) as part of the process execution. In fact – The Smart Client acts as a host for running Light weight processes.

Smart Client normally uses a Submit Action to submit to the server and get the response back. This functionality is utilized for retrieving the metadata and invoking any server side service.

Similar to the PDUI action, the Client Process Driven UI Action launches a form based on the logical form name (LFN) input data section.  At script design time, the Script Designer refers the form’s input data section as show context area. At run time, any input retrieved from the process can overwrite the form’s default launch action properties.

 

Running Scripts from Smart Client form

Client Process Driven UI Action Can be added to any Smart Client form like any other action, and can be invoked by a user action or using application code.  The Client Process Driven UI Action defines various operations:

  • Get a lite process instance
        
  • Start running
        
  • Proceed
        
  • Abort
         
  • Go back (a process step)
        
  • Get log details

 

                                                                                                      Process Navigation

 

After getting response from the process, the Client Process Driven UI Action always invokes a launch action to launch a form based on inputs from the process, except when the process’ return status indicates abort/completed.

If the process returns with completed or aborted state, then it sends a message to its opener form indicating the new status. If this action is overloaded by a PDUI action, (in case the lite process was part of a server process), then, it invokes the dynamically created PDUI action and passes the ‘proceed context’ details (to allow the original server process continue).

The execution of the Client Process Driven UI Action is considered ‘done’ after the action launches the form or if the process is completed or cancelled and the action sends a message to its opener forms.

The action passes the Lite Process Instance (LPI) got from a “GetProcess” operation to all the launched forms. LPI is stored as a property of the launched Smart Client form to allow all CPDUI actions in that form access this Lite Process Instance.

While a Lite Process Instance is being executed, it may respond to one of the following UI steps:

  • Show page step
           
  • Prompt step

At runtime, the process might call for a UI step. This UI step can either a show page step or prompt step.

 

Show Page Step

A show page step dynamically invokes a Smart Client form by:

  • Creating a Launch action
          
  • Setting the launch action’s properties according to the properties provided by the process (in other words: it passes relevant process variables to the launch action properties)
         
  • Launching the target form (the target form is a standard Smart Client form which was previously set as a show page step in the process definition)
            
  • The show page can be invoked either in Synchronous orAsynchronous modes. In Synchronous mode, the Client action overloads existing actions in the form to return data back to Opener form (Script Player) which continues process. For example, clicking Save button in Show page form executes Save Actionand continues client process from Script Player form.An Asynchronous mode, returns data to Opener form right after the Initial Load Action of the Show page form is done and continues process

 

Prompt Page Step

A prompt step uses a dynamic form generator to create the prompt form.

  • The prompt form can be displayed either in the toolbox or workspace area (exact location is set at design time by the process designer
         
  • The prompt form is  based on the prompt info defined at design time in the process

 

 

                                                       Launch Script in Toolbox Area   

 

UifLiteProcessHost Class

The UifLiteProcessHost supports information storage (and retrieval) on the client’s disk. It also supports submitting server requests issued by the lite process instance.

The Smart Client RequestResponseManager is used to submit request to the server.

The UifLiteProcessHost provides the following functionality:

  • Get the required or latest version of lite process instance definition from the APM server and store it in the client
          
  • Submit an AIF operation request to the server based on the client host
         

To get a Lite process instance from the process definition, the Client Process Driven UI Action calls the static API getLiteProcInstFactory(), which returns a process instance factory which is used to create an instance of a Lite process instance.

For example, the action may use the following call to create an instance of the required process:

UifLiteProcessHost.getLiteProcInstFactory(procName, version, deployCount().create().

 

Lite process instance

A Lite process instance is an instance of a lite process definition downloaded from the APM server. The client can run multiple instance of the same process definition at the same time.

For example, when user runs ‘Script A’ once, an instance of Script A’s LiteProcInst is created and used until the script is done.

 

Types of Operations

GetProcess

The inputs to get a client lite weight process are Process Name (mandatory) and Process version – (optional); If not provided, the latest version of the process is used.

Accessing a client process involves getting the LiteProcInst (LPI) based on the lite process definition retrieved from the relevant APM client (CRM) database or from APM server.

After getting the LPI, the defaultLaunchAction specified in the action is invoked. The default Launch Action should give a valid Logical File Name with any required input data.

Additional input required for the process is information regarding the launched form; whether the form should be launched as a Main WORKAREA form or as a TOOLBOX form.

The action fires an event including this information to the application code before launching the defaultLaunchAction. This allows the application code to take advantage of both potentially adding a LaunchMapItem, and pass this as an input to the launched form and use form version selector, which could return the appropriate physical form name to be launched on the WORKAREA or TOOLBOX.

 

Single light process instance per form

When launching the form (executing the defaultLaunchAction), the LPI instance is passed internally through the launch action to the launched form and cached. Any other CPDUI action in the launched form will always use this LPI instance for any other operation involving the same process, which means only a single lite process instance can be used on a form.

Consider an example where the launching form is a Script listing form and the user selects a particular script and clicks play. The play button will be associated with the CPDUI action that has:

  • Operation:                                 “GetProcess”
         
  • DefaultLaunchAction:   launch action where LFN = “

The Client Process Driven UI Action retrieves the Lite process Instance and the target launch area (where to launch this form – WORKAREA or TOOLBOX).

The CPDUI pass this information to the defaultLaunchAction and executes the launch action. The launch action launches the script player form, and sets this Light Process Instance to scriptPlayerForm.LiteProcInst.

If the client process was part of a server process, then PDUI action would dynamically create this action with operation “GetProcess” and use the ShowContext details to get the process name version etc.

As already mention, the Launch action would pass the Show context data and Proceed Context data to the launched form, and if required, overload any existing action in the launched form as described by the Action descriptor. The Proceed Context can be passed back to the server after the client process is done.

 

Start, Proceed, Back, Abort, Restart, ShowLog

All operations other than “GetProcess” should not provide the process name, version as input. If the action’s operation type is set to one of Start, Proceed, Back, Abort, Restart or ShowLog, then the default Lite Process Instance which is already available in the Form (where the action is defined) is used.

LiteProcInst provides APIs to run, proceed, back, cancel the process, which is used to perform the operation.

Restart

Restarting the client process has to clear out the logs created so far, and initiates the process as if nothing happened in this process instance. A process can be restarted before it is complete. It can be done even after a child script is executed, in which case it goes back to the main process that was originally started by the user. Restarting is not possible, after a show page step.

Abort

Aborting a process also requires a Feedback message from the user. It’s up to the application to get this feedback and set it to the action if the operation = “Abort”

ShowLog

Calling the below API on the liteProcInst gets the log details.

LiteProcInst.getLiteProcInstHistory()

The output from the API can be set to a data model in the launched form and displayed as a list (See output processing below).

Advertisement

01/07/2011 Posted by | Amdocs, APM, CRM, CRM, Customer Interaction Management, Development, Front End, Smart Client, Technology | Leave a comment

Contact Resolution Management


Numerous managers have gotten “First Call Resolution Forever” and/or “Done in One” tattooed on their necks.

The majority of conversations about FCR center around two things:

  1. The huge potential impact of First Call Resolution (on operational costs, customer satisfaction and agent satisfaction / retention);
  2. How to measure this mega-metric accurately

See the original full discussion in Greg Levin’s Rev Up Your FCR Rate.

In his article, Greg discusses the following list of tactics to increase First Call Resolution efficiently:

  • Excellent agent training and tools
  • World-class workforce management processes
  • No conflicting performance objectives
  • Incentives around FCR goal achievement
  • Agents empowered to improve FCR-related processes

Amdocs Customer Interaction Manager (CIM) provides an excellent platform for achieving these goals.

 

Contact Management 

Contact management (or CIM – Customer Interaction Manager in Amdocs terminology) refers to a unified desktop application that enables customer facing agent (or CSRs -Customer Service Representatives) to effectively manage media exchanges with their customers.

The user interface is context-driven, and provides agents with immediate access to all relevant information to assist them end up the interaction in timely manner while having satisfied customers.

Relevant information refers to customer information (personal and / or organizational), interaction history (previous contacts) and service history (previous case handling), products and subscribed services, usage of services, service level agreement(s), likes, habits, social behavior, billing information etc.

Customer Interaction Manager combines with Multimedia Integrator to provide a multimedia interface for variety of communication channels such as interactive voice response (IVR), computer telephony interface (CTI), email, and smartphones applications (not provided with core product – requires customization).  The Multimedia Integrator displays an application toolbar that agents can use to efficiently manage inbound and outbound voice, and other media exchanges.

 

Contact Management Concepts

The contact management, focused on the interaction paradigm, is based on the following key Concepts:

Interaction    
Interaction is defined as an exchange of information between a single customer and the agent (or CSR – Customer Service Representative), using one or more channels. The interaction provides a full view of the customer data.

 

Unified Desktop:                
The desktop UI seamlessly provides one front end used by customer facing agents (front of house) which is shared among several applications, covering variety of domains such as CRM, Billing, Ordering, Product Catalogue, Installed Repository Management, and Social Behavior Analysis.

 

Increased Efficiency:         
The shared front end desktop provides an immediate access to any required information during customer interaction. Immediate information access is achieved by minimized key strokes, reduced eye and mouse movement and focus on actionable data. These facilities allow agents to focus on customer service and quickly address raided issues.

 

Toolboxes:                        
Common persistent desktop areas which keep important information always available and enable easier navigation.

 

Contact Management Components

Find Caller

The Find Caller module is used to help the agent quickly identify the source of an incoming call and effectively link it with the relevant contact, service and product.

Depending on the context of the exchange, the agent can seamlessly employ, within the shared desktop, variety of complementary backend services to assist them quickly complete the interaction.

The Find Caller performs different database queries according to the context of the interaction. If the Multimedia Integrator is enabled, it automatically launches the Find Caller feature for inbound calls. If this application is not enabled, the agent can enter contact details and activate the search manually.

A manual search can also be used for outbound calls, for example when used in conjunction with a predictive dialing application.

Find Caller functions in Contact Manager in the same way as in other CRM Smart Client applications, and posts the Search: Contact and Account window as the default search option.

When a valid Billing Manager Client license is installed, Find Caller provides extended search functions for billing, subscription and mobile phone information.

  • Each CRM Smart Client application that deploys Find Caller uses its own server side search (i.e. Worker Bean) to launch the function. For Amdocs Customer Interaction Manager, the generic Find Caller worker bean FindCallerWB is extended by the application-specific worker bean FindCallerCIMWB.
  • Multiple applications can launch their special version of the Find Caller form. For example, Billing Manager, FindCallerWB is extended (by the Billing Manager worker bean FindCallerBMWB) to load its Find Caller version.

 

The following UI forms are commonly used by the contact manager module:

  • FindCallerToolbar.             Displays the current contact and account information on the application bar.
  • FindCallerCimSearch.        Contains the UI controls used for extended searches.

 

Find Caller Search Criteria

As discussed above, the Find Caller module provides two core search types:

  • Customer Interaction Manager Search
  • Billing Search

Each search type has two presentations, one for basic searches and one for extended searches.

 

The default Customer Interaction Manager search form contains the following search fields:

  • Phone
  • Account ID
  • First Name
  • Last Name
  • Email
  • Account Name
  • Customer ID
  • Customer Alias
  • Alternate Contact Method
  • Mobile
  • Serial Number
  • Billing Arrangement ID
  • Financial Arrangement ID

 

Automatic Find Caller

When the Multimedia Integrator is enabled, Find Caller is conducted automatically for incoming calls, and populates mobile phone number and subscription fields accordingly, when the details exist in the database.

 

 Anonymous Caller

Anonymous Caller is a caller who cannot be identified.

In the case where the initial Find Caller search does not find contact details in the database, Customer Interaction Manager allows the agent to assign the caller as Anonymous Caller. Details are then set to anonymous data and the agent enters new information for this caller.

 

Reason Codes

Reason codes refer to a three level hierarchical attributes structure which systematically describe the reason for the call and resulted action. These attributes can be later used for BI analysis.

Reason codes drive downstream processes and can launch relevant activities if necessary

Few reason codes examples are:

 

Visually, above reason codes are implemented as drop down lists, as shown in the following pictures:

   

 

Reason Codes Selection Flow

The Reason1, Reason2, and Result drop-down menus are formed by a hierarchical, user defined pop-up list (UDPL). When an CSR selects a Reason 1 topic, the application updates the list in the Reason 2 drop-down menu. The CSR can then select a Reason 2 topic that is specific to requirements.

 

In addition to the predefined lists of reason codes provided with the application, customized combinations of reason codes can be customized to implement any specific business logic requirements.

 

Topics

A topic represents set of reason codes, their result action and a possible linked object. An interaction may have one or multiple issues raised from one customer enquiry. Each issue represented by a topic. A Topic comprised of two reason codes and a result action code. Topic Tracks the issue(s) for the interaction.

 

Context Manager

An important part of the contact management is the Context Manager. The context manager allows handling several open interactions concurrently by providing the agent the ability for quick context switching between callers while they are on the line.

Interaction context gathers all information presented to the agent during the course of an interaction. Context switching refers to the ability to serve several calls simultaneously while keeping their complete interaction information immediately available by merely selecting the caller name.

The instant context switching (less than 1 sec) is technically achieved by caching all information in memory once it is retrieved from its persistent storage.

In the following pictures, the following two contexts are displayed:

 

Visually, above contexts are implemented in the UI as follows:

                                                                        Context 1

 

                                                                        Context 2

 

Action

Action specifies a result activity which is part of a topic. An action can be a single, short-duration activity, presenting a form, creation of a workflow object for a long duration handling process, or a complex business process which may drive one or more workflow objects.

 

Workflow Objects  

 Known also as workflow tasks, these objects represent continues task which may involve more than one owner during their life time. A workflow object represents any type of long duration task. Example for long duration tasks could be service assurance issues (cases), scheduled activities (Action Item), Change process (Change Request), Opportunity, Sales Quotation (Quote), Order, etc.  

A workflow object has a lifecycle, starting from its creation until it is closed. At any point of time a workflow object is owned by single owner. Ownership can be transferred between owners via intermediate parking lots named Queues.

Ownership is transferred only by mutual handshake process known as ‘Dispatch – Accept’.

A workflow object has several attributes which are continuously updated either explicitly or implicitly to reflect its handling position. The most notably attributes are ‘Condition’ and ‘Status’.

 

Only owners are allowed to change the workflow object’s status. Status changes must follow specific rules known as ‘Status Transition Map’. This map comprised of pre-defined set of rules which specify, for each status, one or more allowed target status values and the allowed role to perform the change.

 

Contact Management Implementation

Contact Management (or Customer Interaction Manager) UI is implemented using Amdocs Smart Client, a rich client architecture which provides flexibility of a Web application. Smart Client applications are deployed over the web and require minimal client-side installation. The front end UI is automatically updated without user intervention while providing the look and feel of a native desktop application.

Contact Manager UI provides the agent with the following operational areas:

  • Find Caller form
  • Interaction Home
  • Customer Overview toolbar
  • Multimedia Integrator toolbar
  • Interaction toolbox

 

 

Contact Management Events

 The Interaction Home page has Quick Action buttons for the several predefined events, such as Case, Action item, Literature request, Sales Opportunity, Sales Quote, Order, Pending credit and Promotion

The standard CIM implementation provides a number of predefined events.

 

  • The agent can trigger these events either by selecting a combination of reason codes or by clicking a Quick Action button on the Interaction Homepage.
  • Each Quick Action button (or reason code combination) uses a Launch Action function to launch the following sequence of events:
    • It may launch an application form (I.e.  CRM or Ordering applications)
    • It may launch an automation process (backend driven or UI driven)
    • It retrieves attributes from the Context Manager and passes them either to the launched form or process.

 This technique can be used to launch any window from any Amdocs CRM application in the interaction flow.

 

Implementing an Event with Reason Codes

Customization can add more functionality to the application or can tailor the application to meet any specific needs. Some commonly customized items include the following:

  • Launch actions
  • Launch wizard scripts
  • Interaction Home form
  • Toolbars
  • Toolboxes

 

 

 

10/01/2011 Posted by | Amdocs, BSS, CRM, CRM, Customer Interaction Management, Smart Client, Technology | 1 Comment

Interaction Management Process


Process Design Questionnaire

  • Who do your call center agents interact with?
  • Customers only?  Dealers?  Partners?
  • What types of interactions are received / sent out?
  • What is the structure of the call center?
  • What is the number of Agents?
  • Will these users be divided into functional groups?
  • Will users have access to some forms/commands/data and not others?
  • Number of Call centers?
  • Where are they located?
  • How many agents are there at each location?
  • What is the number of interactions handled per agent per day?
  • How do you measure your call center agents?

Generic Interaction Management Process – part 1

Generic Interaction Management Process – part 2

 

Generic Interaction Management Process – part 3

 

Generic Interaction Management Process – part 4

 

 

Generic Interaction Management Process – part 5

 

 

 

Sample Implementation Decisions


04/01/2011 Posted by | Amdocs, BSS, CRM, CRM, Customer Interaction Management | Leave a comment

   

%d bloggers like this: