Skip to content
English
Sign in
Go to eatclub.com.au
  • There are no suggestions because the search field is empty.

Refund Request | Customer Support Investigation Steps

Goal: To provide a consistent, auditable process for investigating refund requests and determining the correct outcome (refund, credit, deny, or escalate) while maintaining customer trust and identifying systemic issues.

Common Scenarios

Scenario: Wrong Card Selected / Mis-Tap (Paid Venue Directly)
  • Signals: No EatClub payment/decline logs for that venue/time; refund hub shows no tap events; bank statement shows only venue name.
  • Root cause: Customer tapped personal card instead of EatClub card.
  • Outcome: Refund discount amount they should have received; explain wallet card selection; often add small dining credit for first-time users.
  • Response tone: Educate on how to select the correct card next time; acknowledge the confusion.
Scenario: POS Exclusions / Best-Value Adjustment (Bill Changed After Tap)
  • Signals: Slack shows tap amount differs from final adjusted bill; POS Hub shows excluded/special items; venue page lists exclusions/in-house specials.
  • Root cause: System correctly applied best-value policy; excluded items were not eligible for the EatClub discount.
  • Outcome: Usually "worked as designed"; explain best-value logic via CLEARR framework; often add goodwill credit due to surprise/confusion.
  • Response tone: Explain the win-win logic (why venues exclude items), show them how to check exclusions before ordering next time.
Scenario: Terminal Mismatch / Wrong Venue Location
  • Signals: Decline channel shows terminal name doesn't match redeemed venue/branch; customer reports repeated "card not accepted/try again" then paid normally.
  • Root cause: Customer tapped at wrong location (e.g., Subway Garden City instead of Subway Westfield).
  • Outcome: Redeem correct venue offer; process refund/manual adjustment for failed attempt per policy; explain how to avoid wrong-location taps.
  • Response tone: Apologise for the confusion; guide them to the correct location next time.
Scenario: Venue Terminal Issue / System Fault
  • Signals: Repeated complaints + little/no successful EatClub payments for that venue over a period; wallet may show declines but logs show nothing or only failures.
  • Root cause: Venue terminal not configured, vault migration issue, or terminal not recognising EatClub card.
  • Outcome: Treat as tech fault; process appropriate refunds; add generous credit; escalate with examples + timestamps to tech team.
  • Response tone: Apologise; assure them it's a venue-specific issue, not their fault; let them know we're fixing it.
Scenario: Ghost Tap / Ghost Decline
  • Signals: Wallet shows a decline/tap, but no corresponding log/tap event in our system; customer sees decline on their card but we see nothing.
  • Root cause: Payment declined before reaching our system; card provider issue or vault migration problem.
  • Outcome: Escalate to tech team immediately. Something is not communicating between systems.
  • Response tone: Acknowledge the issue; assure them we're investigating with our payment provider.
