Customer Service Request Form: Routing, Urgency, and Status Schema

A customer service request form that only collects name, email, and a message produces an inbox, not a workflow. The schema that makes requests routable lives in three layers: routing, urgency, and status.

Routing: one owner per category, plus a fallback

Routing should be a strict mapping, not a suggestion. Each category on the form maps to exactly one owner or team:

billing            -> finance
something_broken   -> support engineer on duty
how_do_i           -> support
other              -> triage owner (fallback)

The fallback row is the one teams skip. Requests that do not fit any category, or that customers miscategorize, need a named owner and a reclassification deadline. Without it, "other" becomes the oldest unanswered bucket in the queue.

Urgency: do not trust the dropdown alone

A Low/Medium/High/Critical dropdown gets gamed in both directions: anxious customers overselect, polite customers underselect during real outages. Treat it as one signal among three, and combine it with what the category implies and what the request text contains:

urgent = customer_selected_high
      OR category in [outage, billing_dispute]
      OR content matches [outage, "cannot log in", "charged twice", legal]

Matched requests skip the normal queue and alert a person directly, with the matched reason attached. Two lanes, normal and urgent, resolve most real-world ambiguity. Avoid five priority tiers that nobody can consistently apply under pressure.

Status: a vocabulary, not a mood

new -> triaged -> in_progress -> waiting_on_customer -> resolved
                                                       -> excluded

waiting_on_customer keeps the queue honest about who is blocking whom. excluded removes spam, tests, and duplicates from your metrics before they inflate your backlog count. Internal and customer-facing status should be separate projections of this same state, not the same field exposed twice.

This schema does not include refund-specific fields or decision states -- that is a distinct design problem covered separately.

The full version, including intake field design and the FAQ, is in the Customer Service Request Form guide.