When Does a Telephony Requirement Need Custom Development?

A telephony requirement needs custom development when the desired business outcome cannot be delivered through supported configuration, documented product workflows or a standard external integration. The word “custom” should not be used merely because a company has its own opening hours or IVR wording. Those are normal configuration. Custom work begins when new software behaviour, a new system boundary or specialised integration must be designed and maintained.

Identifying that boundary early protects both the buyer and delivery team. It prevents an appliance from being sold as if it included unlimited engineering, and it prevents a straightforward configuration project from being burdened with unnecessary development.

Configuration, integration and custom work are different

Configuration selects values inside an existing supported capability. Creating extensions, assigning a supported route, choosing a caller ID from an authorised set or setting business hours may be configuration when the product already provides those operations.

Integration connects supported interfaces between systems. It may be straightforward when both sides expose stable, documented mechanisms and the required mapping already exists. Integration still needs ownership and testing, but it does not always require a new product feature.

Custom development creates or materially changes behaviour. It may add a workflow, API, connector, user experience, data model, scale characteristic, compliance control or deployment architecture. It requires requirements, design, implementation, verification and ongoing maintenance.

Signals that a request is genuinely custom

• The requested call journey cannot be represented by the supported inbound, outbound, IVR, queue or routing model.
• A proprietary CRM or business application must control calls through behaviour that no supported connector provides.
• The requirement introduces a new role, approval model, data-retention rule or audit boundary.
• The expected scale, availability or geography differs materially from the supported deployment.
• A carrier requires a signalling, authentication or network mechanism outside the supported provider model.
• The workflow needs a new API, event contract or durable state machine.
• The business wants to modify underlying source code or run on a substantially different infrastructure topology.
• Acceptance depends on specialised regulatory or industry controls that must be designed and independently reviewed.

Any one signal warrants discovery. It does not automatically mean the request should be built.

Examples that may not require development

Changing the spoken greeting, setting an after-hours schedule, routing sales and support to different existing destinations, importing a lead file in the documented format, assigning authorised caller IDs or adding supported users are usually configuration tasks. They still need valid inputs, permission and functional testing.

A customer may describe these tasks in unique business language, but uniqueness of wording is not uniqueness of system behaviour. The delivery team should translate the desired outcome into the product’s existing concepts before proposing code.

Similarly, a one-time data cleanup or provider-side setting is not necessarily product development. Assign it to the correct owner. Do not write software to compensate for an incomplete carrier order, an undocumented firewall restriction or missing business decisions.

Examples that commonly require discovery

Deep CRM orchestration

The business wants calls created, routed and updated according to proprietary case stages, with bidirectional state, retries, permissions and reporting. This is more than showing a contact name. The integration needs an explicit data contract and failure model.

Unusual multi-site resiliency

The requirement calls for automatic failover across regions or providers with strict recovery targets. Architecture, data consistency, media routing and operational testing must be designed.

New automated decision logic

The business wants calls to change course based on proprietary scoring, external data or a new AI behaviour. The authority, privacy impact, deterministic safeguards and human override need design.

Specialised compliance controls

The organisation requires retention, consent, residency, access or evidentiary controls beyond the product boundary. Qualified legal and security review may be required in addition to engineering.

Run discovery before estimating

A credible estimate starts with a business journey, not a list of screens. Identify actors, trigger, inputs, decisions, call legs, external systems, expected records, error paths and final outcome. State volume, concurrency, availability, latency and retention requirements. Record assumptions and open questions.

Map every step to an authority. The SIP provider owns its trunk and public network. Asterisk or the selected telephony engine owns live call execution. Linux owns machine and network state. The application owns its workflow records and access controls. The CRM owns customer records. A custom design should integrate these authorities rather than create conflicting copies of current state.

Define the supported boundary and exclusions in writing. If the project relies on a carrier API, specify version and test access. If it relies on a customer network, state who supplies firewall changes. If it uses AI, identify what information may be sent, what the model is allowed to decide and where deterministic enforcement remains.

Create measurable acceptance criteria

