Use Real ROI Numbers to Pay for Your New Phone System

Use Real ROI Numbers to Pay for Your New Phone System

Use Real ROI Numbers to Pay for Your New Phone System

cisco 7965 phone

Money is tight these days, and only the most essential projects are getting funded. In the data networking realm that means all projects have to show tangible immediate benefits, and save money to boot.

In the Return On Investment discussion, these can often times be split out into hard dollar and soft dollar cost savings. Hard dollar costs are what the organization pays out in cash every month, quarter, and year. For example, PBX lease payments, voice trunk line charges, or call center staffing level, are all examples of hard dollar costs to which savings can be applied.

Soft dollar costs can be more significant, but they are harder to quantify. If it is possible to enable people to work faster, have access to data more quickly, or provide a higher level of customer service, it is clearly a benefit to the organization. Over time those improvements can be responsible for a higher net profit, but since they don’t involve the writing of checks from finance every month they are classified as soft cost from a ROI standpoint.

Let me give an example of an ROI calculation. We were working with an Atlanta company that had offices all over the southeast and they had a big problem. Their PBX leases were coming due. They were disenchanted with the costs and limited performance of their existing system and were looking for something new.

As a side note, one of the common ways that traditional PBX vendors sell is a system is to focus only on the monthly number, in a similar way that some car dealers do. The vendor lists out an entire system, prices it using a FMV lease, includes service and maintenance for the duration of the lease, and only gives one price — the monthly cost. The problem is, with a Fair Market Value lease, the residual value of the PBX is unknown! At the end of the lease, the customer finds out they have been paying every month, and have no assets at all to show for it!

At any rate, this organization was looking at either an Avaya system or a Cisco system to upgrade to. Since we focus on Cisco, he had to look somewhere else for Avaya. After completing the system design, pricing it out, and running it through financing (with a $1 buyout of the system at the end of the lease!), we had a monthly price.

Not surprisingly, the price was too high. That is one of the mistakes commonly made when specifying a Unified Communications system. Because not only does the phone system have to be replaced, many time the LAN switches and WAN routers have to be upgraded as well. This can make for an expensive project when one looks at just forking over the cash. Couple the price with the disruption of business processes that can happen with a voice system changeover makes the decision maker just want to not think about it.

A more successful way to approach the discussion is to quantify the hard dollar cost savings of the project. It is easy for vendors to wave their hands and say, “Our customer across town, with a business just like yours, is saving $20,000 per month by using our system!” It is more difficult to be specific about the exact hard dollar cost savings.

When looking for ROI, a simple tactic is to look for where the large monthly expenses are. If these expenses can be reduced or eliminated, then the project has a much higher likelihood of being funded. So we set about doing just that. Looking at the spreadsheet excerpt below, the existing costs are quantified on the left, and the proposed costs quantified on the right.

The monthly finance payment was generated from an equipment and installation price of $260k, an annual manufacturer maintenance price of $40k, and a 5% annual interest rate. Financing is for 5 years with $1 buyout. It includes all LAN, WAN, UC voice, and installation pricing , with manufacturer maintenance for all five years.

The pricing requires further explanation. For the 17 sites, they were connected by Virtual Private Network, or VPN. When all the phones in the organization are part of one big UC installation, VPN/DSL connected sites only work for very small offices with 2–4 users. All the rest have to be connected with a Private Network, the most common these days being MPLS. Unfortunately, the new Internet and MPLS WAN for this customer ended up costing more than the existing Internet VPN connections. This is not good for ROI.

There are multiple benefits to the MPLS WAN, though. One of the biggest ones is that it can replace almost all of the voice T1’s and analog trunk lines at every site with a SIP trunk. All the existing local phone numbers are ported over to the SIP trunk, and all inbound and outbound calls go over this data link. This is where the real cost savings come into play.

As a side note, just like MPLS (MultiProtocol Label Switching), knowing what SIP (Session Initiation Protocal) stands for doesn’t really help at all.

So, the customer could extend the lease on their PBX’s, and continue to pay $26k per month, or they could get an entire new data network and a new phone system, fully installed, and pay $20k per month. That’s pretty much a no-brainer from a cost savings standpoint.

But it gets even better! The finance guy is now ready to listen because we have demonstrated how the new project will save real money on a monthly basis. Remember the soft dollar cost ROI discussion above? This now comes into play.

With a new phone system, there are multiple benefits that can potentially improve productivity:

  1. Inbound Automatic Call Distribution (ACD) for better customer service.
  2. Four digit dialing from any phone at any site to any other site. No more calling the main number for the other site, chatting with the person who happened to pick up the phone, then a few minutes later talking to whoever you intended to call. Just pick up the phone and call them!
  3. Presence and chat integration into the workstation. See when anyone else is on the phone or not, and run an internal, secure chat server that lets you have a conversation with a co-worker while they are one the phone.
  4. Centralized management of all the phone systems from a web browser. That means no more contracts with local phone companies in every town. A new employee can have a phone ready and working for them within hours of starting.

