I'm creating a twilio service with three actors:
The customer, a person who calls a company
The company, a company who forwards calls to the service-provider
The service-provider (that's us), an entity that services the customer on behalf of the company
Herein lies the catch: The service provider needs to be able to identify the company associated with the customer but it may only use a single phone number. We cannot use multiple phone numbers for cost reasons (the margins are that low). We cannot use the caller id because a single customer may be associated with multiple companies.
I am familiar with Twilio's ForwardedFrom field but as mentioned here it isn't always reliable. In fact, forwarding from my cell-phone carrier results in a null ForwardedFrom field.
How can we (reliably) identify the company who redirected a customer to us without using multiple phone numbers?
You can use the number + extension. http://www.twilio.com/docs/howto/ivrs-extensions
Perhaps you could build a sort of phone tree system, asking the caller the nature of their problem, which would be an indicator of the company their call is related to.
My guess is that you wouldn't want an outright "which company are is your call related to?" question, because that would feel cheap to the customer. So, maybe you could formulate a question or series of questions that wouldn't be overtly asking which company their calling about, but the answer(s) would clearly indicate on the service-provider end which company the call is about.
This could be further whittled down on the service-provider end by doing a company lookup based on the customer's calling number - if it matches a certain company (or set of companies), then that automatically limits the potential company they could be calling about.
Another possibility (if it fits in your use case) is some sort of we'll-call-you setup. Perhaps the customer could text/email requesting a call, and the information they'd provide in the text/email/online-form-submission would indicate the company they wish to speak about (again, you could use questions that aren't overtly "which company do you want a call from?").
Then again, if it's such a low-margin operation, maybe the companies are ok with a phone-tree style call-in number, where the customer needs to select a company they're calling about which is then indicated to the service-provider.
This doesn't seem to be possible at this time (2013). I will keep an eye out for new answers and will accept them if this becomes possible at a later time.
In general, I'd recommend separate numbers per customer but since you say that's not an option, here's another approach:
When the call comes into the Company, that individual leg gets a CallSid which is a unique identifier. When the call is forwarded to the Service Provider, that separate leg also gets a CallSid. Let's call them CallSidOne and CallSidTwo respectively.
If you then query based on CallSidTwo, you'll get back its instance properties as listed here:
http://www.twilio.com/docs/api/rest/call#instance-properties
The key property here is "parent_call_sid" which should be CallSidOne. Therefore, you can connect the two segments together.. then you can query on CallSidOne which gives you the ability to track who called which customer called which customer when.
Does that solve your problem?
~Twilio employee
Related
On a ride booking app, it is required communication between driver and user.
Now the case, if user A contacts the driver via website or app, call or sms can be achieved via Twilio, we don't want to expose their contact numbers to each other.
If three users A, B and C contacts the driver and driver has no app installed, in fact the driver wants call back and sms reply. How the driver can reach users on Caller ID.
There could be large number of users and we can't buy separate twilio number for each user.
Please advise the solution.
How many users are likely to need to contact each individual driver at any one time? Not many I wouldn't think.
Buy 10 Twilio numbers, assign them incrementally as users call/SMS their driver and save the assignment for user/driver numbers in your database.
If the driver calls/SMS a number in response query the database and route the call/SMS to the user it was assigned to when they called the driver.
Recycle the 1st assignment once the 11th user calls/SMS the driver, rinse and repeat.
Twilio developer evangelist here.
In order to maintain anonymous communications in this way you need as many numbers as the maximum number of relationships one person in your system has. The best explanation of this is in this article on masked text messaging with Twilio (though it applies to calls too).
Your comment on miknik's answer suggests you want to keep these relationships alive forever. This is not the way that most services build out this feature. They normally give a particular length to the relationship, Uber for example will recycle the phone number a number of minutes after a ride ends.
If you are looking for an easier way to manage this kind of number pooling and masking, check out Twilio Proxy, it handles a lot of the logic for you. It is still in developer preview right now, but you can apply for early access.
I've been using /d2l/api/lp/1.4/enrollments/myenrollments/ to get a list of enrollments for the current user. Now, I want to just get the enrollments where the user is in an instructor role. So, I'm trying to use:
/d2l/api/lp/1.4/enrollments/users/{userId}/orgUnits/?roleId=105
When I use that, I get an empty list of Items back, with or without the roleId specified.
My expectation is that just calling it without the roleId would return the same list as /d2l/api/lp/1.4/enrollments/myenrollments/. But, I always get an empty list, except when I log in as a system administrator. Only in that case do I get anything back.
Does anyone have any suggestions on what I might be doing wrong?
The various my* API calls specifically exist to provide end users to fetch back details about the system that they should know, but segregated from information they shouldn't (that's available through the more general routes for a particular area). Enrollments is a good example of this. And end-user should be able to see their own enrollments, but they should not have generalized access to enrollment records. In particular, the D2L system treats the D2L user role belonging to an enrollment as fairly privileged information, and a side effect of this is that it's not generally visible to end users.
One way that applications and services can cope with achieving goals that the end-user cannot themselves perform is to have set up a "service account" that the app can use to make calls of an administrative nature, to fetch back data that they can use in the business logic around presenting information to end users. In this particular case, you could, for example use the service account to make calls about a user's enrollments, and then present the user with logic that could filter the list of their enrollments by "these are the student ones, and these are the ones where you're a teacher, and a tutor, and so forth".
But you'd also need to carefully consider the implications of this type of activity in balance against the intentions of the client LMS's policies and administration. Even this level of information may be giving away too much to end users, in the eyes of a client LMS administrator.
Using a service account to let an app make administrative level calls must always be done with great care around the issue of information/functional leakage to end users.
We have one client having two account numbers and single trading partner id. Now
the client sends PO(s) through VAN (Value added Network),
My Question: Is there any way to identify for which
account number's PO is received?
Our Van process is identifying the PO on the basis of Trading Partner ID.
We need to sort the PO(s) according to account number.
The N104 would be a good way to do it. Most of the time, the N104 would designate store location, which you would cross-reference in your application to your account number.
A REF02 could also work, but the N104 was really made for this.
yes, that can be problematic.
check andrew's answer for this, maybe other options:
- GS02 (sender)
- I one had to check the items numbers to find out the right accountID.
Check why the edi-partner has 2 accounts. This often gives a good clue on how to handle this.
And check if it is still needed ;-))
I have a very simple Twilio setup for my company as our phone system. I've one specific problem: at the moment, anyone can use any of the numbers that have been associated with the company on the site for calling out. So Bob might accidentally use Alice's number, and that's unfortunate.
How do I change that? I would like to be able to set it so that each non-administrator user can only use one phone number for calling out, specifically the number associated with their user or device.
You could use subaccounts:
http://www.twilio.com/docs/api/rest/subaccounts
Alternatively, enforce the extra Caller ID logic in your own application and refuse calls if they don't match the correct params.
I have a bunch of customer data that is normalized into multiple tables. I want to decide the best criteria for make a best guess that a customer might be the same. There needs to be a balance between minimizing the number of duplicates but also minimizing the false positives and therefore interrupting users to ask about potential dupes.
I am looking at some combination of first/last name + phone number || email address.
The first question is, what is a good set of criteria for determining if a customer might be the same as another customer.
The second question is, for this specific application, I only want to detect duplicates for customers that have signed up within the last 2 months or so. Does this change the detection criteria at all?
How would you go about asking a customer if they are the owner of a duplicate accoount?
"Hey Sam Jones, there is another Sam Jones that has an ip in your local area, his email is sam.jones#abc.com and your latest registration had an email of sam.jones#apple.com, are you the same guy/girl?"
If the above is even close to your scenario, then you would be leaking private information. i.e. the other Sam Jone's email address.
Typically you don't allow a customer to signup with the same email address, and secondly you verify that the email address they do sign up with is valid. That way if they signup again with a mistype in the email, they can't validate it.
An important thing is to choose attributes that are unlikely to change. If you use something like telephone number or email address, you risk having duplicates any time someone changes ISPs or mobile phone providers.
If these customers are customers that have made purchases in the past, you can store a hash of their credit card number and a hash of their billing address. Whenever they make another purchase, hash their payment info and compare it to your database. (notice I said to store a
hash, NOT their actual payment info)
if this question is of still interest to you, please check this tool https://sourceforge.net/projects/deduper/
I wrote this tool mainly for the purpose that you have mentioned in this question