Route order and refund requests to the Billing group
Order and refund questions open in the Billing group with the order number already on the subject line.
New submission on your "Order help" form
Create a Zendesk ticket assigned to the Billing group, with the order number in the subject and the issue details in the description
One-directional. A submission triggers the action — nothing is written back into your form.
Money questions need a record. A refund asked for in a chat window is a promise nobody can find three weeks later, and the customer remembers it differently from the agent. Sending the request through a form gives you a ticket carrying the order number, the reason and the date it was made.
Small online stores reach for this when order queries start crowding out everything else. The Billing group gets its own inbound stream, and general support stops triaging questions it cannot answer anyway.
Setting it up
- 1
Publish the "Order help" form with Order Number required — without it a Billing agent has to write back before anything can move.
- 2
In Zapier, take the "New Submission" trigger from that form alone, so general enquiries keep their own path.
- 3
Add Zendesk "Create Ticket" and set Group to Billing on the action step, so these skip the general queue entirely.
- 4
Build the subject from Order Number and Reason for Refund together — the view then reads as a list of order numbers with a reason beside each.
- 5
Map Email Address to the requester email. Orders are matched on the address the customer bought under, so a mismatch is worth spotting at triage rather than at refund time.
- 6
Put Additional Explanation in the description with Preferred Refund Method underneath, so the agent has the ask and the method on one screen.
- 7
Add "order" as a static tag, plus a second tag driven by the returns question so refunds and returns can be filtered apart.
- 8
Test with a genuine recent order number, confirm the ticket lands in Billing rather than the default group, then turn the Zap on.
What maps where
Using the Refund Request Form as the starting point. These are its real fields — swap in your own and the mapping works the same way.
| Form field | Zendesk |
|---|---|
| Order Number | Prefix on the ticket subject, e.g. "#10482 — refund request" |
| Reason for Refund | First line of the ticket description |
| Additional Explanation | Ticket description, below the reason |
| Email Address | Requester email — matches the customer's Zendesk user |
| Product Name | Custom ticket field the Billing view groups on |
| Has the item been returned or will it be returned? | Tag separating returns from straight refunds |
Variations worth knowing
The form captures the request, while the refund still happens in the provider that holds the original transaction. Use the Zendesk ticket as the record of who asked, what was agreed and when, and paste the refund reference onto it once it has gone through.
Zendesk groups tickets by requester, so an agent opening today's order query sees the customer's earlier ones in the same side panel. Map an organisation as well if you sell to businesses, and the whole account's history sits beside the request.
If something isn't arriving
Group is chosen on the Zendesk action, never inferred from the form. Set it explicitly on the step. If the dropdown comes back empty, the agent account you connected is not a member of that group and Zapier will not list it.
The mapping picked up the label rather than the value. Re-insert Order Number from the trigger's sample data in Zapier and test again — a sample recorded before that field existed will not offer it at all.
Frequently asked questions
Can the ticket refund the customer automatically?
No. The submission creates a Zendesk ticket and nothing more; an agent issues the refund in your store or payment provider. Payment handling is not part of the form, so treat the ticket as the record of the decision rather than the transaction itself.
What if the customer does not know their order number?
Make the field optional and ask for the purchase date and product name instead, then map both. An agent can search the store on those two. A required order number that people guess at costs more time than a blank one does.
Can one form handle refunds, returns and delivery problems?
Yes, using conditional logic. Show the return questions only when someone picks a return, and branch the Zendesk tag from that same answer. One form and one Zap is far easier to maintain than three that drift apart over a year.
Related automations
- Capture webinar questions as tagged tickets
Questions from webinar registrations open as tickets tagged with the event, ready for the host to answer from one view.
- Collect post-support feedback as low-priority review tickets
Post-support feedback lands as a low-priority tagged ticket in a review view, out of the queue agents work each day.
- Log bug reports as prioritised Problem tickets
Each problem report becomes a Problem ticket in Zendesk, tagged and already carrying the priority the reporter chose.
- Open internal IT requests as prioritised tickets
Staff IT requests become prioritised tickets on your internal Zendesk queue, with the device and issue type already on them.
- Send contact form messages to your support queue
Messages from your contact form open as Zendesk tickets, with a status, a group and the sender already resolved as the requester.
- Capture feature requests as labelled tickets
Product ideas from your feedback form land in Freshdesk as Feature Request tickets the team can group and revisit.
Build the form first
The automation needs somewhere to fire from. Publish a form, connect it once, and every submission from then on runs this flow.
Start free