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

Process Refund Requests | Refund Hub

Goal: Provide Refunds agents with a clear, step‑by‑step process for investigating and actioning refund requests in Refund Hub, using a reason‑first, Slack‑first approach and consistent critical thinking at each check.

 

1. Understand What Lives in Refund Hub

Focus: Know which requests you handle here and what this guide covers.

  • Types in Refund Hub:

    • Refund – Customer made a payment and did not receive the EatClub deal. This guide focuses on these.

  • Categories inside Refunds:

    • Real refunds – Customer paid, did not get the discount, and wants the discount amount back.
    • No refund needed – Customer reports an issue or experience but is not asking for a refund (e.g. venue closed, fully booked, question about credit).

  • How requests arrive:

    • All requests here start from the in‑app refund / need help modal.
    • Some refunds may also be initiated by an agent from the transaction portal; investigation still happens in Refund Hub.

Outcome: You can identify the task type in Refund Hub and know this guide is for Refund cases, with light handling for No refund needed.

2. Workflow Overview: From “Ready to verify” to Outcome

Focus: See the full process and investigation sequence before you dive into details.

  • Entry point:

    • Open Refund Hub.
    • Locate items with Type: Refund and Status: Ready to verify.

  • High‑level sequence:

    1. Open the refund request and identify the reason for the refund.
    2. Immediately check Slack for technical issues linked to this visit.
    3. Work through the Refund Hub verification sections:
      1. Customer information
      2. Offer details
      3. Venue & receipt
      4. Payment & tap events
      5. Amount & service fee
    4. Use evidence from Slack + Refund Hub to decide:
      • Full refund / partial refund / deny / dining credit or voucher.
    5. Apply internal rules for:
      • Service fee (keep vs waive).
      • No‑show fee (threshold placeholder).
      • Repeat refund behaviour (future thresholds – placeholder).
    6. Record your reasoning per existing templates/process.
    7. Communicate the outcome to the customer and, if needed, the venue.
    8. Escalate to a Shift Lead when flags or patterns require it.

Outcome: You understand the end‑to‑end workflow and that reason identification + Slack check are your first investigation steps.

3. Step 1 – Open, Identify the Reason & Check Slack

Focus: From the moment you start the task, identify why the refund is requested and whether there are any technical issues.

  • Steps:

    1. In Refund Hub, locate a Refund item with status Ready to verify.
    2. Click Ready to verify to open the verification view.
    3. At the top, read:
      • Refund reason (system field).
      • Customer notes (free text).
    4. Identify the primary reason category for this refund:
      • Technical – “card isn’t working”, “payment declined”, “I tapped but no discount”.
      • Process / rules – wrong card, wrong venue, outside time, ordered excluded items.
      • Experience / operational – venue closed, venue fully booked, no‑show fee disagreement.
    5. Go to Slack before deeper UI checks:
      • Open Slack.
      • Search the customer’s name in the relevant transaction / fraud / card‑activity channels.
      • Focus on the booking date and expected payment time.
      • Look for:
        • Decline events and reasons (insufficient funds, card expired, GUID mismatch, etc.).
        • Any broader errors or warnings for that venue or customer.
        • Patterns of card issues for this user (multiple declines, multiple GUID mismatches).

  • Classify what you see:

    • Technical issue
      – e.g. GUID mismatch, terminal error, logging bug.
    • User / process issue
      – wrong card selected, payment outside Redemption Window, wrong venue.
    • Venue / operational issue
      – venue closed, fully booked, did not honour deal.
    • No logs (no activity for claimed tap)
      – possible multiple profiles, mis‑remembered card, or suspicious case.

  • If the request is clearly “No refund needed”:

    • Customer explicitly says they do not need a refund or is only asking a question.
    • Treat it as No refund needed (see Section 10) unless investigation shows they should receive a refund.

Outcome: You have a clear initial reason and a Slack‑based view of any technical issues before you invest time in the rest of the checks.

4. Step 2 – Check Customer Information (Section 1)

