Welcome to my second installment of “Writing an RFP for an Open Source IP PBX”… But first let me apologize to my loyal readers, I have let you down… I’ve been caught up in the regular grind of the summer and have neglected OS-VoIP. There’s a lot of interesting things going on in the Open Source VoIP space and I’ve got a long list of things I want to talk about, so get ready for some action here at OS-VoIP! Ok… onto RFP’s…

In my previous post, here, we went over a variety of reasons why Open Source needs to be approached and perceived differently than regular proprietary systems. We also discussed the importance of determining (in detail people!) your own requirements as the very first step in this process.

Part deuce starts with this………

Answer the important questions

Regardless of where you place this information in an RFP, it should always be addressed. The earlier you make these decisions the easier it will be to start off on the right foot when asking vendors to quote you an Open Source IP PBX solution. This is by no way a complete list of questions but these are the important ones.

Do we plan to have a converged or segregated voice and data network?
This is a very important decision and will sometimes dictate the type of phones a vendor recommends as part of your solution. For example, if you are converging the voice and data networks and in turn daisy chaining desktop computers to the phones, you’ll want a phone with a switch, and possibly GigE support should GigE to the desktop be important. Some phones don’t even have a switch so be careful not to make the mistake of converging your networks only to find that the 150 cheap Polycom 320’s you purchased don’t have switches in them! Most network engineers would recommend that the reliable approach to take  is keep your voice and data networks separate but this sometimes carries a greater upfront expense such as running a second ethernet drop to each workstation or purchasing twice as many switches.

On the topic of wiring, I’m going to share a suggestion which some of you might disagree with. Should you ever need new wiring, DO NOT make it a requirement in your RFP that your OS PBX vendor also be required to handle wiring! My opinion – office wiring should be left up to electricians… I’ve always said that any company (specifically in the OS IP PBX world) who does both wiring and Open Source IP PBX’s is going to lack significant skills in one area or the other. Good engineers who really know how to program software like Asterisk sit at their computers all day being programmers… they don’t usually make the best wiring contractors. We live in a world of specialization, companies can either do twice as much half ass’ed, or half as much bad ass! Wiring and software development are just too different for most companies to want to maintain dedicated resources for both.

What type of phone service do we want to use with this new Open Source IP PBX?
The beauty of most OS IP PBX systems is that they will work with almost any type of phone service. A lot of people for some reason think that an IP PBX will only work with digital phone service and this is not the case. If you are replacing a legacy phone system then chances are you’re using either a T1/PRI or POTS lines which won’t have any problem plugging into your new OS IP PBX. Now a vendor isn’t going to care much whether you stick with a PRI or POTS because that usually won’t impact the overall solution (other than the type of telephony cards/gateways quoted), BUT if you plan on using other types of phone service, then there’s a few more things a vendor should address and therefore why you need to let the vendor know about these in the RFP.

So what am I referring to? SIP and Internet based VoIP service. Most large businesses wouldn’t consider using internet based VoIP for their primary voice service because of call quality issues that still plague these options (no QoS, latency, etc), so I won’t discuss these here. Dedicated/private SIP on the other hand is a very good option for an OS IP PBX system. Dedicated/Private SIP is where the phone company is actually providing you with a dedicated voice circuit, such as a T1/fiber/ethernet, which is delivering SIP service directly from their network to your office. Using your data connection to run SIP over the internet is NOT a private SIP solution, it is a public SIP product. Here’s a little article I wrote about SIP which I hope to elaborate on soon.

One of the main advantages of using a SIP service is that you offload call transcoding from the PBX resources onto the carriers network. Asterisk for example is SIP native, so is FreeSWITCH, so by using SIP as your primary phone service that call can in many cases ride un-altered from the handset all the way through the carriers network and the transcoded to the work on the receiving end. By eliminating the need for the PBX server to transcode the call, you save resources and in-turn increase the call capacity of your server.

How do you plan to administrate your Asterisk system?
This is probably the most important question to be answered because what you say to this question will entirely dictate the type of Asterisk flavor you purchase. Although building an Asterisk system using open source or BE Asterisk can result in the most reliable, fully functional, and flexible PBX solution (when engineered properly), it also lacks what most IP PBX buyers want to see which is a user and admin interface. Asterisk is entirely programmed and configured within the command line, and unless your company is of a size where you can afford to hire a telecom administrator with Asterisk experience, you will probably need some sort of administration interface. If you are of the size where having a dedicated employee/s to manage your PBX… then it makes perfect sense to hire Sys. Admins with Asterisk and Linux experience. Actually, if you have these resources then you have even more of a reason to build an OS IP PBX. Remember that if you require an admin interface, and are a company larger than a couple hundred users, then most of your Asterisk PBX options will be licensed products. If you want that admin interface instead of employing an Asterisk engineer then you’re going to likely get tied into licensing and per seat pricing models… just FYI.

Existing PBX

