Designing a Request Path People Use

Every unapproved application is evidence that the approved route was slower than the need. Designing the route is therefore the main lever on shadow IT.

The target

An answer within days for most requests, not weeks.

A predictable process, where a requester knows what will happen and roughly when.

A visible catalogue, so a large share of requests are answered with "we already have that".

A route for urgency that is not a policy breach.

The form

Five fields, not twenty.

What do you want, what will you use it for, what data will go in it, how many people, and roughly what does it cost.

That is enough to tier the request and to route it. Everything else can be asked if needed.

A long form filters out the requests you most want to see, because the person with a deadline abandons it and uses a card.

The routing

Low tier: automatic or near-automatic. Internal or public data, no integration, below a cost threshold. Register it, name the owner, approve. Days.

Medium: a security look and a duplicate check. A week.

High: full assessment. Weeks, and the requester was told that at the start.

Publish the tiers and the expected timescales, so the answer to "how long will this take" is on a page rather than a guess.

The duplicate check

The step with the highest return and the one most often missing.

Before anything else, check whether the organisation already has something that does this.

Frequently it does, and the request resolves in an hour with an existing licence rather than a new purchase.

This requires the register to be searchable by what an application does, not just by name — which is why the register has a one-line description field.

Report how many requests resolve this way. It is one of the clearest demonstrations that the programme pays for itself.

The catalogue

A visible list of what is already licensed and available, with what each is for and how to get access.

Findable by problem, not by vendor name. People search for "screen recording", not for a product.

Kept current, which is the hard part and which follows from the register being current.

A good catalogue prevents requests entirely, which is better than answering them quickly.

Urgency

A defined fast route for genuine urgency, with a lightweight retrospective review.

Better than the alternative, which is a card purchase you find out about in six months.

Log them, and look at the pattern. Repeated urgency in one area means the catalogue has a gap.

What kills it

No response. A request sitting unanswered for two weeks teaches everyone not to bother.

Requiring justification of the obvious.

A committee that meets monthly.

Saying no without an alternative. A refusal with no route to solving the underlying problem produces a card purchase, not compliance.

Inconsistency. Two similar requests handled differently makes the process look arbitrary and undermines it more than slowness does.

The measure

Median time to answer, by tier.

Proportion resolved by an existing licence.

Proportion of new applications arriving through the path versus discovered afterwards. This is the real measure of whether the path works, and it should trend upward for years.

The catalogue entry

What a catalogue entry needs to prevent a duplicate request, which is more than a product name.

What problem it solves, in the words people would use to search.

Who it is for, by role or team.

How to get access, with a link.

What it must not be used for — data types, external sharing.

Who owns it.

Whether there is a cost to the requesting team.

Searchable by problem, not by vendor. Somebody looking for "screen recording" should find it without knowing the product name, which is the entire point of the catalogue.

Handling a refusal well

Saying no badly produces a card purchase, which is worse than the tool you refused.

Say why, specifically, rather than citing policy.

Offer the alternative from the catalogue, and check it actually meets the requirement.

Where no alternative exists, say so and treat it as a gap to fill rather than a request to close.

Offer a conditional yes where possible: approved for this data but not that, or approved for a trial period with a review.

Record the refusal and the reason, so the next identical request gets a consistent answer.

Track refusals that reappear as discovered shadow IT, which tells you exactly which refusals were wrong.