These are just some of the soft dollar cost ROI benefits from a Unified Communications system. There are others that I will list out in detail in another post.

With the combination of monthly cost savings, soft dollar cost benefits, and the upgrade of the entire network, the decision was made to proceed with the project. It turned out well, and the benefits of the increased productivity and cost savings were actually realized.

What I have found through many processes like these is the necessity of finding out what the organization is spending too much money on. The line in the spreadsheet for conferencing is there because some organizations spend a large amount of money on conference calling services every month. In many cases those conference calls can be managed internally for a lower cost.

Same thing with Project Office voice. Some organizations set up 2–4 month project offices at remote sites. It is expensive to arrange and deliver voice and data service to these sites; so the alternative of dropping in a voice gateway, switch, and phones, and having the system run off the main site system is very appealing.

The ROI of Unified Communications systems is very real. What is needed in many cases to make the project move forward is the actual information on what the organization currently spends, and the ability to show real numbers on both hard and soft dollar cost savings.

Author: Rolf Versluis
Adcap Network Systems — Atlanta and Miami
Great Local Engineers Creating Systems that Work!
Posted at Adcap Tech Tips

SIP trunking is a big deal — for saving Money

SIP trunking is a big deal — for saving Money

SIP trunking is a big deal — for saving Money

Two and a half years ago Cisco came out with Call Manager version 5. There were a few notable changes in this release. Besides running on linux, it was the first version that supported both SIP phones and SIP trunks. As fortune would have it, one of our customers at the time had more prescience than I, and had researched the cost savings capabilities of using a SIP trunk for PRI replacement. Since I have never shied away from deploying the latest Cisco voice technology, we agreed to put the system in place.

The cost savings of the SIP trunk is what funded a majority of the deployment.

Since the customer had a main site in Atlanta with 3 PRI’s, servers in a local colocation facility, and 9 remote sites, each with its own PRI, there were 12 PRI’s that could be eliminated. By putting in an MPLS WAN at the same time, ten internet T1’s could be turned down as well, which was a wash as far as pricing went. The SIP trunk plan included all long-distance as well, which was a further cost savings. An important point is that the local numbers on each of the 12 PRI’s were ported over to the SIP trunk, so no phone numbers had to be changed.

The cost savings of 12 PRI’s is about 12 x $600/month, or $7200/month. The SIP trunk cost about $3000/month at the time, so that left $4200/month for financing equipment and installation. Furthermore, the customer received the other standard benefits of a Unified Communications system, including a single point of system management, 4 digit dialing between all sites, and managing the voice system like any other application running on a server.

Things were rolling along great on the deployment. The SIP trunk was working for inbound and outbound voice calls, the SIP loads on the handsets were doing well, all the Quality of Service was set up properly so voice quality was good. We were going through the SIP trunk signoff checklist when we got to the line about DTMF tones. Although it seems minor not to be able to use the keypad during a call, this turned out to be the starting point of a very educational process for me.

It turns out that although SIP is a standard, at that time not every piece of network gear implemented all parts of the standard. The SIP trunk provider sent and received DTMF tones inband. The Cisco call manager and voice gateway sent and received DTMF tones as inband INFO, or what is known as RFC 2833. The provider and Cisco were both compliant with the SIP specification, but each with different parts of it!

Nowadays all SIP trunk providers are RFC 2833 compliant, but it was a major issue then. The only way to solve it and get the system into production was to turn up two Asterisk servers, and use them to perform the conversion, but that is a whole nother story.

The next issue I ran into was faxing. Now, faxing over VoIP networks has always been something that has to be dealt with in a methodical fashion, and we got the majority of the faxing worked out properly. The issue came with turning up the Fax over IP server. We use the market leading Xmedius product, and it is great because it takes a direct T.38 feed, and can be set up with either H.323 or SIP. Usually we take the PRI into the voice gateway, convert it to T.38, and send it to the fax server, and everything works great. Unfortunately the SIP trunk provider did not send faxes as T.38.

Just like the DTMF tones were sent as noise in the RTP stream, the faxes were sent as noise in the RTP stream as well. After a bit of thought, I ended up terminating the fax calls on a Cisco IPIP gateway (now known as CUBE), sending them out a PRI port as inband fax, looping that back into the same router, and converting them from PRI to T.38 fax. After that the faxing worked fairly well.

All the calls were coming in from the SIP trunk provider as G.711. For the remote sites we transcoded those to G.729 to save bandwidth. That was planned for and it worked well. Later on the customer bought more bandwidth and had all the calls running as G.711 since they liked that level of voice quality better.

