Phone system RFP questions

A capable partner designs 911 as a documented dial plan with direct dialing, a central notification path and a location method for each phone type, then proves it with live test calls. Ask for a location register that lists every extension, its site or dispatchable location and its phone type, plus a written test plan with scripts and a signed test record for each site. Ask whether tests run from every site and from off-premises softphones, and how the partner keeps location current when a user moves. Your responsibilities include the carrier and emergency service provider configuration, the address validation service, and approval from your local authority. Confirm in writing whether the answer depends on your site addresses and carrier path, because those inputs decide what the test proves.

The partner should deliver a hardened configuration baseline covering encrypted signaling, restricted access to trunk and admin interfaces, intrusion blocking, strong per-endpoint credentials and removal of default accounts. Toll fraud controls matter as much as access controls, so ask for outbound call limits, international dialing restrictions and alert thresholds with a named responder. Ask for the firewall rule list, the access control lists tied to your carrier's IP ranges and the results of a security test run by someone outside the build team. DeployOpen runs security testing of infrastructure, so independent testing can be scoped in writing as a separate deliverable. Your responsibilities include carrier-side fraud controls and the IP ranges your provider publishes. Confirm which controls ship enabled by default and which need a decision from your team.

The partner usually prepares the porting order and checklist, but your account holder must sign the authorization and the losing carrier controls the port date. Ask for a port-readiness checklist that matches the account number, service address, billing name and port PIN to the carrier's records, since mismatches are a common cause of rejected orders. Ask for a port matrix that groups numbers by range and site, a cutover schedule with interim call routing and a rollback plan if a port fails. Confirm who submits the order, who talks to the losing carrier and who approves the cutover window. Ask the carrier for its stated lead time in writing instead of relying on the partner's estimate, and make sure your contract lists the numbers in scope so porting is not a moving target.

A sound migration starts with an inventory of the current dial plan, including extensions, routes, hunt groups, paging, ring groups and feature codes, then maps each item to its new equivalent. Ask for call flow diagrams, a parallel run period and a test matrix covering internal, external, emergency, international and feature code calls, each with expected results. Ask how legacy features with no direct equivalent are handled and who approves the parity decisions. Request a rollback procedure that can restore the old routing within a defined change window. You are responsible for providing legacy configurations, vendor support access to the old system and decisions about features you want to retire. Confirm whether the test matrix runs with real call traffic or only synthetic calls, since that changes what the results prove.

Monitoring should cover SIP registrations, trunk status, call quality indicators such as jitter, packet loss and mean opinion score, host resources, disk, certificate expiry and failed-call patterns. Treat the 911 path as its own monitored service with a separate alert, so a failure there is never buried in general noise. Ask for written alert thresholds, dashboards, log and call detail record retention periods and the escalation list for business hours and after hours. Confirm whether monitoring is part of the fixed-scope build, a retainer or both. You are responsible for supplying alert destinations, carrier or session border controller telemetry and any network visibility the partner needs. Ask the partner to show a test alert reaching a named recipient during the handover, not just a dashboard screenshot.

The partner should state which Asterisk release line it will run, check that line against the project's published lifecycle and record the end-of-life and security-only dates in your documentation. Ask for the FreePBX compatibility matrix for the same release, since the two must be upgraded together. Ask for the upgrade process: a staging copy of production, dial plan regression tests, and a 911 retest after every upgrade. Ask who applies security fixes, how quickly they are scheduled, and how the partner will plan a move to a newer line before security support ends. You are responsible for approving change windows and budgeting for upgrade work under a retainer or a separate scope. Confirm the policy in writing, including what happens if a security fix conflicts with a custom module.

A clear answer names the hours covered, the severity levels, the response expectations for each level and the person who answers when the phone system itself is down. Ask for an out-of-band contact path that works without the PBX, a written escalation chain to the partner and to your carrier, and a runbook for 911 path failures that includes notification steps. Ask whether the partner tests the escalation path during handover and who holds the on-call roster. DeployOpen offers ongoing support as a retainer, and its terms are agreed in writing, so ask for the exact response commitments in that agreement rather than accepting general wording. Your responsibilities include your own internal on-call staffing and the support contracts with your carrier and handset vendors.

