[cisco-voip] ARC and Cisco product

Tired Banchini tired.banchini at googlemail.com
Mon Sep 28 18:24:30 EDT 2009


Thanks Bennie, thats really useful.

On Mon, Sep 28, 2009 at 9:39 PM, Bennie Grant <Bennie.Grant at mettoni.com>wrote:

>  A very interesting question, and one that does come up from time to time.
> As you may know, I am known for writing wordy replies to queries such as
> this, so I apologize in advance for boring you!
>
>
>
> Firstly, the most important thing to always remember is that *Arc
> Solutions are a 100% Cisco UC Applications focused company, and will NEVER
> make an application that is competing with Cisco*. This is our number one
> policy, and is why we are as successful as we are. In fact, the latest
> demonstration of our closeness is the fact that we’ve just relocated into
> Cisco’s RTP campus (as per my signature below)!
>
>
>
> The Arc product sets are designed in such a way to meet specific
> requirements (Customers, Partners & Cisco themselves) depending on the suite
> itself. I think its easier to list of the main differences as follows:
>
>
>
> *Cisco Unified Business/Department/Enterprise Attendant Consoles (CUxAC)*
>
> These are OEM products from Arc Solutions as you know. These superseded the
> old/free Cisco Attendant Console – there has been a separate thread over
> “why” this route was taken. These products meet the majority of customers
> requirements in a simple configuration, and importantly are designed to be
> simple to install, use and support. This “ease of use” is not just for our
> customers/partners – it has been critical that these applications are easier
> to support for the Cisco TAC folks – as with so many products its tricky for
> them to learn brand new product sets. For the most part this has been
> achieved, and of course there is now a defined roadmap for this product set
> moving forwards
>
>
>
> *Arc Enterprise S+*
>
> This is the basic Arc Enterprise product and is available via the Cisco
> Solutions Plus program (“S+”). This program is where Cisco take 3rd party
> products and put them on the Cisco Global Price List – so although this is
> orderable via Cisco, this is an ARC product – support is via Arc Solutions
> and not Cisco TAC. This product has more functionality than the OEM/CUxAC
> products, and therefore is slightly more complex from an installation
> standpoint – nevertheless this is endorsed and sold via Cisco
>
>
>
> *Arc Enterprise Premium*
>
> This is the top level of Attendant Console functionality for CUCM, and is
> only available via Arc or an Arc partner. The solution/products are fully
> endorsed by Cisco (IVT Certified etc), however they are not on the S+
> program as the belief has been that this would become too complicated for
> the ordering/fulfillment (this is “one” of the reasons why it is not on the
> S+ program – not the only reason). Where customers require voice messaging,
> redundancy and reporting on the operator center, Arc Enterprise Premium is
> the likely fit
>
>
>
> *Arc Call Connect*
>
> As you rightly mentioned, Arc does also have a mini contact center product
> called Call Connect. This does NOT compete with IPCCx. For example, if a
> customer requires database dipping (i.e. looking up account numbers), or
> does not have a Call Center that is likely to change configuration often,
> then IPCCx with the scripting and powerful features is absolutely the right
> fit. However, there are scenarios where a customer requires some basic
> contact center functionality, and IPCCx is either too expensive, too
> cumbersome or too complicated for the requirement. A common scenario is
> where a customer requires a few “small” different CC functions – i.e. a 3
> seat facilities team, 4 seat concierge service, 5 seat internal IT helpdesk
> etc, with centralized reporting and management. In this situation, Cisco
> would likely engage Arc to meet this requirement, while ensuring that
> everything else UC-wise remains as Cisco.  They are safe in the knowledge
> that if Arc Call Connect has been implemented, there is no risk that a
> different PBX/switch could be implemented later and Arc will remain
> functioning (making a transition easier) – there is also no risk of Arc
> attempting to displace any Cisco technologies anywhere – everything we do is
> complementary to Cisco ONLY – as per our mantra
>
>
>
> *XML/Phone Apps & Directory Services*
>
> Arc also have various options around directory services – with enhanced
> call routing, intelligent lookups, presence integration etc – as well as
> other applications for the Cisco IP Phones. A lot of the projects in this
> space are delivered via our Advanced Services team and are completely
> customized to the customers requirements. It is often in this area that the
> Arc team are used to really leverage the Cisco technology – so many
> customers have features or requirements that they would like to deliver on
> IP Phones, but is too bespoke to be offered by Cisco, and too complex to be
> offered by an integrator (as its more of a “product” than a “service”). We
> have a dedicated team at Arc that exist to create and support these
> applications – this group is often engaged by Cisco to help work as a
> differentiator in a competitive environment
>
>
>
> As you can see, Arc certainly offer a lot – either via OEM, S+ or direct
> products. Those partners & Cisco folk who are educated in the offerings
> (we’ve trained most Cisco UC SE’s in North America via WebEx now) appreciate
> which product is the right fit for each customer, and of course know when to
> engage Arc for more unique requirements. The key thing to bear in mind is to
> not try and “squeeze” a particular product into a customers environments
> because it’s the cheapest or “sounds about right” – we have been involved in
> lot of instances across the world now where customers have been sold the
> incorrect product – often due to a lack of discovery process – and Arc have
> been engaged to implement the all encompassing solution later
>
>
>
> Specifically around Contact Center, if you have a complex requirement that
> IPCCx is likely the way to go – and we (Arc) would certainly advise that.
> However, if this does not fit, there is a ready made option in Arc Call
> Connect that may get you what you need. There is some overlap around
> functionality, however this is minimal – Arc does the basic things very well
> (probably better than IPCC), however does not have the advanced
> functionality that many IPCC users want….
>
>
>
> Needless to say, if there’s anything specific you want to know feel free to
> drop me a line directly. I trust this note helps explain how everything fits
> together
>
>
>
> Cheers
>
>
>
> *Bennie Grant
> **VP - Operations
> **Arc Solutions (International) Inc
> *Part of the Mettoni group | www.mettoni.com
>
>
>
> [image: http://assets.bizjournals.com/story_image/118089-600-0-2.jpg]
>
> NEW US HEADQUARTERS
>
> We have moved offices! Arc Solutions are now based in the Cisco RTP campus
> in North Carolina. Please make a note of my new direct line number above.
>
>
>
>
>
>
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Tired Banchini
> *Sent:* Monday, September 28, 2009 9:42 AM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] ARC and Cisco product
>
>
>
> Chaps,
>
>
>
> General question in terms of ARC and how Cisco position ARC's product set
> in comparison to their own. I am particularly interested in the Contact
> Centre product set/ functions....
>
>
>
> ARC have a number of products, which seem to overlap somewhat with Cisco's
> CC product set and from my initial experience it would appear Cisco are
> happy to push some Cisco product set while pushing ARC for others, once such
> example is CU*AC.
>
>
>
> Do Cisco push ARC solutions in the context of small scale CC, ala
> IPCCX....?
>
>
>
> An example might be where you want to fragment the IPCCX functions, such
> IVR/ ACD etc. i.e. deploy IVR separately, while retaining the ACD on IPCCX.
> Does IPCCX become overkill and hence we have a slot for another Cisco
> Product or ARC for the ACD function...?
>
>
>
> TB.
>
> *************************************************************************
> Please consider the environment before printing this e-mail
> *************************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.  http://www.mettoni.com
>
> Mettoni Ltd
> Registered in England and Wales: 4485956
> 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN
> *************************************************************************
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090928/42ccf291/attachment.html>


More information about the cisco-voip mailing list