Revenue Engineering

Case Study: Replacing One Company Average with 28 Branch Reports

A calling platform reported a single number for the whole network. Pulling its API into per branch reporting changed what managers could do about it.

Mauricio Esparza By ·Published ·2 min read
mithub.club
Short answer

A consumer finance network could see one company wide number for its AI calling operation. A branch manager cannot act on an average that includes 27 other branches. Pulling calls, outcomes and transfers from the platform API into a report per branch changed the weekly conversation from how the AI is doing to why one branch converts at half the rate of another, which is a question with an answer.

A deployment write up, anonymised. The company is a consumer finance network in the United States with branches. The name is withheld because publishing it requires the client's approval.

The situation

The AI calling operation was running across the network and there was one number to describe it: a company wide average, taken from the calling platform's own view.

Everybody looked at it in the weekly meeting. Nothing changed for weeks, and not because people were not trying.

Why an average does not work here

A branch manager reading a number that includes 27 other branches learns nothing about their own market, their own calling hours or their own team's response to transfers.

Worse, the average hides the thing that matters most in a network: the spread. Two branches at opposite ends of the distribution can produce a perfectly reasonable looking middle.

What was built

Calls, outcomes and transfers pulled from the calling platform's API into a report per branch, showing:

  • Dials, connects and connect rate for that branch
  • Live transfers, and how many were answered
  • Outcomes by category
  • All of it next to what was expected for that branch

The technical work was straightforward. The work that mattered was deciding what each branch should see and what to compare it against, because a report nobody can act on is easy to produce and worth nothing.

What it revealed

Three things, in order of surprise:

The spread was much wider than the average implied. Some branches were converting transfers at several times the rate of others.

Most of the causes were operational rather than about the AI. Calling windows set for the wrong local hours. Transfer lines nobody was answering during certain shifts.

Some branches had stopped answering transfers entirely, which no company wide number would ever have shown.

What changed in the meeting

The question went from "how is the AI doing" to "why is this branch at half the transfer rate of that one".

The second question has an answer. Usually the calling window, sometimes the transfer line, occasionally the script. All three are fixable in a week by someone who can see them.

The general rule

Report at the level where somebody can act.

A number that reaches a person who cannot change what it measures is decoration. This is true well beyond calling platforms, and it is the most common reporting failure in multi unit businesses of every kind.

The cadence that worked

Weekly for operations, which is fast enough to change a calling window and slow enough to be more than noise. Revenue attribution stayed quarterly, because it needs enough closed deals to be signal rather than variance.

Frequently asked questions

Why not use the platform's own dashboard?

Platform dashboards report the platform's view, which is usually the whole account. The unit that matters operationally is whoever can change something, and in a branch network that is the branch.

What did the per branch view reveal?

Mostly that variation between branches was much wider than the average suggested, and that the causes were operational: calling windows set wrong for the market, and transfer lines that were not being answered.

Is this hard to build?

Not technically. The work is deciding what each branch should see and what to compare it against. A report nobody can act on is easy to produce and worth nothing.

What is the reporting cadence?

Weekly for operations, because that is fast enough to change a calling window and slow enough to be more than noise. Attribution to revenue needs a quarter.

Sources

  1. Building effective agents · Anthropic (accessed 2026-09-22)
  2. Why evaluate AI workflows · n8n Docs (accessed 2026-09-22)
  3. Handle errors gracefully · n8n Docs (accessed 2026-09-22)
Revenue EngineeringCase StudyReporting
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of Revenue Engineering on MitHub.

Keep going

Revenue Engineering

What to Measure in GTM Automation (and What to Ignore)

The metrics that tell you whether an automated revenue system is working, the vanity numbers that hide failure, and the one check that catches silent breakage.

Read · 2 min →mithub.club
AI & Automation

Rolling Out AI Calling Across a Branch Network

What changes when an AI calling pilot has to work in thirty locations: treating a branch as a configuration, the compliance gate, branch level reporting and the QA that keeps it honest.

Read · 3 min →mithub.club
Revenue Engineering

A Two Hour Audit of Your Revenue Process

A self audit any leader can run without tools or consultants: ten leads, six questions, and the leak becomes obvious.

Read · 2 min →mithub.club
AI & Automation

AI Calling for Consumer Lenders with Branches

How a multi branch lender puts AI on the phone without breaking compliance or the branch relationship: which lists to call, what the agent should and should not do, and how each branch sees its own numbers.

Read · 2 min →mithub.club
Revenue Engineering

Revenue Attribution Without the Hype

What revenue attribution can and cannot tell you: the models, a worked example across first touch, last touch and linear, the limits, and what to do instead.

Read · 7 min →mithub.club
GTM Engineering

Hiring a GTM Engineer Remotely: The Practical Guide

How to hire a GTM engineer remotely: what the role is accountable for, how to write it around one number, what to ask, and the paid trial that avoids a bad contract.

Read · 4 min →mithub.club