HOW TO FIND AN IPO PROVIDOR, BY IPO PROS

[aarenot]

This forum is to serve IPO professionals by design, but there are often end users, or business owners, or decision makers who come here for advice on the IPO. I would like to extend advice on what an end user should be looking for in an IPO providor, as well as discuss this subject with knowledgable PA (Product Authorized) IPO technicians. This will be from a technicians point of view, not sales since this is not a sales professionals forum. This will be an evolving post using input from qualified techs as much as is possible. Before responding please identify the year you first became Avaya Product Authorized to implement the IPO since we are looking at offering professional Product Authorized advice in this post only.

let's use a list form, and let us know if you feel your list is in order of importance.

 

[aarenot]

1.) PA Sales person is the best choice since the IPO is a platform with diverse features, and takes training to understand its application, and therefore sell. At least a sales PA, if not an implement PA.

2.) Customer references from customers for the specific PA IPO tech who will be implementing your IPO system.

3.) Printed documentation of the product authorization of the agreed upon implementing technician from Avaya.

4.) Site visit to an implementation site of an end customer of the PA tech whom will be implementing your IPO.

5.) A dedicated IPO experienced project manager whom is knowledgable, and organized whom you can work with, as they will be making demands/requests of your organization which will be mission critical to the proper completion of your project. You will need to trust this person as they will be required to make demands from your organization in order for your needs to be met.

6.) A contact within the customers organization whom will take this project seriously, understand the impact of the im/proper preparation for the project, and will take responsibility for meeting the customers responsibilities, or communciating those requirements in such a way that they will be delivered without impact to the project, or it's timeline.

7.) Understand that project management happens 99% prior to the equipment being installed on site, and that means the time for changes is before that if possible. If you have concerns, or confusion ask before they start programming the system.

8.) Expect to sign off on the programming parameters of the system that will be implemented at the time the system is cut over, as much as a week prior to cutting over to the the new system, and days before the equipment itself begins being installed.

 

[jamie77]

Customer should ask to meet the engineer for a discussion about how the system will be setup. This should be done anyway but quite alot of company don't do this. At this meeting ask "I've heard the IP Office has problems with s/w bugs, what is your experience with this??"

I would respond with: "Any technology has bugs, but most important with the IPO is how careful the tech is when it is installed."

Example: From Alchemy and early IPO days I saw issues when using spaces in User names, mainly to do with Voicemail. This is now supported but I still don't do it.

Word of mouth can be a good tool. Ask to see reference sites.

Jamie Green
IPO Implement 1.4 Oct 2003
CCCv5 Implement Aug 2006
IPO ACA: Implement Jan 2006
IPO ACS: Implement Apr 2007

Jamie Green

ACA:Implement - IP Office
ACS:Implement - IP Office

http://www.alliedcom.co.uk

Fooball is not a matter of life and death-It is far more important!!!!

 

[kholladay]

I agree with jamie77. I think the key is an experienced install tech/programmer. I have methods that have developed over the past several years based on things that I know will work unless something is really broken in the IP Office. An experienced tech is going to know what to avoid based on past experience even if it is working differently in build such and such (yea just because version 2.whatever let you change the 4400 series ring by selecting the ring pattern in Manager doesn’t mean it was supposed to). I have a standard set of programming that I use for every single configuration and then I modify it to fit the specific requirements, it’s tested, it’s proven, it works every time becauseit wasn’t just thrown together after a few conversations with the client. A good technician it's afraid tell you NO! If you have a technician that says yes to every request he either doesn't know what he is doing or you have very simple requirements. We all know that we can make some things work with a little creative programming. And we all know how easy it is for Avaya to break the whole workaround with one small change. I won't make it work unless it is supposed to work and if you push it I'll make you send me an email acknowledging that you understand that if this breaks I am not responsible for fixing it.



Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"If it worked the way it should you wouldn't need me