758 karma · joined March 30, 2010
Keen to hear more about the deliverability issues you are experiencing.
BVP did participate in this round - great team to work with.
[edit] typo.
This is only the first step.
What would you want to use it for?
Have you had an opportunity to check out TaskRouter yet? We released it a few weeks ago - definitely my favorite recent product that works with Twilio Voice:
If you both would like to shoot me an email to rob [at] twilio [dot] com, we'll ship you a t-shirt as thanks for pointing out the error.
1) Smarter Routing - quite a few developers have expressed they'd like to know whether or not a phone number is a landline or not before attempting to send a text message. Twilio Lookup will describe whether the number is mobile, landline, or voip so you can choose the appropriate communication to reach the number.
2) Error Checking - While libraries like libphonenumber are useful for determining if a number can possibly exist, there are some conditions where determining if a number does exist is more valuable. This can be used for error checking - if I as a user input a typo in my phone number (e.g. I mistype my personal phone number as '(347) 193-6073' which does not exist instead of '(347) 923-6073')
I also suspect across larger applications carrier info might also contain useful demography. For example, knowing that your users in Montana mostly use Verizon might inform your advertising to surface more CDMA devices in that market.
Ultimately this will probably end up like every other product we release - the killer use case is one we never even considered.
Good feedback - appreciate you sharing. We do have geographic information with each webhook sharing city, state and zip - agree it would be useful to have this in the Lookup resources as well.
Certainly nothing we'd rather be doing.
Whole lot more work between here and there - glad you could be a part of it with us.
Took a lot of work to get here - stoked to hear you are finding it well.
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.
[edit: typo]
Does that make sense?
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.
Does that help?
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...
https://www.twilio.com/blog/2014/09/getting-started-with-twi...