[cisco-voip] [External] IPCC best practice
Lelio Fulgenzi
lelio at uoguelph.ca
Wed Aug 19 09:52:26 EDT 2020
Not much more to add here, except +1 for calling in IPCC. :) you’d have gotten +2 if you called it CRA. ;)
But, seriously, you have to weigh the pros and cons of injecting a point of failure vs ease of administration.
My thought process is, can you build automatic recovery? Or easily understood manual backup.
And is the design something you can easily hand off to someone?
Lots of things to consider.
Sent from my iPhone
On Aug 19, 2020, at 9:00 AM, Matthew Loraditch <MLoraditch at heliontechnologies.com> wrote:
CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp at uoguelph.ca
We still use Call Handlers. We have fewer resources who can handle script editing and somewhat frequent requests to change hours and such that we need the regular techs to be able to handle.
Definitely a preference thing.
Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518<tel:443.541.1518>
w: www.heliontechnologies.com<http://www.heliontechnologies.com/> | e: MLoraditch at heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>
<http://www.heliontechnologies.com/>
<image137282.png>
<https://facebook.com/heliontech>
<image428710.png>
<https://twitter.com/heliontech>
<image540273.png>
<https://www.linkedin.com/company/helion-technologies>
<image899251.png>
From: cisco-voip <cisco-voip-bounces at puck.nether.net> On Behalf Of Charles Goldsmith
Sent: Wednesday, August 19, 2020 8:39 AM
To: Johnson, Tim <johns10t at cmich.edu>
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] [External] IPCC best practice
[EXTERNAL]
Agreed with TIm, it's just simpler to involve less systems if you can. With 12.0 UCCX and higher, the calendar function is a nice addition, no more XML files for schedules.
On Wed, Aug 19, 2020 at 7:37 AM Johnson, Tim <johns10t at cmich.edu<mailto:johns10t at cmich.edu>> wrote:
It seems to me that there's not a "best practice" label for most scenarios. When I started with UCCX, we went to a call handler first to provide us with an easy way to provide a schedule, and a familiar way for the customer to record a greeting. Later, we ended up building the schedule into our script and directing calls to the trigger. That's my preference, just to involve less systems.
Tim Johnson
Voice & Video Engineer
Central Michigan University
Call me: +19897744406
Video Call me: johns10t at cmich.edu<mailto:johns10t at cmich.edu>
Fax me: +19897795900
Meet me: http://cmich.webex.com/meet/johns10t
-----Original Message-----
From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> On Behalf Of fred at browardcommunications.com<mailto:fred at browardcommunications.com>
Sent: Wednesday, August 19, 2020 8:19 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [External] [cisco-voip] IPCC best practice
Hello, I just have a quick question.
When setting up a call center for a SMB, Is it best practice to have the main number go to a unity call handler 1st, with caller input going to uccx triggers, or is it considered best practice to have the main number go right to CCX? I have seen both ways.
Thank you.
_______________________________________________
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
_______________________________________________
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
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200819/6b62b1b4/attachment.htm>
More information about the cisco-voip
mailing list