Here's a question list which might help.   A major consideration is:  what will the situation be like two years down the track?  Not now, but in the future when the flush of new-system euphoria has faded, and the implementation team has disbanded, or got tired of maintenance (if the system is unstable) or forgotten how to program it (if it's highly reliable and never changes).

The reason for being hard up-front is that a phone system is critical to so many aspects of a station operation, whether it's one line or many.   It's the incoming and outgoing gateway to the business.   A good phone system is transparent.   A bad one gets in between you and your customers.

Having been responsible for telephony of one sort or another for most of my life, ranging from one line to a 400 extension computerised PABX, I've become aware that technologists aren't always the best choosers of such systems.   A bad choice of phone infrastructure can not only cost money, I've seen it cost status and reputation.  [heartbreak icon]   So be sure to get all the input you can, then get agreement to, and documented signoff for, any compromises which have to be made along the way.

John

===============================
Just some of the questions for which you should have answers:

• how might the system turn on lights in the studio to indicate an incoming call?
• what is the process for transferring a call (and consider if the answer makes sense given what you know about broadcasting and studio operations)
• what process will mute the phones so that mic-open situations aren't compromised
• how is the phone system interfaced to analogue hybrid systems for phone patch
• what is the codec used for the VoIP calls, and what bitrate is used per call
  • do calls sound pleasant?
  • is the sound pleasant when listening to a GSM phone (the cascaded codec question)
• what is the predicted aggregate bitrate traffic to the internet connection at 100% load (all lines busy at once)
• what is the predicted aggregate traffic in  megabytes for a month.
• what are all the single points of failure - for instance, if you're using the same internet connection that is used for the rest of the station, what happens when that fails. 
  • How will you call someone to get the system fixed when it fails?
• having identified all the single points of failure, what are the mitigating strategies to ensure business continuity
  • what is the cost of adding another phone?
  • Where do those phones come from?  
  • What is the maximum number of phones that can be attached?
  • Are you going to use standard phones or feature phones?
• How does it handle music on hold?
• How does it handle front and back door access?
• how many other users have this system, and how is support provided?
• what is the cost of maintenance?  Can it be maintained by volunteers?
• how long does it take for the system to come back up when there is a power hit?
• what is the power consumption (in watts)?
• How long will it take to implement?
• What is the implementation training program?
• Is the operation (as tailored for YOUR station) sufficiently obvious that a completely inexperienced volunteer would understand and reliably use the phone system after handling two calls)?

And the big one:

ETC.....   (evil grin!!)

Steve, a PABX might or might not be the best solution for you and your volunteers. From a design point of view, you should separate the functional behaviour

• what do you want it to do, and how will people relate to it

and the technical implementation

• VoIP line presence
• PABX function, audio interface,
• maintainability, programming,
• cost (of hardware, software, handsets, interface cards), etc).

After the analysis it might well turn out that the requirement is better served with a not particularly complex solution, like a BN commander frontended by one or more VoIP ATAs.

Happy to talk this through offline - drop me a line or give me a call (provided you have a working phone) :-)

John