[ 01 · telco ]
Copper retirement & POTS replacement planning
For organizations holding analog lines they cannot fully account for — which is nearly all of them.
- typical length
- 3–6 weeks
- best trigger
- Retirement notice
The problem
Analog lines accumulate over decades and are rarely documented in one place. They bill through facilities, not IT. When a retirement notice arrives, the 90-day window is not enough time to discover what is on them — and some of what is on them is life-safety equipment governed by its own inspection regime.
What we do
- Full line inventory reconciled against carrier billing, CSRs, and physical walkthrough — not just the spreadsheet you already have.
- Classification of every line by function and criticality: elevator emergency phone, fire alarm panel (DACT), door entry, POS, fax, modem, alarm, courtesy phone.
- Replacement path per class — cellular POTS replacement device, SIP ATA, IP-native panel, or genuine decommission — with the trade-offs stated.
- Sequencing and test plan, including who has to witness and sign off which life-safety cutover.
- Cost model comparing the do-nothing trajectory against the replacement program.
What you get
- Line-by-line inventory and disposition register.
- Replacement architecture with per-site bill of materials.
- Cutover runbook and rollback criteria.
[ 02 · telco ]
TDM to IP migration architecture
For carriers and enterprises moving T1, fractional T1, PRI, or SS7-signaled traffic onto SIP.
- typical length
- 6–12 weeks
- best trigger
- Contract renewal
The problem
A PRI does not map cleanly onto a SIP trunk. Call capacity, signaling semantics, DID ranges, caller ID behavior, transfer and redirect, fax, and emergency calling all change shape. Teams that treat it as a like-for-like swap discover the differences during cutover, at 2am, with customers on the line.
What we do
- Circuit and channel inventory, including what is actually provisioned versus what is billed.
- Traffic study and trunk sizing using Erlang B against your real busy-hour data, with the grade of service written down rather than assumed.
- Feature parity matrix: every signaling behavior in use today, mapped to its SIP equivalent, with the gaps called out explicitly.
- SBC architecture — topology hiding, SIP normalization, transcoding, call admission control, and media handling.
- Number portability plan, DID mapping, and 911 registration continuity.
- Codec and QoS design with target voice quality stated as a measurable number.
What you get
- Target architecture and cutover sequencing plan.
- Feature parity matrix with accepted gaps signed off.
- Test plan and go-live acceptance criteria.
[ 03 · ccaas ]
CCaaS selection & migration
For contact centers choosing a platform, or recovering from having chosen the wrong one.
- typical length
- 4–10 weeks
- best trigger
- Renewal or RFP
The problem
Every major platform demos well. The differences that matter — routing model flexibility, reporting granularity, real-time API limits, WFM integration depth, the true cost of a custom integration — do not appear until month four. Selection processes driven by feature checklists reliably pick the wrong platform, because every vendor ticks every box.
What we do
- Requirements built from your actual routing and reporting behavior, not a generic checklist.
- Vendor-neutral shortlist and scored evaluation against weighted criteria you agree in advance.
- RFP or RFI authoring, and design of proof-of-concept scenarios that test the things demos avoid.
- Commercial review: licensing model, concurrency versus named seats, telephony charges, and where the overage risk actually sits.
- Migration architecture, including integration inventory, historical data strategy, and agent transition.
What you get
- Weighted evaluation scorecard with the reasoning behind every score.
- Proof-of-concept scripts and results.
- Migration plan with a phased cutover approach.
[ 04 · conv-ai ]
Conversational & agentic AI evaluation
For teams about to put an AI agent in front of customers, or already regretting that they did.
- typical length
- 4–8 weeks
- best trigger
- Pre-launch
The problem
"Ready for production" is usually undefined. Vendors report deflection; executives hear resolution; nobody measures what happened to the customers who were contained but not helped. Meanwhile the failure modes that matter — hallucinated policy, failed escalation, silent abandonment — are precisely the ones a demo will never surface.
What we do
- Define what "working" means before testing: which intents, which channels, which outcomes count as resolved, and what the escalation contract is.
- Build a graded evaluation set from your real transcripts, including the messy long tail rather than the clean examples.
- Measure intent and NLU accuracy, containment, true resolution, escalation correctness, and latency — reported as separate numbers, because they are separate things.
- Adversarial and edge-case testing: accents, interruptions, code-switching, DTMF fallback, background noise, hostile input, and the paths that only appear under load.
- Comparative model assessment where more than one option is on the table.
- Go-live criteria and an ongoing measurement regime for after launch.
What you get
- Evaluation report with per-intent results and identified failure modes.
- Reusable evaluation set and harness your team can re-run each release.
- Documented go/no-go criteria.
[ 05 · cx-ops ]
Assurance, voice quality & compliance architecture
For contact centers whose obligations have grown faster than their test coverage.
- typical length
- 3–8 weeks
- best trigger
- Audit or incident
The problem
Three separate regimes now attach to an ordinary contact center — E911 dispatchable location under Kari's Law and RAY BAUM'S Act, caller ID authentication under STIR/SHAKEN, and cardholder data handling under PCI DSS v4.0.1 — and they are usually owned by three teams who each assume another one has it. Meanwhile voice quality is discussed anecdotally instead of measured.
What we do
- Compliance architecture review across E911/MLTS, STIR/SHAKEN and Robocall Mitigation Database posture, and PCI DSS scope in the voice path.
- Voice quality measurement design using MOS estimated via the ITU-T G.107 E-model and, where warranted, POLQA (ITU-T P.863) scoring — with thresholds agreed rather than guessed.
- Regression and load test coverage across voice and digital channels, including the paths nobody tests because they are inconvenient.
- Production monitoring design: what to watch, what to alert on, and what a real degradation looks like before customers report it.
What you get
- Gap assessment across the three regimes with prioritized remediation.
- Test coverage map and executable test plan.
- Monitoring and alerting specification.
How an engagement runs
Four stages, in order. You can stop after any of them, and the deliverables from each stand on their own.
-
01
Assess
Current-state architecture, circuit and channel inventory, and an honest map of where the failure modes live.
-
02
Architect
Target design, platform decisions, cutover sequencing, and a path your own team can execute.
-
03
Validate
Coverage across paths, not just the happy one. Acceptance criteria agreed before launch, measured against real conditions.
-
04
Enable
Runbooks, measurement, and handover, so ownership sits with your team when we close.