Route by DNIS?
A common call center request is to provide a custom greetings or route a call to a Customer Service Queue (aka CSQ) based on the number the caller dialed. DNIS or “dialed number information service” is usually the solution to this request. Typically you create a database table in which the index is the DNIS. In this way we can pull back all the information we need to greet and route the caller. The solution consists of mapping a DNIS number to a contact flow that has a lambda function that looks up the greeting and routing details in the database referenced the function.
Assign the incoming DNIS number, actually all incoming numbers should hit this contact flow, and we do the usual setup. Turn on logging which is very useful during testing and you can turn it off later to save a few pennies. Set up recording, preferred voice and then invoke the lambda function that will retrieve the desired greeting and routing information. It is a good practice to set the contact attributes so that you can easily reference the returned variables in subsequent contact flows and to make them available for the CTR records and potential screen pops.
Contact Attributes
Clicking on the “Set Contact Attributes” call flow step in this example we get the following:
You can see that the lambda function is pulling back two variables from the associated database tables: queueId and flowId. in the above contact flow, after we set the contact values, obtained from an “External” database we”transfer to flow”. The external flowId points to the flow we want this DNIS to be used for follow on call handling.
The flow will eventually transfer to a queue, which we obtained from the same “External” database. Like the flowId, the queueId is now a “user defined” value. No reason you could skip the “set contact attributes” step and just use the $,External.flowId but by the assignment and the use of $.Attributes.flowId we associate the value with the CTR and make it more easily available for screen pops etc.
(see the blog on should I route to a queue or route to a flow?)
Additionally we could also pull back any other information we might want that would change based on the number the caller dialed. For example a customer greeting. Did the call the Kin-sue Knife help line or the Hotel reservation line? Maybe this is an Executive suite application in which the operator has to answer “thank you for calling <yourcompanyname>.
Advanced DNIS Routing
It may be that we want to route the caller to an IVR Menu of options based on the DNIS. You can easily handle this by the flow you route the caller to, but do you really want to do the newbie “copy and save as” to repeat the same contact flow for each DNIS? There is now reason why the database can point to a generic IVR flow. The generic IVR menu would have menu options that are variables that might be named “optionOne”, “optionTwo” etc. These options would be defined in the database and in this way, each DNIS could point to the same IVR based contact flow but the menu prompt and all the options would be obtained via the lambda function from the referenced database.
This solution along with the Lambda function and Video tutorial is also available in our online store!
As always we would be glad to assist with this solution just click or call! – DrVoIP@DrVoIP.com
