The Zendesk Submit a Request Form
The Zendesk submit a request form is the one page in your help centre where customers actually type. Every field you add costs completion rate and buys information.
Where the Zendesk submit a request form comes from
The submit a request page is a template in your Guide theme, rendered from your ticket forms and ticket fields. It's not a separate form builder. That surprises people who go hunting for one.
Which means three separate settings decide what a customer sees.
If a field is not appearing, it is almost always the field permission rather than anything to do with the form.
How many fields, honestly
Every field is a small tax on submission. Some are worth it.
Subject and description are unavoidable. After that, ask of each field: will an agent behave differently based on the answer? If not, cut it. "How did you hear about us" on a support form is a marketing question wearing a support costume, and it slows down someone who is already annoyed.
The field usually worth keeping is a well-designed category dropdown, because it routes. Routing saves more agent time than any other single thing on this page. Keep the option list short and written in customer language, not internal team names.
Four fields answered accurately beat nine fields answered carelessly. People satisfice under friction, and wrong values are worse than absent ones.
Conditional fields
Conditional fields let you show follow-up questions based on an earlier answer. Pick "Billing" and you get the invoice number field; pick "Bug" and you get version and browser instead.
This is the correct answer to the tension above. You ask two questions of everyone and three more of the people whose answers actually need them, so the average form stays short while the useful ones stay detailed.
Conditions are configured separately for end users and for agents, which is easy to forget: making a field conditional for agents does nothing to your help centre form. Availability is plan dependent, so check current Zendesk docs against your plan before designing a deep conditional tree.
And keep the tree shallow. Two levels is comprehensible. Four levels is a maze that people escape by picking "Other".
Sign-in, anonymous requests and spam
You choose whether the help centre requires sign-in. Requiring it gives you verified identity, tickets attached to the right user, and no spam. It also loses you every customer who cannot remember a password, and those people email you instead, which creates a second record of the same problem.
Open submission with a CAPTCHA is the common compromise and it works reasonably well. Watch the suspended tickets queue for a week after any change to this setting, because misconfigurations show up there first.
Attachments are a separate toggle. Turn them on. A screenshot removes an entire round trip, and a round trip costs more than the storage does.
Linking to it and embedding it
The form has a stable URL under your help centre, and you can link straight to a specific ticket form by passing its id in the query string. That's how you put "Report a bug" in your app footer and land the user on the right form with the right fields already selected. Very underused.
For in-product submission, the web widget embeds a contact form without sending anyone to the help centre, which is worth it for anything where leaving the app loses the context.
Two things to check either way. Test the form signed out, because signed-in testing hides permission problems. And confirm what happens after submission: the confirmation copy is the last thing a worried customer reads, and "your request has been received" plus an expected response time prevents a decent share of follow-ups.
Watch the drop-off too. If you can see how many people open the form and how many submit it, the gap tells you whether your field list is reasonable. A big gap after you added a required field isn't a coincidence.
If people can't find the form in search, the help centre search guide covers why.
Frequently asked questions
Is the Zendesk help center form the same as a ticket form?
The Zendesk end user form is a ticket form rendered for customers. Same fields, different visibility, which is why a field set to agent-only never appears on the Zendesk help center form.
Why is my field missing from the Zendesk submit a request form?
Nearly always the field permission. A field has to be visible to end users, and the ticket form it sits on has to be available to end users too.
Can I have more than one request form?
Yes. Multiple ticket forms marked available to end users produce a picker, and you can link directly to one by passing its form id in the URL.
Do conditional fields work for customers?
Yes, but end-user conditions are configured separately from agent conditions, and availability depends on your plan. Check the current Zendesk docs.
Should I require sign-in to submit a request?
It stops spam and gives you clean identity, at the cost of people who cannot log in emailing you instead. Open submission plus CAPTCHA is the usual compromise.
Can I embed the form on my own site?
Use the web widget for in-product submission, or link directly to the help centre form URL. The Guide page itself is a theme template rather than an embeddable snippet.
One problem, two submissions
Customers who aren't sure the form worked send it again. Ticket Merger catches the pair before an agent does.
Start free trial14-day free trial. No credit card required.