Customer Support

How to process refund and return requests as Educators, Coaches, and Course Creators

Customer SupportFor Educators, Coaches, and Course Creators3 apps12 steps~24 min to set up

A student emails you at 11pm saying they want a refund for your $497 cohort. You're mid-lesson-prep, so you see it at 7am. You check your Stripe dashboard, find their charge, manually cross-reference your Notion or Google Sheet enrollment tracker to confirm they're actually enrolled, draft a reply from memory about your refund policy, process the refund in Stripe, then remember to update your Teachable or Kajabi seat count, then forget to remove them from your Circle or Slack community. Three days later they're still getting lesson emails because you forgot to update ConvertKit. The whole thing takes 45 minutes across six tabs and you've done it seven times this month.

Build this on Starch → See the apps used

Customer SupportFor Educators, Coaches, and Course Creators3 apps12 steps~24 min to set up

Outcome

What you'll set up

A refund-tracking dashboard that automatically surfaces each refund request from your inbox, cross-references it against Stripe charge data, and shows you everything you need to decide and act in one place — no tab-switching

An automation that, when you approve a refund, processes it in Stripe, flags the student's record in your CRM, and drafts a confirmation email for you to send with one click

A weekly digest that shows you refund volume, the reasons students gave, and which courses or cohort weeks are generating the most requests — so you can fix the product, not just the inbox

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

CRM Customer Support Agent

Data sources & config

Starch syncs your Gmail data on a schedule so refund-related emails surface automatically in your tracker. Starch also syncs your Stripe data on a schedule, so charge history, amounts, and customer records are always current and matchable to inbound requests. Your CRM connects to Gmail and can be enriched with LinkedIn data. Slack is connected from Starch's integration catalog and queried live when your weekly digest automation fires. If you use Teachable or Kajabi to manage course access, Starch can automate access revocation through your browser — no API needed.

Prompts to copy

Build me a refund request tracker. Pull in emails from Gmail where the subject or body mentions 'refund,' 'cancel,' or 'I want out.' For each one, show me the student's name, the course they're in, the date they purchased, and the Stripe charge amount. Let me mark each request as approved, denied, or pending, and add a note about the reason.

When I mark a refund as approved in my tracker, draft a reply to the student confirming the refund, tell them to expect it in 5-7 business days, and remind them they'll lose access to the course materials. Show me the draft before sending.

Every Sunday at 8am, send me a Slack message summarizing refunds processed this week: how many, total dollar amount, and the top reason given. Flag any requests that have been sitting in 'pending' for more than 48 hours.

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Gmail to Starch (scheduled sync). Starch starts pulling in your messages, including any thread where a student has mentioned refunds, cancellations, or dissatisfaction.

2 Connect Stripe to Starch (scheduled sync). Starch pulls your charges, customers, and subscription records so every refund request can be instantly matched to the right transaction without you manually searching.

3 Open your CRM app and tell Starch to treat enrolled students as contacts, with fields for course name, cohort date, purchase amount, and refund status. If you've been tracking this in a Google Sheet, describe it and Starch will import and clean it.

4 Build your refund inbox view: prompt Starch to pull Gmail threads containing refund or cancellation keywords, match each sender against Stripe customer records, and display them in a single queue with the relevant transaction data alongside the email.

5 Add a status field to each request — pending, approved, denied — and a free-text notes field for logging the student's stated reason. This becomes your audit trail if a student disputes the decision later.

6 Build the approval automation: when you flip a request to 'approved,' Starch drafts a confirmation reply using your policy language, queues the Stripe refund for your review, and updates the student's CRM record to reflect their churned status.

7 If you use Teachable, Kajabi, or Thinkific to gate course content, add a browser automation step: after you confirm the refund, Starch logs into your course platform through your browser and revokes the student's enrollment — no API required.

8 Add a ConvertKit or Mailchimp step: connect your email marketing tool from Starch's integration catalog, and when a refund is approved, have Starch remove the student from your active cohort sequences so they stop receiving lesson emails.

9 Set up the community offboarding step: if your students are in a Circle or Slack community, Starch can automate the removal through browser automation (Circle) or via Slack from the integration catalog, triggered by the same approval event.

10 Build your Sunday morning digest: prompt Starch to count refunds processed in the past 7 days, sum the dollar amount, list the most common stated reasons, and send you a Slack message with anything still sitting in 'pending.'

11 Once you have a few weeks of data, ask Starch: 'Which cohort weeks or lessons are mentioned most often in refund requests?' That answer tells you where the product is breaking, not just where your inbox is full.

12 Start the Email Triage app (founder-inbox) as a complement: it triages all incoming Gmail by priority, so refund requests don't sit at the bottom of a launch-week inbox flood — they surface at the top, flagged for same-day action.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

Spring 2026 Cohort Close-Out — Week 3 Refund Spike

Sample numbers from a real run

Refund requests received (week 3)	9
Requests matched to Stripe charges automatically	9
Approved refunds processed	6
Total refunded to students (USD)	2,982
Denied (outside 14-day window)	2
Pending / awaiting response from student	1
Teachable seats auto-revoked via browser automation	6
ConvertKit sequence removals triggered	6
Minutes spent on full batch (vs. ~45 min per request manually)	35

