Genesys, Unified Communications and Contact Center Published Articles

[Adam G]

[b]PLSQL "CREATE VIEW" SCRIPTS (ORACLE)[/b]

[color=red]***WARNING: NEVER "WRITE" DATA TO THE GENESYS CONFIGURATION DATABASE!***[/color]

***USE THESE SCRIPTS AT YOUR OWN RISK - ALWAYS TEST BEFORE DEPLOYING!***

These CREATE VIEW Oracle PLSQL scripts have been extracted from within Threads on this Forum.  The purpose of each is defined by the View Name.  They are intended to assist in producing BI/MI reports and/or Outputs.  Each Script must be run separately on the Genesys cfg Database for them to create a "live" View of the parameters described;

CREATE VIEW dbo.CFG_AGENT_GROUPS AS
SELECT DISTINCT CFG_PERSON.FIRST_NAME,
  CFG_PERSON.LAST_NAME,
  CFG_PERSON.USER_NAME,
  CFG_PERSON.EMPLOYEE_ID,
  CFG_GROUP.NAME AS "AGENT GROUP NAME"
FROM CFG_AGENT_GROUP
INNER JOIN CFG_PERSON
ON CFG_AGENT_GROUP.AGENT_DBID = CFG_PERSON.DBID
INNER JOIN CFG_GROUP
ON CFG_AGENT_GROUP.GROUP_DBID = CFG_GROUP.DBID

CREATE VIEW dbo.CFG_AGENT_LOGINID AS
SELECT CFG_PERSON.FIRST_NAME,
  CFG_PERSON.LAST_NAME,
  CFG_PERSON.USER_NAME,
  CFG_PERSON.EMPLOYEE_ID,
  CFG_AGENT_LOGIN.LOGIN_CODE
FROM CFG_PERSON
INNER JOIN CFG_LOGIN_INFO
ON CFG_PERSON.DBID = CFG_LOGIN_INFO.PERSON_DBID
INNER JOIN CFG_AGENT_LOGIN
ON CFG_LOGIN_INFO.AGENT_LOGIN_DBID = CFG_AGENT_LOGIN.DBID

CREATE VIEW dbo.CFG_AGENT_SKILLS_AND_LEVELS AS
SELECT CFG_PERSON.FIRST_NAME,
  CFG_PERSON.LAST_NAME,
  CFG_PERSON.USER_NAME,
  CFG_PERSON.EMPLOYEE_ID,
  CFG_SKILL.NAME,
  CFG_SKILL_LEVEL.LEVEL_
FROM CFG_PERSON
INNER JOIN CFG_SKILL_LEVEL
ON CFG_PERSON.DBID = CFG_SKILL_LEVEL.PERSON_DBID
INNER JOIN CFG_SKILL
ON CFG_SKILL_LEVEL.SKILL_DBID = CFG_SKILL.DBID

CREATE VIEW dbo.CFG_AGENT_SWITCH AS
SELECT CFG_AGENT_LOGIN.LOGIN_CODE,
  CFG_PERSON.FIRST_NAME,
  CFG_PERSON.LAST_NAME,
  CFG_PERSON.EMPLOYEE_ID,
  CFG_PERSON.USER_NAME,
  CFG_SWITCH.NAME
FROM CFG_AGENT_LOGIN
INNER JOIN CFG_LOGIN_INFO
ON CFG_LOGIN_INFO.AGENT_LOGIN_DBID = CFG_AGENT_LOGIN.DBID
INNER JOIN CFG_PERSON
ON CFG_LOGIN_INFO.PERSON_DBID = CFG_PERSON.DBID
INNER JOIN CFG_SWITCH
ON CFG_AGENT_LOGIN.SWITCH_DBID = CFG_SWITCH.DBID

