Travis Dorso

The Customer Problem

A logistics company used an inbound voice agent to handle delivery tracking and scheduling for purchases made through multiple retailers. Containment had stayed flat for most of a year. The customer needed to understand whether failures originated in the agent, its own systems, or the reporting before deciding what to change.

The Evidence

I traced caller-to-order match rates across the year and separated the results by retail client. One client’s match rate fell to zero while another’s dropped sharply. I checked the timing against several independent records and confirmed the finding with the customer’s head of customer experience.

Recommendations and Follow-Through

The customer’s coverage tables had fallen out of sync. Failed order lookups left the agent unable to complete the request. I developed recommendations with supporting counts, including two changes the customer had already requested in writing. Those recommendations became Jira stories. I also owned verification of the fix against live traffic.

The investigation contributed to expansion into a second division. Engineering owned the fixes; sales owned the resulting deal.

Setting Priorities From Patient Demand

The initial agent handled a limited set of self-service tasks and captured messages for office staff. I classified patient requests to identify where additional capabilities would address the most demand. Appointment changes stood out, giving my recommendations for cancellation and rescheduling a basis in actual calls.

Giving the Customer an Accurate Account

I reviewed calls, ticket records, and reported outcomes across releases. Successful ticket delivery did not always mean the office received accurate information, and some completion flags did not match the patient’s actual outcome. I exposed incorrect patient classifications and premature completion flags, documented the affected calls, and recommended corrections. My readouts brought these gaps into customer discussions alongside what was working, giving the customer a clearer basis for setting priorities.

Finding Why Appointment Changes Failed

As live cancellation and rescheduling became available, I traced incomplete requests through patient identification, appointment lookup, scheduling eligibility, available times, and patient choice. I separated integration failures from business rules and cases where patients declined the available options. That gave engineering and the customer specific causes to address.

Identifying Opportunities for Broader Use

I connected unmet appointment demand to the capabilities and integration requirements needed to serve it. This gave the customer and internal teams a concrete basis for discussing broader use of the service. I measured completion against eligible requests and assessed the caller experience separately, so those discussions reflected both what the service could support and where it still fell short.

As the service expanded, my production reviews confirmed live cancellations, successful rescheduling, and patients choosing a new time instead of canceling. I continued documenting unresolved failures and remaining office follow-up, keeping the customer informed about progress and the work still needed.

The Question

A healthcare provider was replacing Asterisk answering-machine detection with AI detection in batches. Leadership needed to know whether the switch improved connections. New call lists went live at the same time, making attribution difficult. Recording was prohibited, so the investigation depended on call dispositions.

The Method

I defined connection rate as Transferred ÷ (Live Answer + Transferred). I compared switched campaigns with campaigns still using Asterisk during the same weeks and stated what each campaign’s call volume could reliably show.

The Result and Its Limits

The improvement persisted across two weeks in the switched campaign. Two smaller campaigns had too few calls to support a conclusion. The new lists remained a competing explanation, so I reported a positive indicator with that limitation clearly stated. The available evidence did not establish causation.

I delivered a formula-based calculations workbook, methodology document, internal readout, customer email, and executive slide. Engineering and the customer owned the cutover.

The Customer Problem and Review

A medical group had launched an agent for appointment confirmation, cancellation, and rescheduling. I evaluated whether the application and supporting systems could complete those workflows under the customer’s operating rules. Production records and experience scoring helped isolate design gaps, integration problems, and misleading reporting.

Where Requests Failed

When a phone number did not identify a patient, the agent requested another number and transferred. It offered no date-of-birth fallback. Some identified patients still could not complete a request because appointments had been moved or canceled, or were outside the agent’s permitted scope. Customer eligibility rules and transfer timing also affected the results.

A separate carrier issue stripped caller ID before calls arrived, contributing to verification failures. In reporting, a transfer flag could not distinguish required transfers from requests for a person. A change in intent tagging also invalidated a two-week comparison.

What the Work Produced

I sent daily internal and customer readouts, routed reporting corrections to analytics, experience issues to QA, and design improvements to engineering with supporting counts. The caller-ID finding went to a carrier investigation.

Measurement Correction and Remaining Work

I measured containment against eligible self-service requests and treated rescheduling transfers according to the configured business rules. The redesign and carrier fix remained open when my assignment ended.

This corrected the containment calculation so the reported rate reflected eligible self-service requests and the configured transfer rules.