Designing a refund procedure Fin can actually finish at Loomis Subscriptions
Loomis Subscriptions sells three annual and two monthly plans. Refund policy is rule-based: eligibility depends on the subscription start date, the plan, usage during the period, and whether the customer has already received a refund in the past 12 months. Refunds under $50 can be issued directly by support; anything above requires a manager. Agents check four things across a billing admin tool, a usage dashboard, and a CRM record - typically six to eight minutes per case.
Fin resolves 48% overall but only 9% on refund conversations, which are 22% of total volume. Fin currently answers refund questions by quoting the public policy article, and customers then reply with their specific dates and ask 'so am I eligible?'. Agents report that the article is technically correct but the customers never accept it as an answer. There is currently no integration between Fin and the billing system.
1. Is this a content problem, a procedure problem, or a guidance problem? Decide and justify, including why better articles will not move the 9%.
Read the worked answer
It is a procedure problem, with a small guidance layer.
The tell is in the customer behaviour: they read the policy and immediately ask 'so am I eligible?'. The question is not what is the policy - the article answers that. The question is what is my status under the policy, which requires reading four data points from three systems and applying rules. No article, however well written, can answer a question whose answer lives in the customer's account.
Why each alternative fails.
- More articles: improves comprehension of the policy but leaves the customer doing the eligibility calculation. The 9% will not move meaningfully.
- Guidance alone: shapes tone and phrasing but cannot fetch a start date. Fin would still have to guess or defer.
- A procedure: encodes the steps - verify identity, retrieve the four data points, evaluate the rules, branch on the refund amount, execute or escalate, confirm with a reference. That is the only structure that lets Fin finish the job rather than hand it back.
The remaining guidance has a real but secondary role: how to phrase a denial, how to acknowledge frustration, and the exact language for the $50 threshold. But policy phrasing is not the bottleneck.
One caution: this procedure issues money. The design should optimise for never over-refunding over maximising Fin's completion rate. A 60% completion rate with zero policy breaches is a better outcome than 90% with three bad refunds.
2. Design the procedure's steps, including the branches and the failure paths. Where must Fin stop rather than improvise?
Read the worked answer
Steps.
- Trigger and identify. Intent is refund; confirm account identity and the subscription in question before any lookup. Never proceed on an unverified email address.
- Retrieve. Call the billing system for start date, plan, and amount paid; the usage dashboard for consumption; the CRM for prior refunds in 12 months. If any call fails, stop - do not substitute what Fin 'remembers' from the article.
- Evaluate. Apply the four rules. Conflicting data (e.g. billing and CRM disagree on a prior refund) is a stop condition, not a judgement call.
- Branch on amount. Under $50 and eligible: issue the refund, then confirm with the amount, the reference, and the expected timeline. That confirmation step is part of the procedure, not an optional nicety.
- Branch above $50: assemble a summary - eligibility findings, amounts, dates - and hand off to a manager with the data pre-filled, telling the customer what happens next and when.
- Branch ineligible: explain which specific rule excluded them - not the whole policy - and offer the appropriate next step.
Hard stop conditions.
- Any API timeout or partial data.
- Any data conflict between systems.
- Customer disputes the usage figures.
- Any request that reads as a threat of chargeback, legal action, or regulatory complaint.
- Any hint of a negotiated or contractual arrangement.
In every stop case: tell the customer a person is taking over, set the state, and assign with the retrieved data attached. Silence and a queue is a failure mode, not a handoff.
3. How would you test this procedure before and during rollout, and what would make you switch it off?
Read the worked answer
Before rollout - offline, on real history. Pull 200 historical refund conversations with known correct outcomes. Replay them step by step and score: correct eligibility decision, correct branch, correct amount, and - critically - zero cases where the procedure would have refunded someone who was not eligible. False negatives (Fin declining an eligible customer) are a CSAT problem; false positives are a financial and audit problem. Weight them accordingly when deciding whether it is ready.
During rollout - bounded and observable. Start with a small audience, monthly plans only, and a capped refund authority well below the $50 ceiling. Instrument every step: entry rate, per-step completion, drop-off point, API failure rate, and handoff path. The per-step drop-off is the most useful number - if 40% of customers abandon at identity verification, the procedure has a design problem, not a content problem.
Weekly reconciliation. Finance's refund ledger against procedure-issued refunds, line by line, for the first month. Any discrepancy pauses rollout immediately. Reconcile the process, not just the total.
Switch-off triggers, agreed in advance:
- Any refund issued outside policy.
- Any refund issued on an unverified account.
- Fallback-to-human rate above an agreed ceiling (it means the integration is unreliable and the experience is worse than no procedure).
- A CSAT drop on refund conversations versus the manual baseline.
Then optimise. Once the procedure is stable, the largest remaining gain is usually entitlement language and a clear explanation for denials - the 22% of volume stays the same, but the completion rate moves. Review monthly, not weekly, since refund behaviour is seasonal.