[cisco-voip] UCCX Call Escalation/Tiered CSQs

Johnson, Tim johns10t at cmich.edu
Mon Aug 5 11:35:53 EDT 2019


Thanks for the response.

Yeah, you’re right. I hadn’t thought too deep into how it would affect reporting, but splitting into a second application does provide better options there. This is the way we’ve done it with another call center that we provide service for, but I just wasn’t sure if there was a “better” way.

With the Get Digit String, I was thinking we could use their “welcome” prompt on that step. There would be no indication during the prompt that it was available so it would kind of be somewhat of a “hidden” menu. The 1st tier agents would be able to call their main line, and press an expected digit string that I could apply IF logic to and process the call differently. The blind transfer could be handled just by adding a speed dial on their phones to include a wait and then the DTMF digits. That being said though, the call center is thinking that a phase two of this change will be to add a menu for the 1st tier agents to select from to route to agents that specialize in different areas.

From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Sent: Monday, August 5, 2019 10:55 AM
To: Johnson, Tim <johns10t at cmich.edu>
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] UCCX Call Escalation/Tiered CSQs

I wouldn't worry too much about cluttering up your scripts (or apps, or triggers).

First and foremost, I would worry about reporting.  Does the solution allow the stock reports to adequately meet the needs of the reporting personnel?

Second, I would worry about ease of execution for the Agent.  Are the Agents able to easily execute this escalation?

If I had to pick one of your three options, Option 1 would be my choice.  This would allow Application level reporting (real-time and historical), not just called number and/or CSQ level.

I didn't quite understand why your Option 3 uses a Get Digit String.  Can you explain that?  Also, this option would not allow Agents to take advantage of a blind transfer (a speedier option for escalating calls).

On Mon, Aug 5, 2019 at 9:25 AM Johnson, Tim <johns10t at cmich.edu<mailto:johns10t at cmich.edu>> wrote:
Hello,

I’m looking for ideas on how people setup their applications/scripts when handling call centers with multiple tiers of support. More specifically, how do you handle 1st tier agents queueing calls for 2nd tier agents? Below, I’ve provided three ways I can think of to achieve it, but I’m curious if someone has a better idea.


  *   An application/trigger for each tier. The 1st tier agent transfers the call to the trigger for the next tier. Benefit of this being that the scripts are broken out and there’s not as much clutter in each.
  *   A second trigger on the application, and a Get Call Contact Info step to grab the called number and queue the call for 2nd tier CSQ based on that. The 1st tier agent would transfer the call two the secondary trigger. This makes for a more cluttered script, but you don’t have to cross reference anything.
  *   A Get Digit String that is used at the “welcome” prompt, which can be used by the 1st tier agent when they do a supervised transfer to the trigger on the application. This again makes for a more cluttered script than doing two applications/triggers, but maybe makes it easier to manage and do reporting on?

Thanks!

Tim Johnson

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7Cjohns10t%40cmich.edu%7Ceaf43e44a5414c508f3d08d719b4f9dc%7Cc871bc6e7cc64a57a4eb22309fc34963%7C1%7C0%7C637006137390573766&sdata=aiDlHZ1u%2BPfL8QLG7PqgrWXSHYHD%2BaAOWtWRqmNQ8Xw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190805/3ff58e0c/attachment.htm>


More information about the cisco-voip mailing list