What Must Be Documented in a Business Phone System?

A business phone system is not documented when someone has only saved a provider invoice and a diagram. Useful documentation lets an authorised person understand ownership, reproduce intended call journeys, operate routine work, respond to failure, and change the system without exposing secrets. It describes the business design and points to controlled sources of current truth; it does not duplicate every live value into a document that immediately becomes stale.

Start With Purpose, Scope, and Owners

Record the business locations, departments, hours, languages, calling use cases, and critical customer journeys. Name the accountable business owner and the technical owners for the appliance, PBX, network, SIP service, numbers, endpoints, CRM, dialer, recordings, and power. Include vendor support references and escalation paths.

State what is deliberately outside the design. For example, an appliance may provide telephony software and supported operations while the customer separately supplies Internet, SIP trunks, numbers, phones, headsets, switches, and backup power. Clear boundaries prevent support delays and purchasing surprises.

Maintain a Number and Trunk Register

List business DIDs, purpose, department, provider, routing owner, portability status, renewal details, and approved outbound presentation. Keep authentication identity separate from presented caller ID; they may not be the same. Document whether a trunk registers or uses address-based trust, its expected source and destination information, transport, codec constraints, and provider contact.

Do not place SIP passwords or portal credentials in the register. Store them in a secret manager and reference the accountable owner and retrieval procedure. Mark test numbers and emergency-routing responsibilities clearly.

Describe Inbound Call Journeys

For each public number, show the route during business hours, outside hours, holidays, no answer, busy conditions, and system failure. Include IVR prompts and valid, invalid, and no-input behaviour; queue or ring-group membership; timeouts; voicemail or fallback; transfer rules; and the final destination.

Use plain-language diagrams supported by exact route names or identifiers. Record the approved prompt source and language. A screenshot alone is inadequate because it may omit timing, fallback, and the reason the route exists.

Describe Outbound and Campaign Journeys

Document whether calls are direct, customer-first, agent-first, extension-to-customer, mobile-to-customer, or automated IVR. State how caller IDs are selected, how numbers are normalised, how agents or destinations are chosen, pacing and concurrency boundaries, campaign schedules, retry policy, and what happens after no answer or an unavailable agent.

Record that customer and agent legs have separate outcomes. This prevents a failed agent leg from being treated as proof the customer was never contacted. Include the approved test procedure before a campaign is released.

Document Users, Roles, and Endpoints

Maintain role definitions for administrators, configuration agents, campaign operators, reporting users, and integrations. Record approval requirements for configuration, restore, campaign start, recording access, and credential management. Avoid a shared administrator account.

Inventory extensions and endpoints by business owner, type, location, provisioning method, network dependency, emergency-location requirement, and lifecycle status. Do not copy passwords into the inventory. Include onboarding, change, lost-device, and offboarding procedures.

Record Network and Power Dependencies

Document the logical voice path: Internet or private provider circuit, firewall and NAT, switches, VLANs, addressing, DNS, time, QoS policy, remote access, and media paths. Include which MYLO appliance port serves which network role and who controls router changes. Linux remains authoritative for current interfaces, addresses, and routes.

List power supplies, UPS coverage, expected runtime, shutdown and restart order, and backup connectivity. Describe limitations: a secondary Internet link may not support the provider’s source-address rules or adequate voice quality until tested.

Document Configuration and Change Control

Record where the canonical telephony configuration is managed, how loaded state is inspected, which changes MYLO supports, who may approve them, how backups are created, and how verification is performed. Asterisk or FreeSWITCH remains authoritative for loaded telephony state; saved files and change tickets do not prove a reload succeeded.

Every material change record should contain request, observed state, proposal, approval, backup reference, execution result, verification calls, and rollback decision. Preserve failed attempts rather than rewriting history.

Cover Security and Privacy

Document authentication methods, least-privilege roles, secret-storage locations by reference, token rotation, firewall boundaries, remote-administration rules, software-update ownership, and incident response. Include the policy for sending data to an AI provider and the rule that SIP credentials, API tokens, private keys, and unrestricted logs stay out of chat prompts.

Define recording notice, consent, access, retrieval, retention, deletion, and audit requirements with appropriate legal review. Apply similar controls to call records, exports, tickets, and diagnostic bundles.

Explain Monitoring, Reporting, and Evidence

List what is monitored, alert thresholds, responsible person, maintenance windows, and how an alert is verified through the real call path. Describe identifiers used to correlate campaign, run, customer, call, leg, event, and recording records. Define business metrics so “answered” or “completed” cannot be misread.

