Yes, it's definitely doable. The question is how do you want to determine if the customer called?

You can do this based on caller ID for example.

Agent-Based routing is a good idea, however it does not support queueing and there is no way to report on these calls well, so if your requirement is also to queue to this agent I would suggest creating new CSQ just for this agent, and if you need to overflow the calls to another queue you simply build nested select resource logic in your script.

HTH,

Chris

Hi,

so all my configuration should be in the script?

Do you have some example of these scripts?

Assume that the customer is determined by his phone number. So, I should have some database (.txt file) where I can find that number and his agent. That is first problem to solve.

The second one is, when my agent is not available to answer, the call should be routed to some other agent. How to configure this?

Regards,

One note about creating a CSQ by agent: The MCS hardware will have a maximum supported CSQs. If you have to do much of this you could easily reach your limit so be cautious about that.

Regarding the database: You can use an XML file and search it using XPath or a SQL database and use a standard SQL query.

As for "when my agent is not available to answer, the call should be routed to some other agent": Do you mean you want a linear list of people to try one at a time; or, a general CSQ if the initial person is not available?

If the former, you could possibly use resource group-based routing for this depending on how many unique "groups" (lists) you needed.

Either way, you would add a second, nested CSQ within the first Select Resource that attempted a resource.

Example:

Select Resource (resourceID)

--Connected

----Goto END

--Failed

----Select Resource (csqID1)

------Connected

--------Goto END

------Queued

--------...you queued logic here...

We use exactly the same feature... call comes in, database gives 1 or 2 user-logins for this customer, if they are not available, we go to the group

in order to use the 'Select Resource' step for agent based routing you need a 'User' object. The 'Get User' step transforms the agent login to a User object. We have noticed that this could take a couple of seconds. ( so for 2 preferred agents = twice the time )

That's why we now start by getting the reporting statistic for the agent login, and when this returns 'ready', then we get the User object and select the resource.

We don't use nested 'Select Resource' steps, because the agents all have skills for the backup-group and if none of the preferred agents are ready, we simply don't do the first 'Select Resource' Step( agent based ).

So far, no problems with this setup, except reporting not beïng all that clear