“Integrate the CRM” is not an acceptance criterion. A testable version might say: when an authorised agent starts a call from an eligible case, the system uses the approved caller ID, records a stable correlation ID, emits ordered call events, updates the case only after verified outcomes, and handles CRM unavailability without losing the telephony result.

For call journeys, test signalling, route selection, two-way media, DTMF, timeout, transfer, hang-up and recording policy. For data, test authorization, field mapping, duplicates, retries, ordering, retention and deletion. For operations, test deployment, rollback, monitoring, alerting and recovery.

Include negative tests. An unauthorized user, invalid destination, stale approval, unavailable provider, malformed event or failed dependency should stop or degrade predictably. Production readiness includes how the system fails.

Choose the right delivery form

A small, stable extension may be delivered as a bounded custom integration around the existing platform. A broader requirement may justify an open-source deployment that the customer owns. A request that would change the appliance’s core product assumptions should not be hidden as a configuration tweak; it may belong on a separate product roadmap or be declined.

A proof of concept can reduce uncertainty, but it is not production. Define whether it may handle real customer data or traffic, how it will be removed, and what additional work separates it from release. Avoid allowing demonstration code to become an unsupported permanent dependency.

Budget for lifecycle, not only build

Custom work needs a product owner, technical owner and operational owner. Budget for design, implementation, security review, provider testing, documentation, deployment and training. Then budget for monitoring, incidents, dependency updates, credential rotation, regression testing and changes in external APIs.

Specify ownership of source code, configuration, secrets, environments and intellectual property. Decide who can approve releases, who receives alerts and what support hours apply. Define end-of-life: how data and call routes will be migrated if the feature is retired.

A low initial quote that excludes these duties may be more expensive over time than a standard product that covers most of the outcome.

Protect the existing system

Custom development must not bypass the controls that make telephony manageable. Preserve role checks, explicit approvals for consequential effects, protected credentials, bounded file or API scope, pre-change backups, deterministic validation and post-change verification. Do not allow an integration to write arbitrary PBX or Linux state because it can express a plausible request.

Keep a clear line between explanation and execution. An AI model may help interpret intent or evidence, but authorization and mutation must remain deterministic and auditable. A knowledge article or historical example is not proof of current provider or network state.

Prefer small interfaces and single authorities. Duplicating trunk configuration in a CRM database or treating an application row as live network truth creates drift. Read current operational state from the owning system and store only the application records the custom workflow genuinely owns.

A go or no-go checklist

• Is the business outcome valuable enough to justify continuing ownership?
• Have supported configuration options been ruled out with evidence?
• Are the actors, call legs, systems and data flows documented?
• Are external dependencies available for realistic testing?
• Are security, privacy and lawful-use questions assigned to qualified owners?
• Can success and failure be measured end to end?
• Is the deployment and rollback approach defined?
• Are source, support, monitoring and maintenance ownership agreed?
• Does the budget include lifecycle cost?
• Can the project be stopped safely if discovery exposes unacceptable risk?

Example: a request becomes a project

A company asks for “automatic calls from our CRM.” Discovery shows that the system must select eligible cases, obtain supervisor approval, call the customer first, connect an agent only after answer, write ordered events to the CRM, avoid duplicate attempts, respect customer preferences and recover after either system is unavailable.

Some call execution may use supported capabilities, but the cross-system eligibility, approval, idempotency and recovery workflow is new. Treating it as a single setting would hide risk. A proper project defines the event contract, ownership of each state, security boundaries, retry rules, reconciliation process, capacity test and acceptance calls.

If the business instead only needs to upload a supported lead file and export a standard report, configuration may be sufficient. Discovery distinguishes those two outcomes.

The decision

A requirement needs custom development when it changes behaviour rather than values, crosses a system boundary without a supported interface, or demands a materially different operating architecture. The correct next step is structured discovery, not an immediate promise.

Keep MYLO appliance scope, MyLineHub open-source possibilities and custom engineering separate. Configure what is supported, integrate through stable boundaries where possible, and build only when the business value, acceptance evidence and long-term ownership are clear.