FIELD · Customer delivery · 4 min read
Customer support with controlled refunds
One refund policy and payment integration, with explicit approvals.
Arunank Sharan · Kuzushi Labs ·
In this article
This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.
Planning basis and engagement boundary
| Item | Basis for this application |
|---|---|
| Demand and context | 200 new conversations/s; six model turns/conversation; five-minute mean duration |
| First delivery boundary | One refund policy and payment integration, with explicit approvals |
| Acceptance to agree and test | One authorized business operation creates at most one refund, including timeout/retry cases |
| Exclusion or constraint | Policy exceptions and changed bank details always escalate. |
F — Frame the outcome
Reduce support resolution effort while preserving refund policy and single-operation money movement; the support and payments owners jointly define eligible automation.
Value measure: Cost per correctly resolved eligible conversation, including review, retries and payment exceptions.
I — Investigate the workflow
Observe order ambiguity, partial refunds, agent review and channel retries. Establish the payment provider's actual deduplication/status contract.
First evidence task: Commit a test refund, drop the response, restart and retry from another channel.
E — Engineer the solution
Use the durable operation ledger, explicit unknown state and deterministic authority checks; derive load from conversation turns and review staffing, not new-conversation rate alone.
The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.
Contract
Define refund eligibility, amount/currency, approval threshold, actor scope and what counts as resolved. Separate policy explanation from payment execution. Six turns/conversation does not mean six simultaneous requests, and the meaning of “turn” must be clarified.
Implementation plan
Conversation service stores messages and task IDs; a policy/tool service exposes bounded order lookup and refund operations. The model proposes an action, but deterministic policy, identity and current order state authorize it. Persist action intent plus stable operation key before payment submission. States include proposed, approved, submitted, unknown, confirmed, rejected and escalated. Notify the user from verified state.
Sizing
Assuming six model-triggering turns for each of 200 conversations/s in steady state gives 1,200 model turns/s before agent subcalls/retries. At 500 input/100 output tokens/turn, illustrative demand is 600k input/120k output tokens/s. If a conversation lasts five minutes, expected active sessions are 60,000. That is session state, not 60,000 active GPU calls. Human review depends on escalation per conversation and handling time, and must be staffed separately.
Timeout after refund
The payment service may commit before the response disappears. Mark unknown, inquire by stable operation/provider ID and retry only under the provider's idempotency contract. A second device uses the same logical refund identity derived from the order/action context, not an unrelated new request. If provider status is unavailable, escalate rather than issue another refund.
Evaluation
Use multi-turn fixtures with policy changes, partial refunds, ambiguous orders, language variation, hostile instructions, duplicate channels and worker crashes. Check actual payment/order state, policy compliance, resolution rate, review workload and cost/success. Permission and monetary invariants are release gates, not weighted away by fluent answers.
Alternative
Start with recommendation-only refunds where humans execute; expand a narrowly eligible automatic subset when the action contract is proven.
L — Launch with evidence
Pilot a bounded refund category. Verify external payment state, review effort, resolution and duplicate behavior before increasing authority or traffic.
Critical decision condition: Duplicate or unauthorized refunds block the relevant action mode regardless of projected savings.
Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.
D — Develop ownership and reuse
Support owns exceptions, payments owns financial reconciliation and engineering owns incidents. Customer operators must resolve a lost response without issuing another refund.
Candidate reusable asset: Refund operation contract and crash-after-commit fixture.
Commercial decision and next commitment
Accountable decision owner: Payments-authorized release owner with support outcome owner.
The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.
Approve only the next exposure level supported by the evidence. The next useful investment is: commit a test refund, drop the response, restart and retry from another channel.
Method and references
Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register.