|
|
| (3 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | {{SMART UseCase
| + | #REDIRECT [[UseCases/Current/GenesysEngage-onpremises/BO02]] |
| − | |ID=
| |
| − | |Title=
| |
| − | |Offering=
| |
| − | |SMART_Benefits={{SMART Benefits
| |
| − | |UCBenefitID=Improved Employee Occupancy
| |
| − | |UCBenefit=Prioritizing and presenting leads to sales reps reduces idle time, increases throughput and improves their utilization.
| |
| − | }}{{SMART Benefits
| |
| − | |UCBenefitID=Improved Employee Satisfaction
| |
| − | |UCBenefit=Automatic prioritization and distribution of leads prevents "cherry picking" and ensures fairer distribution of leads among team members.
| |
| − | }}{{SMART Benefits
| |
| − | |UCBenefitID=Reduced Administration Costs
| |
| − | |UCBenefit=Automatic lead distribution reduces time spent by supervisors and administration staff in monitoring, distributing and reporting on leads.
| |
| − | }}{{SMART Benefits
| |
| − | |UCBenefitID=Increased Revenue
| |
| − | |UCBenefit=Value-based prioritization speeds up response times for important leads, increasing conversion rates and revenue.
| |
| − | }}{{SMART Benefits
| |
| − | |UCBenefitID=Reduced Handle Time
| |
| − | |UCBenefit=Easy access to lead context speeds up familiarisation and handle time for sales reps.
| |
| − | }}{{SMART Benefits
| |
| − | |UCBenefitID=Improved Net Promoter Score
| |
| − | |UCBenefit=Automation of lead follow-up ensures faster responses to prospects, improving their experience.
| |
| − | }}
| |
| − | |UCIntro=The PS material for this use case has not been finalized. Please contact your local CSD for effort estimates and scope details of this use case.
| |
| − | |UCOverview=This functional use case has been created to enable Genesys customers to leverage the back office automation capabilities to manage their high value leads coming through their web or e-commerce sites or other external databases or lead sources. By using automated work distribution to capture, classify, prioritize and deliver the leads to appropriately skilled and available resources, companies can improve their lead conversion rates and throughput.
| |
| − | | |
| − | The ability to define business logic drives the proper prioritization and distribution of leads between the available resources and will therefore disable the “cherry picking” of leads and balance out the interactions between the available resources fairly and equally. Leads can be prioritized (and continuously re-prioritized) based on multiple business parameters as lead capture date, expected lead value, customer segment, change to convert, etc.
| |
| − | | |
| − | The history of the lead and the additional context information around the leads can be pushed together as one work-item and allows the sales enabled resources to understand what has happened in the past and assess the current status of the lead. Having more relevant and recent information available around the leads increases the chance for conversion by delivering more insights to the sales resources to figure out the best approach how to handle the leads in different circumstances.
| |
| − | | |
| − | '''Additional Context'''
| |
| − | | |
| − | The following diagram shows how iWD can improve Lead Management through the use of dynamic prioritization and delivery:
| |
| − | | |
| − | [[File:HighValueLeadManagementBenefits.png|Lead Handling without Prioritization]]
| |
| − | | |
| − | The above diagram shows how leads arrive into an enterprise; the leads are treated on a FIFO basis, whereby the available resources address the next lead in the queue. With iWD, prioritization rules are applied to "sort" the leads by value, to ensure that the fixed available resources always deal with the highest value and important leads. Leads are re prioritized overtime to ensure that time parameter is also taken inconsideration in the prioritization of the leads.
| |
| − | | |
| − | [[File:HighValueLeadManagementBenefits2.png|Lead Handling with Prioritization]] | |
| − | | |
| − | Genesys iWD can provide high value lead management by the following capabilities:
| |
| − | | |
| − | '''Lead Grading'''
| |
| − | | |
| − | *Genesys iWD solution is responsible for the capture, classification, prioritization of leads. The powerful Genesys Rules Engine defines and sorts the leads according to the business imperatives laid down by the business and supported by IT. This lead sorting is reviewed at regular time intervals to stay aligned with these Business imperatives. This means business users will manage the outcomes of the processing logic by changing or implementing business rules, through a simple business friendly GUI.
| |
| − | | |
| − | '''Lead Distribution'''
| |
| − | | |
| − | *In addition to the capture and prioritizing of leads, Genesys Enterprise Workload Management solution is also responsible for delivering the leads to the correct resource at the right time in order to convert the lead to a sale. This solution leverages the Genesys core routing engine to the back or front office, identifying the available resources with the required skill set and targeting the most urgent lead to that resource.
| |
| − | | |
| − | '''Benefits of iWD Lead Management'''
| |
| − | | |
| − | *Visibility into how leads are processed by employees
| |
| − | *“Managing” items for telesales and marketing rather than relying on people to choose their leads to work on
| |
| − | *Rigorously applying skills-based routing to match lead types to the right skilled resources
| |
| − | *Prioritizing and Re-Prioritizing leads based on various business rules
| |
| − | *Dynamically matching the demand of leads with the supply of skilled resources throughout the day
| |
| − | *Providing visibility through real-time and historic metrics
| |
| − | |UCSummary=A lead is shopping on the web site and abandons his shopping cart. These interactions are captured by the Web Site and delivered to the iWD solution as a "hot lead". The lead is captured from the Web Site, and then placed into the universal queue with a priority defined by the size of the shopping cart, the value of the product/ service and/or by any other information known about the lead (mobile customer segment etc.), the distribution of the lead to lead development representatives could be blended with voice calls. The lead is then continuously reprioritized based on business rules, which define the SLA. All voice / non-voice interactions are distributed to the best skilled lead development representative respecting their SLAs.
| |
| − | |Description=
| |
| − | |PainPoints=* No visibility into lead queues and backlogs
| |
| − | * Employees cherry pick work
| |
| − | * Leads are not handled by employees in time and may get lost
| |
| − | * Leads are pulled rather than pushed to employees
| |
| − | * Unable to plan omni-channel resourcing to match peak online activity
| |
| − | * Unable to measure and report on employee utilization
| |
| − | |DesiredState=* Single global list of tasks (both real-time and offline)
| |
| − | * Real time and continuous prioritization of leads
| |
| − | * Automation of SLA Management
| |
| − | * Consolidated Employee Desktop with full context of the lead
| |
| − | * Equitable distribution of leads across employee base
| |
| − | * Insights into workforce skills and proficiency
| |
| − | |BuyerPersonas=
| |
| − | |QualifyingQuestions=
| |
| − | |MaturityLevel=Defined
| |
| − | |SellableItems=CIM, CIM HA (Optional), Infomart, Genesys InfoMart – HA (Optional), GI2 for iWD (Business Objects), GI2 for iWD (Business Objects) - HA (Optional), Workspace Desktop Edition, intelligent Workload Distribution, iWD - Back Office (Optional)
| |
| − | |CloudAssumptions=
| |
| − | |CloudAssumptionsAdditional_Sales=
| |
| − | |PremiseAssumptions=
| |
| − | |PremiseAssumptionsAdditional_Sales=* This use case is available on Premise
| |
| − | |BusinessImageFlow={{SMART BusinessImageFlow
| |
| − | |BusinessFlow=====Lead Capture (out of scope for the use case)====
| |
| − | Lead Capture (out of scope for the use case) The logic, which triggers the creation of a lead within Genesys, depends on the web site and is out of the scope of this use case. When a lead is detected logic on the company web site or lead capture system will create a new lead within Genesys. A typical scenario is an abandoned shopping cart event as is shown in the following diagram:
| |
| − | |BusinessImage=https://www.lucidchart.com/documents/edit/c285a330-2cac-4352-8b20-f211fcbf7e4f/0
| |
| − | |BusinessFlowDescription=====Lead Capture (out of scope for the use case)====
| |
| − | | |
| − | # A lead browses the web site of the company.
| |
| − | # He is identified using a lead management system or himself by using his customer account or by providig further information on the web site.
| |
| − | # He places one or multiple items in his shopping card. If he proceeds to check-out, no further action occurs.
| |
| − | # If he does not proceed with his buying process or closes the browser, a lead is generated. All relevant data is collected by the web site and the lead is created in Genesys for distribution to a lead development representative.
| |
| − | }}{{SMART BusinessImageFlow
| |
| − | |BusinessFlow=====Business Flow - Distribution====
| |
| − | The following diagram shows the business flow of the use case:
| |
| − | |BusinessImage=https://www.lucidchart.com/documents/edit/118824f4-6d06-4cad-821e-8df9ad4821ef/0
| |
| − | |BusinessFlowDescription=====Business Flow - Distribution====
| |
| − | | |
| − | # A new lead is created in the system with all attached data necessary to process the lead (see chapter “Attributes”).
| |
| − | # The web site creates a new task in Genesys via one of the Genesys capture adapters.
| |
| − | # The interaction is classified and prioritized according to specific lead rules and the business value of the lead.
| |
| − | #* The rules are applied according to the lead attributes.
| |
| − | #* If the lead comes from a non-authenticated customer (with only contact details available), then the value of the basket (or potential sales item) or product category are used to calculate the priority and/or business value.
| |
| − | #* If the lead is a known customer (authenticated in the web site), then additional customer attributes could be used for the prioritization process.
| |
| − | #* The leads are reprioritized in certain periods of time if the lead is not distributed to a lead development representative before.
| |
| − | # The lead is queued with all other interactions in the system. The priority of the lead defines the position of the lead in the universal queue. Once a lead development representative with the right skill becomes available to handle the lead, the lead is distributed to the lead development representative. If it is not assigned within a specified period of time, it is re-prioritized.
| |
| − | # If the lead is assigned to a lead development representative, the lead development representative will open the lead in the Workspace Desktop to manage and/or complete the interaction. The lead development representative desktop will display reference data to the lead (see section “Data presentation to a lead development representative”) and the associated contact details.
| |
| − | # The lead development representative will handle the lead and attempt to call the lead using the provided contact data.
| |
| − | }}{{SMART BusinessImageFlow
| |
| − | |BusinessFlow=====Business Flow - Lead Handling====
| |
| − | |BusinessImage=https://www.lucidchart.com/documents/edit/8977843f-84ce-418c-9121-aca541bbc985/0
| |
| − | |BusinessFlowDescription=====Business Flow - Lead Handling====
| |
| − | | |
| − | # The lead development representative will make an outbound call to the customerlead to convert the sale. There could be various results from this call attempt
| |
| − | # Lead is reached:
| |
| − | #* The lead development representative reaches the lead and attempts to convert the sale.
| |
| − | #* After the call he records the result for reporting purposes (converted, not converted).
| |
| − | #* He finishes his work on the sale via the desktop (“mark done”) and the lead progresing to onboarding as a customer.
| |
| − | # Call needs to be rescheduled.
| |
| − | #* The lead development representative reaches the lead, but the lead wants to have the conversation at a different time.
| |
| − | #* The lead development representative reschedules the call to a specific date and time via his lead development representative desktop and finishes his work on the lead.
| |
| − | #* The system will check if the maximum number of reschedule attempts are reached.
| |
| − | #** If not, the lead is prioritized and queued again when the rescheduled date and time is reached.
| |
| − | #** If yes, the lead will automatically be completed with call result = “max rescheduled”
| |
| − | # Lead cannot be reached
| |
| − | #* In this scenario, the lead development representative cannot reach the lead.
| |
| − | #* He sets the corresponding result and finishes his work on the lead (“mark done”).
| |
| − | #* The system will check if the maximum number of call attempts are reached:
| |
| − | #** If not, the lead is automatically rescheduled within 2 business hours. When the rescheduled time is reached, the lead is prioritized and queued again.
| |
| − | #** If yes, the lead will automatically be completed with call result = “no answer”.
| |
| − | }}
| |
| − | |BusinessLogic=====Attributes====
| |
| − | Lead classification and prioritization in IWD is based on business rules. In order to apply these business rules within IWD, a set of business attributes (parameters) are passed to iWD in the capture event.
| |
| − | | |
| − | iWD's data model separates lead data into three types of attributes:
| |
| − | * Core attributes
| |
| − | * Extended attributes
| |
| − | * Custom attributes
| |
| − | | |
| − | The attributes are used for one or multiple of the following purposes:
| |
| − | * Classification Rules (See chapter “Business Context and Classification Rules” )
| |
| − | * Prioritization Rules (see chapter “Priority Rules”)
| |
| − | * For display within the agent desktop.
| |
| − | | |
| − | The following table lists the attributes which are available as part of this use case. The table also shows for which purpose the attribute is used :
| |
| − | {{{!}} class="wikitable"
| |
| − | {{!}}-
| |
| − | !{{!}}Attribute
| |
| − | !{{!}}Description
| |
| − | !{{!}}Classification
| |
| − | !{{!}}Prioritization
| |
| − | !{{!}}Agent Display
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Capture ID
| |
| − | {{!}}{{!}}Mandatory ID to identify the lead
| |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Contact Number
| |
| − | {{!}}{{!}}Contact number to call the customer
| |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Alternative Contact Number
| |
| − | {{!}}{{!}}Alternative contact number to call the customer
| |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Name
| |
| − | {{!}}{{!}}Customer Name
| |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Surname
| |
| − | {{!}}{{!}}Customer Surname
| |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Customer Segment
| |
| − | {{!}}{{!}}To be mapped to a business attribute by the organization
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Customer ID
| |
| − | {{!}}{{!}}ID to identify the customer in a third party system
| |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Product
| |
| − | {{!}}{{!}}To be mapped to a business attribute by the organization
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Sub product
| |
| − | {{!}}{{!}}To be mapped to a business attribute by the organization
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Deal Value
| |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Type of request
| |
| − | {{!}}{{!}}To be mapped to a business attribute by the organization
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Lead Description
| |
| − | {{!}}{{!}}A short text to provide information to the agent on the lead (max. 30 characters)
| |
| − | {{!}}}
| |
| − | | |
| − | | |
| − | | |
| − | Please note that the IWD data model contains more attributes, however the table focusses on the attributes which are actively used within the configuration of this use case for one of the three purposes listed above.
| |
| − | ====Business Rules====
| |
| − | This chapter describes the business rules which are used to classify and to prioritize an interaction.
| |
| − | For the lead management rules, a basic prioritization and SLA are defined by the value of the lead. The following diagram shows an example for a basic lead prioritization for the lead SLAs:
| |
| − | | |
| − | [[File:HighValueLeadManagementBusinessRules1.png|Logical Prioritization]]
| |
| − | | |
| − | To define the best set of rules the operating principles and constraints of an organization have to be defined. Example: “Customers with a product bundle worth 200 Euro receives call within 12 hours”.
| |
| − | | |
| − | | |
| − | Rules will use attributes from the captured lead to map these principles to the system, i.e. to classify the interaction in a particular process, set the priority according to the requested SLA and to assign it to the proper group of agents. The position of the interaction in the queue to be distributed is determined by the priority.
| |
| − | ====Business Context and Classification Rules====
| |
| − | Within IWD every lead is assigned to an IWD Department and an IWD Process. IWD Departments and IWD Processes are used as reporting dimensions and to organize rules. The leads are assigned after they are captured by the system based on the classification rules.
| |
| − | | |
| − | The configuration for this functional case includes up to 5 departments and up to 10 processes within each department.
| |
| − | | |
| − | The following picture shows an example of two IWD departments and various IWD processes.
| |
| − | | |
| − | All the leads captured from the Web Site are assigned to one of these departments and to one of the processes within the department. To complete this assignment, business rules are applied. The following table shows an example for classification rules (the input parameters may vary depending on the requirements of the organization):
| |
| − | | |
| − | | |
| − | [[File:HighValueLeadManagementDepartments.png|Example: Departments and Processes]]
| |
| − | | |
| − | | |
| − | {{{!}} class="wikitable"
| |
| − | {{!}}-
| |
| − | ! colspan="3"{{!}}Input Parameters
| |
| − | ! colspan="2"{{!}}Output Parameters
| |
| − | {{!}}-
| |
| − | !{{!}}'''Request Type'''
| |
| − | !{{!}}'''Product'''
| |
| − | !{{!}}'''Sub Product'''
| |
| − | !{{!}}'''IWD Department'''
| |
| − | !{{!}}'''IWD Process'''
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Data Packages
| |
| − | {{!}}{{!}}Add. Data Package
| |
| − | {{!}}{{!}}Gold
| |
| − | {{!}}{{!}}Data Packages
| |
| − | {{!}}{{!}}Add. Data Package
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Data Packages
| |
| − | {{!}}{{!}}Add. Data Package
| |
| − | {{!}}{{!}}Platinum
| |
| − | {{!}}{{!}}Data Packages
| |
| − | {{!}}{{!}}Add. Data Package
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Data Packages
| |
| − | {{!}}{{!}}Roaming
| |
| − | {{!}}{{!}}Europe
| |
| − | {{!}}{{!}}Data Packages
| |
| − | {{!}}{{!}}Roaming
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Sales
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}Apple
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}Apple
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Sales
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}Samsung
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}Samsung
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Sales
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}Microsoft
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}Microsoft
| |
| − | {{!}}}
| |
| − | If the necessary attributes for lead classification are not provided from the web site, a default department and process is assigned to the lead.
| |
| − | ====Priority Rules====
| |
| − | ====='''SLA and Calculation of Due Dates'''=====
| |
| − | A) New Leads
| |
| − | | |
| − | The SLA provides the time interval in which the lead should be distributed to a lead development representative.
| |
| − | | |
| − | It is set via business rules using the attributes described above. An example is provided in the table below (the input parameters may vary depending on the requirements of the organization):
| |
| − | | |
| − | | |
| − | {{{!}} class="wikitable"
| |
| − | {{!}}-
| |
| − | ! colspan="3"{{!}}'''Input Parameters'''
| |
| − | ! colspan="5"{{!}}Output Parameters
| |
| − | {{!}}-
| |
| − | !{{!}}iWD Department
| |
| − | !{{!}}iWD Process
| |
| − | !{{!}}Deal Value
| |
| − | !{{!}}Overflow timeout 1 (optional)
| |
| − | !{{!}}Overflow timeout 2 (optional)
| |
| − | !{{!}}LAR timeout
| |
| − | !{{!}}SLA
| |
| − | !{{!}}Business Calendar
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}*
| |
| − | {{!}}{{!}}1-199
| |
| − | {{!}}{{!}}18
| |
| − | {{!}}{{!}}22
| |
| − | {{!}}{{!}}16
| |
| − | {{!}}{{!}}24
| |
| − | {{!}}{{!}}Mo-Fri 8 to 20
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}*
| |
| − | {{!}}{{!}}200-399
| |
| − | {{!}}{{!}}8
| |
| − | {{!}}{{!}}10
| |
| − | {{!}}{{!}}6
| |
| − | {{!}}{{!}}12
| |
| − | {{!}}{{!}}Mo-Fri 8 to 20
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}*
| |
| − | {{!}}{{!}}400-and more
| |
| − | {{!}}{{!}}4
| |
| − | {{!}}{{!}}5
| |
| − | {{!}}{{!}}3
| |
| − | {{!}}{{!}}6
| |
| − | {{!}}{{!}}Mo-Fri 8 to 20
| |
| − | {{!}}}
| |
| − | | |
| − | | |
| − | | |
| − | The due date for a lead is calculated from the SLA starting with the creation time of the lead in Genesys. The overflow times to the secondary and tertiary target and the last agent (LAR) are calculated in a similar way.
| |
| − | | |
| − | See section “Business Calendar” for a description of the role of the business calendar.
| |
| − | | |
| − | '''B) Rescheduled and Not OK leads'''
| |
| − | | |
| − | Due date and overflow times will remain the same after a lead is manually rescheduled or automatically rescheduled because the customer could not be reached.
| |
| − | =====Lead Priority=====
| |
| − | '''A) Priority Calculation for new Leads'''
| |
| − | | |
| − | The lead priority is set as linear dependency between submit date time, due date time, initial priority, reprioritization increment and reprioritization interval. Maximal priority Value which is reached at the due time, will be computed based on the previous values. This allows to sort the universal queue according to closeness to the respective SLA, so that the leads which are on top of the queue are those closest to their due date and the High value for the organization represented by the initial priority value.
| |
| − | | |
| − | The lead priority is recalculated during each reprioritization interval based on the following parameters:
| |
| − | * Initial priority
| |
| − | * Reprioritization increment
| |
| − | * Reprioritization interval
| |
| − | * Lead Creation Time
| |
| − | * Current date and time
| |
| − | * Due date and time
| |
| − | | |
| − | The following shows the priority graph for the lead :
| |
| − | | |
| − | [[File:HighValueLeadManagementPriorityGraph.png|Lead Prioritization Example Graph]]
| |
| − | | |
| − | Please note that reprioritization will not stop outside business hours. The formula which is used to calculate lead priority is explained the Appendix.
| |
| − | | |
| − | The parameters needed for the calculation are configurable via business rules. An example is shown in the table below (the input parameters may vary depending on the requirements for the organization):
| |
| − | {{{!}} class="wikitable"
| |
| − | {{!}}-
| |
| − | ! colspan="2"{{!}}Input Parameters
| |
| − | ! colspan="6"{{!}}Output Parameters
| |
| − | {{!}}-
| |
| − | !{{!}}iWD Department
| |
| − | !{{!}}Deal Value
| |
| − | !{{!}}Initial Priority
| |
| − | !{{!}}Repriorit. Increment
| |
| − | !{{!}}Overdue Priority
| |
| − | !{{!}}Reprio interval
| |
| − | !{{!}}units
| |
| − | !{{!}}Priority Max (calculated)
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}abandoned_cart
| |
| − | {{!}}{{!}}1-199
| |
| − | {{!}}{{!}}100
| |
| − | {{!}}{{!}}37,5
| |
| − | {{!}}{{!}}1001
| |
| − | {{!}}{{!}}1
| |
| − | {{!}}{{!}}hour
| |
| − | {{!}}{{!}}1000
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}abandoned_cart
| |
| − | {{!}}{{!}}200-399
| |
| − | {{!}}{{!}}600
| |
| − | {{!}}{{!}}37,5
| |
| − | {{!}}{{!}}1054
| |
| − | {{!}}{{!}}1
| |
| − | {{!}}{{!}}hour
| |
| − | {{!}}{{!}}1050
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}abandoned_cart
| |
| − | {{!}}{{!}}400-and more
| |
| − | {{!}}{{!}}875
| |
| − | {{!}}{{!}}37,5
| |
| − | {{!}}{{!}}1108
| |
| − | {{!}}{{!}}1
| |
| − | {{!}}{{!}}hour
| |
| − | {{!}}{{!}}1100
| |
| − | {{!}}}
| |
| − | The following graph represents the evolution of the priority over time for the 3 examples of the above table:
| |
| − | | |
| − | | |
| − | '''B) Priority for unsuccesful leads'''
| |
| − | | |
| − | The priority for leads which need to be distributed again because the lead development representative could not reach the customer is calculated with the same logic as for new lead with two modifications:
| |
| − | * Initial priority and maximum priority is increased by a value depending on the number of attempts.
| |
| − | * The priority formula is based on the rescheduled data and time instead of the lead creation time.
| |
| − | | |
| − | A side effect of this configuration is that older multiple unsuccessful leads are mixed with new leads or leads with fewer unsuccesful attempts. The priority of leads with multiple unsuccessful attempts will increase faster than the priority of leads with less unsuccessful attempts.
| |
| − | | |
| − | The following shows a priority graph for a lead which has been rescheduled multiple times:
| |
| − | | |
| − | [[File:HighValueLeadManagementPriorityGraphUnsuccessful.png|thumbnail|Priority for rescheduled leads]]
| |
| − | | |
| − | '''C) Priority for manually rescheduled leads'''
| |
| − | | |
| − | The number of priority points for leads which have been manually rescheduled by a lead development representative on the customer's request are set to maximum to keep the call back promise made to the customer. The setting of priority in this case will also be configurable based on business rules.
| |
| − | | |
| − | '''D) Priority for overdue leads'''
| |
| − | | |
| − | When a lead reaches the due date, the priority is set to the overdue priority and is not changed after this. This overdue priority is set in the same priority rules as described in the section “Priority Rules”. For unsuccessful leads (Not OK), the overdue priority is increased based on the current attempt number.
| |
| − | ====Business Calendar====
| |
| − | A business calendar is used to reflect working hours of the organization. This avoids setting a due date to an out-of- office hour. (Please note that lead prioritization will still continue during out of office hours corresponding to the linear model described above). SLA, T1 and the overflow time outs are calculated from the lead creation or activation date excluding the out-of-office hours.
| |
| − | | |
| − | One business calendar is configured as part of this use case.
| |
| − | ====Lead Lifecycle====
| |
| − | As described within the business flow above, various options exist for the lead once it is distributed to the lead development representative desktop. This chapter provides details on the functionality provided for these options.
| |
| − | =====Lead Completion=====
| |
| − | Once a lead is delivered to a lead development representative, the lead development representative will:
| |
| − | * Call the customer to reach him on the number delivered with the lead.
| |
| − | * He is connected to the customer and potentially converts the lead.
| |
| − | * The lead development representative will set the call result according to the outcome (converted, not converted) and will finish the lead handling within the lead development representative desktop. In this case, the iWD lead interaction is completed and the lead is archived.
| |
| − | In this case, the iWD lead interaction is completed and the lead is archived.
| |
| − | | |
| − | =====Reschedule Lead=====
| |
| − | Once a lead is delivered to a lead development representative, the lead development representative will:
| |
| − | * Call the customer to reach him on the number delivered with the lead.
| |
| − | * He is connected to the customer, but the customer asks to reschedule the call.
| |
| − | * The lead development representative sets the reschedule time and date in the lead development representative desktop and finishes the lead handling.
| |
| − | | |
| − | In this case, the lead is processed again by IWD using the reschedule date as activation date, i.e. IWD will not attempt to distribute the lead to a lead development representative before the activation date. Once the activation date is reached, the lead will prioritized according to the rule described above. IWD will attempt to distribute to the same lead development representative who rescheduled the lead. However, if this is not possible within a configurable time out, the lead is queued for the corresponding skill.
| |
| − | | |
| − | A counter for rescheduled leads is increased after each rescheduling by a lead development representative. The number of maximum rescheduling is configurable. Once this number is reached, the lead development representative cannot reschedule the lead again and the lead development representative needs to close the lead with a corresponding call result. However, if the lead development representative reschedules by mistake the lead is completed automatically with call result =” max rescheduled”.
| |
| − | =====Unsuccessful call attempt=====
| |
| − | Once a lead is delivered to a lead development representative, the lead development representative will:
| |
| − | * Call the customer to reach him on the number delivered with the lead.
| |
| − | * He cannot reach the customer and sets the call result to “Not OK”.
| |
| − | * The lead development representative finishes the lead handling in the lead development representative desktop and is ready for new leads.
| |
| − | | |
| − | In this case, the lead is processed again by IWD using the reschedule date as activation date, i.e. IWD will not attempt to distribute the lead to a lead development representative before the activation date. Once the activation date is reached, the lead will prioritized according to the rule described above. IWD will attempt to distribute to the same lead development representative who rescheduled the lead. However, if this is not possible within a configurable time out, the lead is queued for the corresponding skill.
| |
| − | | |
| − | A counter for Not OK leads is increased after each unsuccessful call attempt by a lead development representative. The number of maximum retries is configurable. Once this number is reached the lead is completed automatically once the lead development representative finished the lead handling. The call result is set to “no answer”.
| |
| − | =====Lead goes end of life=====
| |
| − | If a lead could not be distributed to a lead development representative within a configurable amount of time (e.g. 24 hours) the lead is automatically completed. This is based on the general observation that customers are reached quickly after they visited the web site to be able to successfully handle the lead. Lead conversion probability drops if the lead development representative call is too late. Additional Business Logic In a blended environment, the configuration of maximum and minimum priority must be synchronized with the priority settings of other media types.
| |
| − | | |
| − | | |
| − | ====Additional Business Logic====
| |
| − | In a blended environment, the configuration of maximum and minimum priority must be synchronized with the priority settings of other media types.
| |
| − | |DistributionImageFlow={{SMART DistributionImageFlow
| |
| − | |DistributionFlowIntro=The following diagram shows the distribution flow:
| |
| − | |DistributionImage=https://www.lucidchart.com/documents/edit/acb40a6d-c782-4354-b493-aedab7efd408/0
| |
| − | |DistributionFlowDescription=# A lead needs to be distributed.
| |
| − | # If the lead has been rescheduled, Genesys will attempt to distribute the task to the last lead development representative until a configurable time out is reached. After this time out the distribution will be to the primary target for this task defined by all lead development representatives with a specific skill / skill level.
| |
| − | # If the lead cannot be distributed to the primary target within a configurable time out, Genesys will expand distribution to the secondary target.
| |
| − | # If the lead cannot be distributed to the secondary target within a configurable time out, Genesys will expand distribution to the tertiary target.
| |
| − | # Genesys will wait for a lead development representative satisfying the skill / skill level requirements for the tertiary target until the task can be distributed.
| |
| − | | |
| − | The time out values for the overflow logic is related to the SLA of a lead and is therefore be set by the same business rules which define the SLA (see chapter “SLA and calculation of due date”).
| |
| − | }}
| |
| − | |DistributionLogic=====Routing to Last lead development representative====
| |
| − | If a lead development representative reschedules the lead, the distribution logic will first attempt to distribute to a same lead development representative. If the lead cannot be distributed to this lead development representative within a specific time out, routing to the skill is applied. This timeout is configurable by IWD Department and Process. Distribution Flow
| |
| − | ====Skill based routing====
| |
| − | This use case is provided with a predefined routing strategy that creates all the queues needed to assign a lead to a specific lead development representative. The routing strategy is based on distribution via skill, ensuring that a lead is distributed to the best suitable lead development representative independent on his place in the organization.
| |
| − | | |
| − | | |
| − | The required skill is defined by the IWD department and IWD process the lead belongs to (see section “Business Context and Classification Rules” for the logic to define IWD department and process).
| |
| − | | |
| − | | |
| − | Each lead development representative will have one or more skills associated to their profile and a skill level associated to each skill, referred to in this document as proficiencies. The skill level is used to define primary, secondary and tertiary targets within the routing logic described below.
| |
| − | | |
| − | | |
| − | The targets are defined as follows:
| |
| − | * Primary target = lead development representatives with base skill level > N
| |
| − | * Secondary target = lead development representatives with base skill level > M
| |
| − | * Tertiary target = lead development representatives with base skill level > P
| |
| − | | |
| − | | |
| − | The values for N, M, and P are configurable based on IWD Department and Process.
| |
| − | |CustomerInterfaceRequirements=N/A
| |
| − | |AgentDeskRequirements===== Lead handling related functionality ====
| |
| − | | |
| − | The lead development representative desktop provides sets of functionalities which are related to:
| |
| − | *Lead processing from iWD
| |
| − | *Auto vs. manual answer
| |
| − | *Rescheduling of the call by setting a reschedule date and time.
| |
| − | *Dispositions codes to record the call result. Up to 15 different disposition codes are configured within the solution. Some of these are used for reporting purposes only, but some disposition codes are used to record that a customer could not be reached and must be set appropriately to enable the corresponding functionality.
| |
| − | *In case Genesys Voice Routing is used by the organization, automatic click-to-call to the customer phone number is provided.
| |
| − | | |
| − | ==== Data Presentation to a lead development representative ====
| |
| − | | |
| − | The data set which is displayed to the lead development representative are: :
| |
| − | *Contact number of the lead
| |
| − | *Alternative contact number (if available via the web site)
| |
| − | *Name (if available via the web site)
| |
| − | *Surname (if available via the web site)
| |
| − | *Type of request
| |
| − | *Deal Description
| |
| − | *Deal Value
| |
| − | *Product and Sub-Product (if available via the web site)
| |
| − | *Number of reschedule attempts
| |
| − | | |
| − | ==== General functionality ====
| |
| − | | |
| − | The interaction workspace application will provide following functionalities:
| |
| − | *The lead development representative desktop will have multiple not-ready reason codes configured (Admin Work, Break, Lunch, Meeting, Pause, RONA and Training).
| |
| − | | |
| − | ==== Statistics Displayed on lead development representative Desk ====
| |
| − | | |
| − | The required statistics to be presented at lead development representative desktop consist from lead development representative, status and interactions statistics. The status statistics are:
| |
| − | | |
| − | *Logged in time (total for current day)
| |
| − | *Ready time (total for current day)
| |
| − | | |
| − | Time related statistics are:
| |
| − | | |
| − | *Call handling time (total for current day)
| |
| − | | |
| − | The lead handling statistics are:
| |
| − | | |
| − | *Number leads received (total, for current day)
| |
| − | *Number calls made (total for current day)
| |
| − | |RealTimeReporting=The iWD out of the box Pulse templates can provide the following reports in Pulse:
| |
| − | | |
| − | IWD lead development representative Activity: A report presenting lead development representative or lead development representative group activity as it relates to the processing iWD work items type contacts.
| |
| − | | |
| − | IWD Queue Activity: A queue report presenting an overview of current or near real-time activity associated with the iWD queues.
| |
| − | | |
| − | The following diagram shows a typical dashboard configured with iWD templates for work item monitoring.
| |
| − | | |
| − | [[File:HighValueLeadManagementPulse1.png|thumbnail|Example of Genesys Pulse Workitem Display]]
| |
| − | |HistoricalReporting=Interactive Insights for IWD is used to provide historical reporting. The IWD department and process provide the dimensions for out-of-the box aggregated information in iWD Datamart for them.
| |
| − | | |
| − | Additional dimensions include:
| |
| − | | |
| − | *Customer Segment
| |
| − | *Type of request
| |
| − | *Deal Value ranges
| |
| − | *Product
| |
| − | *Call Result
| |
| − | | |
| − | Lead perspective reports are listed in table below. The dimensions are shown in the columns and reports and report types are defined in rows.
| |
| − | Report details are:
| |
| − | | |
| − | *N_COMPLETED_IN_SLA, number for leads completed before due date was reached
| |
| − | *N_COMPLETED_OUT_SLA, number for leads completed before due date was reached
| |
| − | *T_WAIT, is total waiting time of interactions from dispatch till assign
| |
| − | *T_HANDLING_TIME, is total handling time of interactions by a lead development representative, time when interactions are assigned
| |
| − | *T_PROCESSING, is time from created till completed interaction status.
| |
| − | | |
| − | From lead development representative perspectives have been following statistics defined:
| |
| − | | |
| − | Lead disposition code needs to be stored into separate attached data, each time when lead is processed by a lead development representative.
| |
| − | |GeneralAssumptions=
| |
| − | |CustomerAssumptions=*Genesys standard Web Service Adapter, Database Adapter or xml file adapter to be used for source system integration.
| |
| − | *Customer will handle the integration between the web site and Genesys IWD needed to create leads for leads.
| |
| − | *Any changes within the web site which is needed for the integration with Genesys are within the customer responsibility.
| |
| − | *Genesys Interactive Insights for IWD is used for historical reporting.
| |
| − | *Workspace Desktop Edition (WDE) is used as lead development representative desktop.
| |
| − | *Up to 5 departments with 10 processes each are configured as part of this use case.
| |
| − | *Standard rules templates to be used to define all the classification and prioritization rules plus the addition of Java functions for priority calculations.
| |
| − | *Pulse is used for real-time reporting.
| |
| − | |RequiresAll=
| |
| − | |RequiresOr=
| |
| − | |Optional=
| |
| − | |Exceptions=
| |
| − | |SMART_PremiseAssumptions=
| |
| − | |PremiseAssumptionsAdditional=This use case is available in Premise
| |
| − | |SMART_CloudAssumptions={{SMART CloudAssumptions
| |
| − | |Cloud_Assumption=This use case is not available in the cloud
| |
| − | }}
| |
| − | |CloudAssumptionsAdditional=
| |
| − | |SMART_HybridAssumptions=
| |
| − | |Requires=
| |
| − | |Conditions=
| |
| − | |DocVersion=v 1.0.2
| |
| − | }}
| |
