Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to figure out how to set up a miniature call center for a small business. Like, for 1-4 people to take calls, but hopefully expandable to more.

We want to accept nation-wide calls, and then I guess distribute the calls among the available agents. If no one is available, I guess it should either put them in a queue and play some annoying music for them, or forward to call to an agent who has least-recently taken a call who can then quickly answer and say "please hold" until they're done their call.

We want to have one phone number that customers can call. I guess we then need some kind of ACD system which would take each call and forward it to an agent based on some algorithm? Then we would need to purchase a separate phone line for each agent, plus one just for the distributor? Or do we need several "extra" lines to maintain a queue (one for each customer waiting too)?

This "ACD" thing, is it just a device that you would plug a phone line into (or several?), and maybe connect to a computer, aided by some software? Or is a subscription thing that I would need from my local telephone provider?

Next, the business we're running, the callers will be repeat customers. It would be helpful to automatically pull up their profile based on the incoming number. The "software" our agents will be running will just be a website where they can log in (preferably from home) and then enter some information they would obtain through the call. So, the system would have to somehow interface with the website if possible. If not, we'll just have to ask each customer for an identifier (phone number, username, customer number, or something). Is this possible? I guess each computer would need a device that the call would pass through, and then if I can somehow hook into that, then I can write some software that will interface with the site.

So, where do I start? What hardware do we need to buy? What subscriptions do we need?

We were thinking this magicJack might help us in accepting long-distance calls for cheaper, but my understanding is that they provide you with some weird-looking number, is there a way we could "mask" it with our toll-free number? And then pass the incoming calls through the distributor system, which would then get passed to the call-accepting device which would both allow an agent to answer the call and have a software hook?

(I realize this might be partially out of the scope of SU, but I wasn't sure where else to ask. It is about computer(-aided) hardware and software anyway.)

P.S.: I don't need any of that "press 1 to talk to..." or "say xyz to..." junk. Just a straight-forward, connect-to-next-available-agent system.

share|improve this question

2 Answers 2

I don't know much about the subject in question but i know that THE open source software to do this is Asterisk, it can do what you want and more, i'd search for compatible hardware for it.

share|improve this answer

Pronexus VBVoice, a free IVR application development toolkit, combined with Dialogic HMP are a great solution to your situation. You'd also need a VoIP provider for the telephony connection.

With a T1 system, you would need to purchase a full T1 from the Telco, and also have a T1 card on the Terminating Equip (IVR). In such a scenario you may not be using all 23 channels available, and you may not be using all of the resources available on the T1 card at the T.E. This means that your investment is greater than what you require.

A VBVoice/HMP (VoIP) system would allow for expandability; you only purchase the number of licenses for the number of resources you need on the system. So, if you need 4 channels to do voice calls, you just need to purchase the licenses for that many channels. When you are ready to increase capacity, you purchase additional licenses for the same system. From the VoIP provider point of view, this would just be bandwidth useage. It is possible to have hundreds of channels within an alotted amount of bandwidth.

A VoIP call would come into the VBVoice IVR. The VBVoice application could do a database lookup based on the Caller ID, or even the number the caller dialed to reach the IVR. In order to handle call queuing, you'd use the VBVoice CallQueue control which is used for putting callers in a 'loop' where they would listen to music or some other message while they wait to be connected to an agent.

My question to you is whether you want the call into the IVR bridged to an agent, or transferred. If you do call bridging, the connection between the initial caller and the agent will be done in the IVR. This type of connection will require 1 inbound channel and 1 outbound channel for each connection. So, a system that would handle 4 inbound calls, would require 4 outbound channels also. Potential benefit to bridging the calls in the IVR would be that the bi-directional conversation between the caller and the agent could be recorded within the IVR application.

An important point to note is that in the event that the IVR does not have an available channel to answer the inbound call, the inbound call will fail, since there is nothing to actually answer the call. The CO or Telco would not be able to connect the inbound call in this scenario, and the call would fail. This means that when purchasing licenses/resources, you must anticipate how many channels the system will need to have connected at one time.

An alternative to call bridging would be to transfer the inbound caller to the agent, thus clearing the channel from the IVR so that it can accept another call on the same channel.

Having the IVR application and Web Interface (for the agent) connected to the same database would allow for shared information between the two systems. So, as the IVR application does any kind of update to the database, this information could be available to the agent. It is also possible to generate screenpops to the agent when calls are connected, so the agent receives some caller information on their computer screen as the call is coming in to them. From the description though, this would all be handled through the agent's Web Interface. It would also be possible to have the VBVoice application call on Web Services.

The agents could easily use VoIP softphones to handle the calls, rather than a traditional POTS phone connection. Since the IVR would be running VoIP this would make this fairly streamlined.

If you are interested in building a prototype, download VBVoice from the Pronexus website.

share|improve this answer
    
Wow, amazing answer! Very thorough. Thank you so much :) I'm definitely going to check this out! –  Mark Dec 29 '10 at 19:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.