|
|
| (8 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | {{SMART UseCase
| + | #REDIRECT [[UseCases/Current/GenesysEngage-cloud/BO02]] |
| − | |SMART_Benefits={{SMART Benefits
| |
| − | |UCBenefitID=Improved Employee Utilization
| |
| − | |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 Customer Experience
| |
| − | |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 intelligent Workload 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 into the sales resources to figure out the best approach on how to handle the leads in different circumstances.
| |
| − | | |
| − | '''Additional Context'''
| |
| − | | |
| − | The following diagram shows how intelligent Workload Distribution (iWD) can improve Lead Management through the use of dynamic prioritization and delivery:
| |
| − | | |
| − | [[File:HighValueLeadManagementBenefits.png|Lead Handling without Prioritization]] | |
| − | | |
| − | <!-- NewPP limit reportCPU time usage: 0.007 secondsReal time usage: 0.007 secondsPreprocessor visited node count: 1/1000000Preprocessor generated node count: 4/1000000Post‐expand include size: 0/10485760 bytesTemplate argument size: 0/10485760 bytesHighest expansion depth: 1/40Expensive parser function count: 0/100-->
| |
| − | | |
| − | | |
| − | <!-- Transclusion expansion time report (%,ms,calls,template)100.00% 0.000 1 - -total-->
| |
| − | | |
| − | The above diagram shows how leads arriveing in a sales and marketing organization; the leads are treated on a First In First Out (FIFO) basis, whereby the available resources address the next lead in the queue. With <span>intelligent Workload Distribution</span>, 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 over time to ensure that the time parameter is also taken into consideration in the prioritization of the leads.
| |
| − | | |
| − | [[File:HighValueLeadManagementBenefits2.png|Lead Handling with Prioritization]]
| |
| − | | |
| − | Genesys <span>intelligent Workload Distribution</span> provides high-value lead management through the following capabilities:
| |
| − | | |
| − | '''Lead Grading'''<ul><li>Genesys <span>intelligent Workload Distribution</span> is responsible for the capture, classification, prioritization of leads. The powerful Genesys intelligent <span>Workload Distribution Manager</span> (iWD Manager) defines and sorts the leads according to the business imperatives laid down by the business and enabled through the cloud with minimal IT support. This lead sorting is continually applied to stay aligned with your Business Imperatives. This means business users manage the outcomes of the processing logic, changing or implementing business rules, through a simple business-friendly web-based interface.</li></ul>
| |
| − | | |
| − | '''Lead Distribution'''<ul><li>In addition to the capture and prioritizing of leads, Genesys <span>intelligent Workload Distribution</span> is also responsible for delivering the leads to the correct resource at the right time in order to convert the lead. This solution leverages the Genesys core routing engine for leads, work items in the back or front office, Genesys channels and identifying the available resources with the required skill/proficiency set and matching the hottest lead with the resource.</li></ul>
| |
| − | | |
| − | '''Benefits of iWD Lead Management'''<ul><li>Visibility into how leads are processed by employees </li><li>“Managing” items for telesales, lead development representatives and marketing rather than relying on people to cherry-pick the leads to progress</li><li>Rigorously applying skills-based routing to match segmented leads with the best-skilled employee</li><li>Prioritizing and re-prioritizing leads based on various business values at that moment in time</li><li>Dynamically matching the demand of leads with the supply of skilled resources throughout the day </li><li>Providing visibility through real-time and historical metrics</li><li>Providing the necessary data for workforce management and optimization</li></ul>
| |
| − | |UCSummary=A lead is shopping on the online shop and abandons their shopping cart. These interactions are captured by the website and delivered to the <span>intelligent Workload Distribution</span> solution as a "hot lead". The lead is captured from the website, and then placed into the universal queue with a priority schema defined by the size of the shopping cart, the value of the product/ service and/or by any other data points known about the lead (mobile customer segment, etc.), the distribution of the lead to lead development representatives is optionally blended with other work such as chat or voice leads. The lead is then continuously reprioritized based on business rules, which define the service level. All voice / non-voice interactions are distributed to the best-skilled lead development representative respecting their service level agreements.
| |
| − | |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=Head of Sales, Head of Ecommerce, Head of Business Units
| |
| − | |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)
| |
| − | |CloudAssumptionsAdditional_Sales=Capabilities Assumption: Not available for Partner Cloud but iWD Cloud is available for partners of PureEngage Cloud to sell
| |
| − | |PremiseAssumptionsAdditional_Sales=Capabilities Assumption: Not Applicable
| |
| − | |BusinessImageFlow={{SMART BusinessImageFlow
| |
| − | |BusinessFlow=====Lead Capture (out of scope for the use case)====
| |
| − | The logic, which triggers the creation of a lead within Genesys, depends on the website and is out of the scope of this use case. When a lead is detected logic on the company website 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 website or customer portal of the company.
| |
| − | #He is identified using a lead management system or himself by using his customer account or by providing further information on the website.
| |
| − | #He places one or multiple items in his shopping cart. 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 website 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 website creates a new task in Genesys via the Genesys capture adapter.
| |
| − | #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, then additional customer attributes could be used for the prioritization process.
| |
| − | #*The leads are constantly reprioritized if the lead is not distributed to a lead development representative.
| |
| − | #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 and proficicency level 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 continues to be 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 sale. The lead development representative desktop will display reference data about 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 makes an outbound call to the customer lead 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 progressing to on-boarding as a customer.
| |
| − | #If the call attempt fails, The advisor records the outcome and either parks the lead in their workbin or returns the lead to the queue.
| |
| − | }}
| |
| − | |BusinessLogic=====Attributes====
| |
| − | Lead classification and prioritization in intelligent Workload Distribution are based on business rules. In order to apply these business rules within intelligent Workload Distribution, a set of business attributes (parameters) are passed to iWD in the capture event.
| |
| − | | |
| − | intelligent Workload Distribution data model separates lead data into two types of attributes:
| |
| − | | |
| − | *Core attributes
| |
| − | *<span style="color: rgb(0, 0, 0);" data-mce-style="color: #000000;">Custom attributes </span>
| |
| − | | |
| − | The attributes are used for one or multiple of the following purposes:
| |
| − | | |
| − | *Segmentation (See chapter “Business Context and Segmentation” )
| |
| − | *Prioritization (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
| |
| − | !{{!}}Segmentation
| |
| − | !{{!}}Prioritization
| |
| − | !{{!}}Agent Display
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}External 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
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Subproduct
| |
| − | {{!}}{{!}}To be mapped to a business attribute by the organization
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}{{!}}X
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Deal Value
| |
| − | {{!}}{{!}}The actual or estimated value of the lead
| |
| − | | |
| − | {{!}}{{!}}
| |
| − | | |
| − | {{!}}{{!}}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 intelligent Workload Distribution 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 a lead.
| |
| − | For the lead management rules, basic prioritization, and due date and time are defined by the value of the lead. The following diagram shows an example of a basic lead prioritization:
| |
| − | | |
| − | [[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 to be contacted within 12 hours”.
| |
| − | | |
| − | | |
| − | Rules will use attributes from the captured lead to map these principles within the system, i.e. to classify the lead in a particular process, set the priority according to the requested due date and time and to assign it to the proper group of employees. The position of the lead in the queue to be distributed is determined by the priority schema and the classificaiton of the lead.
| |
| − | | |
| − | *The priority schema that is defined within iWD manager is highly flexible and business users can adjust the priority curve to suit their business needs. In the following example, the business value of the lead degrades over time and there is a promotion that the sales department are running for leads that didn't convert within 6 days. So the business user has raised the priority between 6 and 8 days after the lead was captured.
| |
| − | *This scenario allows for this segment of hot leads to reach a lead development representative quickly and when there are leads over 1 day old these leads can be blended with older leads based on the desired business outcome.<br />
| |
| − | | |
| − | [[File:Screen Shot 2019-06-26 at 09.48.13.png|right|thumb]]
| |
| − | | |
| − | *<span style="color: rgb(255, 0, 0);" data-mce-style="color: #ff0000;"><span style="color: rgb(0, 0, 0);" data-mce-style="color: #000000;">Please note that in a blended environment the priority ranges used for leads will be broadly aligned with the priority ranges for other media types to ensure the right behavior (distribution order) within the environment. For example, if the employee is answering both phone calls and leads, the sales manager would like phone calls to be answered first, then the priority of voice calls should start higher than work items maximum priority. If there is an inflection point where the leads are more important than voice calls then the prioritization strategy should reflect that. e.g. leads within 2 hours of their due date and time are more important than voice calls that are in the queue for 30 seconds.</span></span>
| |
| − | | |
| − | ====Business Context and Classification Rules====
| |
| − | With intelligent Workload Distribution, every lead is assigned to a Department and a Process. Departments and Processes are used as reporting dimensions and to organize rules. The leads are assigned after they are captured by the system based on the segmentation criteria.
| |
| − | | |
| − | 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 departments and various processes.
| |
| − | | |
| − | All the leads captured from the website are assigned to one of these departments and one of the processes within the department. To complete this assignment, business rules are applied. The following table shows an example for segmentation (the input parameters may vary depending on the requirements of your organization):
| |
| − | | |
| − | | |
| − | [[File:HighValueLeadManagementDepartments.png|Example: Departments and Processes]]
| |
| − | | |
| − | <!-- NewPP limit reportCPU time usage: 0.011 secondsReal time usage: 0.006 secondsPreprocessor visited node count: 1/1000000Preprocessor generated node count: 4/1000000Post‐expand include size: 0/10485760 bytesTemplate argument size: 0/10485760 bytesHighest expansion depth: 1/40Expensive parser function count: 0/100-->
| |
| − | | |
| − | <!-- Transclusion expansion time report (%,ms,calls,template)100.00% 0.000 1 - -total-->
| |
| − | {{{!}} class="wikitable"
| |
| − | {{!}}-
| |
| − | ! colspan="3"{{!}}Input Parameters
| |
| − | ! colspan="2"{{!}}Output Parameters
| |
| − | {{!}}-
| |
| − | !{{!}}'''Request Type'''
| |
| − | !{{!}}'''Product'''
| |
| − | !{{!}}'''Sub Product'''
| |
| − | !{{!}}'''Department'''
| |
| − | !{{!}}'''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 website, a default department and process is assigned to the lead.
| |
| − | ====Priority Rules====
| |
| − | ====='''Service Level and Due Dates'''=====
| |
| − | A) New Leads
| |
| − | | |
| − | The service level 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):
| |
| − | | |
| − | <br />
| |
| − | {{{!}} class="wikitable"
| |
| − | {{!}}-
| |
| − | ! colspan="3"{{!}}'''Input Parameters'''
| |
| − | ! colspan="5"{{!}}Output Parameters
| |
| − | {{!}}-
| |
| − | !{{!}}Department
| |
| − | !{{!}}Process
| |
| − | !{{!}}Deal Value
| |
| − | !{{!}}Secondary timeout 1 (optional)
| |
| − | !{{!}}Tertiary timeout 2 (optional)
| |
| − | !{{!}}All
| |
| − | !{{!}}SLA
| |
| − | !{{!}}Business Calendar
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}*
| |
| − | {{!}}{{!}}1-199
| |
| − | {{!}}{{!}}18
| |
| − | {{!}}{{!}}22
| |
| − | {{!}}{{!}}16
| |
| − | {{!}}{{!}}24 hours
| |
| − | {{!}}{{!}}Mo-Fri 8am to 8pm
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}*
| |
| − | {{!}}{{!}}200-399
| |
| − | {{!}}{{!}}8
| |
| − | {{!}}{{!}}10
| |
| − | {{!}}{{!}}6
| |
| − | {{!}}{{!}}12 hours
| |
| − | {{!}}{{!}}Mo-Fri 8am to 8pm
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}Tablets
| |
| − | {{!}}{{!}}*
| |
| − | {{!}}{{!}}400-and more
| |
| − | {{!}}{{!}}4
| |
| − | {{!}}{{!}}5
| |
| − | {{!}}{{!}}3
| |
| − | {{!}}{{!}}6 hours
| |
| − | {{!}}{{!}}Mo-Fri 8am to 8pm
| |
| − | {{!}}}
| |
| − | | |
| − | | |
| − | The due date and time for a lead are calculated from the SLA starting with the creation time of the lead in Genesys. The overflow times to the secondary and tertiary target and all employees are calculated in a similar way.
| |
| − | | |
| − | See the 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 be determined by service level 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 by the priority schema in iWD Manager. The schema represents the dependency between the submit date time, due date time, initial priority, reprioritization increment, and reprioritization interval. The priority value which is reached at the due time can be set in the iWD Manager use interface. This allows sorting within the universal queue according to closeness to the respective due date and time so that the leads which are on top of the queue are those closest to their due date and the Highest value for the organization represented by the lead 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]]<!-- NewPP limit reportCPU time usage: 0.006 secondsReal time usage: 0.007 secondsPreprocessor visited node count: 1/1000000Preprocessor generated node count: 4/1000000Post‐expand include size: 0/10485760 bytesTemplate argument size: 0/10485760 bytesHighest expansion depth: 1/40Expensive parser function count: 0/100--><!-- Transclusion expansion time report (%,ms,calls,template)100.00% 0.000 1 - -total-->
| |
| − | | |
| − | Please note that reprioritization will continue outside business hours. The formula which is used to calculate lead priority has been explained in the Appendix.
| |
| − | | |
| − | The parameters needed for the calculation are configurable by the user in iWD Manager. 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="5"{{!}}Output Parameters
| |
| − | {{!}}-
| |
| − | !{{!}}Department
| |
| − | !{{!}}Deal Value
| |
| − | !{{!}}Initial Priority
| |
| − | !{{!}}Repriority, Increment
| |
| − | !{{!}}Overdue Priority
| |
| − | !{{!}}Priority schema
| |
| − | !{{!}}Priority Max (calculated)
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}abandoned_cart
| |
| − | {{!}}{{!}}1-199
| |
| − | {{!}}{{!}}100
| |
| − | {{!}}{{!}}37,5
| |
| − | {{!}}{{!}}1001
| |
| − | {{!}}{{!}}Small carts
| |
| − | {{!}}{{!}}1000
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}abandoned_cart
| |
| − | {{!}}{{!}}200-399
| |
| − | {{!}}{{!}}600
| |
| − | {{!}}{{!}}37,5
| |
| − | {{!}}{{!}}105
| |
| − | {{!}}{{!}}Medium carts
| |
| − | {{!}}{{!}}1050
| |
| − | {{!}}-
| |
| − | {{!}}{{!}}abandoned_cart
| |
| − | {{!}}{{!}}400-and more
| |
| − | {{!}}{{!}}875
| |
| − | {{!}}{{!}}37,5
| |
| − | {{!}}{{!}}1150
| |
| − | {{!}}{{!}}Large carts
| |
| − | {{!}}{{!}}1100
| |
| − | {{!}}}
| |
| − | The following graph represents the evolution of the priority over time for the 3 examples of the above table:
| |
| − | | |
| − | | |
| − | '''B) Priority for unsuccessful 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 schema is based on the rescheduled date 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 unsuccessful 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]]<!-- NewPP limit reportCPU time usage: 0.007 secondsReal time usage: 0.007 secondsPreprocessor visited node count: 1/1000000Preprocessor generated node count: 4/1000000Post‐expand include size: 0/10485760 bytesTemplate argument size: 0/10485760 bytesHighest expansion depth: 1/40Expensive parser function count: 0/100-->
| |
| − | | |
| − | | |
| − | <!-- Transclusion expansion time report (%,ms,calls,template)100.00% 0.000 1 - -total-->
| |
| − | '''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 is set to maximum to keep the callback promise made to the customer. The setting of priority, in this case, will also be configurable based on the prioritization schema applied.
| |
| − | | |
| − | '''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 the working hours of the organization. (Please note that lead prioritization will still continue during out of office hours corresponding to the linear model described above).
| |
| − | | |
| − | One business calendar is configured in Designer 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:
| |
| − | | |
| − | *Contact the customer to reach him on the contact details delivered with the lead.
| |
| − | *He is connected with the customer and potentially converts the lead.
| |
| − | *The lead development representative will set the lead result according to the outcome (converted, not converted) and will finish the lead handling within the lead development representative desktop. In this case, the Genesys lead is completed and the lead is archived.
| |
| − | | |
| − | ====Rescheduling a Lead====
| |
| − | Leads that can not be closed on first contact can either be saved to the lead development representitives workbin or transferred back into queue for follow up
| |
| − | ====Unsuccessful call attempt====
| |
| − | Once a lead is delivered to a lead development representative, the lead development representative will:
| |
| − | | |
| − | *Contact the customer to reach them on the details delivered with the lead.
| |
| − | *If they cannot reach the customer they set the lead result to "Not OK"
| |
| − | *Save the lead to their work bin or transfer the lead to a follow up queue
| |
| − | *The lead development representative finishes the lead handling in the lead development representative desktop and is ready for new leads.
| |
| − | | |
| − | ====The lead goes stale====
| |
| − | If a lead could not be distributed to a lead development representative within a configurable amount of time (e.g. 24 hours) the lead can be marked as stale and not deliverd. This is based on the general observation that prospects who are contacted quickly after they visited the website are more likely to be converted while they are showing buying intent. Lead conversion probability drops if the lead development representative contact is too late.
| |
| − | | |
| − | ====Additional Business Logic====
| |
| − | <p>In a blended environment, the configuration of maximum and minimum priority must be synchronized with the priority settings of other media types.
| |
| − | | |
| − | </p>
| |
| − | |DistributionImageFlow={{SMART DistributionImageFlow
| |
| − | |DistributionFlowIntro=This chapter describes the business rules which are used to classify and to prioritize a lead. For the lead management rules, basic prioritization, and due date and time are defined by the value of the lead. The following diagram shows an example of a basic lead prioritization:
| |
| − | |DistributionImage=https://www.lucidchart.com/documents/edit/acb40a6d-c782-4354-b493-aedab7efd408/0
| |
| − | |DistributionFlowDescription=#A lead is waiting to be distributed.
| |
| − | #Genesys verifies if it is a rescheduled task or not?
| |
| − | #*If it is a rescheduled task, Genesys waits for the last agent.
| |
| − | #*If it is not a rescheduled task,Genesys waits for the primary target.
| |
| − | #If an agent becomes available before the timeout, Genesys routes to that agent and opens the lead in the Genesys desktop.
| |
| − | #*If an agent does not become available before the timeout, Genesys waits for the secondary target.
| |
| − | #If an agent is still not available before the time out Genesys routes to the tertiary target.
| |
| − | #*When an agent becomes available Genesys routes to that agent and opens the lead in the Genesys desktop.
| |
| − | }}
| |
| − | |DistributionLogic=====Skills based routing====
| |
| − | This use case is provided with a predefined routing strategy that creates all the queues needed to match the lead with the best development representative. The distribution strategy is based on distribution via skill, ensuring that a lead is distributed to the best suitable lead development representative independent on their place within the organization.
| |
| − | | |
| − | | |
| − | The required skill and proficiency are guided by the department and process the lead belongs to (see section “Business Context and Segmentation” for the logic to define department and process).
| |
| − | | |
| − | | |
| − | Each lead development representative will have one or more skills associated with 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 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
| |
| − | *Dispositions codes to record the lead 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 supported by the desktop or the Gplus adapter.
| |
| − | | |
| − | ====Lead Presentation to a lead development representative====
| |
| − | The data set which is displayed to the lead development representative is:
| |
| − | | |
| − | *The contact details of the lead
| |
| − | *Alternative contact number (if available via the website)
| |
| − | *Name (if available via the website)
| |
| − | *Surname (if available via the website)
| |
| − | *Type of request
| |
| − | *Deal Description
| |
| − | *Deal Value
| |
| − | *Product and Sub-Product (if available via the website)
| |
| − | *Number of rescheduling attempts
| |
| − | | |
| − | ====General capabilities====
| |
| − | The workspace application will provide the 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 consists of lead development representative, status and interactions statistics per day)
| |
| − | |HistoricalReporting=Customer Experience 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.
| |
| − | | |
| − | | |
| − | For more information on the historical reporting please see the Genesys Work Distribution use case (BO02).
| |
| − | |DocVersion=v 1.0.1
| |
| − | |CustomerAssumptions=*Genesys standard REST capture adapter to be used for inbound leads from the source system.
| |
| − | *Outbound webhooks can be sent from the capture point back to the lead source system.
| |
| − | *The customer will handle the integration between the website/source system and Genesys IWD needed to create leads for leads.
| |
| − | *Any changes within the website which is needed for the integration with Genesys are within the customer responsibility.
| |
| − | *Genesys Customer Experience Insights for iWD is used for historical reporting.
| |
| − | *Workspace Web Edition (WWE 9) is used as a lead development representative desktop.
| |
| − | *Up to 5 departments with 10 processes each are configured as part of this use case.
| |
| − | *Standard iWD Manager rules templates to be used to define all the classification and prioritization schema and the customer will be shown how to change to match their requirements.
| |
| − | *Pulse and iWD Manager are used for real-time employee reporting.
| |
| − | *iWD Manger and Designer are used for managing the leads waiting for a lead development representative and associated realtime analytics
| |
| − | |RequiresAll=CE01, BO02
| |
| − | |PremiseAssumptionsAdditional=N/A
| |
| − | |CloudAssumptionsAdditional=*Business Calendars will be handled in Designer
| |
| − | *Customizations of the Business Process and rules is supported through Designer and iWD Manager
| |
| − | *This capability is for routing of leads/work items and non-realtime work items only
| |
| − | *Employee capacity rules are provisioned through Agent Setup
| |
| − | *The blending of voice, chat, and workitem is supported. From a capacity point of view, the agent will only work on one item at once. e.g. voice, call, chat, email, etc. Routing will then handle the delivery of work based on priority.
| |
| − | *The following known limitations exist in this use case for cloud
| |
| − | *#3rd party system integration via any media except work item capture is NOT supported by cloud engineering
| |
| − | *#Business Process (BP) or Designer Application customization by customers or Professional Services is NOT supported by cloud engineering.
| |
| − | *#Prioritization rules editing and or execution capabilities are NOT supported by cloud engineering as iWD is designed for the customer to support this themselves
| |
| − | *#Desktop customization by customers or PS is NOT supported by cloud engineering
| |
| − | *#Desktop changes by cloud engineering are not in scope (configuration only by cloud provisioning)
| |
| − | *#Custom attribute support during routing and reporting is NOT supported by cloud engineering and can be supported by Professional Services.
| |
| − | *#Real-time and Historical report customization perfromed by customers or Professional Services is not supported by cloud engineering
| |
| − | *#Pulse templates are not supplied by Genesys Engineering and will be provided by Professional Services
| |
| − | *#Manual work item monitoring and management (e.g. iWD Manager’s Global work item List) is supported by cloud engineering through the iWD REST API and through iWD Manager
| |
| − | *#Business calendar support in iWD Manager is not supported by cloud engineering e.g. the iWD Manager prioritization will not adjust for weekends or inside and outside of business hours. The distribution of work will stop outside of Designer business hours.
| |
| − | *#All work items need to be submitted through the cloud capture point only. This capture may be technically capable of capturing other media type but the infrastructure behind this capture point will only support work items or work items routed, screen popped and reported through the REST capture point.
| |
| − | }}
| |