Focus: Assess the customer’s history and behaviour and see whether it supports the reason they’ve given.

  • Key fields in Section 1 – Customer information:

    • Total number of refunds.
    • Count of no‑shows vs paid redemptions.
    • Count of successful transactions.
    • Any existing customer notes.
    • Stripe account link for underlying card charges.

  • Steps:

    1. In Section 1, review:
      • Number of refunds and no‑shows.
      • Total successful EatClub Card transactions.
    2. Click the Stripe link if needed to confirm:
      • A payment actually occurred.
      • The amount and time of the charge.
    3. Read any existing notes (e.g. suspected abuse, previous education).

  • Primary checks (always):

    • Does their history look like a normal user (mostly successful transactions, occasional refund)?
    • Are they heavy on refunds with few successful transactions?
    • Are they heavy on no‑shows compared to paid redemptions?

  • Flags & how they relate to the reason:

    • Flag: Many refunds, few successful transactions.
      • Action:
        • Check if their current reason matches previous ones.
        • Apply stricter scrutiny across all sections.
        • Consider escalating to Shift Lead if you suspect gaming the system.
    • Flag: High no‑show count.
      • Action:
        • Check for any no‑show fee charges.
        • Decide if fee removal is justified.
        • Use the future rule once defined:
          • [PLACEHOLDER: Insert exact no‑show fee threshold – e.g. X no‑shows in Y redemptions.]
    • Flag: Prior notes about repeated education or suspected misuse.
      • Action:
        • Make sure your outcome and explanation are consistent with past handling.
        • Avoid giving unlimited “last chances”.

Outcome: You understand whether this customer’s behaviour supports their stated reason and whether you should treat this as standard or higher‑risk.

5. Step 3 – Check Offer Details (Section 2)

Focus: Confirm that the customer actually qualified for the deal based on Pay‑by‑Time and Redemption Window, and see whether the real reason is rule‑based rather than technical.

  • Key fields in Section 2 – Offer details:

    • Offer time (arrival window).
    • Arrival time recorded in the app.
    • Payment window (start and end).
    • Offer type (flexible vs strict, sit‑down vs quick‑service).
    • Any special terms (e.g. exclusions).

  • Steps:

    1. Review offer time, arrival time, and the payment window.
    2. Compare the payment window with the receipt time (Section 3).
    3. Use context:
      • All‑day deals (e.g. bubble tea): a small deviation is usually fine.
      • Tightly timed sittings: early or late payments often void the deal.

  • Primary checks (always):

    • Was the customer within the Redemption Window?
    • Did they pay within the payment window?
    • Does this support or contradict the stated reason?
      (e.g. “card didn’t work” vs “actually paid too early/late”.)

  • Flags & how to respond:

    • Flag: Payment clearly outside the allowed time for a strict sitting deal.
      • Action:
        • Treat as ineligible for the deal.
        • Plan to deny the refund unless there is a strong exception case.
        • Explain timing rules using email templates.
        • Escalate to Shift Lead if you believe a rare exception is appropriate.
    • Flag: Payment slightly outside the window on an all‑day or flexible deal.
      • Action:
        • If consistent with how we and the venue operate (e.g. bubble tea), approve the refund and document reasoning briefly.
    • Flag: Offer configuration or wording seems misleading.
      • Action:
        • Decide fairly for this customer.
        • Flag to Shift Lead for Account Management/Product review.

Outcome: You know whether the true cause is timing/rules and whether the customer should have received the deal in the first place.

6. Step 4 – Check Venue & Receipt (Section 3)

Focus: Validate the venue, receipt, and amount; check that they match the deal and the reason, and are not reused.

  • Key elements in Section 3 – Venue & receipt:

    • Deal venue name and location.
    • Receipt image:
      • Venue name and address.
      • Date and time.
      • Total amount and line items.
      • ABN where available.
    • Other receipts from this venue (to compare format).
    • Nearest payment events at this venue.

  • Steps:

    1. Inspect the receipt:
      • Venue name matches the deal venue.
      • Date and time align with the booking.
      • Amount is plausible for the stated party size.
    2. Compare with other receipts from the same venue to confirm layout and format.
    3. Look at nearest payment events:
      • Identify any other payments of similar amount at similar times that could indicate reuse.
    4. Note any promo items or excluded items on the receipt that may impact the refund amount later.

  • Primary checks (always):

    • Does the receipt come from the correct venue?
    • Does the timestamp line up with the offer details?
    • Is the amount realistic for the party size?
    • Are there nearby transactions that could be someone else’s identical bill?

  • Flags & how they relate to the reason:

    • Flag: Receipt venue is different from the deal venue.
      • Action:
        • Use Slack + Section 7 to confirm a GUID mismatch (terminal connected to a different venue).
        • Contact the customer and explain they paid at a different location than the deal venue.
        • Guide them to:
          • Redeem a new deal at the correct venue.
          • Pay using the EatClub Card at that venue.
        • Process the correct refund and reject the mismatched one.
    • Flag: Another payment with the same or near‑identical amount at almost the same time.
      • Action:
        • Check Slack to see if that payment belongs to someone else.
        • Treat as a potential case of receipt reuse.
        • Escalate to Shift Lead if suspicious.
    • Flag: Receipt details inconsistent or extreme (e.g. 1 person, $1,000 bill; many mains for one person).
      • Action:
        • Scrutinise further across all sections.
        • Consider partial refund or denial.
        • Escalate to Shift Lead for suspected organised misuse.