After a week or two of the system running in production, we started to get some complaints about calls to outside IVR systems. Instead of calling in and receiving a menu, the call would just ring and ring. It was puzzling and took quite a bit of troubleshooting through SIP logs to determine the issue, and the solution.

Basically, these IVR’s required the call to be connected on our side before they would answer the call. My understanding is still somewhat incomplete, but the answer was that SIP early media was required on all outgoing calls.

SIP early media was generated at the Cisco Call Manager by checking the MTP required check box of the SIP trunk, which at that time defined the codec as G.711 and connected the call. That required provisioning of multiple MTP resources. The Call Manager could only have 24 MTP resources, so I had to define software MTP’s on the voice gateways. In this deployment defining two voice gateways at the colocation facility with MTP’s worked out just fine. It turns out that every SIP deployment has the same requirements for early media, so now I just cut to the chase and define the MTP’s properly up front.

After working through the DTMF, T.38, codec, and early media issues with MTP’s, all that remained was the basics of any good voice deployment, which is a high level of attention to detail, proper end-user training, and immediate followup with any perceived end-user issue. End-users don’t care about the technical issues, of course. They just want it to work.

In subsequent deployments at other customers, where the SIP trunk is being provided over the MPLS WAN, the precise definition of Call Manager Media Resource Groups and Lists, with the careful ordering of MTP’s on remote voice gateways, is absolutely essential to good voice quality and proper bandwidth utilization. MTP’s are tricky to do correctly, but they are an essential part of a multisite SIP deployment and have to be handled properly. MTP issues often appear to be QoS issues, which makes them even more difficult to solve.

Cisco is now on Call Manager version 7. We are finishing up a 20 site SIP deployment at a local customer, and everything is humming along fine. They are saving lots of money on phone bills, have a shiny new phone system and network in place, and are experiencing a high level of both reliability and voice quality.

SIP trunking is definitely a big deal, and it can certainly save an organization a lot of money. There are definitely many details that need to be addressed in any multi-site SIP deployment to ensure success, and anyone that says otherwise does not have the depth of experience to conduct one properly.


Posted at: Adcap Network Systems Blog

Posted at Adcap Tech Tips

Author: Rolf Versluis

Twitter: @adcapnet
LinkedIn: Rolf Versluis LinkedIn
Facebook: Adcap Network Systems Facebook Page
Adcap Network Systems — Atlanta and Miami
Great Local Engineers Creating Systems that Work!

Should I Work to Set Up a Community Wifi Mesh Network?

There is a park nearby where I walk my dog. At the park there are softball fields where my daughter played for a few years, football fields…

There is a park nearby where I walk my dog. At the park there are softball fields where my daughter played for a few years, football fields, tennis courts, and a community center. It’s a really nice park. There are similar ones all around. None of them have any wifi access.

I’m considering working to set up free wifi access at the park. With current technology, this is possible to do without having to spend too much money. It would mostly be using solar powered access points, set up in a mesh network. I could do this, but should I?

Solar Power Mesh Network Node — Image from Torsten Braun, University of Bern

There are many issues. I’ve got some relevant experience, and can address many of the technical issues, including:

  • Provisioning of low cost equipment using open source projects.
  • Setting up robust data network, network security, content filtering.
  • Preventing individual users from being bandwidth hogs.
  • Monitoring and maintaining the system.

There are some issues that I am not sure how I would address at this point, but I expect I would be able to work through them.

  • Permission from the City to set up the equipment.
  • Internet connection from a local provider that can be shared.
  • Donations from local organizations to keep things running.
  • Assistance from others to continue the work and keep things running.

If the free community wifi access is successful at this one local park, I expect to be able to do the same type of thing at other locations. I don’t want to do this all myself, and expect to be able to work with local community organizations who would be able to contribute time and effort to the project, including:

  • Local Amateur Radio Club
  • Boy Scouts, specifically Eagle scout candidates looking for projects.
  • Former military people who have experience in radio and data networking.
  • Technical people at local businesses.

What I am thinking about doing next is:

  • Form a non-profit organization for the purpose of providing free community wifi.
  • Set up prototype of the solar powered mesh wireless pod.
  • Follow the guidelines at Wireless Networking in the Developing World.
  • Contact local organization and ask for their assistance.

But the problem is, I can’t find anywhere else in the United States where this seems to have been done successfully. That’s a big warning sign!

So I have some questions, and wondering if anyone can provide answers.

  • What are the issues that I am missing in this project?
  • Are there reasons why free community wifi at the local parks would fail?
  • Does anyone have a perceived need for this?
  • Are there better places to look at doing this?
  • Has anyone worked to do anything like this and have suggestions on how to improve chances of success?

I’d love to hear from anyone who has an opinion on this. Thanks!