Designing a request form with useful categories

Choose request categories by what happens after submission. A useful category helps the receiving team triage the work or ask the right follow-up question. Its label should also make sense to someone who does not know the team's internal structure.

Start with the receiving team's decisions

Sample the requests the team handles. For each, note who first reviews it, what information they need and whether it follows a different process. If two proposed categories always lead to the same review and questions, one clearer choice may be enough.

For a hypothetical facilities form, Lighting, Heating or cooling and Room access could prompt different details. The facilities team must choose the actual list. A submitter should not need to know whether an employee or a contractor will do the work.

Give each choice a boundary

Explain labels that could mean two things. “Room access” might describe a broken lock or permission to enter; those may need different routes. Give staff realistic examples and ask which category they would choose before you explain the intended answer.

Provide Other or unsure for cases that genuinely do not fit. Ask for a description and make a named coordinator responsible for reviewing these requests.

Repeated similar entries may reveal a missing category. One unusual case does not necessarily justify a permanent choice.

If an urgent route is needed, define what qualifies, what the submitter should provide and who checks it. Do not promise a response time the team has not agreed to provide.

Ask for facts available now

A first form might ask where the problem is, what happened, when it was noticed and how the team can clarify the report. Make labels specific: “Which room has the problem?” is clearer than “Location” when someone might otherwise enter their own office.

Show a follow-up question only when the chosen category calls for it. A lighting report may need a room and fitting; a room-access report may need a door or entrance.

If the category changes, decide what happens to answers that are now hidden. Check the chosen builder's configured behaviour before assuming those answers are cleared.

Do not ask the requester to supply an owner, approval result or closure reason. Require a value only when it is needed at submission and the person can reasonably know it. Where an unknown answer is acceptable, let them say so rather than guess.

Make submission and correction clear

If a routing mistake would be costly, let the person review the category and description before saving. After a confirmed save, show the request ID and next step. A queued or failed write needs different feedback.

Decide how the requester can add a missing detail and how a coordinator can correct the category. A changed category may require a new assignment. Keep the original description available so the receiving person can understand the report.

Before rollout, use fictional straightforward, ambiguous and uncategorised requests. Ask intended users to complete the form without coaching, then inspect the saved records and where each would go.