Ticket types and intake questions

Most slow tickets are slow because the first reply is a question. Typed intake fixes that by asking for what you need at the moment the request is raised.

The trade-off is real: every extra field costs you some submissions.

Who this is for

Support leads deciding how requests should arrive.

Before you start

• Permission to manage support settings.
• A look at your recent tickets — specifically, what your first reply usually asks for.

Every field is a tax on submitting
Each question you add makes the form slightly less likely to be completed. That is worth paying when the answer genuinely saves a round trip, and not worth paying for information you could look up yourself. Start with the one or two questions your first reply always asks and stop there.

Set up typed intake

1. Read your own first replies
   Go through recent tickets and note what your first response asks for. That list is your intake questions, evidenced rather than imagined.
2. Define the request types
   Group requests into the few kinds you actually handle differently. If two types get the same treatment, they are one type.
3. Add the questions each type needs
   Different types need different details. A billing question and a bug report should not be asked the same things.
4. Keep it short
   One or two questions per type. The goal is removing a round trip, not building a survey.
5. Test it as a customer
   Submit the form yourself from outside and read the ticket that arrives. If it still leaves you needing to ask something, adjust.
6. Revisit after a few weeks
   If a field is being filled with nothing useful, remove it. Fields that do not earn their place cost you submissions for no benefit.

What you get

• Tickets arriving with the details needed to start work.
• Fewer first replies that are only a question.
• Requests sorted into types your team handles differently.
• A form that stays short because it was tested and trimmed.

Frequently asked questions

How many questions should I ask?

As few as remove a round trip. One or two per type is usually right. Every additional field reduces the number of people who finish the form.

What if a customer picks the wrong type?

Expect it. Types are a routing aid, not a contract — an agent can correct it. Design so a wrong choice is recoverable rather than trying to prevent it.

Should I make fields required?

Only where you genuinely cannot start without the answer. A required field that someone cannot answer means they abandon the form instead of contacting you.

Where does typed intake appear?

On the help center contact form, which is the customer-facing route into your ticket queue.