Submit Request
Work enters through a shared intake path instead of side-channel emails, chats, or hallway asks.
Shows how work enters SysOps, how it is prioritized, and how different audiences stay informed.
The intake and prioritization flow is now route-native in `apps/web`, turning the operating model itself into a first-class product surface instead of leaving it in the legacy demo layer.
This is the simplest version of the process. Every request should move through these same core steps.
Work enters through a shared intake path instead of side-channel emails, chats, or hallway asks.
IT identifies whether the work is an incident, standard support request, access/security request, or project/enhancement item.
Priority is based on mission impact, time sensitivity, risk, dependencies, and available capacity.
Some items move immediately, some are scheduled into the queue, and some require leadership tradeoff or sponsor input.
An owner is assigned, the work moves forward, and blocked items are surfaced quickly instead of silently stalling.
IT confirms the fix or delivery worked, explains status in plain language, and shares timing changes early.
Work is closed cleanly, recurring issues feed runbooks or problem review, and leadership reporting stays current.
This keeps prioritization from feeling arbitrary. These are the factors leadership and stakeholders should expect IT to use.
Does this affect core agency operations, public reporting, leadership decisions, or staff productivity in a meaningful way?
Is there a real deadline, outage, audit timing issue, or external commitment driving when this must be done?
Does delaying the work create security, access, continuity, or governance risk for the agency?
Can IT complete this quickly, or does it depend on vendors, approvals, other teams, or prerequisite work?
If this moves up, what work moves down? The queue should show that tradeoff clearly.