An intake form that does not route is a form that puts a person in the middle of every request. For low volume, that person is fine, and the form is fine. For higher volume, that person becomes a bottleneck, and the form becomes a complaint at the next retro. The fix is to make the form route automatically. The fix is harder than it sounds, because most teams design their forms for capture and then bolt routing on later.
This is the working version of how to design an intake form whose routing actually works in production, with rules that survive the awkward edge cases that show up after launch.
The form is the routing input
The most important piece of advice on this topic is the simplest. The form is the input to the router, and the form must be designed with routing in mind. A form that asks for what the team needs to know to do the work, but not for what the team needs to know to route the work, is a form that cannot route automatically.
The second most important piece of advice. Routing logic that depends on free text fields almost never works. The router needs structured fields. Drop-down selectors, multiple choice, yes-no questions. Free text is for context and detail that humans will read, not for fields the router will branch on.
A useful exercise when designing the form. Write the routing rules first, in plain English. "Requests for new hardware go to IT. Requests for software access go to IT-security. Requests for benefits questions go to HR." Then design the form fields that produce the data those rules need. The form question that asks "what is this request about" with a drop-down of categories that exactly match the rules is what makes the routing real.
If the rules cannot be written in plain English, the routing cannot be automated. That is a real finding. Some workflows are too complex to route by rules and need human routing. Owning that fact is better than building a router that pretends to handle the workflow and breaks under contact.
Conditional fields are how to keep the form short
The instinct, once routing requirements are clear, is to ask every possible question on the form. The form gets long. People abandon it. The team gets fewer requests, which the team interprets as a quiet quarter rather than as the failure mode it actually is.
Conditional fields are the fix. The form starts short. Based on the first answer, additional fields appear. A request to IT for a laptop reveals fields about model, configuration, and shipping address. A request to IT for VPN access reveals different fields about the system being accessed and the time period. The respondent only sees the fields relevant to their request.
The team's job is to design the conditional logic. The decision tree behind the form. Most teams find that two or three levels of conditionality is the right depth. Beyond that, the form starts to feel like a wizard, and respondents get lost. If a request type needs more than two or three layers of branching, it probably should be a separate form rather than a deeper branch of an existing one.
Routing rules in production
The first version of the routing rules is always wrong in some way that surfaces only in production. Real requests do not always fit the categories the team designed. The router has to handle the edge cases without becoming a maze.
A few patterns hold up.
Default routing. Every form should have a default destination for requests that do not match any rule. The default is usually a human triage queue. The triage queue is owned by a named person or rotation who handles unmatched requests by either routing them manually or refining the rules so that the next similar request matches automatically.
Tiebreaker routing. When two rules could match, the rule with more specific conditions wins. The router's logic should be deterministic about this. Production routing systems that produce nondeterministic results when rules overlap eventually produce ambiguous routing decisions that surface in incident postmortems.
Override routing. There are always requests that need to go somewhere other than where the rules say. The router should support a manual override that captures the override and the reason. The overrides are themselves data. A request type that gets overridden frequently is a sign that the rule for that type is wrong and should be updated.
Periodic rule review. The routing rules should be reviewed quarterly. New request patterns appear, old categories become irrelevant, and approval chains shift. A team that sets up routing once and never revisits it produces a router that gradually becomes less useful as the underlying work changes.
Approvals belong in the routing flow
A common mistake is to treat approvals as a separate step that happens after routing. In practice, approvals are part of the routing. The request goes from the form to the first approver, then to the second approver, then to the team that does the work. Each transition is part of the routing flow.
Designing this explicitly produces a few benefits. The approvers know they are in the flow before the request lands on them. The system can track time spent at each approval step. Requests that stall at a particular approver can be escalated automatically.
The mistake to avoid is over-designing the approval flow. Most internal workflows need at most two approvals. Some need none. The pattern of "approval required from manager, director, and VP for every request" tends to produce delays without actually catching problems, because each approver assumes the others did the real review. A leaner approval flow, where the people in the flow each have a clear and distinct role, produces better outcomes than a longer one.
The status updates that matter
The intake system should produce a small set of status updates that are visible to the requester. Each update marks a transition that the requester actually cares about.
Submitted. The request was received. This is usually an automatic confirmation.
Approved. The request was reviewed and approved. This is the first update most requesters actually want.
In progress. Work has started. The expected completion date or window goes here when possible.
Complete. The work was finished. The requester should hear this without having to ask.
Held. The request needs information from the requester before it can proceed. The system should make it easy to reply.
Updates beyond this set tend to be noise. The team's instinct is sometimes to update the requester at every internal handoff. Most requesters do not care. They care about the status that affects them.
The updates should arrive as email, by default, with a link to a public status page if needed. Forcing requesters to log in to a separate tool to see status is one of the most reliable ways to make an intake system feel slower than the inbox it replaced.
The first thirty days after launch
The pattern after launch is consistent. The first thirty days produce most of the rule edits and form refinements that the launch design did not anticipate. The team should treat this period as planned tuning, not as a reason to declare the project over budget.
The team should track every request that needed manual override or manual triage in the first thirty days. Each of these is data about how the form and the rules need to evolve. Most teams find that the volume of overrides drops sharply after the first month of tuning, then stabilizes at a low rate that is largely unavoidable.
The team that schedules the tuning explicitly into the project plan tends to ship a working intake system in five or six weeks. The team that treats the launch as the end of the project, and the tuning as someone else's job later, tends to ship a flaky intake system that takes a quarter to settle into reliability. The work is the same. The schedule is the difference.
The team that gets this right finds that the form, three months in, is processing meaningfully more volume than the inbox could, with less management overhead, and with a record of every decision that anyone made. That is the work of an intake form that actually routes.