Consistent context helps requests get reviewed

The example intake route gathers a clear description of the problem, its impact, and preferred timing before review. A complete request supports a better-informed review; it does not guarantee approval or a particular schedule.

Common questions

Answers for requesters and people following a request.

What belongs in a project request?

Describe the problem, who or what is affected, the expected benefit, and preferred timing. Include relevant non-sensitive context that helps someone understand the need.

What should I do if a reviewer asks for more information?

Answer the specific question and update the request with the missing context, so the review can continue from one clear record.

Can I suggest a solution?

You can describe an idea, but make the underlying problem and desired outcome clear too. That gives reviewers room to consider appropriate options.

What if the priority changes after submission?

Use the approved process to update the request with what changed and why. Do not assume an earlier timing preference still represents the current need.

Does submitting a request put it on the schedule?

No. Submission starts review. Any decision or schedule is a separate communication through the approved process.

Make the request specific

Fictional before-and-after example for the shared reporting scenario.

Details More useful Too vague
Request description Our team manually combines several updates for the weekly summary; a more consistent way to bring them together would help leads compare recurring work. Make reporting better.
Why it helps Names the current problem, affected audience, and intended outcome without locking in a solution. Does not explain what is wrong, who is affected, or what improvement is needed.