Five lessons, about an hour and five minutes. Every support role eventually comes down to this: a written policy, a specific customer, and a decision only a person can make well. This module is about reading a policy the way it's meant to be read, and knowing exactly where your own judgement is supposed to start.
Most support reps read a returns policy once, remember the gist, and answer from memory after that. This is how "30 days" quietly becomes "about a month" in someone's head, and how a customer at day 33 gets refused for something the actual policy might have allowed under a clause nobody reread.
A policy is not a vibe you remember. It's a document with edges, and the edges are where the real questions live.
Read for the exact numbers (is it 30 days from purchase, or from delivery — these are different dates and the gap between them matters at the edge). Read for named exceptions (some brands' policies exclude sale items, or make an exception for a manufacturing defect regardless of the window). And read for what the policy doesn't say — a genuine gap, which is different from an unfavourable answer, and is exactly where lesson 5.3's escalation judgement applies.
"Items may be returned within 30 days of delivery, except sale items, which are final. Products with a manufacturing defect may be returned at any time within 6 months, regardless of sale status."
A sale item, bought 40 days ago, with a broken pump: reads as "final sale, too late" on a fast skim. Read properly, it's a defect claim, not a change-of-mind return — a completely different clause, with a 6-month window, applies.
Find a real return policy — any brand's, publicly posted — and write down its exact window, what date it counts from, and any exception clause you find.
Some refund requests need a genuine check — a photo of the damage, an order number that matches, a claim that seems inconsistent with the shipping record. Asking for that verification is completely reasonable. Asking for it in a way that implies the customer is lying is how a legitimate request turns into a lost customer, even when the refund is eventually approved.
Frame the ask as routine process, not suspicion of this specific person. "Could you send a quick photo of the damage? — it's just so I can flag the batch to our supplier" does real verification work while giving the customer a reason that isn't "I don't believe you."
"We'll need to see proof of the damage before we can process anything."
"So sorry about that! Could you send a quick photo when you get a chance? It helps me flag the batch to our supplier so it doesn't happen again — I'll get your refund started as soon as I see it."
Notice the second version also tells the customer what happens next and why the photo matters beyond just proving their claim — it becomes useful information for the brand, not a hoop to jump through.
Rewrite an accusatory-sounding verification request into a routine-sounding one, using the worked example's shape.
Not every judgement call is yours to make alone, and knowing the line matters as much as having good judgement in the first place. A rep who escalates everything is nearly useless; a rep who never escalates anything eventually gives away money, stock, or trust the brand didn't authorise.
The same request can sit in different tiers depending on the brand and the amount — a ₦5,000 goodwill discount might be squarely tier one at Bumi Naturals, and tier two the moment it's ₦50,000. Know your own thresholds, in writing, rather than guessing them fresh each time.
Asking unnecessarily costs a founder a few minutes. Guessing wrong on something with real money or reputation attached costs considerably more — the same principle Course 01's escalation lesson applies to a virtual assistant's work.
Sort five real or made-up refund requests into the three tiers, and write your reasoning for each.
A free gift, a discount, an extra item thrown in — goodwill gestures genuinely work to keep a frustrated customer. They also, used carelessly, teach a customer that complaining is the fastest way to get something free, which creates more complaints rather than fewer.
A goodwill gesture answering a real, verified problem builds loyalty. A gesture handed out because a customer sounded annoyed, with nothing actually wrong, teaches the wrong lesson. The distinction isn't about being generous or stingy — it's whether the gesture is responding to a genuine issue or to volume of complaint alone.
A verified late delivery, first time for this customer. A small discount on their next order, offered without being asked, alongside the apology. Reads as generous, unprompted, and tied to something real.
A customer complains loudly that a product "isn't as described" with no specifics, and immediately asks what compensation they'll get. A free item handed over here, with nothing actually verified, is noticed — and repeated next time.
Write one situation where a goodwill gesture is clearly earned, and one where it clearly isn't, using the same brand for both.
An exception granted and never written down doesn't stay an exception for long. The next rep sees the order history, notices a refund was approved outside policy, and — reasonably, with no other information — assumes that's now how it's done. Module 5's whole discipline collapses one undocumented exception at a time.
The specific clause or window that was set aside, the reason, and — critically — that it was a one-time exception rather than a new rule. Two lines is usually enough.
"Order #2311 — refunded a sale item at day 40 (outside the 30-day window and normally final-sale). Exception: 3-year repeat customer, documented family emergency delayed the return. One-time — does not set a new policy."
Write a log entry for the exception you granted in 5.3's drill or 5.4's worked example, in the shape above.
Ten refund and return requests are supplied, checked against Bumi Naturals' actual return policy. Some are clearly within policy, some clearly outside it, and several sit right on an edge deliberately.
Whether policy, verification, escalation judgement and documentation all show up together on the same request — not any one of them in isolation.
You should now have: a habit of reading a policy's actual clauses, a routine-sounding verification shape, a three-tier escalation key with your own thresholds, a goodwill test, and an exception log. Module 6 turns to the knowledge base itself — where these answers should live so the fifth rep to ask doesn't need you personally to get it right.