VoIP Feature Checker: Build Your Business Requirements
Choose the Right Phone Features for Your Business
Turn real customer-call problems into prioritised VoIP requirements. Decide what is essential, define supplier acceptance tests and export a useful brief before comparing packages. Free, independent and no sign-up required.
Independent Phone-System Requirements Tool
Start with the customer journey, not a supplier feature list. Record your priorities, then ask each provider to demonstrate the same required behaviours in its proposed package.
Build Your VoIP Requirements
Start with your team’s call handling, CRM, security and continuity needs. Prioritise each requirement before asking suppliers to quote or demonstrate their solution.
What Your Requirements Brief Delivers
A supplier-ready list of Must Haves, Should Haves and unresolved decisions, with specific test procedures and evidence requests for the selected capabilities.
Planning note: A selected feature is not proof it exists on a particular plan. Obtain written, edition-specific confirmation and demonstrate each essential workflow before signing.
Build Your Business Phone Requirements
Start with your key customer-call journeys. Select essential, optional and unresolved features, then export questions suppliers can answer and demonstrate.
Build Your Supplier Requirements Brief
Start with the calls your business must handle. Select a priority for each requirement and check the proposed supplier’s evidence. This tool prepares evaluation criteria; it does not verify features, score providers or request personal contact information.
Record operational outcomes, not personal customer data or supplier promises.
Choose Requirements by Business Workflow
Every feature starts as Unknown until someone decides. Expand each acceptance test to add your business rationale and the internal sign-off owner for that requirement.
Your Business Requirements Summary
| Feature / Workflow | Priority | Required Behaviour / Acceptance Test | Supplier Evidence Required |
|---|
Data remains in this browser page only. CSV includes decisions, internal owners and explicitly excluded items. Download the HTML supplier brief and use your browser’s Print / Save as PDF function to obtain a focused PDF. No generated document proves supplier compatibility.
Privacy: no contact information, login or external API is required. Inputs are processed locally. Closing or reloading the page clears your selections unless you have exported them.
From Customer Journey to Feature
Define the expected result of every incoming call. Translate unanswered calls, closures and transfers into requirements that can be tested.
Check Evidence Before Buying
Require suppliers to demonstrate your Must Haves with the relevant licences, configuration, administration and support arrangements.
BEFORE SUPPLIER COMPARISON
What a Feature Selection Does Not Prove
A list of checked features cannot verify provider compatibility, quoted licence coverage, data safeguards or resilience. Obtain and record actual supplier evidence.
Choose phone-system features by the work they must actually do. This VoIP feature checker helps UK businesses turn customer-call problems, staff workflows, compliance needs and continuity expectations into a prioritised requirements brief. Record what is essential, what would improve operations and what still needs checking. The outcome is a supplier-ready specification—not a provider ranking or a claim that a particular package includes a feature.
A feature list can look impressive without proving that the telephone service will handle your busiest or most important customer interactions. “Includes call queues” is a product description. “Keeps a customer waiting no longer than our chosen threshold before routing the call to an agreed overflow team” is a business requirement that a supplier can demonstrate and your team can test.
Build Your Phone-System Requirements
Describe how calls move through your organisation, who answers them, which systems staff use and what happens when the normal process cannot operate. Then assign a priority to each capability instead of ticking everything as essential.
| Priority | Meaning | How to use it |
|---|---|---|
| Must have | The business cannot accept the proposed service without this requirement | Include a specific acceptance test and request written supplier confirmation |
| Should have | Important for a better daily workflow but there may be an acceptable alternative | Describe the operational consequence of its absence |
| Nice to have | Valuable if available at a justifiable cost | Keep distinct from non-negotiable requirements |
| Not needed | The workflow does not currently require this capability | Exclude it from mandatory supplier evaluation |
| Unknown | The business has not decided or has insufficient evidence | Assign an owner and resolve before treating the specification as complete |
Build my requirements
First Describe Your Calling Environment
| Business question | Why the answer matters |
|---|---|
| Who answers the main number? | Determines reception, group and fallback routing needs |
| What happens outside opening hours? | Identifies announcements, voicemail, scheduling and emergency cover |
| Which teams share incoming calls? | Establishes queue, hunt group, supervisor and transfer requirements |
| Do users work from offices, home or mobile locations? | Reveals device, application and user-management needs |
| What must happen when someone misses a call? | Defines overflow, callback or notification workflows |
| Do calls need to appear in your CRM or helpdesk? | Separates an essential integration from a convenience feature |
| Who can change routing, access and reporting settings? | Establishes administrative permissions and governance |
| Are recordings necessary? | Triggers retention, access, transparency and privacy requirements |
| What happens during an internet or power failure? | Defines continuity and emergency-communications questions |
| Who will sign off the requirements? | Prevents undocumented assumptions becoming contract commitments |
The most useful starting point is one real workflow that matters to customers: a new sales enquiry, an urgent support call or a reception transfer. Follow that interaction from first ring to its final destination. The features you need should follow from the journey, not from a supplier’s marketing list.
Turn Business Problems Into Verifiable Requirements
| Business need | Potential phone-system capability | Acceptance evidence to request |
|---|---|---|
| Calls are missed when reception is occupied | Ring group, queue, overflow or agreed callback route | Demonstration of busy and unanswered calls reaching the correct fallback |
| Different teams need different opening times | Scheduled call routing and holiday rules | Demonstration of in-hours, out-of-hours and exceptional closure settings |
| Callers must reach the right function | Auto-attendant or menu-based routing | Live test of every advertised menu option and failure route |
| Team leaders need to supervise call handling | Queue visibility, supervisor controls and reporting | Named dashboard fields, role access and reporting sample |
| Customer records should be accessible during calls | Supported CRM or helpdesk integration | Demonstration with the relevant edition and permission model |
| Staff move between office and remote work | Softphone, mobile app or device handover | User test across the intended work locations and devices |
| Administrators must restrict access | Role-based permissions and account offboarding | Demonstration of restricted access, leaver removal and activity evidence |
| Service must remain usable during disruption | Failover routing and documented continuity process | Written design and a test of the agreed failure scenario |
A capability is not verified because a salesperson confirms it verbally. Ask for evidence tied to the proposed product edition, licence tier, configuration and support arrangement. The same feature name can describe very different behaviour depending on how a service is packaged and deployed.
Practical Business Call-Handling Scenarios
Business problems should determine the requirements. These six examples are test scenarios, not customer case studies or provider rankings.
Call Handling: Specify the Actual Journey
Reception, Sales And Support
Start with the destination of an incoming call. Does the business need one shared main number? Should departments have separate direct numbers? Can a customer reach a named colleague without going through the main menu? These are routing questions that should be represented as individual requirements.
For a busy support team, define exactly what happens when all advisers are engaged. Options might include a queue with an announcement, overflow to another team, a voicemail route or a callback process. None is automatically right. The chosen route should fit the customer experience and the staff available to support it.
Opening Hours And Exceptional Circumstances
Normal opening hours are only part of the requirement. Check holidays, training closures, emergencies and unexpected staffing shortages. A system that routes correctly on a normal Tuesday but sends an urgent call nowhere during a closure has not met the complete business need.
What A Meaningful Demonstration Looks Like
Example acceptance test — a missed support call
- Place an external call to the published support destination during business hours.
- Confirm the greeting and whether the call reaches the right team.
- Make the team unavailable or busy, using the agreed test arrangement.
- Verify the queue, announcement or overflow behaviour specified in the requirements.
- Confirm that the caller reaches a defined outcome and that the staff team can see or recover the missed interaction as agreed.
- Record the result as demonstrated, not demonstrated or needs clarification.
This is a test procedure, not a fabricated customer success story. It produces evidence the business can use when reviewing an actual supplier demonstration.
Verify Essential Features Before Purchasing
Ask suppliers to prove every Must Have in the actual quoted edition, not just point to a generic feature list.
Check Call Journeys and Integrations
Demonstrate busy and unanswered calls, opening hours, transfers and failed integrations.
Record the actual result, proposed licence tier and any extra configuration needed.
Confirm Security and Recording Controls
Test a restricted administrator, joiner/leaver processes, recording retention and access to customer data.
Require written evidence for the proposed service and review the organisation’s privacy obligations.
Supplier Verification, Governance and Continuity
Record plan-specific demonstrations, account controls, emergency arrangements and supplier responsibilities before approving a phone-system purchase.
Capture integration behaviour, access controls, emergency arrangements and supplier responsibility before turning a feature list into a purchasing decision.
CRM and Helpdesk: Specify the Data Flow
“CRM integration” is too broad to be a reliable purchasing requirement. A basic click-to-dial connection is not the same as automatic customer recognition, activity logging or a service ticket created from a missed call.
| Workflow | Requirement to establish | Supplier question |
|---|---|---|
| Click to call | An authorised user initiates a call from a customer record | Which CRM editions and user permissions are supported? |
| Customer identification | Incoming callers can be matched to an accessible record where permitted | What number matching and permission limitations apply? |
| Call history | The organisation retains relevant call activity in a defined record | Which events are logged, and how are failures handled? |
| Support follow-up | A missed or completed call produces an agreed task or ticket | Does this require a separate connector, workflow tool or paid tier? |
| Data governance | Access to customer and call data follows organisational policy | What personal data is transferred, stored and retained? |
Only request a feature where the business has a clear use for it. If the organisation has no CRM, a complex CRM connector should not become a mandatory requirement simply because other buyers ask for one.
Security, Administration and Call Recording
A phone system needs clear ownership. Decide who creates users, allocates numbers, changes call flows, approves external integrations and removes leavers. Ask suppliers to demonstrate role restrictions, authentication options, audit visibility and account recovery appropriate to the proposed deployment.
Call recording requires separate consideration. The Information Commissioner’s Office explains that routine recording of workers’ calls is not automatically proportionate: a business needs a defined purpose, an appropriate lawful basis, transparency, retention controls and a sensible approach to access. Where recording is proposed, include the operational need and applicable privacy review rather than assuming it should be enabled for everyone.
| Control | Business decision | Test or evidence |
|---|---|---|
| Administrator roles | Who may change users, numbers, routing and recording settings? | Demonstrate a restricted administrative account |
| Sign-in protection | What authentication protections suit each user group? | Confirm available authentication controls for the proposed plan |
| Joiners and leavers | Who grants and removes access, and how quickly? | Demonstrate a controlled offboarding workflow |
| Call recording | Is there a documented business purpose for each type of recording? | Confirm notices, permissions, retention and deletion controls |
| Data access | Who can view recordings, reports and call records? | Show access restrictions and relevant logging |
| Support ownership | Who responds when the system fails or security concerns arise? | Review support hours, escalation routes and contract responsibilities |
A recorded feature does not replace legal assessment or internal policy. Sector-specific obligations may require separate advice.
Continuity and Staff Accessibility
Internet or power failure can affect IP telephone services, local networking and powered devices. Describe how critical calls should be handled during those events. A mobile diversion, alternate internet circuit, resilient cloud routing or another agreed arrangement may be appropriate, but its actual suitability must be demonstrated.
For critical or safety-related services, treat emergency communication and line-dependent equipment as dedicated requirements. A generic promise of high uptime is not evidence that a particular emergency arrangement, alarm interface or business-critical endpoint will continue operating.
Accessibility And Staff Usability
A suitable service should also work for the people who use it. Consider accessible control interfaces, suitable headsets or devices, readable call-status information, training needs and any reasonable adjustments. An otherwise capable system can fail operationally if the team cannot use its essential workflows reliably.
Define Supplier Evidence
Require a demonstration of the exact user journey, edition, integration and permissions.
Mark a requirement unresolved until proof is available.
Keep Critical Dependencies Separate
Document emergency calling, power loss, broadband failover and line-dependent devices as explicit requirements.
Request named ownership and a failure-test procedure.
Describe your call journeys, then prioritise each required capability. Open Feature Checker.
Check the mandatory features, their acceptance tests and unresolved decisions. How Requirements Work.
Request written proof and an actual demonstration for every Must Have. VoIP Comparison Builder.
Choose VoIP Features With Clear Evidence
Turn actual business workflows into demonstrable requirements, then ask shortlisted suppliers for evidence that matches the quoted edition and licence.
FAQs
Answers about feature priorities, supplier demonstrations, CRM connections, recording, security and what the requirements brief can prove.
Create a Supplier-Ready Specification
A usable specification brings together a requirement, its business purpose, evidence and sign-off status in the same record.
| Requirement field | What it should establish |
|---|---|
| Business workflow | Which real caller or staff journey needs supporting |
| Priority | Must have, should have, nice to have, not needed or unknown |
| Required behaviour | Precisely what should happen, and under which conditions |
| Acceptance test | How the team will recognise a successful demonstration |
| Evidence requested | Demo, written confirmation, technical document or contract provision |
| Supplier response | Confirmed for the proposed plan, not confirmed or clarification required |
| Internal owner | The person accountable for deciding or signing off the requirement |
Supplier demonstration rule: a mandatory requirement remains unverified until evidence is available for the actual configuration being proposed. Do not convert an “unknown” into a pass just to complete a checklist.
A Useful Supplier Question Set
Ask each shortlisted supplier to answer the same questions: What is included in the quoted licence? Which behaviours need configuration or add-ons? Can the team see the call journey demonstrated? What happens when an integration fails? Who operates the backup route? What does the support agreement cover? Can the functionality be validated before the business commits to a migration?
A consistent question set reduces the risk of comparing attractive feature names that conceal different operational capabilities.
From Requirements to a Purchasing Decision
| Finding in the brief | Recommended response |
|---|---|
| A must-have workflow is untested | Request a demonstration or pilot acceptance test |
| A feature depends on a paid tier | Ask for written confirmation of the actual quoted tier and associated charges |
| A CRM or helpdesk integration is unclear | Test the relevant integration and permission model with representative records |
| A critical internal decision is unknown | Assign an owner and settle it before final approval |
| A requirement is desirable but not essential | Keep it separately costed rather than allowing it to inflate the minimum specification |
| Mandatory requirements are evidenced | Take the final criteria into the VoIP Comparison Builder for a supplier-by-supplier assessment |
The VoIP Buyer’s Guide explains the wider provider-selection process. The VoIP Comparison Builder is the next stage when the business has named suppliers to assess against its requirements. This checker does not rank or endorse providers, and selecting an item never proves that a supplier supports it.
Evidence-Led Decisions and Privacy
Start with one important customer-call journey, determine what must happen, record the requirements that support it and ask each supplier to prove the same behaviours. That creates a defensible specification without confusing feature popularity with suitability.
VoIP Buyer’s Guide · VoIP Comparison Builder · Business phone numbers guide
Our Approach To Feature Evidence
CompareVoIPService treats a feature selection as a business preference, not as proof of supplier capability. Acceptance tests and written, plan-specific supplier responses are the evidence that turns an expressed requirement into a verified purchasing criterion. No provider scores or compatibility claims are inferred from the checklist alone.
Sources and limitations: This checker maps business needs to user-selected requirements and supplier acceptance questions. It does not assert supplier compatibility, regulatory compliance, feature availability or measured performance. Recording and personal-data decisions may require review of Information Commissioner’s Office guidance and applicable sector rules. Inputs stay in your browser unless exported.