dslreports logo
    All Forums Hot Topics Gallery


how-to block ads

Search Topic:
share rss forum feed



[General] IVR new setup

Hi Team,
i could not find this info online.
i am new to IVR,
what am i looking at for cost if all i want is

people call from outside,
get few options recorded,
punch in few DTMF options back to an SAP server, via ip.

no call center, no other fancy stuff.
i want a HW based thing, at the site where the SAP server is.

thats all




1 recommendation

Your question is too vague to give a specific answer. I assume that callers will query and possibly update an SAP database. Is that correct? Could you provide an example of what a caller would hear and enter for a typical transaction? How many concurrent callers do you expect?

If you will be processing only a few callers at a time, you can run Asterisk or FreeSWITCH on almost any physical or virtual server at your location. The software itself is free. If the incoming VoIP service is toll-free, expect to pay two to three cents per minute, plus a few dollars per month. For a local number, you'll pay $8 to $20 per month for each channel of call capacity.

The cost of setting up the system can be substantial, if you need prompts in multiple languages, have complex menus or help messages, have special security or logging requirements, etc. You may also want to pay for professional voice talent. If you don't have the skills in-house, there are companies that specialize in developing custom IVRs.

If the general public will be calling in, you should consider a speech-enabled IVR; it's dangerous to enter DTMF while driving.


Hi Stewart,

here is the setup,

a driver would call in after finishing his load from the PSTN that number, and only drivers do,
that number will give very few prompts to accept load number, location code, and amount,
all to be done thru DTMF RELAY, no more than 20 digits all together,

that dtmf need to go to SAP webservices enabled server via IP.

thats all
i expect no more than 10 calls at one time to each client setup.

i really want to find a system to demo in my office,
then install it at client site.
again, i know nothing about IVR or how the thing look like,
but i prefer a HW based, connected to a dedicated analog line, thats talks to that SAP server via IP at the site on the same LAN.

how is that possible ?



Why do you want an IVR? My first choice would be a smartphone app, if the drivers have smartphones and data plans (or access to Wi-Fi). To get started quickly, use a web form instead of a custom app.

If they don't all have smartphones, I'd have them send an SMS (text message) with the three numbers. Look at Anveo or Tropo. The SMS gets turned into an HTTP request, your server validates the information and sends a confirmation or reject text back to the driver. In addition to being faster and less error prone than the IVR, the info on the driver's phone could be useful for troubleshooting or resolving disputes.

If you must have an IVR, IMO it's quicker and more reliable to do it in the cloud. Tropo is designed for your type of app; Anveo can do it too (and less expensively), but their documentation is sparse and it can be harder to get started. However, either will be easier than using your own server.

If you must use your own server, I'd go with a VoIP number, at least for the demo, so you won't get bogged down with details of configuring FXO ports, etc. If you feel that VoIP is not reliable enough for the production systems, IMO you should use a PRI (with a backup if desired), it's more economical and less problematic than 10 analog lines.

If you absolutely want analog lines, for the demo get an Obihai OBi110 to interface one analog line to your server. For production, look at Digium's offerings.



whats the best way of doing this, without having to rely on smart phones, and too much technology...as these drivers have their own phones.
they are in oil and Gas, and the less complicated this is done for them the better. now its all done on a piece of paper.


I can't say what's best, but doing this with a text message will be a lot easier for you, may be easier for the driver, and would inherently include a record of what the driver sent and the confirmation he received.

For example, a driver would report load #1234, location #567, quantity 5000 by sending a text
1234 567 5000
to 415-321-4567, where that is an Anveo number set to forward SMS to HTTPS. See »www.anveo.com/api.asp?code=apihe ··· ive_http . When the SMS is received, Anveo would fetch e.g. »yourcompany.com/driverreport.php ··· 567+5000 , where 415-234-5678 is the caller ID from the driver's phone.

The PHP script on your web server would validate the input and pass it to SAP. Depending on the returned result, you'd send an SMS to the driver, either confirming the transaction or showing the error and requesting that he resubmit. »www.anveo.com/api.asp?code=apihe ··· end_http . Of course, you could use a language other than PHP, if supported on your server.

If you would rather accept the report with an IVR, you would set up an Anveo Call Flow that requests each parameter, accepts DTMF, and stores the number in a variable. When all have been successfully received, you'd send the request to your server, in a format similar to the above. Of course, setting up the IVR will require you to learn considerably more about Anveo. You could set up the same number to accept both SMS and IVR reports, and could send confirmations by SMS, even when the entry was made by IVR.

Tropo is even more powerful -- you could do your entire app on their server (provided that your SAP interface is exposed to the public Internet). I believe that they still offer free accounts to developers, so you could do the demo without any out-of-pocket costs. However, their learning curve is yet steeper.


thanks Stewart,
this is great info, i appreciate the tips.

i want to have a HW system for this, a box, that i own, and leave at customer sites, right next to the SAP servers. with a PRI i guess dedicated for that inbound call.

for something that simple would you still suggest Aveno ?




Simple? This all may be simple in concept, but the full implementation doesn't sound that simple to me (for a HW system / box that you own and leave at customer sites, right next to the SAP servers). Are you planning to develop the web interface that communicates with the SAP server and host that in the "box"? I agree that a service like Tropo (which I'm familiar with) or Anveo (which may be applicable) would be appropriate for handling a SMS (or PSTN/SIP) gateway, but getting this into a production state will require a fair amount of research and development, especially if you expect this to be a robust solution. Do you care if the message gets through? What if the call drops or if the service is unavailable?

To get an idea of the cost, I think you need to clearly understand/document your requirements and go out for bids, but I think Stewart gave you an idea for a nice cost efficient design approach.



1 recommendation

reply to java1900
I believe that focusing on the "iron" is a mistake -- if you want to write a book, you don't start out by buying a printing press.

However, if you want to follow that path, take a look at »www.sqlphone.com/data-collection ··· tion.htm . It's not cheap, but you can download a free demo, buy a Dialogic card on eBay, stick it in an old PC, hook up an analog line, and have an IVR running in a couple of hours. You'll still need to write some code to interface with SAP Web Services, because the software is set up to access an SQL database directly. Possibly, you can find a similar product that works with SAP or at least can "speak" SOAP.


On premise is so 1990's... you should host the solution for all your clients, or find a hosted IVR provider to do it for you.