What about IP IVR? Sent from my iPhone
> On Aug 19, 2020, at 9:16 AM, Lelio Fulgenzi <[email protected]> wrote: > > > +100 for Anthony! 😊 > > > > From: Anthony Holloway <[email protected]> > Sent: Wednesday, August 19, 2020 10:48 AM > To: Lelio Fulgenzi <[email protected]> > Cc: Matthew Loraditch <[email protected]>; Charles Goldsmith > <[email protected]>; [email protected] > Subject: Re: [cisco-voip] [External] IPCC best practice > > 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 > [email protected] > > Wait Lelio, CRA is older terminology than CRS, so it should go: > > +1 IPCC > +2 CRS > +3 CRA > > Right? > > On Wed, Aug 19, 2020 at 8:53 AM Lelio Fulgenzi <[email protected]> wrote: > > 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 > <[email protected]> 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 > [email protected] > > 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 > w: www.heliontechnologies.com > | > e: [email protected] > <image137282.png> > > <image428710.png> > > <image540273.png> > > <image899251.png> > > From: cisco-voip <[email protected]> On Behalf Of Charles > Goldsmith > Sent: Wednesday, August 19, 2020 8:39 AM > To: Johnson, Tim <[email protected]> > Cc: [email protected] > 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 <[email protected]> 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: [email protected] > Fax me: +19897795900 > Meet me: http://cmich.webex.com/meet/johns10t > > > -----Original Message----- > From: cisco-voip <[email protected]> On Behalf Of > [email protected] > Sent: Wednesday, August 19, 2020 8:19 AM > To: [email protected] > 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 > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