CREATE VIEW dbo.CFG_APPLICATION_ADDP_PARAMETERS AS
SELECT
HST.NAME AS "HOST",
APPFROM.NAME AS "APPLICATION",
APPTO.NAME AS "CONNECTS TO",
CON.CONN_PROTOCOL AS "PROTOCOL",
CON.TIMOUT_LOCAL AS "LOCAL T/O",
CON.TIMOUT_REMOTE AS "REMOTE T/O",
LC.LC_VALUE AS "TRACE MODE"
FROM CFG_APPLICATION APPFROM
INNER JOIN CFG_APP_SERVER CON
ON APPFROM.DBID = CON.APP_DBID
INNER JOIN CFG_APPLICATION APPTO
ON CON.APP_SERVER_DBID = APPTO.DBID
INNER JOIN CFG_SERVER SRV
ON SRV.APP_DBID = APPFROM.DBID
INNER JOIN CFG_HOST HST
ON SRV.HOST_DBID = HST.DBID
INNER JOIN CFG_LOCALE LC
ON CON.MODE_ = LC.LC_SUBTYPE
WHERE LC.LC_CLASS = 8 AND LC.LC_TYPE = 30


CREATE VIEW dbo.CFG_APPLICATION_CONNECTIONS AS
SELECT APP.NAME AS APPLICATION,
  APP_CONNECTIONS((SELECT DISTINCT '' + APP2.NAME + ', '
        FROM CFG_APPLICATION APP2, CFG_APP_SERVER CFG
        WHERE CFG.APP_SERVER_DBID = APP2.DBID
                AND CFG.APP_DBID=APP.DBID
            FOR XML PATH(''), TYPE
            ).VALUE('.', 'NVARCHAR(MAX)')
        ,1,0,'') CONNECTIONS
FROM CFG_APPLICATION APP
GROUP BY APP.NAME, APP.DBID

CREATE VIEW dbo.CFG_APPLICATION_HOSTS AS
SELECT DISTINCT CFG_APPLICATION.NAME AS "APPLICATION NAME",
  CFG_HOST.NAME                      AS "HOST NAME",
  CFG_SERVER.PORT,
  CFG_HOST.IP_ADDRESS
FROM CFG_APPLICATION
INNER JOIN CFG_SERVER
ON CFG_APPLICATION.DBID = CFG_SERVER.APP_DBID
INNER JOIN CFG_HOST
ON CFG_SERVER.HOST_DBID = CFG_HOST.DBID

CREATE VIEW dbo.CFG_APPLICATION_OPTIONS AS
SELECT DISTINCT CFG_APPLICATION.NAME AS "APPLICATION NAME",
  CFG_HOST.NAME            AS "HOST NAME",
  CFG_SERVER.PORT,
  CFG_HOST.IP_ADDRESS,
  CFG_APP_OPTION.OPT AS OPTIONS
FROM CFG_APPLICATION
INNER JOIN CFG_SERVER
ON CFG_APPLICATION.DBID = CFG_SERVER.APP_DBID
INNER JOIN CFG_HOST
ON CFG_SERVER.HOST_DBID = CFG_HOST.DBID
INNER JOIN CFG_APP_OPTION
ON CFG_APP_OPTION.OBJECT_DBID = CFG_APPLICATION.DBID

CREATE VIEW dbo.CFG_APPLICATION_STARTUP_PARAMETERS AS
SELECT
CFG_HOST.NAME AS "HOST",
CFG_HOST.IP_ADDRESS AS "IP",
CFG_APPLICATION.NAME AS "APP",
CFG_APP_TENANT.TENANT_DBID AS "TENANT",
CFG_APPLICATION.VERSION AS "VERSION",
CFG_SERVER.PORT AS "PORT",
CFG_APPLICATION.WORK_DIRECTORY AS "PATH",
CFG_APPLICATION.COMMAND_LINE AS "COMMAND LINE",
CFG_APPLICATION.CMD_LINE_ARGS AS "ARGUMENTS",
CASE CFG_APPLICATION.AUTO_RESTART
WHEN 1 THEN 'NO'
WHEN 2 THEN 'YES'
ELSE 'UNKNOWN'
END AS "AUTO-RESTART",
CFG_APPLICATION.STARTUP_TIMEOUT AS "STARTUP TIMEOUT",
CASE (
SELECT LOWER (PROP_VALUE)
FROM CFG_FLEX_PROP
WHERE PROP_NAME = 'AUTOSTART'
AND OBJECT_DBID = CFG_APPLICATION.DBID
AND OBJECT_TYPE = 9) -- CFGOBJECTTYPE APPLICATION
WHEN 'TRUE' THEN 'TRUE'
WHEN 'FALSE' THEN 'FALSE'
ELSE 'NULL'
END AS "AUTOSTART"
FROM CFG_APPLICATION
INNER JOIN CFG_APP_TENANT ON CFG_APPLICATION.DBID = CFG_APP_TENANT.APP_DBID
INNER JOIN CFG_SERVER ON CFG_APPLICATION.DBID = CFG_SERVER.APP_DBID
INNER JOIN CFG_HOST ON CFG_SERVER.HOST_DBID = CFG_HOST.DBID

