Planning is an essential component of any IT project – especially when installing a new communications system in a school. Education budgets for technology projects, including phone systems, are usually tight leaving little room for error. Scoping changes in a VoIP project can cause delays and cost overruns if not identified in the planning phase. In part two of our Get Schooled blog series, we show you how one school successfully managed their phone system project and made installation and configuration in the move to a historic school building a breeze.
For Providence Classical School, their project started with a detailed planning effort. The following questions were generated for the office manager to help determine the scope of the project before configuring their VoIP phone system:
– What experience should an external caller have when they call the school’s main number?
– Why do people typically call the school?
– Who do teachers need to communicate with outside of their classroom?
– What experience should a teacher have when they call the office from their classroom?
– Who needs voicemail?
– When does the office need to use the intercom or page the school?
– Any preferences on how the phone extensions are numbered?
– Does the school receive faxes?
The initial questions led to a Statement of Work and the programming specification for the school VoIP project. There were some areas that required detailed designs before configuration, including:
- School Directory – First, identified all the extension numbers to be used throughout the school. Then, utilized a numbering scheme that would be logical and allow the office manager to own it. The focus was on simplicity.
- User and Extension Profiles – By specifying the types of users and expected functionality the phone system should provide to each assigned extension, it made it easy to create templates for each type of user. Time was saved by not having to recreate the detailed configuration for every extension. In this school project, for example, the following extension profiles were identified
– Administration: Office staff with the most permissions
– Teachers: Phone with teacher assigned
– Standalone: Phone with no person assigned as an owner
– Paging: Extension used for paging only
– Virtual: No phone assigned but does have an extension number with voicemail
- Call Queues and IVR (Interactive Voice Response) – Spent time identifying what a caller should hear when dialing into the main number. Based on the requirements, an internal and external IVR was designed.
- IP Network Design – Designing the LAN included a broader set of requirements than just the IP phone system. For this school project, the focus was on simplicity for maintenance and installation, therefore the IP phones were not segmented from the data connections in the classrooms.
Once the technical design was complete, it was time to start configuration. Since this school project used Digium’s VoIP phone system, it meant the Switchvox Admin GUI was very intuitive and easy to understand. As a note, it was helpful to have gone through the Switchvox Admin course. Also, because some configuration items are dependent on others, the order of configuration does matter. Here are five quick configuration tips:
- Set up all the Extension Profiles first. This will ensure the extension permissions are consistent across all the profile types.
- Set up all Extensions. Import from an Excel file or type them in manually. Use the profiles!
- Configure IP Phones. After the extensions are already loaded, this process is really simple. Plug in a phone into the POE switch. Select the extension number from the Digium IP phone’s LCD to provision it. No XML or any real programming is required to configure the phones. This video.If configuring in a lab, put a label on the phone with the extension number so you know where it goes later without having to power it up.
- Setup Call Queues and Ringing Strategies. Inside the building, dialing “0” for the operator goes through a different ring strategy and IVR. First the receptionist phone rings, if no answers after 4 rings, the call forwards to the office call queue where 4 other administration phones will also ring.
- Build IVRs. IVRs are best built from the ground up by configuring the final actions first. After reviewing the IVR script, the “voice” of the school met us at the lab to record all the sound prompts. We recorded and built the IVRs on the fly in about an hour. We used an agile development approach that involved testing and re-recording repeatedly to get the best end result.
While all of this was handled off-site, moving from the “lab” into the school building was easier than expected. The Switchvox appliance (sever) and POE switches were installed in the server room. Next, the patch panel was cross-connected with the POE switches to light up at least one POE port in every room. Tip: Having a schematic of the building that correlates the patch panel port with the jack location within the school is really handy.
With the server room completed, the next step was to deploy all of the IP phones throughout the school. Remember, the IP phones had already been configured so the only challenge at this stage was making sure the correct phone was placed in the right room. An IP Phone was plugged into the correct jack in each room and then it powered on with the appropriate extension. Finally, a call was made to the office to test out the connection.
How could we know for certain all the phones were connected? Simple, in the admin GUI, the SIP connection status screen showed the status of all the SIP endpoints.
With the school phone system working inside the building, the final task was to connect voice services for inbound/outbound calling. The service provider delivered POTS lines to a demark point in the server room. The lines were tested with a plain analog phone to verify they worked before plugging into a FXO port in the Switchvox appliance. Then, a simple configuration in the Switchvox Admin GUI was completed to route the POTs lines to the external IVR extension. All inbound fax traffic was routed to one extension in the school office.
No technical design is perfect nor is the implementation engineer flawless. Testing all of the primary use cases in the design is important to uncover anything that may not have been configured properly or doesn’t quite work as expected. It’s not unusual for a few mistakes to surface during testing.
In the next post, we’ll recap the training for the school’s faculty and staff on how to use their new VoIP phone system.