A telephony request family, not a new vendor relationship.
Phone systems generate the same recurring-request pattern as Microsoft 365: a new extension, a call-routing change, an occasional port. This names that pattern as a catalog lane instead of leaving it to whoever happens to know the phone system.
What enters the telephony lane.
Useful when phone-system requests currently land on whoever is available, instead of following the same written procedure as everything else.
User and extension administration — add, move, or change a user's extension, voicemail, and call-handling rules on the platform already in place — call-routing changes such as business-hours schedules, hunt groups, ring groups, and auto-attendant menus, number and porting coordination with the client's carrier or platform vendor, and basic device or softphone support on the user's end.
An authorized change is applied and confirmed with the affected user, or a porting request is tracked against the carrier's own timeline with the client kept informed.
Which platform is actually in scope — this is administration of an existing system, not a vendor-selection or deployment service — the admin-access method, the authorized-requester list, and a named carrier or vendor contact for porting.
Where a phone request stops being routine.
- Choosing or replacing the phone systemIs a procurement and project decision, scoped and estimated on its own — not a lane request.
- A number portRuns on the carrier's own timeline; delivery tracks and coordinates it, and does not promise a date the carrier controls.
- Call-quality issues that trace back to the networkRoute through the network lane instead of being treated as a phone-system fault.
- A new site or platform redesignIs scoped like any other project, with its own estimate and acceptance.
Who owns what around the phone system.
| Vendor or carrier account relationship | Confirmed at intake — practice or client; delivery administers it, it does not hold the account. |
|---|---|
| New DID or porting request | Named authorized requester approves, per the intake list. |
| Call-quality issue that turns out to be network-side | Routed to the network-management lane. |
| Platform replacement | Practice decides, scoped separately as a project. |
Ask these before assuming phones are covered.
- Does the lane name the actual platform, or just say "phones"?The request families above assume one named platform, not general telecom expertise.
- Who is the authorized approver for a new extension or a port request?Confirm the list before the first request, not during it.
- What happens when call quality is actually a network problem?Confirm the handoff to the network lane in advance.
- Is a platform replacement already being discussed as a project?Do not let it get assumed into the recurring rate by default.
See where telephony joins the rest of the catalog.
It follows the same request-family pattern as Microsoft 365 administration, and the same escalation rules as any other lane.