With simulring, voice mail picks up and its considered answered. Inside Twilio Studio Flows(or anywhere else inside Twilio), is there a way to have the person answering have to interact to actually accept the call vs just answering the call. I am trying to create a system that rings multiple sales peoples numbers and the first one to answer gets the lead. Voice mails are killing that system.
I've reached out to support with no luck
Related
I've got a basic twilio setup using studio for a simple IVR (like less than 20 minute setup kind of simple).
One thing I'm doing is using simulring to hit multiple parties and whoever answers. The issue I'm having is that if there is a voicemail to be hit, it appears to be ok with that and then plays the endpoints custom voicemail.
That's not really good with our setup.
Do you guys know how I can trigger the calls to multiple phones, detect a real person and then transfer the call, otherwise trigger a voicemail?
I can't imagine this is unique.
Twilio developer evangelist here.
There are two options you can use here, either call screening/human detection, in which you ask the person answering the phone to, for example, dial 1. A voicemail won't do this and you can leave a message or hang up, a human will dial the number and you can then take them on to the rest of the call. Or there is answering machine detection (AMD). When making an outbound call with AMD, once detected Twilio will make the webhook callback with a parameter that describes whether the call was answered by a human or a machine.
I recommend reading this article on both options, which should help you to understand what will work best for your use-case.
I've nearly finished my lambda service for my smart home skill, and everything works great. The Echo is receiving my confirmations and correctly relaying their information. I'm now trying to build in error handling.
From the SHS API reference, there are a bunch of error messages listed that correspond to different circumstances. Are these errors supposed to change what Alexa says? Regardless of which one, if any, that I use Alexa just responds that the command doesn't work on that device. Right now I'm literally just using callback(err) and return the copy and pasted object from the API reference and still Alexa responds with the generic error.
It's easy to put in a bunch of constants to define error returns. It's harder to wire all of that into a firmware patch of a hardware device. Also, they only release an update to the SDK a few times a year. While they patch the hardware every couple of weeks.
Given that, I suspect that they put those error returns into the SDK to meet with a ship date with the SDK. More as placeholders than specific functionality. Over time, and if there is increased adoption of home skills, they will roll out updates to the hardware device that will take advantage of those returns.
My advice would be to use them. But not to expect there to be a difference right now. And don't mention differences in your documentation. If there is another place you can surface diagnostic information, you might want to do that so your customers can fix their problems.
I would like to know if there is a web api for asterisk. I would also like to know if the average wait time to talk to a customer service agent is exposed through the api.
I have looked around online, but could not get an firm answer.
Any pointers are appreciated.
AFAIK, no, there is no such thing in Asterisk.
What does exist is the ability of parsing the queue_log file. You can get the moment the call started, the moment the call was answered by an agent, and subtract them - this will give you the wait time. Also, the first extra data value of the CONNECT event contains the time waited.
(If you are not in the mood for parsing a text file, you can register the queue logs in the database and use SQL to generate reports based on the logs. This is in fact my preferred approach.)
If you want to provide this information to other apps, you can write your own application which reads queue_log file/table and provides a webservice which returns wait times. In the case you decide to do it, we can try some more robust answers.
Note: A have asked this question at the Superuser community first, but since it involves a lot of software-building-related topics I decided to move it here.
I need to provide a simple call-center solution to a small local business.
They have a local 6-digit land line number. They accept calls locally, i.e. nobody calls them from another cities.
The problem is that they started to lose customers, because with a certain amount of calls every day it has become impossible to reach the local phone number (it is always busy).
So, there is a call center solution needed.
I assume that I can somehow hook to Asterisk PBX and then do all the business logic and CRM stuff with some Java+MySQL custom written module.
I tend to think that I could have a PBX server with a land line somehow plugged in to it, and in addition to that I can call the PBX API from my Java/MySQL custom written module.
So, what should I start with? How can a land line number be attached to a PBX server? What is the best open source PBX that has rich API to call?
P.S. Here is the SRS:
The non-functional requirements are:
the client needs the quickest time-to-market possible solution;
open source: the client does no like to be in 'vendor lock-in';
the main call center server's API should be accessible via the Internet, which means that a telephone operator can pick up phone calls remotely (sitting at her home computer, for example);
the solution should be scalable from just a couple of telephone operators (persons who accept calls) to many.
The functional requirements are:
when a customer makes a call his phone number should be looked up in a database; if there is a record, then the phone operator should see something like "John Smith is calling you (Customer details: Number: XX-XX-XX; Last_order: 1 Jan 2012; etc.);
if there is no db record for the calling customer, the phone operator should be able to add the new customer do the database (the phone number is filled in automatically);
the customer's call can be put on hold or redirected to another telephone operator;
a next customer in the queue can be picked up the the operator manually or automatically;
if a customer calls and the line is busy, she is put in the queue;
the telephone operator can set a status: Available/Not available;
if the phone operator does not pick up the phone, the call is redirected to the next available operator;
the phone operator should be able to make a call back to any of the customers recorded in the database; the call can be manual or automatic (automatic means the software keeps calling if the line is busy);
each customer call can be recorded and stored on disk.
You could definitely build everything you want using:
an Asterisk box with an FXO/FXS card for connecting to the 'land line' (http://www.digium.com/en/products/hardware/analog)
a Webserver (could be on the same box)
Software SIP Phones for your queue agents
You could also build all your own software on the asterisk box to perform these functions. However, if you really want something 'quick to market', I suggest you look into one of the available Asterisk CRM products. A quick google search turned up the following open source options:
AsterCRM (http://astercc.org/products/astercrm)
KINAMU/abcona Open Asterisk Connector for SugarCRM (http://www.sugarforge.org/projects/yaai/)
Hope one of these solutions fits your needs. If your client becomes more flexible on the open source part, there are also several other CRM integration projects for asterisk.
I need to invoke a long running task from an ASP.NET page, and allow the user to view the tasks progress as it executes.
In my current case I want to import data from a series of data files into a database, but this involves a fair amount of processing. I would like the user to see how far through the files the task is, and any problems encountered along the way.
Due to limited processing resources I would like to queue the requests for this service.
I have recently looked at Windows Workflow and wondered if it might offer a solution?
I am thinking of a solution that might look like:
ASP.NET AJAX page -> WCF Service -> MSMQ -> Workflow Service *or* Windows Service
Does anyone have any ideas, experience or have done this sort of thing before?
I've got a book that covers explicitly how to integrate WF (WorkFlow) and WCF. It's too much to post here, obviously. I think your question deserves a longer answer than can readily be answered fully on this forum, but Microsoft offers some guidance.
And a Google search for "WCF and WF" turns up plenty of results.
I did have an app under development where we used a similar process using MSMQ. The idea was to deliver emergency messages to all of our stores in case of product recalls, or known issues that affect a large number of stores. It was developed and testing OK.
We ended up not using MSMQ because of a business requirement - we needed to know if a message was not received immediately so that we could call the store, rather than just letting the store get it when their PC was able to pick up the message from the queue. However, it did work very well.
The article I linked to above is a good place to start.
Our current design, the one that we went live with, does exactly what you asked about a Windows service.
We have a web page to enter messages and pick distribution lists. - these are saved in a database
we have a separate Windows service (We call it the AlertSender) that polls the database and checks for new messages.
The store level PCs have a Windows service that hosts a WCF client that listens for messages (the AlertListener)
When the AlertSender finds messages that need to go out, it sends them to the AlertListener, which is responsible for displaying the message to the stores and playing an alert sound.
As the messages are sent, the AlertSender updates the status of the message in the database.
As stores receive the message, a co-worker enters their employee # and clicks a button to acknowledge that they've received the message. (Critical business requirement for us because if all stores don't get the message we may need to physically call them to have them remove tainted product from shelves, etc.)
Finally, our administrative piece has a report (ASP.NET) tied to an AlertId that shows all of the pending messages, and their status.
You could have the back-end import process write status records to the database as it completes sections of the task, and the web-app could simply poll the database at arbitrary intervals, and update a progress-bar or otherwise tick off tasks as they're completed, whatever is appropriate in the UI.