[diggz]

I'm Diggz, Chief Evangelist at Tropo.  I'm sorry you had a negative experience with Tropo.  We're constantly improving our docs and services and would love to hear any feedback you have.  I was recently made aware of your SMS load test with Canadian numbers and I believe with a couple of tweaks, we can get those SMS's cruising along.  

For SMS-only apps that don't use voice or speech recognition, we also have http://SMSified.com which is a RESTful API based on the GSMA standard for SMS - launching in international beta soon (U.S only ATM).

International SMS is tricky (as most will agree) but we do have many devs and customers using our Tropo Canadian SMS service without performance issues.  One of the reasons we don't charge developers to test on Tropo is because we know it takes time (and lots of testing) to make an app that your customers will be able to trust and rely upon. Feel free to email me at diggz at tropo dot com.

[axiom]

I definitely recognize that SMS is a tough problem, so I sympathize as an engineer. That being said, as a customer I don't care about any of that, I just want it to work.

Simple test: send more than 1 message from a phone number in the span of 15 seconds during a bulk test. At random Tropo will drop the second message because the first one hasn't gone through yet on your system. No error message, nothing, it just drops the data. I know why it does this, I've read the docs, but that's a crazy "feature"! why can't you queue it like Twilio does? that's just one example. Don't even get me started on your logging system. There's no sane way to get reports! none!

We looked at SMSified and even tried to use their Canadian numbers (somehow we got a few Canadian SMS enabled numbers even though we were told it's not supported.) That thing was basically unusable. Delivery rates of around 60%, with totally random inexplicable failures.

Twilio on the other hand has been awesome. No weirdness, very reasonable defaults, rock solid performance, good logs. Just very pleasant to use in general.

[diggz]

I appreciate the feedback and I also agree with you on several points. Tropo's logging today IS incredibly verbose and I've been working with our product dev team to filter it to make it more developer-friendly.

You are correct that Tropo does not have built-in queueing today and I also agree that it should at least let you know if it can't deliver a message.

Better reporting is also at the top of our list for the next rev.

Again, thanks for taking the time to give me your feedback. I think you'll be pleased to see these suggestions baked into the next version of Tropo. +) Diggz

[axiom]

Awesome, thanks!

Any ETA on those changes?

[diggz]

On the roadmap for Q1 2012