41–50 of 85 posts
Earlier quoted context omitted.
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.
Twilio did a presentation at re:Invent last year talking about how they power AWS SMS messages.
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…
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…
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.
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!)
They are making money at multiple points: 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…
The world's largest collection of customer service phonecalls might make an interesting training corpus for ML/AI projects.
They are making money at multiple points: 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…
My first thought was this was a way to get an enormous amount of recording call information to train the AI inside of Amazon.
(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.
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…
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.
Some things: (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 Ama…
That AWS failure that was... last month? The month before? Took out half the Internet, including AWS's own status panel.
Good job, Amazon.