home case studies

Halving partner query volume through product-led fixes

A contact ratio of 10+ queries per disbursed loan. Treating it as a product metric, not an ops one, cut it by more than half.

Background

I managed a B2B2C loan origination platform serving a large network of DSA and channel partners who sourced, documented, and tracked MSME loan applications on behalf of a lending institution. Partners ranged from large national DSAs to thousands of sub-partners operating across the country.

One of the metrics I tracked closely was what I called the "contact ratio" — the number of queries a partner raised per disbursed loan. Every query represented a failure in the product: something the partner couldn't find, couldn't understand, or couldn't resolve without human intervention. At scale, high contact ratios meant the ops and support teams were overwhelmed, partner satisfaction was suffering, and the cost-per-loan was quietly inflating.

The Problem

When I took ownership of this metric, the contact ratio was running at more than 10 queries per disbursed loan. Partners were regularly raising queries about:

The volume was significant enough that ops teams were spending a large portion of their time managing inbound partner queries rather than processing loans. Partners, in turn, were frustrated by slow resolutions — which affected their trust in the platform and, in some cases, their willingness to continue sourcing leads.

The instinctive fix was to hire more support staff. The right fix was to ask why partners were raising these queries in the first place — and eliminate the need at the source.

The Approach

I treated contact ratio as a product metric, not an ops metric. Every query category was a signal that the product was failing to give partners the information or control they needed, at the moment they needed it.

Step 1: Query taxonomy. I worked with the ops team to categorize inbound partner queries by type, frequency, and stage of the loan journey. This created a ranked list of the highest-volume query types — the ones where fixing the product would have the most immediate impact on contact ratio.

Step 2: Visibility improvements. The single largest query category was application status — partners couldn't see where their loan applications were in the pipeline in real time. I built a live application tracking layer into the platform, surfacing status updates at each stage of the journey (submitted, under review, terms generated, KYC pending, disbursed, declined) with clear, plain-language explanations for each state — including decline reasons, which had previously required a support call to obtain.

Step 3: Self-serve documentation correction. A significant portion of queries were about correcting documentation errors after submission. I built a self-serve document re-upload and correction flow, allowing partners to fix errors without raising a support ticket and without waiting for an ops agent to intervene.

Step 4: Payout transparency. Commission and payout queries were the second-largest category. I built a real-time payout dashboard showing partners the status of each payout — disbursed, processing, settled — along with the calculation breakdown for performance slab-based commissions. This eliminated the need to query ops for payout status or commission reconciliation.

Step 5: In-platform guidance. For query types that couldn't be fully eliminated through self-serve (FI verification timelines, co-lending status), I added contextual in-platform guidance — explaining what each stage meant, what the expected timeline was, and what action, if any, the partner needed to take.

Results

Metric Before After
Partner queries per disbursed loan 10+ queries Under 5 queries
Contact ratio reduction More than 50% reduction
Ops time spent on inbound partner queries High Significantly reduced
Partner satisfaction Frequent escalations Materially fewer escalations

Key Takeaways

Contact ratio is a product metric, not an ops metric. Every query a partner raises is a product failure — a gap between what the partner needed to know and what the platform surfaced. Treating it as an ops workload problem leads to hiring more support staff. Treating it as a product problem leads to eliminating the query at the source.

Visibility is the highest-leverage fix. Across every query category I analyzed, the most common root cause was the same: the partner couldn't see what was happening. Real-time status, plain-language explanations, and proactive notifications eliminated more queries per unit of effort than any other intervention.

Self-serve beats support at scale. When a partner network is large enough, even a small reduction in query rate per partner has a compounding effect on ops load. Self-serve correction flows and payout dashboards scaled naturally with partner growth — unlike support headcount, which doesn't.

Share
All case studies
✉️ Email me 𝕏 Twitter