The Zendesk Web Form
The Zendesk web form is a channel, not just a page. Once you see it that way, several confusing things about your reporting start making sense.
What the Zendesk web form channel actually is
Zendesk records how each ticket arrived. Email, chat, API, voice, and web form, which covers tickets created through the help centre submit page and through the widget contact form.
That matters more than it sounds. Views, triggers and reports can all filter on it, so you can treat a form submission differently from an email without tagging anything yourself. A trigger firing only on web form tickets is a clean way to send a confirmation with different wording, or to route on a field that only exists on the form.
It also explains a common confusion. A ticket somebody swears they emailed shows as web form because they used the widget. The channel records where it entered, not where the conversation carried on.
Ticket forms versus the widget
Two different things with confusingly similar names, and teams pick between them without noticing they're choosing.
A ticket form is a named set of fields in a chosen order, rendered on your help centre submit page. It supports conditional fields, it can be restricted per brand, and you can link to it directly. The full treatment is in ticket forms.
The widget contact form is the same underlying fields presented in a panel on any page of your site. Less room, less structure, far more convenient for the customer because they never leave the page they were on.
The practical answer is usually both. The widget catches people where they already are. The help centre form is where you send anyone who needs a structured request, and where your articles should link. What you want to avoid is two different sets of questions producing tickets that report inconsistently, because six months later nobody can explain the numbers.
Which fields to require
Required fields are the biggest lever on both completion rate and ticket quality, and they pull in opposite directions.
Everything beyond that should be conditional. Ask for an order number when somebody has picked "problem with my order", and never otherwise.
Remember that end-user and agent requirements are set separately. Ask the customer for very little, and require the agent to fill in whatever your reporting depends on before they can solve it. That's usually the right shape and hardly anyone configures it.
Signed in versus anonymous
Whether you require sign-in before submitting is a real decision with a real cost on both sides.
Requiring it gives you a verified identity, a clean user record and a working request history page. It also loses you the person who can't remember their password and gives up, which on a consumer site is a lot of people and none of them tell you.
Allowing anonymous submission catches everyone and quietly creates duplicate user records, because the same human uses a personal address one week and a work address the next. If you go this route, plan on merging users periodically rather than pretending it won't happen.
Most teams land in the right place by allowing anonymous submission but prefilling everything they can when somebody is recognised.
Spam and the suspended queue
A public form gets found by bots quickly. Zendesk applies its own filtering and suspicious submissions land in the suspended tickets queue rather than in your views. Check it weekly, because real tickets end up in there too and nobody notices for days.
The pattern worth watching for: a sudden spike of near-identical submissions with slightly different email addresses. That's automated, and the fix is usually a form change rather than a filtering change. More detail in the spam filtering guide.
Reading it in your reporting
One thing worth doing on a Monday: break your volume down by channel and look at the trend rather than the totals.
A web form share that's climbing while email falls is usually good news, because it means people are finding the structured route. A web form share climbing while email also climbs is usually the same people writing in twice, and that's a different problem entirely.
Frequently asked questions
What does a Zendesk web form ticket look like in reporting?
It arrives with the web channel attached. A Zendesk web form ticket is distinguishable from email in Explore, which is the main reason to keep the Zendesk online form rather than publishing an address.
What is the Zendesk web form channel?
The channel recorded for tickets created through the help centre submit page or the widget contact form, as opposed to email, chat, voice or API.
Should the subject field be required?
Yes. Blank subjects make views hard to scan and make duplicates much harder for an agent to notice.
Can customers submit without signing in?
That is a setting. Anonymous submission catches more people and creates more duplicate user records, so plan for periodic user merging if you allow it.
Why do some tickets show as web form when the customer emailed?
They used the widget rather than email. The channel records how the ticket entered, not how the conversation carried on afterwards.
Web form plus email, same person
The customer who emails and then fills in the form is the most common duplicate there is. Ticket Merger catches it automatically.
Start free trial14-day free trial. No credit card required.