Skip to content
JUSTIN BARRETT

Work

From call recordings to call intelligence.

Integrated systems gained transcripts and call analysis—lead quality, advisor effectiveness, and customer-support context—in place of a basic list of recordings.

Role
Sole developer · end-to-end application
Context
Professional work · multiple integrators
Technologies
PHP, Laravel, React reporting embeds, AI transcription

A call recording tells the whole story—if someone has time to listen. I built a service that turns those recordings into transcripts, summaries, and structured analysis that other applications can actually use.

The problem: recordings without context.

Integrated systems could list calls, but understanding what happened still meant manually listening to a recording—or going without sentiment analysis altogether. A call log could show that a conversation happened without explaining the quality of the lead or how effectively the advisor handled it.

The opportunity was to make that information useful inside the systems people already worked in, while keeping reporting available in the analysis application itself.

My contribution: the complete application.

I designed and built the service end to end: the recording submission workflow, transcription and analysis, webhook responses, reporting, and the application interface. It serves multiple integrators rather than a single consuming application.

OWNERSHIPEnd-to-end development

Service application · integrations · analysis workflow · reporting · interface

The application is built with PHP and Laravel, with React reporting embeds. AI handles transcription; the service connects that processing to the integration and reporting workflow.

A recording goes in. Useful data comes back.

  1. 01 / SubmitRecording link

    An integrator submits a link to a call recording.

  2. 02 / ProcessTranscription

    The service transcribes the call into text.

  3. 03 / AnalyzeContext & metadata

    Analysis extracts sentiment, keywords, and a summary.

  4. 04 / DeliverWebhook response

    Text/JSON transcripts and sentiment metadata return to the requesting system.

Functional workflow based on the implemented service. This shows the data flow, not a deployment architecture.

Integrators receive results through a webhook instead of being limited to a list of recordings. The application also supports reporting through multiple query vectors, so the analysis remains useful beyond a single call or a single integration.

Making the analysis readable.

The interface brings together sentiment, lead quality, advisor performance, appointment status, and phone-coaching metrics. The purpose is to make a recorded conversation easier to assess: what kind of lead was it, how was the call handled, and what happened next?

INTERFACE DETAILExample call
Call sentimentPositive 72 / 100

72 out of 100

0 / Negative50 / Neutral100 / Positive
Lead quality72/ 100
Advisor performance73/ 100
Appointment statusNo appointment
Filler words9.5per minute
Talk speed147words / minute
Response time5.9seconds average latency
Interface detail recreated from neutral sample data. Values describe one example call.

The hard part: multiple integrators, one reporting service.

The central engineering challenge was isolating data across multiple integrators well enough to support reporting from the service itself. Each integration needed its own data context, while the application still needed to answer reporting queries.

Each integrator supplies its own reference for the account or location associated with a call, along with the ID of the call record in its own system. Those references give the service a way to associate analysis with the correct external context and support reporting queries.

The reporting reference model

Account / location reference
The integrator’s reference for the business context associated with the call.
Call-record ID
The integrator’s identifier for the original call record.
Combined queries
Any or all supplied references can be used as reporting query parameters.

I kept reporting in the service so integrators did not need to maintain redundant copies of the analysis data just to report on it. The integrator’s existing identifiers connect the reporting back to its own records.

The decision that shaped the application

Deliver the results.
Keep reporting close to the data.

Webhook delivery puts analysis into the requesting system. Reporting in the service avoids requiring a second reporting dataset in each integration.

The result: more than a call log.

Integrated systems moved from simply listing calls to providing data about lead quality and effectiveness on the phone—both in closing leads and supporting customers. Transcripts and analysis gave those systems a way to expose the content and context of a conversation.

The change was concrete: a recording no longer had to be manually reviewed before someone could get useful information about the call. The service produced structured results for the integration and retained reporting capability in the application.