Outcome: You are confident the receipt is real and belongs to this venue and customer, and that it supports (or contradicts) the stated reason.

7. Step 5 – Check Payment & Tap Events (Slack‑First + Section 4, With GUIDs)

Focus: Use Slack first, then Refund Hub Section 4, to confirm what actually happened with the EatClub Card and whether the story holds up.

  • Terminology:

    • Use GUIDs (Globally Unique Identifiers) when referring to terminal/location identifiers.
    • A GUID mismatch means the customer tapped at a terminal that belongs to a different venue/location than the one in the deal.

  • Steps (Slack‑first):

    1. In Slack (if not already done in Step 1):
      • Search the customer’s name in:
        • Transaction / card‑activity / fraud channels.
      • Focus on the booking date and expected payment time.
      • Look for:
        • Declines with reasons (insufficient funds, card expired, GUID mismatch, other errors).
        • Evidence of multiple cards/profiles.
        • Venue‑level technical problems.
    2. Classify Slack findings:
      • Technical issue – e.g. GUID mismatch, internal error, terminal issues.
      • Expected decline – e.g. insufficient funds, wrong wallet selection.
      • No logged activity – no taps or declines for this time/venue.
    3. In Refund Hub, open Section 4 – Payment / card events:
      • Check for tap events and declines.
      • Compare what you see with Slack (do reasons match, or is something missing?).
    4. Check for multiple profiles:
      • If Slack shows activity under a different account, open the customer portal.
      • Review transaction history across profiles.

  • Primary checks (always):

    • Is there a tap or decline that corresponds to this visit?
    • Does the decline reason in Slack/Refund Hub explain the customer’s experience?
    • Do the logs support their reason (e.g. “card didn’t work”) or indicate a user mistake (wrong card, wrong venue, outside time)?

  • Flags & what they guide you to:

    • Flag: Clear technical decline (e.g. internal error, GUID mapping issue) seen in Slack but not surfaced correctly in Section 4.
      • Action:
        • Treat this as an EatClub system/config issue.
        • Consider waiving the service fee if the customer followed all steps correctly.
        • Escalate to Shift Lead so Product/Engineering can fix GUID mapping or logging.
        • Explain clearly to the customer what went wrong technically.
    • Flag: GUID mismatch – Slack shows a decline because the tap happened on a different GUID/terminal than the deal venue.
      • Action:
        • Combine with venue/receipt details to confirm wrong location.
        • Follow the “wrong venue” flow described in Step 4.
        • Ensure the customer understands they must redeem at the correct venue for the discount to apply.
    • Flag: Decline due to insufficient funds, expired card, or similar.
      • Action:
        • Explain the specific decline reason to the customer.
        • If they then completed a valid payment and otherwise met all rules, you may refund and educate.
        • If they never completed a valid tap/payment within rules, consider denying.
    • Flag: No payment or decline logs at all.
      • Action:
        • Investigate multiple profiles and alternative cards.
        • Ask the customer for additional evidence (e.g. bank screenshot, which card they used).
        • If no data supports their story and other flags exist (odd receipts, heavy refund history), consider denial or escalation.
    • Flag: Multiple taps, extreme bill vs party size, or clusters of large transactions.
      • Action:
        • Scrutinise for potential fraud or misuse.
        • Consider partial refund or denial.
        • Escalate to Shift Lead for high‑risk cases.

Outcome: You have a clear, evidence‑based understanding of what the card actually did, how that relates to the customer’s reason, and whether the root cause is technical, user, venue, or suspicious.

8. Step 6 – Set Refund Amount & Service Fee (Section 5)

