Building an IT intake process that captures the why

An IT intake process is the front door for every request that competes for technology capacity. When it works, leaders see all demand in one place, compare requests fairly, and approve work with a clear purpose. When it doesn't, requests arrive through email, hallway conversations and executive favors, and the loudest voice decides what gets built.

The goal isn't more paperwork. It's capturing the why behind each request at the moment it's cheapest to capture.

Signs your intake process needs work

• Teams learn about new projects after they've been promised to someone.
• The same request is submitted three times in three different places.
• Nobody can produce a list of everything waiting for a decision.
• Approved projects often lack a clear objective or owner.
• People bypass the process because it's too slow.

The last one matters most. An intake process that takes six weeks to say no will be routed around, no matter how well designed it is.

Step 1: One front door

Pick a single place where every request is submitted, and make it the only path to capacity. Requests that arrive elsewhere get redirected there, politely and every time. This alone can make demand visible for the first time.

Step 2: Ask for the problem, not the solution

The request form should be short and focused on the why. Five fields are usually enough:

1. Problem: who is affected, what happens today, what it costs. (See How to write an IT problem statement.)
2. Objective: the measurable result that would show success.
3. Owner: the business person accountable for the outcome.
4. Urgency: a date that matters and why, if any.
5. Affected area: the product, process or system involved.

Resist the urge to add more. Estimates, risk ratings and architecture notes belong to assessment, not intake. A long form discourages good requests and rewards people who are good at forms.

Step 3: Triage fast, then route by size

Triage should happen within a few business days and answer three questions:

• Is the request complete enough to assess? If not, send it back with specific questions.
• Is it really a project, or a support issue or small change?
• Roughly how big is it?

Then route by size:

Size-based routing keeps small requests moving and reserves leadership attention for investments that need it.

Step 4: Assess with relative scores

For medium and large requests, assess value, complexity and risk on a simple relative scale, such as 1 to 5. Relative scoring is fast, good enough to compare requests, and avoids false precision. Identify which teams and systems the request touches, because hidden dependencies are a common source of surprise. See Getting estimates from every impacted team.

Step 5: Decide on a regular rhythm

Hold a recurring decision forum: every two weeks or monthly works for most organizations. Each request leaves with one of four outcomes:

• Approved, with an owner, an objective and the assumptions recorded.
• Deferred, with the condition for revisiting.
• Declined, with the reason.
• Returned, with the questions that need answers.

Record every outcome. A declined request with a clear reason is valuable information for the requester and for future decisions. See Designing a project approval workflow.

Step 6: Show the queue

Make the list of open requests visible to requesters and stakeholders: what's waiting, where it is, and what's next. Visibility reduces the "just checking in" emails and builds trust that the process is fair.

Measuring your intake process

Track a few simple measures:

• Time to triage: days from submission to first response.
• Time to decision: days from complete request to decision.
• Completeness rate: share of requests that arrive with problem, objective and owner.
• Bypass rate: work started without going through intake.

If time to decision is long, people will bypass the process. Fix speed before adding rigor.

How Aizu supports intake

Aizu gives every request one place to land, with the intended outcome, owner and product placement recorded at intake. Requests that lack context are marked as needing it. Value, complexity and risk ratings let a review compare items side by side, and decisions are recorded with their rationale. Requesters and leaders see the same queue. Related: Stage gates without bureaucracy.