# Building the Tally Refund Form **From Chapter 4.3 of *The 4-Hour Side Hustle*.** Module 1 of the six-module refund chain. Three fields, ten minutes, free. `Tally form → Make.com → Stripe refund → Kit tag → Airtable Orders → Telegram` Everything here works on **Tally's free plan**. Webhooks are free to all users, and the native Make integration is too — no upgrade is needed for any part of this. --- ## Step 1 — Create the form 1. Go to [tally.so](https://tally.so) → **Create form** → **Start from scratch**. 2. Name it `Refund request`. **Title block:** > ### Request a refund > > Thirty days, no questions. Fill this in and it processes within the hour — you don't need to explain yourself and you don't need to wait for a reply from me. That paragraph is doing real work. Someone arriving here has already decided, and the fastest way to turn a refund into a bad review is to make them feel they have to argue for it. --- ## Step 2 — The three fields Type `/` in the form body to insert each block. ### Field 1 — Email - Block type: **Email** - Label: `The email address you bought with` - **Required: yes** - Help text: `This is how we find your order.` ### Field 2 — Order number - Block type: **Short answer** - Label: `Order number, if you have it` - **Required: NO** — see the note below - Help text: `It's in your receipt email. If you can't find it, leave this blank — the email address is enough.` ### Field 3 — The optional box - Block type: **Long answer** - Label: `Anything I should know?` - **Required: no** - Help text: `Genuinely optional. Your refund goes through either way. I read every one of these and it's the most useful feedback I get.` ### Submit button Change the label from `Submit` to **`Request refund`**. --- ## One deliberate departure from the book **Chapter 4.3 describes the order number as one of three fields. I'd make it optional, and I'd change the book to match.** Customers routinely can't find an order number. Making it required means someone who has decided to leave now has to go hunting through their inbox before they're allowed to — which is exactly the friction the chapter argues against, reintroduced in the one place it does the most damage. You don't need it. The Stripe module in step 2 of the chain looks up the charge by email *or* order ID, and email is the field people can always supply. The order number is useful when it's there, so keep the field — just don't gate on it. --- ## Step 3 — Publish Click **Publish**. Copy the form URL. Put it in two places, per the refund policy copy: - The **receipt email**, at the bottom, on every receipt — not just the first. - The **sales page**, in block 8 beside the price. --- ## Step 4 — Connect it to Make Two ways. **Use the first.** ### Native Tally module (recommended) 1. In Make: **Scenarios** → **+** → search **Tally**. 2. Choose the trigger **Watch New Responses**. 3. **Add** a connection → authorize Make to reach your Tally account. 4. Pick `Refund request` from the **Form ID** dropdown. That's module 1 of the chain. Free on both sides. ### Webhook (if the module gives you trouble) In Tally: **Integrations** tab → **Connect** next to **Webhooks** → paste a Make custom-webhook URL. The payload is JSON: submission metadata plus a `fields` array, each entry carrying the question label, the field type, and the answer. Slightly more mapping work than the native module, which is the only reason it's second choice. --- ## Step 5 — Make it duplicable for readers This is what `/refund` promises: a form your readers can copy rather than rebuild. 1. Open the form → **Share** tab. 2. Scroll to **Create a template** → **Create**. 3. Name it `Refund request — The 4-Hour Side Hustle`. 4. Privacy: **Public** — anyone with the link can view and use it. 5. Pick a category, add a description, optionally a preview screenshot. 6. **Complete.** Copy that template link. **That's the asset** — it goes in the resource library, not the form URL. Sending readers your live form would have their refund requests arriving in your Make scenario. --- ## Before you trust it with real money **Test the whole chain with a real charge.** Buy your own product with a real card, submit this form, and confirm all six modules run: the refund lands, the Kit tag applies, the Airtable record flips to Refunded, and Telegram tells you. Two things worth knowing while you build: **The refund can only go back to the card that paid.** Someone submitting a stranger's email can cancel that person's purchase but cannot redirect money to themselves. That's what makes automating this safe when automating a payout wouldn't be. **Set the threshold anyway.** Automate refunds up to your rung-two price; route anything above it to Telegram for a human yes. Chapter 1.2's rule about never automating money movement holds — what makes this the exception is direction and bound, not the fact that it's convenient. --- ## Checklist - [ ] Form named `Refund request`, three blocks - [ ] Email required - [ ] Order number **not** required, with help text saying so - [ ] Reason box optional, with help text saying it's genuinely optional - [ ] Submit button relabelled `Request refund` - [ ] Intro copy states thirty days, no questions, processes within the hour - [ ] Published, URL in the receipt email **and** the sales page - [ ] Connected to Make via the native Tally module - [ ] Template created, set to Public, link saved for the library - [ ] Template link — not the live form link — is what readers get - [ ] Full chain tested with a real card and a real refund - [ ] Refund threshold set; anything above it routes to Telegram