EIM 4.3 - Route to Last Agent

Unanswered Question
Aug 18th, 2010

Hello,

I have a requirement to have emails route to the last agent that worked on them. Using integrated EIM, I can't any way to do this.

On a previous Cisco TAC case, the engineer, mentioned something about Sticky Agents, but I couldn't find any documentation on this at all.

Has anyone here had to route to the last agent before? I do have the Data Adapter license, so was thinking of maybe some funky query in a work flow pass back to ICM the original agent ID?

Thanks for your help!

Barry

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Barry,

I can certainly do the second part.

Create a Data Access Link and a Data Usage link and do the lookup in the worklfow (I guess the customer email address is the lookup key) and deposit the results of the query into the activity table, then pass this up to ICM in a call variable and use Queue to Agent to queue the activity. You can deal with the various options of no result, agent not logged in, queue for a while and overflow to the SG etc.

Now to the first part - how to write the agent into a database. You could get it by trolling the TCD in ICM - but you know how careful you need to be there. You could also get it in an ugly way - have a Link on the EIM desktop that writes to the database the email address and the agent peripheral number, but I think they may have to enter it.

Interesting idea. I'm willing to discuss this further.

Regards,

Geoff

BarryMclellan72678_2 Wed, 08/18/2010 - 08:51

Hmmm, I was thinking (no idea how yet), when an agent responds to an email, it must have their agent ID stored in one of the local EIM tables along with the case number. (I haven't found the EIM Database Schema documented)

Then, at the start of the workflow, check an EIM table for this case number. If the case number is found, return the last most recent Agent ID associated with that case and stuff it in a call variable.

When EIM routes up to IPCC, check and see if there is an agent ID in the call variable, and attempt to route to that agent, and keep the call queued with that agent for XXXX seconds before overflowing to an EIM queue.

What do you think?

Barry

Barry,

We are in agreement on part 2.

The schema for 4.3 is not published yet - I have requested it myself. But the 4.2 is published and worth checking out.

Since the PIM certainly passes down the agent ID in the DO_THIS_WITH_TASK event, it is most certainly in some EIM table, and I bet you can find it in the schema. It will be almost certainly matched on activity ID. I'm guessing you would have a few joins to do to get from the case ID to the previous agent, but maybe not.

Go to Cisco.com and download the schema doc.

If I get a little time this morning I'll have a quick look myself. It's interesting.

Regards,

Geoff

BarryMclellan72678_2 Wed, 08/25/2010 - 07:11

Well, I am getting close!

Have the cisco agent ID being passed back to a mapped call var in IPCC. Now just have to queue to the agent ID, and see how that affects reporting!

Let me know how you made out, if you are still interested, I can post what I have done so far.

Barry

BarryMclellan72678_2 Wed, 08/25/2010 - 22:46

Hey Geoff!

I wrote a nested SQL query so that I could get the case ID, and the last user who worked on it. I then take the user who worked on it (which is an EIM index), and hit the EIM agent table to get the login name.

Since I am using integrated the login name is prefilled which matches my IPCC agent login id exactly, I can send this data back in my call variables, and use the queue to agent node.

Barry

Since I am using integrated the login name is prefilled which matches my IPCC agent login id exactly, I can send this data back in my call variables, and use the queue to agent node.

Barry, as long as you send up the agent's peripheral number (what they would use to log in to CTIOS) you will be able to use the Queue to Agent in implicit mode. The name will not work - but that is what you select in explicit mode in a Queue to Agent node.

Regards,

Geoff

BarryMclellan72678_2 Thu, 08/26/2010 - 12:56

Yup, sending up the agent login number (same that they use for CTIOS).

So far it is working great, now on to yet another work flow that isn't in the product that should be!

BarryMclellan72678_2 Thu, 08/26/2010 - 14:11

Sure, here is the query for my data access link.

My Data Usage Link passes in the case_id macro.

select USER_NAME
from egpl_user
where egpl_user.user_id IN
(
   select case when egpl_casemgmt_case.user_last_worked IS NOT NULL then
           egpl_casemgmt_case.user_last_worked
      else
            0
      end as New_Owner

   from egpl_casemgmt_case,
           egpl_casemgmt_customer
          where egpl_casemgmt_case.customer_id = egpl_casemgmt_customer.customer_id and
                    egpl_casemgmt_case.case_id = <%case_id%>
)

There is obviously a bit to setup in your workflow, data access links, adding new field to activity table, and all that good stuff. If you need more info, let me know.

Barry

kimv Fri, 08/27/2010 - 05:13

Hi Barry,

It isn't actually called "Sticky Agent", its called "Preferred Agent".

The way you do it is to put a User node within the Inbound Workflow which has several options and is placed at the end of a workflow.  Of course the agent that is the Preferred (sticky) agent needs to be currently logged in.  Truthfully I haven't played around with it in my lab, but you can find it in the following document.

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/cisco_interaction_manager/cim_43/user/guide/cisco_im431_cce_userguide_administration_workflow.pdf

Hope this helps.

Kim

kimv Fri, 08/27/2010 - 06:11

Kim Vogler

Customer Support Specialist IV

Unified Contact Center Products

[email protected]

Phone: +1 978 936 3356

Cisco Systems, Inc.

1414 Massachusetts Ave

Boxborough, MA. 01719

Cisco.com - http://www.cisco.com

Please note that my regular business hours are 8:00am to 5:00pm EDT. // If

you are contacting me in regards to a Service Request that we are working

together, and I am unavailable, please refrain from requeuing unless there

is an urgent need to speak to an engineer. If however you do need to work

with a TAC engineer urgently while I am unavailable, you may requeue this

Service Request to an available engineer by either calling the 800.553.2447

TAC Toll Free number or writing the [email protected] address and requesting it.

This email may contain confidential and privileged material for the sole use

of the intended recipient. Any review, use, distribution or disclosure by

others is strictly prohibited. If you are not the intended recipient (or

authorized to receive for the recipient), please contact the sender by reply

email and delete all copies of this message.

For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

BarryMclellan72678_2 Fri, 08/27/2010 - 08:35

Thanks for the attempt Kim, nice to know you guys are monitoring these thread's as well!

I'm sure by version 6, this should be all integreated

Barry

lohjintiam Wed, 09/22/2010 - 04:11

Isn't this fixed?

CSCtb98517 Sticky Agent functionality broken

Symptom:
Sticky Agent functionality broken. Emails are not being assigned back to last agent who updated the case/activity.

Conditions:
CIM 4.2.5, ES4, and an ET image (Engineering Test image).
ICM 7.2.6

Thanks!

-JT-

BarryMclellan72678_2 Wed, 09/22/2010 - 05:44

Hi JT,

The problem is 'kind of' fixed, however their version of 'sticky agent' doesn't really work very well.

Here is the scenario - using the sticky agent.

Step 1:

Email comes in to IPCC after routing through EIM

No Agent ID is passed with the email

Agent A receives the email

Agent A sends email to customer

Customer responds

Email comes back into system, EIM see's there is an existing case and passes IPCC the agent ID for Agent A.

IPCC routes the email to the agent -- ** Perfect **

   - however EIM has now updated the customer's preferred agent id with the last agent who handled the email.

Step 2:

Email comes in to IPCC after routing through EIM

No Agent ID is passed with the email

Agent B receives the email

Agent B sends email to customer

Customer responds

Email comes back into system, EIM see's there is an existing case and passes IPCC the old agent ID from Agent A.

IPCC routes the email to the agent A  ** BAD **

    - if Agent B was swift enough to change the preferred agent id to their ID, Agent B would have taken the call.

Now, these are two simple steps,imagine if you had a customer with two different email threads at the same time working with two different agents... much like we would do if we had more than one TAC case open.

The change EIM needs to do, is route based on the last agent who was working on that specific activity.

Barry

lohjintiam Wed, 09/22/2010 - 11:10

Barry,

Thanks for explaining!

I guess the problem lies in the initial email where no Agent ID is passed from EIM to ICM? Some might argue that (taking Step 2 as example), it should try to route to Agent A first if not available then route to Agent B and continue on with Agent B from there onwards.

-JT-

BarryMclellan72678_2 Thu, 09/23/2010 - 08:09

The problem is, that even if you wanted to try A, then go to B, once B worked on it, the next reply for this same case from the customer would go back to A, and not B, B would not be known by the system.

partheeban1 Wed, 11/10/2010 - 04:45

Hi Barry,

We are running the UCCE integrated EIM 4.3.2 and we required these type of call routing. Could you please share us what are configurations need to be done for achieving this functionality.

-Parthee

Actions

This Discussion