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
