Request Form Template
Every organization runs on requests, and most run them through the worst possible infrastructure: the inbox of whoever was unlucky enough to be named in the message. IT requests die in one inbox, facilities requests in another, and the requester’s experience is identical in both — submit into silence, wonder, follow up, discover the request went to someone who left in March. The problem isn’t any single team’s responsiveness. It’s that the organization has many front doors and no system deciding which door a request belongs behind.
This request form template is that system: one intake for every internal service, a routing structure that sends each request to its owning team automatically, severity that triages rather than decorates, and a lifecycle from submission to resolution that anyone with access can audit. It’s the front door for IT helpdesks, facilities, HR service delivery, finance requests — any function whose work begins when someone asks for something.
The Routing Table
The intake’s most important field is the first one after identity: a dropdown of service categories — IT support, facilities, HR, finance, access and permissions, procurement. Each category is a routing key: submissions notify the owning team through self notifications the moment they land, so requests reach their destination without a single forward. The category list deserves governance — it’s the map of your internal services, and it should be maintained like one: reviewed quarterly, extended when new services appear, pruned when categories gather dust. A request landing in other is a routing miss worth investigating, not a bucket worth normalizing.
Severity That Means Something
Severity fields decay into noise when every requester marks everything critical — so the form defines severity behaviorally rather than adjectivally. A multiple choice where each level states its consequence: blocked — cannot work until resolved; degraded — workaround exists; routine — no time pressure. Requesters who must choose between described states answer honestly, because the descriptions force the question the word urgent lets them skip. The triage queue then sorts by the answer, and the response-time expectations each level carries become the internal service levels — published on the form’s confirmation screen so requesters know what they’ve bought with their severity selection.
The Description That Prevents the First Reply
The request’s second-most-expensive failure is the description that triggers a clarification round before any work begins. The form structures the description to avoid it: a long text field for what’s happening and what’s been tried, with conditional follow-ups per category — revealed by the routing choice — asking the questions each team always needs: device and software for IT, location for facilities, the employee affected for HR. A file upload takes the screenshot that replaces a paragraph. The pattern is the intake equivalent of a good triage nurse: enough structure that the request arrives diagnosable, enough openness that reality fits.
The Lifecycle, Auditable
Once intake is centralized, the request’s whole life becomes visible: submitted, routed, resolved — each stage timestamped in the response archive, which converts the eternal internal argument (how long do these things actually take?) into a filterable fact. Resolution patterns surface from the same archive: the request type that recurs weekly (build the self-serve article), the team whose queue chronically backs up (staffing or scope conversation), the category nobody uses (retire it). Where requests must feed external tooling — ticketing systems, asset registers — a webhook carries each submission onward, and shared workspaces with role permissions give every team visibility of its own queue and nobody else’s.
Serving External Requesters Too
The same structure serves client-facing teams: agencies receiving client requests, departments serving other companies, service desks with external users. The form is white-labeled to the serving organization, and the confirmation screen carries the external-facing service promise. The template sits in the request templates sub-category, with the creative-adjacent variant in the creative request form family.
Frequently Asked Questions
One form for everything, or a form per team?
One form with routing, until volume proves otherwise. A single front door is simpler to publish, simpler to train, and simpler to audit — and the category dropdown does the dividing a multi-form setup does painfully. Teams do eventually split off forms for high-volume specialist intakes (a dedicated IT intake with deep diagnostics, say), but the general front door remains the default and the catch-all.
How do we stop severity inflation?
Behavioral definitions, published response times, and gentle consistency: when a blocked request and a routine request visibly receive different speeds, requesters learn the scale means something — and when severity is ignored, they learn it doesn’t. The archive’s data makes the consistency visible internally too: a queue sorted by stated consequence is defensible in a way a queue sorted by requester volume isn’t.
What belongs in the form versus the team's own tooling?
Intake and the record in the form; execution and status in the team’s tools. The form’s jurisdiction ends at a complete, routed, timestamped request — everything after belongs to whatever system the team works in, fed by webhook where the handoff should be automatic. Trying to run the whole lifecycle in the form works at small scale and fails at exactly the moment the team needs its real tools.
How do we handle requests that arrive at the wrong team?
Cheerfully and visibly: any team can reroute a misrouted request, and the archive records the reroute — which turns misrouting from an invisible failure into calibration data. A category that misroutes weekly has a naming problem (fix the label) or a boundary problem (merge or split the category). The front door improves itself, but only if the reroutes are recorded rather than grumbled about.
Should requesters see request status?
At minimum, they should see the lifecycle timestamps on their own request — which the archive provides without any extra machinery. Teams that close the loop with a resolution notification (a self notification to the requester at resolution) report the biggest trust gain for the smallest effort: the difference between a request system and a suggestion box is precisely that the requester finds out.