Most ACD platforms provide work flow routing APIs so that third party applications can route tasks to the connected agents. Doesn't mean this is any less than an ACD with API's on it. Also task routing has become ubiquitous with the omni-channel multi-channel routing and CRM routing you see across all contact center vendor platforms.
Rob from Twilio here. Very fair question - a lot of these concepts are foreign for folks that haven't worked in the call center space before.
I think Al Cook on our product marketing team described it most aptly as referring to Task Router as "ripping the still-beating heart out of a high volume call center and sitting it on a table for a developer to plug in his/her app."
Task Router is a set of primitives that takes the state that must be managed to accept work from multiple channels and delivering it to resources that can complete them. You can define the core logic to accept tasks from any channel, assign it to the appropriate workflow based on its attributes, and connect it to a resource ready and able to complete it. These flows are defined by you, all without re-implementing the state management common to this problem domain.
You are doing yourself a disservice by talking about "primitives" and "call state" without naming the actual, industry-standard mechanism you have built.
This is an ACD. In the cloud. Using common terminology gives other developers a reference point in which to do more research and draw their own conclusions about the technology. Even a reference and link to Wikipedia would be good -- the ACD page is lucid [1], and I understood exactly what an ACD does after reading that. I don't get the same sense about TaskRouter from the blog post.
You have a decent explanation of an ACD mechanism, but now telecom-inexperienced developers have to try and internalize your meaning without the benefit of knowing the precise jargon, and potentially missing out on the decades of experience others have had in this field.
From the WikiPedia page: "Routing incoming calls is the task of the ACD system".
TaskRouter isn't an ACD in that sense.. or no solely an ACD system anyway. It is an API driven way to distribute user defined tasks. It can serve as an ACD, such as routing calls to an available agent.. or.. SMS.. or chat.. or "tickets" or whatever you define as a Task and a Worker using.. primitives. No dependence on calls.
To your point.. maybe using the ACD would help some people understand it at first glance.
Sure, that's what the Wikipedia article says (since calls are what ACDs were originally designed for), but commercial ACDs have been multi-channel for a long time, doing all the things you mentioned.
Totally fair solution. Some folks like to roll their own, some folks like to use ours. Important bit is the app is validating the data is sending and receiving.
Param ordering changes in your framework can definitely hit. I've caught similar bugs when upgrading frameworks before hitting production with some validation unit tests. Here is an example if that is helpful: https://github.com/RobSpectre/Twilio-Hackpack-for-Heroku-and...
Kind of you to say - we work pretty hard on it. If you want a quick intro to the interface, we've but up examples in six languages for you to take a look at:
Awesome - stoked to hear SMS on toll-free numbers is working out for you. We're keen to extend MMS to them as well - don't have a timetable to share on that score.
Bandwidth are indeed a bunch of bright folks that do good work and we work with them on a number of products, but to be clear we are not reselling their messaging.
Lot of effort by a large crew of committed developers and the helpful participation of our carrier partners are what brought Twilio MMS to market on US phone numbers. Were MMS as easy as wrapping another product in a HTTP request, I imagine it would be a more common offering.
Want to make sure the effort of the Twilio engineering crew is given its due.
Would love to learn more about why these messages are failing for you. Reckon you could shoot us some of the failed SmsSids to help@twilio.com? I'd be much obliged.
Webpage says it's sent but nothing ever arrives to the phone. I'll send an email to help@twilio.com with my phone number if someone over there wants to try a few test sends for debug info.
As a side note I just tested using the SMS page and it seems to work now. When I last tried it a couple months ago when swapping SIMs and trying to test SMS it silently failed with both sets of phone numbers and SIM Cards while every other SMS source I could try worked fine. That appears to not be an issue anymore so it's just MMS.
MMS to and from the phone works fine with Verizon and AT&T cellphones so I'd imagine there is some plumbing somewhere going wrong in my case.
I just tried this as well using my AT&T Straight Talk phone number, and the result was the same (message reports being sent, but never shows up on my end).
I'll also fire off an email so that you can have at least two numbers to test with.
Does that make sense?