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.
> Anyone can tell folks who are not into call centers like me why this TaskRouter is so special?
I have a work queue which routes tasks based on events on an ECommerce website [leans towards small businesses] so I basically built something identical for internal use.
For instance, we generate a SMS to customers when there is an issue with their order. [e.g. Item out of stock or not enough stock to fulfill the request] We then generate a call center task to call the customer if they haven't responded by the time the warehouse is ready to ship their order.
This is frequently a problem with Amazon shipments as they are generally small purchases and Amazon doesn't update our inventory in real time. They also to send FBA shipments via the merchant if they are having issues. So we'll get an order for 20 of part X and only have 5 in stock on our long tail items.
If you don't get ahold of the customer, they get pissed because generally they told their customer they'd have their car fixed by day X.
Pretty much all of operations, not just call centers, is managing task completion. Stuff needs to get done, gets routed to individuals who work on it, perhaps needs to be reviewed or approved, etc. Looks like a generic workflow system which could certainly be interesting.
My first job was building something like this into sugarcrm circa 2005. It was more of a generic workflow tool and is a great way to automate business process. Not not sure how enjoyable it was for people to come into work, check their taskboard, and find 20 identical tasks on their list of things to do that day though.
It certainly exposes bottlenecks if they weren't obvious already.
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.
Will it be possible to plug in 3rd party platforms? For example, can I plug in a task to POST to the API of another platform with some data about the call?
Hmm, a marketplace for these 3rd party integrations to advertise compatibility would be pretty neat as well.
A fair concern. I think Task Router is less going up the food chain and more going up the stack - we're trying to provide more abstraction for the state common to all these problems as a pure platform.
My hope is all our customers can leverage these primitives to invest more development time in their applications rather than solve the same mundane problems over and over again. I think that's the promise of a continually improving platform rather than an elbow move.
I would agree with the characterization that it's moving up the stack... but it does seem to (without saying it explicitly -- not clear whether that's conscious or not) start to overlap heavily with an existing space [1]. How would you differentiate it from BPM / workflow tools (one open-source example being Activiti [2], but there are many in the market)?