It’s very useful for a vendor to know what type of PBX you’re currently running. This should give your vendor at least a general overview of the features and functionality current users are comfortable with, plus  the vendor should be familiar enough with other PBX systems to know what features may or may not work differently to those found in an OS IP PBX.

Within your RFP, list the features of your existing PBX which are currently USED by your employees. Everyone utilizes different features so be sure to include all your departments in the conversation while you uncover all those features you never even used but others might find quite handy. This is a good beginning to your requirements gathering process so don’t forget to also prioritize which existing features are important and which ones are not.

Call Centers

Now here’s a hot Open Source topic… Asterisk  and Open Source software for the call center-
I’m not going to stray down this road too far because writing an RFP for a call center PBX  is usually quite different than a standard enterprise communication system. Call Centers have about a gagillion feature requirements and in many cases these requirements are so specific that a highly customized Asterisk system is sometimes just what the doctor ordered. Typically in a call center, specifically one using Open Source technology, Asterisk is rarely the only software being used as  part of the “total solution”. There’s a whole slew of applications and OS software which… when combined… can rival even some of the most established call center solutions.

Actually, not many people knew this but Genesys (dubbed the worlds #1 contact center software) used to fully support Asterisk. Quite a few call centers were deployed with Genesys software running in conjunction with the Asterisk PBX. I think this is a fairly good testament to Asterisk’s increasing presence in the large enterprise space. Genesys even used to be a participating partner in the Asterisk community… but not any more. Word on the street is Genesys partnered up with Microsoft with an integrated solution with Microsoft communication products and that was pretty much the end of their partnership with Digium… dang it.

Proprietary call center applications are purchased in modules – inbound, outbound, agent portal, etc….and each module costs more money. In the Open Source VoIP space, modules are replaced by 3rd party applications which work in conjunction with software like Asterisk. For example, ViciDial is free software for Asterisk designed for outbound call centers. QueueMetrics is licensed software with hundreds of reporting functions and options that works in conjunction with Asterisk. Aheeva makes a fully functional call center solution built entirely on Asterisk but unfortunately they’ve licensed the product out the wazoo which I think is very non-open-sourcian of them…

If you are compiling an RFP for an Open Source call center,  then you definitely take your phone system more seriously than most businesses… obviously… because it IS your business. And naturally you’re concerned with the risk you might take with implementing an Open Source PBX system. As a call center I’m sure writing an RFP is as familiar as cotton candy at the carnival,  so I won’t draw this out more than I need to. BUT… what I will say is “keep an open mind”. Your biggest risk in implementing Open Source VoIP software for a call center is not the technology itself, it’s the capabilities and experience of the company who implements the solution. Or, depending on your own technical chutzpah, maybe you can develop your whole call center PBX internally. I recently lost a call center bid for a 400+ agent facility due solely on the fact that the non-technical CEO hadn’t heard of Asterisk… and despite the fact we met EVERY requirement, and despite being able to scale infinitely with their growth, and even despite the capital cost being about $250,000 less than Cisco… they still got cold feet due to inaccurate assumptions and a bloated stomach from all the proprietary spoon feeding.

Here’s an important tip about the RFP process- if you’re making a recommendation to the CEO or CIO to purchase an Open Source IP PBX… insist that they participate in all discussions with the vendor. I’ll be the first to say that it’s not a simple task to understand these systems, and reading a proposal (the result of your RFP) is rarely going to single-handedly sell an OS IP PBX against a proprietary system. If a CIO is reading two proposals, one by Cisco for example, the other an Asterisk system… their instant gut reaction to the Asterisk proposal is to completely discredit it because the price is so low. If the decision maker isn’t educated about these systems, seeing a 50% price difference usually hurts more than it helps. They think “oh this solution must be the Yugo of phone systems” or “this vendor has wildly underestimated our requirements” or “where’s the other zero” ….

Without fully understanding the technology, the development, the capabilities of these systems… a CIO can not make an educated decision about an Open Source IP PBX. What is the solution, I’ve already said it… participate in discussions with the Open Source vendors, don’t make assumptions, ask questions when you have concerns, and LISTEN to the answers.

When buying Cisco or Avaya… the primary characteristics a decision maker cares about are features and price; they usually don’t question the products ability to simply “work”. Features and price are simple to address in a proposal. An Open Source IP PBX on the other hand… decision makers question EVERYTHING, will it be reliable? Will I get support? Does it have the features I need? Will it be too hard to use? These are all gut reactions which must be addressed by the vendor, and it’s no easy task. You simply can’t eliminate all these concerns through information in a single proposal… no matter how large it might be… It requires numerous calls, meetings, and research on the part of the final decision maker. Unless the final decision maker takes the initiative to understand these products, and participates in calls with the vendors to explain these systems, then they’re not going to be equipped for the questions and concerns they’ll undoubtedly have once a solution has finally be recommended by the vendor. So why should the CEO, CIO, or final decision maker spend so much time in understanding these systems…. because if an OS IP PBX is the right fit, they stand to save their own company A LOT of money, not just in upfront capital but most importantly in ongoing costs.

Solutions you might need, but didn’t know could be done with Open Source VoIP

And lastly I want to leave you all with a slightly greater understanding of the capabilities of software like Asterisk… because once you have a well engineered Open Source IP PBX, you’ll learn there’s much more you can get out of that bugger, the only limitation is… well…you. When it comes to the world of technology, and software, and especially voice, if you can think it… you can do it with Open Source software (caveat-if you know what you’re doing) For example, I’m working with a company right now for whom we built a custom IVR solution which in a lot of cases would be the extent of this systems capabilities. But with Asterisk, we are now able to take the same hardware, same software, and with some additional development increase the capabilities of their solution from an IVR to a full blown PBX to support almost one hundred remote call center agents.

So, where you might think you need multiple solutions or systems… you’ll find that sometimes your highly customizable Open Source IP PBX will scale and do the job just fine.

Here are some examples:

Paging – I see this ALL the time, I’m sure you do too. Company has their PBX, and they have their dedicated external paging system, and the two integrate. Well because endpoint costs on OS IP PBX’s are so low, I see very little reason why you wouldn’t use your PBX as your paging server as well. Paging features such as multi-zones, two way paging/intercom, and music are features which can all be replicated by most PBX systems. You can either use analog paging speakers, or IP paging speakers…. check out CyberData’s product. They have a very impressive product line, let me just forewarn you that every time I’ve ordered their products they’ve showed up anywhere from 2-6 weeks late. External paging with Asterisk = works swimmingly. All this is on top of the obvious fact that you can still page through the handset.

Emergency Notification – Companies can spend LOTS of money on emergency notification systems… but a lot of the same functionality can be dealt with by Asterisk. In an Emergency, the idea is to send out blasts to a particular group using all communication methods… email, voice, text, page, etc. By integrating Asterisk with something like a contact database, you could initiate Asterisk to make outbound blasts to phone numbers… either record a message or send via text which Asterisk can then read via a text to speech engine. On top of that, integrate Asterisk with an SMS gateway and that’ll take care of texting. Additionally, Asterisk could page all phones and paging speakers… and with the addition of a basic web app or custom script I’m sure there’s a LOT More you can do… like tweet, or facebook, oh the possibilities!

Access Control - Did you know that with IP access control devices which are SIP compliant, you can actually use Asterisk for access control? The interface might be a little dodgy but let’s say you have IP card readers to access a building, Asterisk can actually open the door (integrated with a door jam – analog or IP), you can log that action just the same as you can log when a user makes a phone call, you could even program Asterisk to make a call once someone entered a particular room. For example, maybe campus or corporate security receives a notification or call from Asterisk whenever someone enters a particular secured area. There are big massive giganticly expensive security systems that do just this, and usually people will integrate their PBX with said systems… but if your requirements are fairly basic, and you’re willing to compromise on sexy interfaces, you’ll find that your PBX might do exactly what you need for a fraction of the cost. Plus you eliminate the integration costs.

Now I know what you’re thinking… “if I use my Open Source IP PBX for everything won’t it become a single point of failure?” It all depends on how the system is built, maybe you build dedicated Asterisk systems with a single function. Or, with ALL the cash dollaz you save by using your Open Source PBX to replace other dedicated proprietary systems, you’ll have some extra budget to beef up the redundancy of your IP PBX. Pay a little extra to cluster or load balance your systems, purchase larger and more reliable servers, beef up your network redundancy, buy more POTS lines for fail over, heck… get some internet SIP trunks, and keep the PRI… You can make any technology completely fault tolerant with 100% up time… you just have to make the right development decisions and you need to spend the right amount of money. The lesson here is what would be cost prohibitive in the proprietary world is often affordable when evaluating an Open Source IP PBX.

Keep your options open, start from an “anything is possible with Open Source” mentality… and work backwards from there.

If you’re in the market for more than just a PBX, discuss with an Open Source PBX vendor and  perhaps include a list of your requirements in the RFP. Just maybe you’ll kill multiple birds with one stone… a stone meticulously made out of Open Source software and COTS hardware!

Oh, and one last thing. Building an Open Source IP PBX is NOT free… I get this a lot. For some reason people expect to just buy the hardware, install the software and BAM, they’re good to go…. wrong. Large enterprises should realize that if you’re looking at a proprietary system that costs a million dollars for example, an Open Source system may cost half that. Nevertheless we’re talking real money, and even at half the price, five hundred thousand is still a chunk of change. If you plan on doing an Open Source IP PBX the right way, plan on paying top dollar for the best hardware and the best development resources. But you know what’s awesome….even if you pay top dollar for everything… your capital investment is still going to be a heck of a lot less than what you’d expect to pay for a proprietary system… and you’ll probably get a heck of a lot more!

Good luck hunting…

By Aaron Rosenthal