This is a fantastic move for Amazon and I'll tell you why. The cost of long distance is nearing 0 and application providers are making bank. The pricing is also extremely disruptive. Most contact centers price minutes/DIDs just like Amazon but ALSO charge a per-agent per-month fee. [1]
All of the contact center solutions mentioned so far were customers of mine at MagicJack. We did wholesale long distance for them. The one trend in the industry is that long-distance continues to fall fast, but the pricing of telecom-related apps stayed the same.
Since I am no longer under NDA, the average cost of long distance (US Domestic) at MagicJack when I left in 2013 was $0.0017/minute!!
For those saying contact centers won't move over because the investment - I will tell you that we lost and gained 1,000 agent operations over 10% cost savings every single month.
Absolutely right. Though in India we have been charging the regular call center model for our cloud call center, http://cloudagent.in, we knew the model will not continue for long, especially in the US. So for our US product getkookoo.com we did away with the per agent pricing. We went with a zero agent rental and fixed monthly cost model with free minutes included[1].
[1]-http://getkookoo.com/getting-saas-pricing-right-pricing-clou...
I would be surprised if amazon has access to the voice recordings, maybe something can be found in the terms of use?
Customer data is pretty closely guarded at aws, I would be surprised if they would jeopardize uptake by medical and financial sectors for the sake of a small amount of training data (when they already have all the data they could want from amazon.com)
The fact of the matter is there is nothing new or transformative about Amazon Connect. Anyone who knows something about how contact center technology can attest to this.
Wow, thanks mjw305! I looked Fenero up due to your comment, and they fit all my needs on call center and ACD/ predictive dialer.
I do need to give a shoutout to Fenero and their VP of customer development, Charlie Callari, who called and did a video training showing me the ins and outs of their system, few minutes after I signed up for their free trial. I'm impressed, to say the least.
DD
I built a Five9 instance from the ground up in support of a ~20 person customer service center several years ago.
Switching costs, even for that little 20 person shop, would be insanely high to move to Amazon between training reps, rebuilding custom reporting, recreating workflows, DID switching, etc.
And Five9 matches several of the amazon features - cloud based, minimal contracts (month to month at last check), decent API integration support, object-oriented set-up UX, etc.
I am excited about Amazon's entry in this space to push everybody forward, but I think they're going to make more impact forward than penetrate existing organizations.
This has been mostly true for any new business or technology. The "hockey stick" growth point often occurs when it becomes more difficult for existing businesses not to use it.
Was that for an inbound, outbound, or blended environment?
Having dealt with Five9 for a high volume outbound use case, their API integration and the number of actions which can unintentionally block dialing for a campaign while processing led to a constant headache of working around Five9, not with it.
Setting up the inbound stuff was pretty easy. And setting up the outbound wasn't necessarily hard. But managing outbound was... less than pleasant.
It's interesting that Amazon continues to move up the stack. This can't be great for folks like Five9, inContact, Genesys, etc. And it's probably incrementally negative for Zendesk, RingCentral, and Twilio - where some percentage of customer use cases is tied to contact centers.
I wonder if AWS will turn to Twilio to replace the SMS capabilities of SNS which are aging and limited with respect to modern features such as emojis and long messages.
I had they're one of the providers but I've also heard, from a smaller Twilio competitor at a conference, that AWS utilizes several SMS providers, which might make sense regarding the extra limitations.
While Twilio and Amazon Connect have some integrations it does not appear that Connect is built on top of Twilio. The Amazon FAQs says that all telephony services are charged separately by "AMCS LLC" which I'm guessing is a telco they've set up to do this at the lowest possible margins. If they went through someone else their pricing would be higher.
Twilio entered into an agreement with Amazon to power their telephony services. I wouldn't be surprised if this was built in collaboration as they'd benefit from the volume.
Twilio has been using many AWS services since inception. Many of Twilio's early team members, including Jeff Lawson came from Amazon/AWS. It was while at Amazon watching AWS's explosive growth that Jeff had the lightbulb to offer cloud telephony services.
I've been watching $TWLO as I think their stock is undervalued. They do have some risk in terms of a few customers that make up the majority of their revenue (see $FB). Anybody know how big of a deal/partnership this is? Terms?
twilio isn't going anywhere. Its not worth amazon's time. You're talking lots of integrations with legacy ISPs which takes time, and not profitable / revenue heavy enough for Amazon's time.
Also, their market share is being eroded from the bottom, as nowadays Asterisk-based call-centers are ubiquitous. You just need an Asterisk ISO (or appliance) and some additional software for statistics and agent interactions - like https://www.queuemetrics-live.com/ - and you can run a 50-agent inbound/outbound system in minutes. So much of what used to be a captive market for big PBX makers is now gone.
And the numbers we see are very significant.
This feels a lot like Amazon's ecommerce activities. Since Amazon own the platform in ecommerce, they can detect which goods are most successfully sold, sell those goods themselves, and use their scale and distribution to muscle out competitors.
Now since Amazon owns the cloud infrastructure, they can detect which apps are among the most successful (e.g. customer service apps) and build only winners. Again, they can use their scale and distribution to muscle out competitors.
You seem to assume that they have bad intentions. They are just increasing the number of value-add services they offer. They aren't necessarily trying to muscle out competitors, competition in the marketplace is ultimately great for the consumer.
> competition in the marketplace is ultimately great for the consumer
Not necessarily. History is replete with monopolies that arise through competition; cabals, sweetheart deals and other secret arrangements designed to fool the consumer into believing there is competition where there is none; race to the bottom in terms of quality vs profit margin; exploitation of underprivileged workers; and so on.
Not to say that all competition is bad, just that market competition is not a panacea.
into believing there is competition where there is none
It feels like you're validating the original point here. These secret arrangements are not competition and instead consolidation. If market competition did exist, free from illegal practices, the product that provides the most value for a given consumer will win that customer's business.
You're instead talking about why anti-competitive practices are bad... Which is why we have the sometimes-inept DOJ.
I think this is a safe assumption. It's well known in the dev tools space that if you do well, AWS will start to compete with you.
A bunch of VCs have articles about how the big cloud players change the ecosystem (esp that AWS will just compete - won't even offer to buy), and Andy Jassy said something like "your success is our opportunity" at the last re:invent.
(I should really have citations for all this stuff but a quick search didn't find them and I'm in a rush, sorry!)
I wouldn't call it bad intentions. I'd call it being opportunistic or having unaligned incentives.
When you own the platform and discovery features (i.e. search), you can create an environment in which your products could be on average more successful than 3rd party products.
The calculation to build your own products is probably "is the total value of having a given category of 3rd party products on my service worth more or less than if I build that category of products myself and sell directly to customers?"
This is correct. A lot of people don't realize that Amazon actually makes more money from Marketplace (3rd party sellers) than they do with their "Sold by Amazon" products.
The store I work for sells on Amazon and we've listed things that Amazon doesn't sell (and never has sold). Each time we did that and the product sold well for a month or two straight, Amazon would start selling it for less than we were able to (less than the wholesale price we were getting the products for!), forcing us to stop selling it.
If Amazon really makes more when we sell it than when they do, there's no reason they would have undercut us by that much every time.
edit to add: In case it matters, the types of products we this happened with were coursebooks, toys (from foreign manufacturers), and wall and desk calendars.
On any individual product, Amazon makes more when they sell it, most likely. But the point is, that there are way more products sold by 3rd party than within Amazon. So in aggregate, they make more on 3p.
It may be context dependent: today they have many high value uses for capital, better than using it for filling a warehouse, but in the future ,this could be different.
Contact center apps are definitely not the most successful at this point in time and as a category is looked on pretty unfavorably by VCs compared to other spaces.
I assume that's because few of the CC app developers have any real world experience in a call center. The applications I've used have terrible keyboard support - it is not cool to require an agent to use the mouse when they are expected to asynchronously take and give information.
They are doing this to train Lex and Alexa on conversations. Remember Tesla has better data therefore it has the betters self driving car. The end goal is of course to lose the human operator.
While Americans are worried about jobs lost due to H1b, outsourcing or offshoring, such automation will be the real job steeler. It even steels the outsourced job back to US!
Curious to see the effect of Amazon Connect on call centers in US and around the world.
As an aside, the level of over-employment in the US and the UK blows me away at times. I walked by tiny hole-in-the-wall type restaurants that could seat maybe 20, and they had valet parking (because why not?). Two valets were working 4 car spaces.
In the UK, a postman walks into a 100 apartment building and goes door to door putting the mail and packages into the slot for each individual unit.
Anywhere else in the world, you park your own car, and your mailbox is at the entry of the apartment building so the postman can access all 100 mailboxes at once.
Maybe because i'm a noob on telephony dev. but what's a "soft phone"...does that mean that the humans who receive the calls don't actually use traditional phones (like landlines or mobile phones), but rather via their web browsers?
Silly question: but if i didn't want my folks to use web browsers, and simply wanted to route a call to whomever is on call (and that person works remote, let's say), I wonder if possible to simply route the calls to that person's mobile phone?
Thanks. It seems - based on other comments - that this is likely a service for bigger customers, so i would guess those customers know what these terms mean.
Presumably, it is designed for larger customer support requirements, where you have a call center team taking many calls one after the other. It doesn't seem worth it to take occasional support calls.
1) If you're a contact center veteran but new to AWS, know that evaluating any just-launched service against existing competition is unwise. Check back a few months after they've had time to incorporate customer feedback. AWS released over 1000 updates to the platform in 2016, and Amazon as a whole deploys software about once per second. Think twice about brushing this off like EMC, Oracle, HP, and Cisco did around 2010.
"Amazon Connect supports voice interactions for incoming and outgoing PSTN telephony...It supports DTMF input, text-to-speech output using Amazon Polly, which can optionally be combined with Amazon Lex...for natural language interactions."
Sounds like you can build a fairly sophisticated robodialer with it. That's not terribly easy to find out in the market. Hope they have some controls to curb abuse.
Twilio got out of that business a long time ago in order to focus on the core product, which was the right decision at the time and ultimately still now. There are loads of Twilio customers who make their living sell contact center solutions built on top of Twilio and that is exactly what Twilio wants.
There is a 100 ways to integrate it with WebRTC. You don't mind wasting 6 hours of your life driving, but can't be bothered to do your own research, let me guess, you are a sales person, selling cloud stuff.
Thanks...That was helpful. ;) Have a look at my profile if you want to know what I have done. Driving with kids is what you do as a parent on spring break.
As for the question, I was trying to discern if amzn was making the video conf functionality (debuted with the Kindle Fire) for customer service available, or if integration was contemplated and discussed in the content. It does not appear as such.
I wish I could give you 100 uovot s to encourage more of your behavior.
(1) I do not like putting all my eggs in one basket for telecom. I don't care if Amazon is managing the API server for my grandma's heart monitor - I never trust one TSP. One TSP = one point of failure. I hope they do something to address this. (and please don't bother replying with some assumption that multiple paths disqualifies the need for redundancy through multiple TSPs)
>Amazon Connect runs on Amazon Web Services proven infrastructure operating 42 Availability Zones within 16 geographic regions around the world. This makes Amazon Connect more highly available, fault tolerant and scalable than would be possible if a contact center solution was run from a single data center.
Amazon Connect is only offered in US East as of right now. I wonder what that means for reliability/fault tolerance. Does the user have to initiate geographical replication?
(2) I do not like relying solely on an internet service for telephony/CC. I will rely on it for most of my telephony/CC most of the time, but I see no reason why CC offerings shouldn't have some kind of offline component. I hope they do something to address this concern.
(3) I see they have released the "Streams" API[1]. It's well documented, which means I can create similar API calls for an offline replacement. I'm glad they addressed this somewhat, although I wish they would consider making a useful multipurpose soft phone so I can use SIP registrations from other systems in an emergency.
(4) The limit of 10 DIDs seems exceptionally low. Sure, once the call hits Amazon, it can go through its routing steps, but Amazon is not in control of where the customer gets the number. DIDs often serve an analytical function, especially when that's the only useful data (besides Caller ID) coming in from the PSTN. It would seem more reasonable to max out at 100 (yes even for a starter account). I hope they do something to address this concern.
(5) Getting to use their ASR is a big deal - especially over the PSTN. When I realized I'd have to write an MRCP plugin just to reliably stream audio to the Google Speech API, I gave up on that dream. I wish Google would address the concern of PSTN to the Google Speech API... I don't care about any other call center doodad, but being able to leverage a speech processing - especially Google's or Amazon's - API is a really big deal. The fact Amazon has made this available over the PSTN with the possibility of having an API make decisions from speech is exciting.
All in all, this is nice and I'm sure they have rough edges they'll polish. At the end of the day, their speech stuff is something I'll definitely be using, the other stuff does not make me feel confident it's redundant/fault-tolerant. There are just too many points of failure.
Item #5 is the key. Nuance dominates the ASR market for IVR based speech applications. BlueWorx has a MRCP product for IBM Watson. I press the Google team constantly to provide ASR for IVR solutions. We move most customers off clouds because of either (1) poor telecom performance/quality, and (2) lack of enterprise ASR for IVR self-service.
1. Charging you per-minute for use of the service.
2. Charging you a per-DID fee per day of use. Why? You are already paying for the service, and for the VOIP termination. BTW at Amazon scale, the DID numbers are either free or less than 10 cents/month per DID.
3. Charging you (in the USA at least) for the actual VOIP calling.
With 1) and 3), a USA call costs you 0.0048 cents per minute on inbound. Under usual circumstances, inbound calls to USA numbers are free.
They will also (should you request it) record the calls and store them in S3...
It's worth noting that, at that scale, you actually get PAID for inbound calls. At MagicJack, the cost of our went into the negative because of access fees. Even though Amazon is not a carrier (yet), they will likely work a deal to get paid.
Vonage does the same thing. They receive a revenue share of the access charges from level 3.
Is this pricing that unusual? Almost all the other products I've looked into had pricing plans where you pay a per user license, plus the cost of a DID and usage. A couple offered just per user license, but when you did the math you could have people to be on the phone for 10 hours a day before you started saving vs per minute prices
Yes it is very unusual in this industry. As a matter of fact, it is so unusual that it will continue to exist for the foreseeable future since most companies depend heavily on the licensing model to survive. It's the heart of their operation - changing it would most likely have an adverse impact on their business.
But, it is going away with companies like Fenero, and now Amazon Connect, leading the way.
Amazon Connect has a lot of catching up to do since it is no where near the feature set required to run a real contact center (it can't even support blended agents or call outcome dispositioning and reporting!)
I totally understand why Amazon Connect may seem like a big deal for those of you outside of the space, or that aren't real close to the various advanced technological capabilities in this industry.
Thats why we have removed per agent pricing and charge only for minutes[1]. After some scale, it might make sense to go for fixed agent rental. But to start of,its better to have no agent pricing.
Hmm, I've never heard that definition. Maybe "cloud hosting". But in general, "cloud" software just means hosted somewhere else and usually accessed via a browser or mobile app rather than with a local install.
I build "cloud" contact center software. To most people it just means no servers at the customer site. To discerning customers, cloud means horiz-scaling, while hosted just means we manage the servers for you.
All of the contact center solutions mentioned so far were customers of mine at MagicJack. We did wholesale long distance for them. The one trend in the industry is that long-distance continues to fall fast, but the pricing of telecom-related apps stayed the same.
Since I am no longer under NDA, the average cost of long distance (US Domestic) at MagicJack when I left in 2013 was $0.0017/minute!!
For those saying contact centers won't move over because the investment - I will tell you that we lost and gained 1,000 agent operations over 10% cost savings every single month.
[1] - http://blog.kunnect.com/2014/10/how-much-does-cloud-based-ca...