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 <johns...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip