Six situations we're built for

The situation

A regional operator has committed to retiring copper facilities and consolidating wire centers. Engineering knows the plan. What nobody has assembled is a complete view of what still rides those facilities — legacy private lines, alarm circuits, wholesale interconnects, and the selective router paths that carry 911.

Why it's harder than it looks

Discontinuing any facility that supports 911 delivery — interconnection trunks, selective router TDM circuits, dedicated 911 paths, TDM private lines used for 911 transport — requires coordination with 911 service providers well ahead of the Section 214 filing. Miss that coordination and the whole schedule slips, or worse, a PSAP loses a path nobody realized it depended on.

What we do

• Facility-level dependency mapping, with 911-supporting paths identified first and treated as a separate workstream.
• Interconnect and wholesale customer impact analysis, so notification obligations are known before they're triggered.
• IP interconnection target design and a grooming sequence that empties facilities in a safe order.
• A filing and notification calendar that works backwards from the coordination requirements rather than forwards from the retirement date.

What changes

The retirement program moves from a network-engineering schedule to a plan that survives regulatory and public-safety scrutiny — with the 911 dependencies found early, while there is still time to do something about them.

The situation

A multi-site operator — retail, franchise, healthcare, hospitality, the pattern is the same — has analog lines at every location, accumulated over twenty years, billed through facilities rather than IT. Nobody can say with confidence what each line does. Then the notices start arriving.

Why it's harder than it looks

The lines that matter most are the ones nobody thinks about: elevator emergency phones, fire alarm communicators, door entry, and card terminals. Several are life-safety systems subject to inspection regimes that are entirely separate from the telecom project. Cutting one over incorrectly isn't an outage — it's a failed inspection, or worse.

What we do

• Reconcile carrier billing, customer service records, and physical survey into one register — because none of those three sources is complete on its own.
• Classify every line by function and criticality, and identify which cutovers require an authority having jurisdiction to witness and sign off.
• Select replacement paths per class. Cellular POTS replacement devices are frequently the right answer for life-safety analog equipment, because they avoid depending on site internet or the internal IT network — but that's a decision to make per class, with the trade-offs written down.
• Build a site-by-site sequencing plan with rollback criteria and a test that actually proves the fire panel can still reach the monitoring center.

What changes

The program stops being reactive. Sites are migrated on your schedule against a known inventory, rather than scrambling inside each 90-day window as notices arrive.

Reference: POTS line replacement ↗

The situation

A multi-building healthcare campus runs a mix of legacy PBX, newer IP telephony, and softphones on laptops that move between buildings and go home. Kari's Law and RAY BAUM'S Act apply. Nobody is certain the estate complies, and nobody wants to find out during an incident.

Why it's harder than it looks

The two laws ask for different things. Kari's Law requires direct 911 dialing without a prefix, plus notification to on-site personnel when a 911 call is placed. RAY BAUM'S Act requires a dispatchable location — a validated street address plus the detail that actually finds the caller, like building, floor, and room — along with a callback number. On a campus, "the street address" is nearly useless on its own, and the answer differs between a fixed desk phone, a nomadic device on site, and an off-premises softphone.

What we do

• Endpoint census by category — on-premises fixed, on-premises non-fixed, off-premises — because the location obligation is defined differently for each.
• Test direct-dial behavior and prefix handling across every system in the estate, including the ones people forgot were still there.
• Design the location data model: how a wiring closet, switch port, wireless AP, or user-declared location becomes a dispatchable location the PSAP can act on.
• Specify the notification path — who gets alerted, how, and whether it actually reaches somebody at 3am.

What changes

Compliance becomes a documented architecture with evidence behind it, rather than an assumption. Where gaps exist, they're prioritized by risk instead of discovered by incident.

Reference: E911 and MLTS compliance ↗

The situation

A contact center takes payments during calls. Recording is enabled for quality and dispute purposes. The current control is pause-and-resume: agents are trained to stop the recording before card entry and restart afterwards.

Why it's harder than it looks

PCI DSS v4.0.1 has been mandatory since 31 March 2025, and it is unambiguous that recordings must not contain cardholder data. Pause-and-resume depends on an agent remembering, every time, under pressure. Reported agent compliance with pause/resume typically lands somewhere in the 80–95% range — which means a meaningful share of recordings still capture card data. Worse, the storage containing those recordings is now in scope, and so is everything attached to it.

What we do

• Map where cardholder data actually flows through the voice path — media, recording, transcription, QA tooling, analytics, backups, and any AI system now reading transcripts.
• Design the technical control rather than the procedural one: DTMF masking so digits are suppressed in real time and never reach the agent, the recording, or the transcript.
• Scope reduction analysis — what leaves PCI scope entirely once the technical control is in place, which is usually the largest cost saving in the project.
• Evidence design: what your QSA will ask for, and how the architecture produces it without a manual scramble.

What changes

The control stops depending on human memory. Scope shrinks, the evidence trail becomes routine, and the recordings stop being a liability.

Reference: PCI DSS in the contact center ↗

The situation

Several hundred agents across three sites on an on-premises ACD approaching end of support, fed by PRI trunks. Leadership has approved a move to cloud. The internal debate has stalled: every shortlisted vendor answers yes to every requirement.

Why it's harder than it looks

Feature checklists don't discriminate, because the differences that matter aren't features. They're the routing model's flexibility when your business rules don't fit the vendor's assumptions, the granularity of historical reporting, real-time API rate limits, how deeply WFM integrates, and what a bespoke CRM integration genuinely costs to build and maintain. None of that surfaces in a demo. Meanwhile the telephony migration underneath — PRI to SIP — is a separate project that usually gets underestimated.

What we do

• Derive requirements from observed routing and reporting behavior, then weight them by what the business actually depends on.
• Design proof-of-concept scenarios around the hard cases, and make vendors build them rather than describe them.
• Model true cost including telephony charges, concurrency versus named licensing, and integration build and run.
• Plan the trunk migration as an explicit workstream with its own feature-parity matrix, rather than a footnote.

What changes

The decision gets made on evidence, with the reasoning recorded so it survives the people who made it. And the telephony work is planned rather than discovered.

Reference: platform evaluations ↗

The situation

A utility has built an AI voice agent to handle outage reporting and status inquiries. It performs well in demonstrations. The vendor reports a high deflection rate. Launch is scheduled. Nobody has written down what would constitute a failure.

Why it's harder than it looks

Deflection, containment, and resolution are three different measurements, and they are routinely conflated. A system can show very high deflection while resolving far less — the caller left the queue, which is not the same as the caller being helped. And an outage line has a brutal load profile: the traffic that matters arrives all at once, from stressed callers, on bad connections, often with background noise and interruptions. That is the opposite of demo conditions.

What we do

• Agree the definition of resolved, per intent, before any measurement begins.
• Build the evaluation set from real transcripts — including the long tail, the interruptions, the accents, and the callers who don't follow the script.
• Report containment, true resolution, escalation correctness, and latency as four separate numbers, and show where they diverge.
• Test the storm case explicitly: concurrency, degraded audio, DTMF fallback, and what happens to the escalation path when the human queue is already saturated.
• Hand over a harness the team re-runs on every release, so quality is tracked rather than assumed.

What changes

Go-live becomes a decision with criteria attached. Sometimes the answer is launch; sometimes it's launch for two intents and hold the rest. Either way it's a decision rather than a hope.

Reference: evaluating an AI agent ↗