CREATE VIEW dbo.CFG_SCS_ALARM_CONDITIONS AS
SELECT DISTINCT CFG_ALARM_CONDTN.NAME AS "ALARM CONDITION NAME",
  CFG_ALARM_CONDTN.DESCRIPTION,
  CFG_ALARM_CONDTN.CATEGORY,
  CFG_ALARM_CONDTN.CLEARANCE_TIMEOUT,
  CFG_ALARM_CONDTN.STATE
FROM CFG_ALARM_CONDTN

CREATE VIEW dbo.CFG_SWITCH_INTERCONNECTIVITY AS
SELECT DISTINCT CFG_SWITCH_ACCESS.FROM_SWITCH_DBID AS "FROM SWITCH",
  CFG_SWITCH_ACCESS.TO_SWITCH_DBID                AS "TO SWITCH",
  CFG_SWITCH_ACCESS.ACCESS_CODE,
  CFG_SWITCH1.NAME      AS "FROM SWITCH NAME",
  CFG_SWITCH.NAME      AS "TO SWITCH NAME",
  CFG_PHYS_SWITCH1.NAME AS "TO PHYSICAL SWITCH NAME",
  CFG_PHYS_SWITCH.NAME  AS "FROM PHYSICAL SWITCH NAME"
FROM CFG_SWITCH_ACCESS
INNER JOIN CFG_SWITCH
ON CFG_SWITCH_ACCESS.FROM_SWITCH_DBID = CFG_SWITCH.DBID
INNER JOIN CFG_PHYS_SWITCH
ON CFG_SWITCH.PHYS_SWITCH_DBID = CFG_PHYS_SWITCH.DBID
INNER JOIN CFG_SWITCH CFG_SWITCH1
ON CFG_SWITCH_ACCESS.TO_SWITCH_DBID = CFG_SWITCH1.DBID
INNER JOIN CFG_PHYS_SWITCH CFG_PHYS_SWITCH1
ON CFG_SWITCH1.PHYS_SWITCH_DBID = CFG_PHYS_SWITCH1.DBID

[Adam G]

[b]What else can you do to automate processes in a Contact Center?[/b]

There have been many, many studies relating to the time and effort applied to simple, repeated tasks in the workplace, in an effort to optimize or automate them. It's nothing new - it's been going on since the industrial revolution began. How to optimize, what to automate, where to augment, how to reduce costs - what can be made better, faster or more cost effective? All of them standard, basic questions and more complex equations and systems to make tasks more efficient.

In a Contact Center environment, things are no different. As time passes new technologies, products, processes and work flows tend to homogenize tasks which are recognized as standard and repetitious. After a period of trial (and error!) using existing tools, more specialized (local) systems tend to be developed in niche areas, catering for specific automation tasks. This is precisely how the local telephony switch (PBX) was born. And automated call distribution (ACD). And Computer Telephony Integration (CTI). And the IVR. And Workforce Management. And Workflow Management. And integrated CRM Solutions. Well - you get the idea...

