In case you haven't heard, the old Interconnect model of good, better and best is still alive and well for some Interconnects. These companies always had or still do have the aforementioned three product lines to fit into customer budgetary or feature needs. But does this past model sell PBXs or guarantee continued success today?
Instead of talking about whether Interconnects are "IT enough" or "IP qualified," or debating if they should sell UC solutions instead of moving pizza boxes, I want to take a different approach that almost always works for us. Yes, I am an Interconnect and yes I will continue to sell PBXs whenever I encounter a good fit. My position isn't "ALL PBX or nothing," as is with many advocates of UC and hosted services. You haven't heard me proclaim the death of TDM or PBXs, but you will hear me discuss how PBXs do continue to fit into solutions and how they will "morph" into solutions with hosted services.
Then with 100% certainty what you won't sense from me is that I will bury my head in the sand and cling to "some hope for retirement." Anyone who is in this mindset is sorely mistaken. Opportunities exist under your noses.
What I stated previously in a post found here was that: "Any premise PBX sold today is provided with surgical precision and if it's not, it will likely not stand the test of time." I will elaborate for what you already know or should know, and that is that selling PBXs isn't as easy as in the past. No mystery here--but if you aren't clued into to hosted services, or are in denial or thinking that things in the past will continue to sell in the future, then you definitely need to evaluate the present. Then, for those selling UC and hosted solutions, you're challenged to install solutions that will stand the test of time.
Let's take a quick walk through the process I refer to as "Discovery," using a typical case in point:
The initial customer meeting lasted 2.5 hours, with one hour discussing their needs, concerns and business (i.e., Scope of Work) The remaining time we used to document inventory, wiring and site discrepancies, photographed the demarc using our iPhones and asked questions of different staff members. We documented all gear in all locations, both voice- and data-related. We gave the premises a good look-over and left to gather our thoughts and sort through what we learned.
The key customer statements:
* We cannot afford an IT guy although we do call on one for limited help.
* We want the investment to last, meaning we don't like technology refresh every couple of years because it's too expensive.
* Is the technology simple to use and maintain, or will it require service contracts and software licenses, updates, etc.?
* The network is too slow.
* Why are our costs so high?
The week following, we gathered more information about the customer's network configuration, inventory and reviewed their contracts with Verizon. Again, we spent more hours calling the customer and their contacts asking questions, following up with Verizon and the customer and then nailing down specifics about their network connectivity and services. This is what I mean by the "discovery process," and the more you put into discovery, the higher the reward.
After Verizon referred me to Adtran to discuss the customer's router configuration, I got curious, and since I already noted their public IP while onsite, I queried the router and logged in using only the default credentials. I copied their router configuration and printed a copy. While the customer router lacked any security (this should be a note for ALL Verizon customers who assume WAN routers are secure), their internal gear and the configurations made even less sense. Instead of adding internal wiring, it appears that adding a retail router with an onboard switch and WLAN access point without any thought to "network" was the method used to add new employees and offices.
Again, we met with the customer for another 2.5 hours to answer their questions and concerns about what we proposed. We reviewed the proposed work plan and scope of work, what it included, what it did not, and why we left certain components out.
Here's a summary of what we found:
* Demarcation evolved with out-of-service gear and wiring remaining still connected and powered on.
* Three internal routers in the LAN found on initial site survey
* WiFi: some days it works, some days not
* Network--slow, yet we did timed tests, remotely pinging from their unsecured WAN router outbound and found latency acceptable and router statistics in check
* Users lose network connectivity for no apparent reason
* All the desktop PCs replaced have 1-Gbps capability, and only 3 desktops are remaining to be replaced, while LAN switch is 10/100 Mbps
* The circuit protection used on the analog POTS service is from the early 1980s, using technology no longer supported or sufficient.
* LAN cabling lacking proper wire terminations (no patch panel/field crimped cables/no strain relief)
* There's a sump pump connected to the same receptacle as the telephone system and network equipment
So the prescription given is to make this site whole. No hosted solution thrown into this site would fare much better. Of course those Interconnects who risk customer implementations "site unseen" will risk customer churn. The discovery process is a local process that requires eyes and hands on site. This process can be replicated with "partners" that sell hosted services. Customer engagement including employees is another exercise and one that can arguably be emulated.
We don't look at the customer, their business and the opportunity as a phone system sale, we look at it as a lifetime opportunity. We know infrastructure--certainly better than the on-call IT guy that the customer can't afford. We will make this site whole and no, don't misunderstand, I am not displacing an IT guy. We don't sell LAN servers, we sell "communications servers." More importantly our core business is to sell solutions directed at convergence. There is no one-size-fits-all. Yes, we walked out of the customer's office with a check in hand and the approval to proceed, and next time I'll discuss more.
Follow Matt Brunk on Twitter and Google+!
@telecomworx
Matt Brunk on Google+
