A support form is a queue, and a queue needs an owner and a category.

The category is the whole design

One inbox with every request in it requires a human to sort before anyone can work. A category field moves that sorting to the visitor, who already knows what the problem is about, and a route rule finishes the job by sending the notification to the right recipient.

<form action="${host}/f/FORM_ID" method="POST">
  <label for="category">What is this about?</label>
  <select id="category" name="category" required>
    <option value="">Choose one</option>
    <option value="billing">Billing and invoices</option>
    <option value="delivery">Delivery</option>
    <option value="account">Account access</option>
    <option value="other">Something else</option>
  </select>

  <label for="detail">What is happening?</label>
  <textarea id="detail" name="detail" rows="5" required></textarea>

  <label>
    <input type="checkbox" name="blocked" value="yes">
    This is stopping my work
  </label>

  <button type="submit">Send request</button>
</form>

Give them a reference

The most useful thing a support form can return is an identifier. "Your reference is 8f2c…" lets the next email start from the record instead of from a description of the record. A JSON submission returns that id on success, so put it in the success message.

Trust the text, not the scale

Four-level priority menus convert poorly and lie consistently. A single "this is stopping my work" checkbox is honest, easy to answer, and correlates with what actually needs attention first — combined with the category, it is enough to triage without a second round of questions.

What a support form should not do

• Require an account, which locks out the people who cannot sign in.
• Ask for information already on the order or the account.
• Promise a response time the team has not agreed to.
• Send the notification to a shared inbox nobody owns on a Friday.