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.
Top comments (1)
Very solid breakdown — especially the separation of routing vs urgency vs status as independent systems rather than one overloaded “ticket model.”
The routing layer is doing the most important architectural work here: forcing ownership determinism. The explicit fallback owner is a detail a lot of systems miss, and it’s usually where “other” becomes permanent debt instead of a temporary classification error.
The urgency model is also well-structured. Treating priority as a multi-signal inference problem instead of a user-controlled field is the right move in practice. Most ticket systems fail exactly because they assume user intent is a reliable classifier.
I also like the status vocabulary design — especially waiting_on_customer and excluded. Those two states are what keep operational metrics honest instead of artificially inflated by stalled or irrelevant work.
If anything, the most important implicit idea here is that this isn’t a “form design” problem — it’s a state machine design problem with human inputs at the edges. Once you frame it that way, most of the common SaaS support chaos becomes predictable.
Clean, practical structure.