Scenario: Double Payment (Paid EatClub + Venue Directly)
  • Signals: Customer says they paid twice; bank statement shows two charges; Slack logs show both a successful EatClub tap and a venue charge.
  • Root cause: EatClub payment went through, but customer also paid venue directly (either didn't realise payment succeeded, or terminal issue made them think it failed).
  • Outcome: Escalate if this is a systemic issue. For individual cases, process double refund (refund EatClub payment + Stripe payment). Add generous credit.
  • Response tone: Apologise for the confusing experience; explain what happened; assure them we're making it right.
Scenario: Deal-Share Complexity
  • Signals: Customer says they shared a deal; you can't find their redemption on their account; payment logs show a tap but no matching deal owner.
  • Root cause: Deal was shared with another user; the sharer (not the deal owner) is requesting the refund.
  • Outcome: Find the deal owner's transaction; verify the sharer's portion; confirm they paid separately. Escalate if unclear.
  • Response tone: Acknowledge the complexity; ask for clarification if needed; process once you've verified the details.
Scenario: Paid Outside Payment Window (Far Outside)
  • Signals: Deal window was 5–6pm; customer paid at 10pm; receipt shows late arrival time.
  • Root cause: Customer arrived/paid well outside the deal window.
  • Outcome: Usually deny; explain venue fairness and why timing rules exist. Small voucher as goodwill only if warranted.
  • Response tone: Respectful but firm; explain why restaurants post time-limited deals; educate on arrival time importance.
Scenario: Paid Outside Payment Window (Slightly Outside, Broad Deal)
  • Signals: Deal window was 4:30–9pm; customer paid at 9:15pm; first-time user.
  • Root cause: Customer slightly outside window, but deal is broad and venue likely still benefits.
  • Outcome: Often justify a one-time exception + education.
  • Response tone: Acknowledge the timing; explain the rule; offer the refund as a one-time courtesy; educate for next time.
Scenario: Insufficient Funds / Card Declined by Bank
  • Signals: Tap event shows decline; decline reason is "insufficient funds" or "bank decline"; customer may have loaded funds after and tried again.
  • Root cause: Customer's linked card didn't have enough funds; bank declined the transaction.
  • Outcome: Refund the discount amount; explain that they need to ensure funds are available on their linked card.
  • Response tone: Neutral; explain the issue; offer the refund; educate on ensuring funds are available.

Detailed Steps & Checks

1. Triage & Initial Assessment

When a refund request arrives, quickly capture the essentials:

  • Confirm the request type: Refund request, "card didn't work," charged wrong amount, double charge, POS exclusion/best-value confusion, or other billing issue.

  • Assess urgency: Very upset tone or long wait time → treat as higher priority.

  • Capture minimum details:

    • Venue name and location.
    • Date and approximate time of transaction.
    • Amounts: bill total, amount charged, any second charge.
    • Evidence provided: receipt photo, bank/wallet screenshots.
    • What they tried: EatClub card vs personal card; exact error message ("declined," "card not accepted," "try again," etc.).

  • Form initial assumptions:

    • Receipt provided → likely dined and paid; investigate if EatClub discount flow applied correctly.
    • First-time user → mis-tap, wrong card, or payment window misunderstanding more likely.
    • Experienced user with sudden failure → venue/terminal/system issue more likely.
    • Regardless of fault, optimise for de-escalation and customer education.

2. Investigation Workflow (Recommended Order)

Use this as a checklist. Stop once you have enough evidence to decide and respond. Not every step is needed for every ticket.

Step 1: Search Slack for Payment Activity

  • Use global search with customer full name (and variants if needed).

  • Look for automated logs showing: customer name, venue, date, time, amount, tap events, decline reasons.

  • Key channels to check: main transaction log, decline/terminal-mismatch channel (e.g., "GUIDS").

  • If you find a successful payment:

    • Confirm venue, date, and amount match the customer's story and receipt.
    • Note tap amount vs final bill differences (often due to POS "best value"/exclusions).

  • If you find declines:

    • Check decline reason (timeout, insufficient funds, bank decline, terminal mismatch, etc.).
    • Terminal mismatch (wrong location) → redeem correct venue offer, then process refund/manual adjustment per policy.

  • If you find no relevant logs:

    • Key signal: customer didn't tap EatClub card, or upstream technical issue (terminal not configured, vault migration, "ghost" behaviour).
    • Use absence of logs together with wallet screenshots and refund-hub data to piece together what happened.
Step 2: Check Customer Account/Profile
  • Search by email, phone, or name.
  • Note: first-time vs experienced user, successful transaction history, prior refunds.
  • Flag risk signals: many refunds vs few successes; multiple accounts on same phone/email.
Step 3: Check for Existing Refund Requests
  • Confirm whether an in-app refund or internal refund ticket already exists.
  • If already processed: confirm amount, destination card, status, and timestamps to avoid double-refunding.
Step 4: Review Tap Events & Declines in Refund Hub
  • Read tap attempts (e.g., 1/1, 1/2, 0/1, 2/3).
    • 1/1 = 1 tap attempt, 1 successful payment.
    • 1/2 = 1 successful payment, 2 tap attempts (1 failed, 1 succeeded).
    • 0/1 = 0 successful payments, 1 tap attempt (declined).
  • Use decline details/codes (timeout, insufficient funds, bank decline, terminal mismatch) to understand what blocked success.
Step 5: Verify Venue & Transaction Evidence
  • Confirm receipt matches venue (name, legal name, ABN if present), date, and time.
  • Check receipt time fits the customer's story and sits within relevant offer/payment windows.
  • If "two charges" claimed: request and confirm bank screenshots; match against Slack logs, Stripe, and refund hub.
Step 6: Check POS / Transactions Hub
  • Search by venue + date; narrow by time/amount.
  • Compare grey amounts (original at tap) vs black amounts (adjusted after).
  • Open line-item view to see discounted/excluded items.
  • If you can't find by customer name: consider deal sharing. Locate deal owner via venue + date + time, then reconstruct sharer's portion.
Step 7: Check Venue Deal Rules & Exclusions
  • On venue page, review "Best Value Policy" and "View Items."
  • Confirm whether excluded items or in-house specials explain an adjustment.
Step 8: Check Offer & Payment Timing
  • Compare payment/receipt time to arrival time and configured payment window (e.g., 2–3 hours after arrival).
  • Slightly outside the deal window (esp. first-time user) → often justify a one-time exception + education.
  • Far outside deal window (e.g., 5–6pm deal, paid at 10pm) → usually deny; explain venue fairness and why timing rules exist.
Step 9: Check Stripe for Payment Records
  • Verify actual payments made to the account.
  • Helps identify device type, payment method, and any suspicious patterns.
Step 10: Duplication Sanity Checks
  • Multiple accounts tied to same phone/email; many refunds and few successes.
  • Receipts for same venue/date that look duplicated or edited.
  • Another successful payment around same time/amount that already matches this receipt (double-claim risk).
  • If anything looks off, escalate for a second review.
Step 11: Assign Root-Cause Category

Document what you found. Examples:

  • Wrong card selected / mis-tap.
  • Terminal mismatch / wrong location.
  • Insufficient funds / timeout / bank decline.
  • POS exclusion / best-value adjustment.
  • Paid outside payment window.
  • Venue terminal not configured.
  • Deal-share complexity.
  • Double payment.
  • Ghost tap / ghost decline.

3. Decision & Outcome

Once you've gathered evidence, decide on one of four outcomes:

Refund
  • When: Customer should have received the deal but didn't due to system/venue issue or user error (first-time user, wrong card, etc.).
  • Action: Process refund for the discount amount they should have received.
  • Add internal notes: What you checked, what you found, root cause, why you chose refund.
Goodwill Credit
  • When: Policy worked as designed, but experience was confusing/unpleasant (e.g., best-value adjustment, unexpected exclusion, long wait time).
  • Action: Refund + small dining credit ($5–$10 typically; adjust based on deal value, severity and wait time).
  • Add internal notes: What you checked, what you found, why you added credit.
Deny
  • When: Clearly outside rules (e.g., far outside payment window, no evidence of attempt to use deal, fraud signals).
  • Action: Respectfully explain why the refund cannot be processed, tied to venue fairness and system rules. 
  • Add internal notes: What you checked, what you found, why you denied.
Escalate
  • When: Systemic/technical issue likely (venue terminal broken, ghost taps/declines, strong fraud signals, deal-share complexity, double payment, unclear situation).
  • Action: Do not process refund yet. Escalate to senior agent or tech team with all evidence, screenshots, and timestamps.
  • Add internal notes: What you checked, what you found, why you're escalating, what decision is needed.

4. Responding to the Customer

  • Use the CLEARR framework (Context, Logic, Event, Action, Resolution, Review) to structure your response. Assume agents have been trained on this method.

  • Always include:

    • Why the system works the way it does (context & logic).
    • What happened in their specific case (event).
    • What you're doing about it (action).
    • What they'll receive and timelines (resolution).
    • How to avoid it next time (review).

  • Tone: Empathetic, educational, solution-focused. Optimise for de-escalation and customer understanding.

5. Things to Check & Note

Common Fraud Signals
  • Multiple accounts tied to same phone/email.
  • Many refund requests + few successful transactions.
  • Receipts that look duplicated, edited, or suspiciously similar.
  • Same amount/time/venue claimed by multiple customers.
  • New customer with immediate refund request (no successful transactions).
  • Action: If you spot any of these, escalate rather than accuse.
System & Tool Limitations
  • Slack logs: May not capture all transactions; absence of a log doesn't mean no payment occurred.
  • POS Hub: Only shows integrated POS venues; non-integrated venues won't appear.
  • Refund Hub: Only shows refunds requested through the in-app flow; email refund requests require manual investigation.
  • Deal sharing: Currently difficult to track; deal owner's transaction may not show sharer's details. Requires manual cross-referencing.
  • Receipt uploads: Currently photo-only (no documents) to prevent fraud; this means some customers email receipts instead, creating extra work.
Escalation Decision Tree

  • Escalate to Tech Team if:

    • Venue terminal appears broken (repeated complaints, no successful payments).
    • Ghost tap/decline (wallet shows decline, system shows nothing). 
    • Vault migration or card provider issue suspected.
    • Double payment (systemic, not one-off).

  • Escalate to Senior Agent if:

    • Deal-share complexity (unclear payment ownership).
    • Strong fraud signals (multiple accounts, duplicated receipts).
    • Ambiguous situation (not enough evidence to decide).
    • Customer is very upset or has been waiting a long time. 

  • Escalate to Venue/Ops if:

    • Venue terminal issue confirmed.
    • Venue exclusion rules seem unfair or unclear.
    • Venue has multiple refund requests (pattern).
Key Principles to Remember
  • Always complete the investigation before responding. Gather all evidence first.
  • Document everything. Internal notes should show what you checked, what you found, and why you decided.
  • Optimise for customer understanding, not blame. Even if it's the customer's fault, explain why the system works the way it does and take the opportunity to offer some education.
  • Compensate for bad experiences. A small dining credit often prevents escalation and builds loyalty.
  • Spot systemic issues. If you see a pattern (e.g., multiple refunds for the same venue), flag it for the tech team.
  • Use the refund hub as a canary. Refund requests often signal broken terminals, vault issues, or user confusion. Investigate the root cause, not just the symptom.