Benjamin Nwandu.Let’s talk
All projects

Reporting & QA operations

Voice Agent Reporting Hub

A reporting system that turns raw voice-agent call logs into client-ready weekly reports — built for a voice AI agency and used on real client accounts.

01 / THE PROBLEM

Why this matters.

An agency running voice agents for several clients has the raw material for a good weekly report — thousands of call rows — and no way to turn it into one. Counting by hand is slow and inconsistent, and each client wants different agents, tabs and thresholds. Meanwhile the numbers in front of a client have to be right the first time.

02 / THE DIRECTION

The solution.

A password-gated internal hub that pulls call logs, classifies each call by tier, outcome, intent and hang-up reason, computes every metric deterministically, and renders a client-facing report. Each client is a YAML file — agents, tabs, column aliases and thresholds — so onboarding a client or an agent needs no code change.

My role.

Designed and built the hub — the data pull, the classification layer, the metrics engine, the report renderer and the review flow. Built for a voice AI agency alongside my QA analyst work. No client names, call recordings, transcripts or caller details appear here or anywhere in this portfolio.

03 / ARCHITECTURE

How the pieces connect.

System flow

  1. 01Raw call logs
  2. 02Classification · tier, outcome, intent
  3. 03Deterministic metrics
  4. 04Draft report
  5. 05Human review
  6. 06Published client report

04 / ENGINEERING DECISIONS

Designed with intent.

  • Configure clients in YAML rather than code, so adding a client or an agent is a config change.
  • Keep all counting deterministic — the model classifies, it never computes a number that reaches a client.
  • Label synthetic demo rows in a visible banner rather than ever showing unlabelled placeholder data.
  • Keep generated output and real client data out of version control entirely.
  • Treat a report as reviewed-then-published, never generated-and-sent.

05 / EVALUATION APPROACH

What needs to hold true.

  • A 511-test suite covering classification, metric counting and report rendering.
  • Verification rules check pulled data before it can reach a report.
  • Every metric is traceable to the rows it came from.

Technology direction.

Python · implementedFastAPI · implementedGoogle Sheets API · implementedClaude · implementedPytest · implemented

Challenges & tradeoffs

  • Client data meant privacy came first: personal data stays out of logs and tool output, and nothing real is shown publicly.
  • Deciding where the model stops — it classifies conversations, but never produces a figure a client reads.

Results

  • Weekly client reporting moved from manual counting to a reviewed, repeatable pipeline.
  • 511 tests covering the classification and metrics the reports depend on.

Let’s build something useful

Good conversations.
Better systems.

Have a conversational AI challenge, an automation idea, or a role in mind?