Your Support Team Is Issuing Discounts With No Ledger

Your Support Team Is Issuing Discounts With No Ledger

Every support inbox issues discounts. Late delivery, damaged item, wrong variant, rude surprise at checkout — the agent reaches for a code to close the ticket. It feels like service. In aggregate it is an uncontrolled discount channel with no owner, no menu, and no expiry discipline.

Ask three questions: who issued what depth last month, at what total cost, and how many recipients bought again at full price? If no one can answer in under a minute, the channel is ungoverned — and it is training exactly the behavior you fear.

How apology discounts become a habit loop

A complaint that reliably produces a code teaches complaint economics. The shopper learns the path; worse, communities learn it too — "message them, they'll send 20% off" travels fast in reviews and forums. Repeat complainers concentrate: a small share of accounts collects a large share of apology value, and first-contact resolution starts to mean first-contact discount.

Agents are not the problem. Discretion without structure is. One agent sends 10% with a 30-day window, another sends 25% with no expiry, a third stacks a code onto a refund. Each ticket closes. The combined cost never appears anywhere because no single discount object ties the issuances together.

The fixed remedy menu

Replace open-ended codes with an ordered menu, cheapest effective remedy first:

1. Fix the order — reship, replace, correct the variant. Solves the problem without pricing anything.
2. Refund the harm — partial refund tied to the specific failure (shipping refunded for late delivery), not a percentage off the next order.
3. Store credit with a window — when a refund is wrong but goodwill is owed. Capped, expiring, single-use, account-tied.
4. Scoped code, last resort — single-use, short expiry, minimum-aware, non-stackable, tied to the account. Never a public string, never reusable.

Order matters. Leading with a code when a reship would have cost less and satisfied more is margin surrender disguised as speed.

Caps, expiry, and the ledger

Every issuance records: reason code, order, agent, depth, expiry, and whether the recipient was a first-time or repeat complainer. Review weekly: issuance per agent, repeat-complainer share, redemption depth, and 90-day full-price repeat of remedied customers vs. a control cohort of similarly affected customers given non-price remedies.

Set hard rules and enforce them in the tooling, not the handbook: maximum depth per reason, maximum issuances per agent per week without approval, no multi-use strings ever, no codes without expiry. If the platform allows it, issue account-tied credits rather than strings — there is nothing to share, screenshot, or index.

Measure service, not closure

Ticket closure is the wrong metric — every discount closes a ticket. Measure repeat complaint rate, cost per resolved ticket (remedy cost plus handling), and downstream full-price behavior. A remedy that closes fast while doubling repeat complaints is not service. It is acquisition of complainers.

The takeaway

Support discounts are discounts. They need what every discount needs: a menu, a cap, an expiry, and a ledger.

Fix the order first, refund the harm second, credit third, code last — single-use, short-lived, account-tied, and recorded. Anything else is a second discount program run by your inbox.

---

Support issuing codes nobody can tally? Connect your Shopify store and Unico will replace open-ended apology strings with a capped remedy menu — recorded, expiring, and measured on repeat full-price behavior.