Focus: Calculate the correct refund base, handle exclusions, and decide how to treat the service fee.

  • Key elements in Section 5 – Amount & service fee:

    • Total bill amount.
    • Custom amount field.
    • Service fee toggle (keep vs remove).
    • Refund destination card details.

  • Steps:

    1. Confirm the total bill from the receipt.
    2. Identify any excluded items:
      • Promotions (e.g. free “Beer of the month”).
      • Category exclusions in the offer terms.
    3. Determine the eligible spend:
      • Subtract excluded items.
      • If needed, enter that value in the custom amount field.
    4. Decide whether to keep or waive the service fee using the rules below.
    5. Verify the refund card the customer selected.

  • Refund amount rules:

    • Refund only the eligible portion of the bill.
    • Example:
      • Bill total: $58, including an $8 promo beer not eligible.
      • Eligible base: $50.
      • Set custom refund to $50.
    • Use partial refunds when only some items or part of the spend qualify.

  • Service fee rules:

    • Default: Keep the service fee.
      • Rationale: Refunds are manual and we want to avoid customers bypassing the service fee by gaming refunds.
    • Waive the service fee when:
      • A clear EatClub system or configuration error caused the issue (e.g. GUID mapping wrong, missing decline handling) and the customer followed the correct process.
      • A clear venue/terminal issue (terminal down, misconfigured) prevented the discount despite the customer following instructions.
      • Charging the fee would reasonably feel like a “slap in the face” because the problem is entirely on EatClub’s side.
      • [PLACEHOLDER: Add any extra “waive fee” conditions after policy is agreed.]
    • Do not waive the service fee when:
      • The customer ignored clear deal rules (wrong venue, wrong time, did not tap the EatClub Card).
      • The overall pattern suggests deliberate misuse of the system.
      • [PLACEHOLDER: Add extra “do not waive” criteria – e.g. repeated wrong‑card use after education.]

  • Future behaviour thresholds (placeholders):

    • [PLACEHOLDER: Insert numeric rule for “too many refunds” (e.g. more than X refunds in Y days → escalate / deny).]

Outcome: You have set a fair refund amount, excluded ineligible items, and made a consistent, defensible decision on the service fee.

9. Step 7 – Decide the Outcome & Escalate When Needed

Focus: Turn your investigation into a clear decision that matches both the customer’s reason and the actual root cause.

9.1 Outcomes (Refunds agents can action all)

  • Approve full refund (including service fee):

    • When the customer followed all rules and the issue is clearly on EatClub or the venue.
    • Use when you want to fully restore trust.

  • Approve full refund (service fee kept):

    • When the customer is eligible for the deal but there is no EatClub/venue fault requiring fee removal.

  • Approve full refund (service fee waived):

    • When a technical or configuration problem (GUID error, internal bug) caused the issue.
    • Customer behaviour supports their reason.

  • Approve partial refund:

    • When part of the bill is clearly ineligible (promo items, excluded categories).
    • When only part of the timing worked (e.g. some items ordered within the window).

  • Deny refund:

    • When the evidence shows the customer did not meet deal conditions and there is no strong reason for an exception.
    • Use templates to explain logic and educate for future visits.

  • Convert / correct from “No refund needed”:

    • When a case originally flagged as “No refund needed” turns out to deserve a refund or credit.
    • Run the proper Refund flow and document clearly.

  • Add dining credit or voucher (with or without refund):

    • For poor experiences (venue closed, fully turned away, repeated venue issues).
    • To repair the relationship when strict rules would otherwise feel harsh.

9.2 When to escalate to a Shift Lead

  • Escalate to Shift Lead when:

    • Fraud or abuse risk:
      • Heavy refunds with weak reasons.
      • Suspicious receipts (duplication, doctored) or GUID patterns.
      • No supporting logs, plus other red flags.
    • Venue‑level patterns:
      • Multiple recent refunds for the same venue type of issue (terminal down, closed, fully booked).
    • System/data problems:
      • Slack shows declines or GUID mismatches not appearing correctly in Refund Hub.
      • Other mismatches between Refund Hub, Slack, and Stripe.
    • Exception decisions:
      • High‑value or high‑risk refunds that break normal rules.

  • Shift Lead responsibilities (high level):

    • Make the final decision on complex cases.
    • Use the Internal CS Escalation Process – SOP to:
      • Loop in Account Management for venue issues.
      • Loop in Product / Engineering for technical issues.
      • Ensure documentation and visibility across tools.

Outcome: Every refund is either resolved with a clear, reason‑aligned decision or properly escalated with context and evidence.

10. Handling “No Refund Needed” Requests (Minimal Flow)

