Part 7 · 8 chapters · ~40 min

Support: the feedback loop you are ignoring

Analytics tells you what someone did. A support contact tells you what they could not do, in their own words, with enough frustration to write in. It is the highest-signal product feedback an organisation produces and the least read, and roughly one in twenty affected customers bothers to contact you, so every ticket stands for about twenty silent ones.

Support volume as a product signal

the question

“Why is engineering reading support tickets?”

worked numbers

support volume is the highest-signal, least-read
product feedback an organisation produces.

  an analytics event tells you what someone did
  a support contact tells you what they could not do,
    in their own words, with enough frustration to write in

and roughly 1 in 20 affected customers actually contacts you,
so every ticket represents about twenty silent ones.

what contact volume reveals that nothing else does

Confusion, which no error metric captures. A feature that works perfectly and is not understood generates contacts and zero errors.
Silent failures. Part 13 of the CBA module made this point: a handler returning 200 with a rejection body improves every technical signal. Support is the detector of last resort.
The gap between the model and the mental model. "Why is my balance different from my available balance" is a Part 5 design surfacing as a support cost.
Which of your edge cases are actually common. The case you thought was rare has forty tickets a week.

the practice worth adopting

Every engineer reads support tickets for an hour a month, unfiltered. Not a summary, not a dashboard: the actual words. It is the cheapest source of product insight available and it consistently changes what people build. Teams that do this stop arguing about what users find confusing, because they have read it.

Tiering, escalation, and the engineering interface

Tier	Handles	Needs from engineering
Self-service	FAQ, in-app help, status page	Accurate, current content
Tier 1	Common cases, account questions	A read model and scripted actions
Tier 2	Complex cases, disputes, investigations	Deeper tooling, transaction tracing
Engineering	Genuine bugs, data issues	A clean escalation with context
Specialist	Fraud, compliance, legal	Case management, evidence

what makes the engineering interface work

A structured escalation form, not a forwarded email. Account id, journal id, what was expected, what happened, what has already been checked.
A rota, not an interrupt. One engineer on support duty per week, so escalations do not fragment the whole team.
An SLA both directions. Engineering responds within a stated time; support provides the required context before escalating.
Escalation volume is a metric. Rising escalations mean either tier 2 tooling is inadequate or the system has a new problem.

the anti-pattern

Engineering as tier 2. When agents escalate anything non-trivial because their tools cannot answer it, engineering becomes the support team and stops building. The fix is tooling, not a stricter escalation policy, and the escalation rate is the measurement that tells you which it is.

Tooling: what agents need and never get

the tools that eliminate the most escalations

A unified customer timeline. Every event in order: logins, transfers, notifications sent, restrictions applied, support contacts. Most escalations are "what happened to this customer" and this answers it.
Transaction detail with state. Where is this payment right now, what state is it in, what happens next, and when. Part 6's state machine, rendered for a human.
The "why" for every decline. Part 18 insisted the limit resolution reports its binding source. An agent who can say "your tier-2 daily limit, resetting at midnight" resolves the call; one who can only say "declined" escalates.
Scripted safe actions. Resend a notification, release an expired hold, refund a fee within a cap. Bounded, audited, no engineering required.
Search that works. By phone, email, account number, transaction reference, amount and date.

the return on investment

Support tooling is consistently the highest-ROI internal engineering work and consistently the least prioritised, because its beneficiaries are not in the room when priorities are set. A week of tooling work that removes 30% of escalations pays for itself in a month, and it is measurable, which makes it one of the easier arguments to win if anyone makes it.

The read model for support, and its access controls

design constraints

Read-only by default, with a small set of explicit, audited write actions.
Built on the serving layer, per Part 11, never on the ledger. Support queries must not compete with the money path.
Field-level masking. An agent needs the last four digits, not the PAN, and usually needs a name rather than a full address.
Purpose capture. Viewing a record asks why, tied to a ticket. This is what makes anomaly detection on access possible.
Rate-limited per agent, per Part 3, so bulk browsing is detectable.
Every access logged to the immutable audit store, which Part 9 monitors.