Document report freshness, time zone, retention, reconciliation, and access. Monitoring data is evidence, not automatic proof of root cause; current network, telephony, provider, and application authorities must be consulted.

Keep Operating Procedures Practical

Provide short runbooks for opening MYLO, adding or removing an authorised user, planned changes, trunk failure, Internet failure, one-way audio, lost phone, campaign pause and resume, restoration, provider escalation, and post-change testing. Each runbook should state prerequisites, approval, steps, expected result, stop conditions, and escalation.

Use placeholders for secrets and customer information. Test procedures during normal operations, not for the first time during an outage.

Control the Documentation Lifecycle

Assign an owner, review date, product and environment scope, and change history to every document. Review after system changes, incidents, provider changes, office moves, and staff transitions. Archive earlier versions rather than silently overwriting decisions where audit history matters.

Validate documentation against live state. A stale diagram should be marked stale, not used as authority. Keep a compact master index that tells an operator where each controlled record lives and who can access it.

Minimum Documentation Set

1. Business scope, owners, suppliers, and support contacts.
2. DID and trunk register without embedded secrets.
3. Inbound, outbound, IVR, queue, campaign, and fallback journeys.
4. User roles, approvals, extensions, and endpoint inventory.
5. Network, security, power, backup, and recovery design.
6. Configuration baseline and immutable change records.
7. Monitoring, reporting definitions, and incident procedures.
8. Privacy, recording, retention, and credential policies.
9. Go-live and recurring verification results.
10. Review dates, version scope, and document owners.

The goal is continuity: another authorised person should be able to understand the service, make a safe decision, and prove whether the customer journey works.

Document Capacity and Cost Assumptions

Record expected concurrent calls, agents, extensions, trunks, campaigns, recordings, codecs, bandwidth, storage growth, provider channel limits, and busy-period assumptions. State how capacity was tested and which component becomes the limiting factor. A user count is not the same as concurrent channels.

Keep recurring provider, number, support, connectivity, licence, power, and maintenance responsibilities visible. Cost documentation should explain assumptions without exposing commercial credentials or mixing one-time implementation work with recurring service.

Keep Prompts and Customer Content Controlled

Maintain a prompt inventory with business owner, language, script, approval, recording source, effective date, and routes that use it. Store source audio and production formats predictably. A file named “final” is not reliable version control.

Review greetings after schedule, department, legal-notice, or brand changes. Test volume, clarity, silence, DTMF timing, invalid input, and fallback over the real provider path, not only through local playback.

Record Test Evidence and Known Limitations

Keep a test matrix for inbound, outbound, transfers, IVR, queue, no answer, busy, failure, two-way audio, recording policy, events, reports, restart, and backup connectivity. Each result should include date, environment, tester, call identifier, expected outcome, actual outcome, and correction reference.

Maintain an honest limitations register with impact, workaround, owner, and review date. This is more useful than allowing staff to rediscover the same boundary during every incident.

Create a One-Page Service Authority Map

Alongside detailed records, maintain one concise map showing the customer journey and the authority for each layer. It should connect the public number and SIP provider to the firewall, network, PBX, route, endpoint or queue, CRM or dialer, and final reporting system. For each boundary, name the accountable owner, where current state is verified, and the escalation path. This helps an operator distinguish a carrier delivery problem from a PBX routing problem, a network media problem, or an application reporting problem.

The map should not contain credentials, private keys, or unnecessary customer data. Use references to controlled inventories and secret stores. Review it after provider, address, firewall, trunk, route, integration, or ownership changes. During an incident, mark the observed failure boundary rather than editing the map to fit a theory.

Document Recovery Scope and Prove It

Every important component needs a written recovery statement: what is backed up, what is excluded, where the backup is stored, who can restore it, how integrity is checked, and which real business calls prove recovery. A telephony configuration backup may not include Linux networking, provider-side routing, recordings, CRM records, endpoint provisioning, or campaign state. Document these differences explicitly so a restore button is not treated as a complete disaster-recovery plan.

Record the last successful restore exercise and its evidence. Include the environment, backup identifier, elapsed time, dependencies, expected result, actual result, and unresolved limitations. Test on an appropriate controlled system rather than risking production merely to satisfy a checklist. If recovery depends on a provider or specialist, document the contact, authority, and realistic response assumptions. Documentation is operationally useful only when another authorised person can locate the correct material, understand its scope, and verify the restored customer journey.