In week 3 of your spring cohort — typically when the workload kicks in and some students decide it's not for them — 9 refund requests arrived across 4 days. Before Starch, each one was a 45-minute multi-tab exercise. With the refund tracker live, all 9 requests appeared in one queue with the Stripe charge amount, purchase date, and email thread visible side by side. Six were within your 14-day window and approved in a single session: Starch drafted the confirmation emails, queued the $2,982 in Stripe refunds for one-click processing, revoked their Teachable seats through browser automation, and removed them from the ConvertKit 'Active Cohort Spring 26' sequence. Two requests were outside the policy window — Starch drafted denial emails citing the policy language, which you sent as-is. One student hadn't replied to your clarifying question, so it stayed in pending and surfaced again in Sunday's Slack digest. The whole batch took 35 minutes instead of roughly 6.75 hours. The Sunday digest also flagged that 4 of the 9 requests mentioned 'too much material in week 3' — a product signal, not just a support problem.

Measurement

How you'll know it's working

Refund rate by cohort (% of enrolled students who request refunds, tracked week-over-week to catch product or delivery problems early)

Time-to-resolution per request (hours from email received to refund processed — your goal is under 24 hours, not 3 days)

Refund reason distribution (what students say when they quit — categorized by lesson, workload, fit, or personal circumstance)

Revenue at risk in pending queue (total dollar value of requests not yet approved or denied — tells you what's sitting unresolved)

Post-refund email leak rate (how many refunded students are still receiving course drip emails — should be zero)

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Manual Gmail + Stripe + Notion tracker

Works fine at 2-3 refunds a month; at 10+ per cohort, the tab-switching and manual data entry is where the errors and delays pile up — Starch eliminates the cross-referencing you're doing by hand.

Kajabi or Teachable built-in refund tools

These handle the course-access side, but they don't touch your Stripe reconciliation, your CRM, your email sequences, or your community offboarding — you still do those manually.

Zendesk or Freshdesk

Full-featured support ticket systems with refund workflows, but priced and configured for teams — a solo coach with 200 students will spend more time configuring Zendesk than handling refunds.

Zapier automations (Stripe + Gmail + Teachable)

You can wire individual steps together in Zapier, but each step is a separate Zap, there's no shared student record tying them together, and describing the logic in natural language isn't how Zapier works — you're building flows node by node.

Google Sheets manual tracker

Almost every solo course creator starts here; it breaks when a student is in two cohorts, when a charge was split across installments, or when you're handling refunds during a live launch week and the sheet isn't open.

On Starch RECOMMENDED

One platform — crm, founder inbox, customer support agent all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

I use Teachable, not Kajabi — does this work the same way?

Yes. Starch connects to Stripe directly (scheduled sync) regardless of which course platform you're on, so the payment data is always there. For revoking course access in Teachable, Kajabi, Thinkific, or any other platform that doesn't have a direct Starch connection, Starch automates the revocation through your browser — it logs in and clicks through the same steps you would, no API required. You just confirm the action before it runs.

What if a student paid via PayPal or a payment plan, not a single Stripe charge?

PayPal is reachable from Starch's integration catalog and can be queried live when your automation runs. For installment plans through Stripe, Starch syncs all charge records, so you can see the full payment history — how much they've paid so far and whether a partial refund is what your policy calls for. You'd tell Starch how to handle partial-pay refunds when you build the automation, and it applies that logic consistently.

Will Starch actually process the Stripe refund automatically, or do I still click a button?

By default, Starch drafts the refund action and shows it to you before executing — you click approve. If you want fully automatic processing for requests that clearly meet your policy criteria (within 14 days, no prior refund, under a certain dollar amount), you can build that logic into the automation and Starch will run it without stopping. Most solo course creators prefer the one-click-confirm step, at least at first.

I've heard about a Customer Support Agent in Starch — can that handle refund requests automatically?

Customer Support Agent is coming soon — it's in development and you can request beta access now. When it launches, it will handle inbound requests across chat, email, and social using your own policy documents as the source of truth, which would include routing refund requests to the right workflow and resolving the clear-cut ones without you. For now, the Email Triage app plus the custom refund tracker described here covers the same ground with a bit more manual confirmation on your end.

Is my Stripe and Gmail data stored securely in Starch? I'm not SOC 2 certified but my students expect their data handled responsibly.

Starch is not SOC 2 Type II certified yet — that's an honest limitation worth knowing. Stripe and Gmail data syncs into Starch's database on a schedule and is used to power your apps and automations. If your students are in a regulated category (e.g., healthcare or financial coaching with compliance obligations), talk to Starch about your specific situation before connecting sensitive data. For most course creators and coaches, the data involved in refund processing — name, email, charge amount — is standard and handled with the same care as any SaaS tool in your stack.

I run cohorts every 6 weeks. Do I need to rebuild this every time?

No. The refund tracker and automations you build persist and apply to every cohort going forward. The only thing that changes is the cohort tag or enrollment date you're filtering by — you'd tell Starch 'show me refund requests from students who enrolled after April 1' and it adjusts the query. You build it once; it works for the spring cohort, the summer cohort, and the one after that.