How to Submit a Ticket in Zendesk

To submit a ticket in Zendesk should take a customer thirty seconds. From your side, the interesting question is whether they can find the way in at all.

The routes a customer has to submit a ticket in Zendesk

There are more than most teams realise, and every one of them creates a ticket.

Email your support address. Still the most used route by a distance, and the one requiring nothing from the customer at all.
The help centre submit page, usually at /hc/requests/new on your Zendesk domain. This is what "submit a ticket" means in the documentation.
The widget contact form, on whatever pages of your site happen to carry it.
Chat or messaging, which becomes a ticket when the conversation reaches an agent.
A direct link to one specific form, which is the underused one covered below.

You don't get to pick which of these people use. You only get to decide which one is easiest to find, and most help centres decide that by accident.

Making it obvious

This is where most help centres quietly fail. The submit link exists, technically, at the bottom of a page, in grey, next to the copyright notice.

Three things worth doing, none of them difficult.

Put a visible submit action on every help centre page, article pages included. Somebody who's just read an article that didn't answer their question is exactly the person you want to catch, and that's the moment they're deciding whether to give up.
Link directly to the right form. Every ticket form has an ID, so you can send people straight to it: https://yourcompany.zendesk.com/hc/en-us/requests/new?ticket_form_id=360000123456. Put the returns form link in the returns article. Your tickets arrive pre-categorised and the customer never sees a dropdown of internal-sounding names.
Say what happens next. A line reading "we reply within one working day" on the form itself does more for your ticket volume than any amount of design, because it's the second-guessing that generates the follow-up.

The field-by-field detail of what that page shows is in the submit a request form guide.

Sign in, or not

Whether the customer must be signed in before submitting is a setting, and it's a genuine trade-off rather than a best practice with one right answer.

Signed in gives you a verified identity, a working request history and a much cleaner user list. It also loses the person who can't remember which email address they used, and on a consumer product that's a lot of people who'll just email you instead and end up as a second user record anyway.

A reasonable middle: allow submission without an account, but recognise people who are signed in and prefill everything you can. Asking a logged-in customer for their email address makes you look like you don't know who they are, and they're right to find that odd.

What happens after submit

The customer presses the button and the page changes. That moment is where your future ticket volume gets decided.

A confirmation email, sent by a trigger, is the single most important message in your whole setup. It should confirm the request arrived, give the reference, state when to expect a reply, and explain how to add information: by replying to that email, rather than by filling the form in again.

The requests page, usually at /hc/requests, lets a signed-in customer see their open tickets and add comments. It's genuinely useful and almost nobody links to it. If you allow anonymous submissions, most of your customers can't use it at all, which is worth knowing before you point people there in a macro.

The follow-up trap

Here's the specific failure, and it happens in every helpdesk that has ever existed.

The confirmation lands in spam, or the customer skims past it. A day passes with no reply they can see. So they go back to the help centre and submit again, often from a different address, with a shorter and crosser description.

You now have two tickets about one problem, and depending on how your views are built, two different agents may pick them up and answer differently. It isn't the customer being difficult. It's your confirmation not being seen, and it's the most common way a well-designed form still produces a mess.

A five minute audit

Open your own help centre in a private window and try to raise a ticket as a stranger. Time it. Count the clicks from the home page.

If it took more than three clicks, or if you had to scroll to find the link, your customers are emailing you instead and your carefully built form fields are sitting empty. Fix the path before you add another field to the form.

FAQ

Frequently asked questions

How does an end user create a ticket?

Through the help centre form, an email, or the widget. Any Zendesk create a ticket end user flow ends in the same place, and to raise a Zendesk ticket without signing in the form has to allow anonymous requests.

How does an end user submit a ticket in Zendesk?

By emailing your support address, using the help centre submit a request page, filling in the widget contact form, or starting a chat that becomes a ticket.

Where is the submit a request page?

Usually at /hc/requests/new on your Zendesk help centre domain. You can also link straight to a specific form using its form ID as a URL parameter.

Can customers see their submitted tickets?

Signed-in users can, on the requests page in the help centre. Anonymous submitters cannot, which is a real cost of allowing anonymous submission.

How do customers add information to an existing ticket?

By replying to the notification email or commenting on the request in the help centre. Say so explicitly in the confirmation, or they will submit a second ticket instead.

Why do we get the same request more than once?

Usually because the confirmation was not seen and the customer assumed the first one failed. Fix deliverability and wording first, then handle the duplicates that remain.

The second submission

When a customer submits twice because the first confirmation was never seen, Ticket Merger matches the pair on requester and subject and merges them.

Start free trial

14-day free trial. No credit card required.