Customer Support form templates
Something has gone wrong and the customer is about to tell you about it — as an IT ticket, a complaint, a refund or warranty claim, a bug report, a cancellation, or a rating once it is all resolved.
Building this from scratch instead? See Contact forms.
Collections
Smaller, hand-picked sets built around one job, with a line on each template explaining when to reach for it.
Support requests rarely arrive usable: a Slack message, a phone call, an email saying it's broken. The first reply is then a request for the missing detail.
Three jobs run through it: reporting a fault, with an issue type and steps to reproduce; claiming a remedy, keyed to an order number or a serial and model number; and closing the loop, with a desired resolution and a rating of the agent.
What is a customer support form?
A customer support form takes in a problem the way a triage nurse takes in a patient. It asks who is reporting it, which record it concerns, what went wrong and how badly, so the request arrives as a workable ticket rather than a message that starts a conversation. The shape holds whether the reporter is an employee whose VPN login has failed or a customer claiming under a two-year warranty.
What these forms usually ask for
The questions that appear most often across our 7 customer support form templates.
- Email Address4 of 7
- Customer Name3 of 7
- Phone Number3 of 7
- Date of Purchase2 of 7
- Product Name2 of 7
Why use customer support form templates
An order number, a serial and model number, or the device affected is what connects a report to a record. Asked on the form it is there; asked afterwards it costs a day.
A scale worded from minor inconvenience to full outage lets you work the queue by consequence rather than by who wrote in capitals.
Webhooks fire on submit and 60+ apps connect through the published Zapier app, so a bug report opens an issue. The submission triggers the action; nothing is read back.
How to create your own
- 1
Lead with whatever ties the request to a record: order number, serial and model number, or the device affected.
- 2
Add an issue or complaint type using categories named after your own products and failure modes, so "other" stays small.
- 3
Word severity as consequences — minor inconvenience through to full outage — not as urgent, high, medium and low.
- 4
Split the description: steps to reproduce against expected and actual behaviour for a bug, what happened against the resolution sought for a complaint.
- 5
Give people somewhere to put evidence — a short text field takes a link to a screenshot, a receipt or a photo of the damage — and webhook each submission to whoever works the queue.
Getting better responses
Response times by priority, your return window, warranty coverage and its exclusions belong above the fields, where people can self-qualify.
Refund, replacement, repair, credit or an apology — customers arrive with an outcome in mind, and guessing wrong turns one exchange into four. Make it required on complaint and warranty forms.
A cancellation form that captures the reason, an effective date matched to the billing cycle and a data export preference gives you churn data you can count. Hiding it earns a public review instead.
Who uses these forms
Frequently asked questions
What does a support form need beyond a description of the problem?
An identifier that ties the request to a record, a category for the type of problem, a severity or priority judgement, and a description field with enough room to be useful. For anything involving a purchase, add the purchase date — it decides warranty and refund eligibility before a human looks at the claim. A screenshot or a photo of the damage often settles the case in one step, so add an upload field for it; files are capped at 2 MB each, which a screenshot comfortably fits.
Should complaints, refunds and warranty claims share one form?
They ask genuinely different questions, so usually not. A refund needs an order number, a reason and a preferred refund method; a warranty claim needs a serial number, a place of purchase and a technical description of the defect; a complaint needs an incident date and the resolution the customer is asking for. Keeping them separate also lets you count each one on its own terms.
How do you stop every ticket being marked critical?
Describe the levels by consequence rather than by name — "I can work around it" against "nobody in the office can work" — so choosing one is a factual decision instead of a plea. Publish what each level means in response time, and the scale starts to police itself. Priority inflation is usually a symptom of people not knowing what happens next.
Can support submissions create tickets in the system we already use?
Yes. Real-time webhooks fire on every submission and there is a REST API, alongside 60+ apps through the published Zapier app, so a bug report can open an issue and a complaint can raise a task. The flow runs one way only: the submission triggers the action, and ticket status is not read back into the form. Early access unlocks all of it at no charge.
Related templates and guides
Start from scratch and build exactly the form you want.
Start building