the balance to get right

Too restrictive and agents cannot help, so they ask engineers, who have unrestricted access and no purpose capture. The restriction has then made things worse: the access happened anyway, with less accountability. Give agents enough access to do the job, with full audit, rather than too little access and an informal back channel.

Contact-driven development

worked numbers

the loop most organisations do not close:

  contact → categorised → counted → reported → filed

the loop that works:
  contact → categorised → counted → ranked by volume × cost
  → top causes enter the engineering backlog
  → fixed → volume measurably falls → next cause

the difference is whether contact reasons compete for
engineering time on the same backlog as features.

making it concrete

Categorise by cause, not by symptom. "Cannot complete transfer" is a symptom; "declined by tier limit and did not understand why" is a cause you can fix.
Cost each category. Volume times average handling time times loaded cost, plus churn where it applies. A category costing ₦4m a year is a prioritisation argument.
Present the top five monthly, with the trend, at the same meeting as the scorecard from Part 0.
Measure the fall after a fix. If contact volume for that cause does not drop, the fix addressed the symptom.

Deflection, and when it is hostile

Deflection	Legitimate when	Hostile when
FAQ and help content	It genuinely answers	It is a maze that never resolves
Chatbot	It resolves or routes fast	It is a barrier before a human
In-app status	It is accurate and current	It says all systems normal during an outage
Fixing the cause	Always	Never
Hiding contact options	Never	Always

the distinction

Deflection that resolves the need is good product. Deflection that prevents contact without resolving anything is cost-shifting onto the customer, and in a regulated business it also generates complaints, which are more expensive than the support contact would have been. The metric to watch is resolution rate rather than contact rate: driving contacts down while resolution falls is making things worse and reporting it as an improvement.

the one deflection that is always right

Proactive notification. Telling a customer their transfer is delayed, before they notice, removes the contact and improves trust simultaneously.
Part 12 built the mechanism. A payment sitting in settle_suspense past its threshold is exactly the trigger for "this is taking longer than usual, here is what is happening".
It is the only deflection where the customer is better off, which is the test.

Complaints, regulators, and the paper trail

what makes a complaint different from a support contact

Regulatory definition and clock. In many jurisdictions a complaint must be acknowledged and resolved within statutory periods, and the clock starts at receipt rather than at recognition.
It must be recorded as a complaint, even if resolved immediately. Under-recording is itself a finding.
Escalation rights. The customer can go to an ombudsman or the regulator, and their file will be compared against yours.
Root cause reporting. Regulators ask for complaint volumes by category and what was done about them.

the engineering consequence

The systems that handle complaints need the same rigour as the money path: immutable records, accurate timestamps, complete evidence and reproducible reporting. Part 8 of the CBA module made this point about disputes and the deadline queue. A complaint that was resolved well but recorded badly is a regulatory problem regardless of the outcome for the customer.

Closing the loop into engineering priorities

the mechanism, concretely

A standing agenda item at the same monthly review as the Part 0 scorecard. Top five contact causes, costed, with trend.
A committed share of capacity. Not "we will get to it": a stated percentage of each cycle, the same way maintenance is budgeted in Part 8.
Named ownership per cause, so it is somebody's to reduce.
The measurement is the contact volume, not the ticket being closed. A fix that does not reduce contacts did not fix the cause.
Escalation rate and resolution rate on the scorecard, because they measure whether tooling and product are keeping up.

the argument that wins the capacity

Costed. "Tier-limit confusion generated 4,200 contacts last quarter at ₦1,100 each, which is ₦4.6m a year, and a week of work on the decline message removes most of it." That is a return-on-investment argument in the language the business already uses. "Support says customers are confused" is not, and it loses to a feature every time, which is usually an articulation failure rather than a prioritisation one.