Sometimes it's a no-brainer and it's obvious where automation fits. Usually, even with the simplest of processes in place, additions are straightforward to implement. Agent Scripting is a good example of this; if a new product or service is introduced, part of the process for launch would be a new set of scripts for Agents to be able to support the product. Easy. But is that all you need to do? No. No, it isn't.

The implementation of any automated process or augmentation system is only the first step in getting things optimized. It's the[i] "vehicle for success"[/i] - but it isn't a map. It doesn't indicate what training might be required, where bottle-necks are - and it can't provide advice about what doesn't work. That requires another level of monitoring and management - and a lot of questions;

[list]
[li]Are staff fully conversant with the processes and products in their remit? How do you know? How can you find out?[/li]
[li]Are your automation processes still fit for purpose? How do you know? How can you find out?[/li]
[li]Are your standard workflow processes efficient? How do you know? How can you find out?[/li]
[li]What level of feedback do you get from the staff who use automation or workflow processes or the information being automatically provided?[/li]
[li]What is your process for improvement?[/li]
[li]Who is responsible for process improvements within your organization?[/li]
[li]What tools exist in the marketplace to further optimize local processes?[/li]
[/list]

- If you can't answer some of these questions using your current processes, perhaps it's time to review how your automation and optimization techniques are working!

As general pointers, here's a few areas of automation that you may not have already considered, for your Contact Center;

[list]
[li]IVR Pass-Back Services: this involves a Voice Agent reaching a point in a conversation where information needs to be very succinct and very accurately repeated to a caller. It may be a regulatory requirement or warranty advice or perhaps even a service authority requirement. Rather than the Agent reading back information from on-screen prompts, they call/consult an IVR script, which reads to script to the caller, gains acceptance or understanding from them, records it and then passes the caller back to the Agent.[/li]
[li]Orchestration Services: this is the means to be able to (re-)use the same basic information and processes, across different types of interactions. You'd be surprised how many Contact Centers operate voice, multimedia, sms and social media independently by using totally separate teams of Agents. Not orchestrating those types of services means duplicating many of the workflows that surround them - and that is bad for business![/li]
[li]Reason Codes: a lot can be learnt from collecting post-interaction information. Comparing a service that was accepted (for example through IVR digits) with the result of the interaction (through post-call Reason Codes) goes a long way to explaining what might be wrong with your processes. Knowing this can also indicate where to optimize not only staff processes - but technology processes, too.[/li][/list]

Of course a lot depends on the business you are in - and just how much of your internal processing can be combined and optimized, without rocking the proverbial apple cart...

[Adam G]

[b]Harnessing the Real Power of Dynamic Routing[/b]

Not heard of Dynamic Business Rules? Never used VXML? Don't know what a Data Dip is? Weren't aware that you can empower authorized personnel to make changes to call and multimedia routing and your IVR on-the-fly? Don't worry - you're not alone...

Most days - and most of the time - static rules are great for interaction routing and IVR's. The appliance of IF…THEN statements ("if this happens... then do this...") are a mainstay of operations - and it works 99% of the time. But what about the other 1%? What about when things are not going according to plan? When your workforce is snowed-out by a blizzard - or there's been a flu bug in the contact center - or your CRM system is off-line? What then..?

Thankfully, there are ways to program pre-set elements into your routing to counteract "Force Majeure" - and things not quite so epic!

In the simplest terms; Genesys core routing has the means to "look-up" data fields in other locations and act upon them. This opens the possibilities for authorized members of your workforce to make significant adjustments to the way in which both your routing and your IVR operate. For example;

Your normal working parameters are to have a standard greeting in your IVR. You can set up a business rule which dynamically replaces that announcement with a different announcement if there are a high number of calls. In this way, your announcement automatically switches to inform callers of high call volumes - and possible extended wait times - and a suggestion that they may want to try again, later. But it's not the only way the announcement can be invoked. If a supervisor is aware of a forthcoming reduction in the resources available (for unplanned breaks, meetings, a fire drill etc.) it is possible to allow them to determine when the high call volumes announcement should be played, by updating information which is external to Genesys routing. It doesn't have to be rocket science, either; a standard lookup in the Routing and a simple plain text file update can make all the difference.