Expect an as-built architecture, a version-controlled configuration repository, runbooks, a 911 location register and test records, porting records, a change log and an access register listing every administrator account. Ask who holds admin credentials at handover and confirm that you receive full ownership of configurations and documentation. Ask for an administrator training record and a written list of the open items after go-live. Documentation matters beyond operations, because call recording and retention may fall under rules such as the three-year preservation requirement in 17 CFR 240.17a-4 for broker-dealers. DeployOpen documents systems and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Your auditors and certification bodies make those determinations.

The cost is set by the written scope, and DeployOpen issues a quote from that scope rather than from a published price list. The main drivers are the number of sites, the number of users and devices, the number of integrations (such as CRM, paging or call recording), the depth of 911 and failover testing, the support hours you need after go-live, and the volume of numbers to port. Each driver is a separate line in the quote, so you can see which choices move the total. Ask the partner to split the quote into one-time work (design, build, testing, porting, documentation) and recurring work (support, upgrades, monitoring). Separate SIP trunk, number and handset costs are paid to carriers and vendors, not to the implementation partner.

The schedule depends on the scope, so a partner should give you a timeline only after it has agreed the sites, integrations, testing depth and porting plan in writing. Number porting is often the item with the longest lead time because it depends on the losing carrier, so ask for the porting schedule separately from the build schedule. Ask the partner to show which phases can run in parallel, such as dial plan build and carrier setup, and which must wait, such as 911 test calls on production trunks. Ask what the buyer must approve at each phase and how long each approval takes in your organization.

The partner will need a current inventory of users, sites, phone numbers, trunks, call flows and any systems the phone platform must talk to. You will also need to name an owner for 911 location data, decide who approves carrier and porting actions, and confirm which network segments and firewall rules can change. Give the partner access to your cloud accounts, data center or on-premises environment, and agree how change windows will work. Missing inputs in these areas are a common reason scope grows after signing, so settle them before the statement of work is final.

Some organizations run Asterisk or FreePBX with internal staff, especially when they already have engineers who know SIP, Linux and VoIP troubleshooting. The harder parts are usually 911 design and documented testing, SIP security for any endpoint on the internet, number porting, and keeping upgrades on a supported Asterisk release. Ask yourself whether your team can cover these during a normal week and during an outage at 2 a.m. A partner can take on any subset of this work under a fixed scope, and your staff can take on the rest. Decide the split in writing so that ownership of each system and runbook is clear.

The partner should design the 911 path for each site and each phone type, including direct dialing, notification to the right staff, and the dispatchable location the carrier receives. Ask for a written test plan that covers every site, every trunk and the remote or softphone users, and for evidence of each test result that you can keep for audits. Confirm who signs off on the design, who owns the location database and how changes are logged when users move. The partner prepares the systems and evidence, but your legal and compliance owners must confirm that the design meets the rules that apply to your organization.

A good SIP security plan covers how endpoints register, whether any SIP port is reachable from the internet, how trunks are authenticated and restricted to known carrier addresses, and how brute-force attempts are detected and blocked. It should also cover encryption of signaling and media where your carriers and devices support it, and a patching process for Asterisk, FreePBX and the operating system. Ask the partner to describe its test method, such as scanning and call-fraud testing, and what evidence it will hand over at the end. DeployOpen runs security testing for applications, infrastructure and APIs, which can be scoped to the phone platform if you want independent testing of the build.

A partner should start with an inventory of every number, its carrier, its service address and its current routing, then sequence the port so that the most critical lines move in controlled waves. The dial plan migration should be tested in a parallel environment with test calls for internal, external, emergency and after-hours routing before any number is moved. Ask who files the port requests, how the losing carrier's requirements are met, and what the rollback plan is if a port fails. Porting lead times are set by carriers, so confirm the expected schedule in writing with both the carrier and the partner.

Ask the partner to name the Asterisk release it will deploy, the date that release reaches end of life, and the upgrade path to a supported version, including FreePBX compatibility for that release. Confirm monitoring coverage, alert ownership, the support hours that apply to your sites and what is excluded, such as carrier faults. Support and upgrades are usually recurring, and they are sold separately from the build as retainers. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and it issues a quote for these from the written scope, so ask for the hours, response paths and upgrade testing steps in the quote.