Focus: Recognise and process No refund needed tasks without turning this into a second playbook.

  • How to recognise “No refund needed”:

    • Task type Refund, but status/action shows No refund needed instead of Ready to verify.
    • Customer notes indicate:
      • They don’t need a refund.
      • They are asking a question (e.g. “Why haven’t I received dining credit?”).
      • They are reporting a situation (venue closed, fully booked, forgot to cancel).

  • Minimal handling steps:

    1. Open the task and read the reason and customer notes.
    2. Decide if any action is required:
      • Remove or adjust a no‑show fee if appropriate
        [PLACEHOLDER: insert exact no‑show threshold here].
      • Add a voucher/credit for poor experiences (closed or fully booked venues).
      • Send a clarification (e.g. how dining credit works).
    3. Take the action in our tools (refund hub, wallet, or Help Desk, as appropriate).
    4. Add a brief note following existing documentation practice.
    5. Close the request with No refund needed.

  • When to trigger further follow‑up:

    • Venue closed:
      • Check if other EatClub transactions occurred that day.
      • Flag to Shift Lead → Account Management for deal/hours review.
    • Venue fully booked:
      • Record that the customer was turned away.
      • Usually provide a voucher.
      • Supports future deal optimisation.

  • More detail:

    • A dedicated No Refund Needed guide will contain:
      • Detailed categories.
      • Response templates.
      • Reporting instructions.

Outcome: You can correctly classify and close No refund needed items and trigger follow‑up where necessary, without mixing them with real refunds.

11. Communication Expectations: Customer & Venue

Focus: Define when and how to communicate, and where to get wording.

  • General rule: Every real refund case includes some form of customer communication.

  • Contact the customer when:

    • You need clarification (receipt missing/unclear, timings inconsistent).
    • You approve a refund (full or partial) to explain what happened and what you did.
    • You deny a refund, to explain which conditions were not met and educate for next time.
    • Their issue is due to user/process error (wrong card, wrong venue, outside window).
    • You convert a “No refund needed” situation into an actual refund or credit.

  • Contact the venue when:

    • Venue was closed while advertised as open.
    • Venue is regularly fully booked and turning EatClub customers away.
    • Terminal or process issues recur at the same venue.

  • How to structure communication:

    • Use the Refund requests email templates – common scenarios for:
      • Scenario‑specific wording.
      • CLEARR (context → logic → event → action → resolution → review) structure.
    • For escalations and internal notes:
      • Follow the Internal CS Escalation SOP structure: Issue / Investigated / Action Taken / Blocker / Required to resolve.

Outcome: Customers and venues receive clear, consistent explanations, and all decisions are well‑documented.

12. Critical Thinking Checklist

Focus: Summarise the must‑do checks and follow‑on checks in one place.

  • Primary checks (do for every refund):

    1. Reason & Slack:
      • Read the refund reason and notes.
      • Check Slack for related declines, errors, or GUID issues.
    2. Customer (Section 1):
      • Refund and no‑show history.
      • Successful transactions.
      • Any previous notes or patterns.
    3. Offer (Section 2):
      • Arrival time vs Redemption Window.
      • Payment time vs payment window.
      • Deal type (flexible vs strict).
    4. Venue & receipt (Section 3):
      • Does the receipt venue match the deal venue?
      • Date/time/amount consistency.
      • Any signs of reuse or implausible spend.
    5. Payment & taps (Slack + Section 4):
      • Tap/decline present for this visit.
      • Decline reason understood (GUID mismatch, insufficient funds, etc.).
      • No unexplained gaps.
    6. Amount & fee (Section 5):
      • Eligible amount set correctly (exclusions removed).
      • Service fee decision follows guidelines.

  • Follow‑on checks (when something feels “off”):

    • Deeper Slack searches across multiple channels.
    • Check for multiple accounts or cards.
    • Look at other recent refunds for the same venue.
    • Review previous emails or calls with this customer.
    • Escalate to Shift Lead when fraud, repeated venue issues, or system bugs are suspected.

  • Future numeric rules (to be added):

    • [PLACEHOLDER: No‑show fee threshold specifics.]
    • [PLACEHOLDER: Heavy refund behaviour thresholds and automatic escalation rules.]

Outcome: You have a repeatable checklist to avoid missing critical steps or flags, while aligning every decision to the initial reason and real root cause.

Key Principles / Things to Note

  • Reason‑First, Slack‑First:
    Always identify the reason and check Slack for technical issues before you dive into the UI details.

  • Manual on Purpose:
    Refunds are manual by design. Never treat refund processing as a rubber‑stamp task.

  • Evidence Over Assumptions:
    Base decisions on Refund Hub, Slack, Stripe, and receipts, not on guesses or customer statements alone.

  • Educate to Reduce Repeat Refunds:
    A correct decision includes clear education so the same customer does not need multiple refunds for the same reason.

  • Protect Both Customer and Venue:
    Be fair to both sides. Do not approve refunds that clearly go against venue deal terms unless there is a strong, documented reason.

  • Escalate Patterns, Not Just Cases:
    You are the canary in the coal mine. Escalate when you see repeating patterns for a customer or venue, not only when a single case feels difficult.