Here's a few examples of how and why this type of dynamic routing could be integrated;

[b]LOAD BALANCING[/b]

...is where a percentage of calls are distributed across geographically separated contact centers. Local updates to a dynamic lookup by authorized personnel - outside of Genesys - can change this ratio.

[b]SLAKPI ("Slack-Pie")[/b]

...where a given SLA or KPI is "hard-coded" in the DNA of routing. Again, a simple update - outside of Genesys - can change this dynamic.

[b]THROTTLING[/b]

...the "conveyor belt" of incoming interactions can be managed locally, using the same basic tools.

[b]IVR MENUS[/b]

...means having the ability to (temporarily) remove or replace/update IVR menu options and announcements using the same methods.

[i]But that's a lot of power to give local resources, isn't it? [/i]Not really - these on-the-fly changes can be reset by routing rules, too. With the right application, resource-powered changes to routing and IVR options can be given a time limit. So, a change made by authorized staff using this method can be reset after 15 minutes - or an hour - or for however long you decide!

[Adam G]

Meta Data for Agents = AIM

Recently I have heard a lot of noise about “meta” in the media. Usually in relation to an “amazing fourth wall break” in a movie ([b]Dead Pool[/b] - I'm looking at you...) - or an Easter egg hidden away in a scene - or an external reference in a videogame. But meta has been around a very long time indeed - in fact, it’s the lifeblood of a contact center. Aside from the verbal conversations and CRM interactions, everything else is meta. Key Performance Indicators? Meta. Service Level Statistics? Meta. Customer Satisfaction? Meta. But why stop there?

At the coalface of every interpersonal interaction is a resource with almost no meta. The Agent. Performing tasks almost perfunctorily, an Agent becomes a part of the whole - a series of metrics. Average Speed of Answer, Average Talk Time, After Call Work Time, SLA’s, KPI’s, Skills, Break Times, Shifts.... but aren’t they worth a little more than that? Even your customers have a “voice” - what about your Agents? So - how about we step this up a bit? How about getting more from your Agents by giving them more of a voice - more meta? Let’s give it a name - since 3-letter abbreviations are all the rage in IT - how about “Agent Interaction Meta” (AIM)

So - AIM, then - is a concept of metadata providing metrics and measures which can be presented and collected by Agents during a call or interaction - or in a Wrap-Up Mode or “After Call Work” (ACW). These new AIM meta metrics can be developed into the Agents desktop interface and stored, along with other CRM data, for future use.

But - why the heck are AIM metrics useful to a business, Adam...?

Glad you asked! 😊

OK - here’s some very basic examples of how our newly-formed AIM metrics can support business scenarios, leading to better interactions - better service - and better business;

For [b]Customer Services[/b], it would be feasible for an Agent to record AIM metrics to make some decisions and record re-usable meta information about;

...a caller's natural language - or “mother tongue”, which can be saved for future interactions with the caller...
...a caller's propensity for future marketing and/or sales with a simple 0-5 scale...
...a caller's wants and needs, beyond the services being provided through a maximum of 140-character text box on the Agents screen (Tweet if you see where I got that one from... 😊)...

For a[b] Tech Support[/b] line; it might be beneficial to interpret the relative understanding - and/or relative patience - of the customer, through meta information completed by the Agent. An AIM metric applied to a previous interaction with the caller would indicate if they were particularly knowledgeable or technically minded. On the next interaction with the caller - and on the basis of that scoring - you can avoid matching a trainee with the “wrong type of caller...” (worst case scenario - but it happens a lot!)

These are just a few ideas off the top of my head - every item will be particular to your own line of business - and related to what you find important to know about your customers. What’s important to remember is that an Agent has a lot more insights which could be nurtured and extracted through the correct appliance of meta data collection. And giving your workforce a new voice, actively supporting your business goals must be a good thing, right?

Why not give it a try? You never know, it might just work if you AIM high enough!