Requests pile up across emails, channels, and tickets. Your senior people spend their week on traffic control.
A designed intake system for IT, with three lanes, capacity-aware forecasting, and the maths to back the design before rollout.
- Discrete-event simulation
- Capacity modelling
- Service design
The problem in depth
Most IT teams I work with do not have a front door. They have several. Email, Slack, Teams, two ticketing systems, the boss who walks over. Requests land in different shapes, get triaged inconsistently, and the commitments made to requesters are mostly fiction.
The cost is not just chaos. Your most senior people spend their week routing work instead of doing it, and your stakeholders learn not to trust forecasts. Every escalation is a vote of no-confidence in the system you are running.
I design front doors as systems, not as forms. A working intake separates work into honest lanes, communicates capacity in real time, and forecasts in ranges that adjust as conditions change.
"Stop being a dispatch desk. Start running an intake system that tells the truth to requesters and teams in real time."
From a front-door design proposal
What I deliver
-
Three-lane taxonomy
A clear tier structure (Straightforward, Considered, Open-ended) with examples, criteria, and a routing rubric anyone can apply.
-
Capacity model
A team-level model of demand against capacity, with thresholds for green, amber, and red, and rules for what each state means.
-
Forecast ranges
Range-based commitments to requesters that widen and narrow as the system observes itself, not point estimates that lie.
-
Discrete-event simulation
A model of the proposed system that shows how the design handles realistic traffic before it goes anywhere near production.
-
Rollout plan
A staged rollout with what to instrument, what to communicate, what to leave alone in iteration one, and what to expect at each stage.
How I work
I start with two weeks of observation: how requests actually land, who triages them today, and what the commitments look like versus what the requesters experience. The simulation comes next; rollout is the last 30 percent of the work, never the first.
Worked example
A platform engineering team buried under intake from 14 product squads. The redesign moved 60 percent of requests onto a self-service straightforward lane within two months, and senior engineering time on triage dropped from 12 hours per week to under 3.
Three lanes, three honest commitments
The intake taxonomy in one figure. Each lane has its own forecast logic, its own capacity flag, and its own route. Nothing is forced into "we'll get to it when we get to it".
-
Straightforward
62% of planAccess requests, environment refreshes, standard configuration changes.
RouteSelf-service or single-team automation. No human triage on the happy path.
-
Considered
88% of planCross-team integrations, security reviews with non-trivial scope, scoped data work.
RouteRouted through a triage rubric to a single accountable team, with a named driver.
-
Open-ended
104% of planStrategy questions, capability builds, anything that needs a discovery loop.
RouteTriaged into a discovery loop. Forecast emerges from the work, not from the form.
Discuss a it front door engagement.
A 30-minute conversation is enough to know if we should keep talking.