Access Requests and Waiting

Most organisations measure access provisioning in days and the work involved in minutes. The gap is pure waiting and it is the largest single friction in many places.

The friction described in “Access Requests and Waiting” becomes easier to prioritise when the team can separate active work from waiting and repeated handling. An organisation evaluating the platform summary can record time against the affected workflow and compare the effort before and after a change, while ticket and device records remain the evidence of the technical event itself.

For an independent benchmark, compare this approach with Nielsen Norman Group; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

Where the time goes

Waiting for the requester to find the right form.

Waiting for an approver who is in meetings.

Waiting for a second approver.

Waiting in a queue for somebody to action it.

And frequently waiting to discover that the request was wrong and must be resubmitted.

Actual work: minutes. Elapsed: days.

Measuring it

Elapsed time from request to working access, by system.

Split into waiting-for-approval and waiting-for-action.

Your workflow system records both already.

One query, and the result is usually the most persuasive number the programme will produce.

The fixes that need no technology

Delegation thresholds: below a defined risk level, one approver rather than two.

Auto-approval for role-standard access, granted on joining rather than requested.

Named deputies for every approver, so leave does not stop the queue.

A service level for action time, published.

Each of these is a policy decision and each removes days.

Role-based provisioning

The structural fix: define what a role needs and grant it at onboarding.

Most requests are for access the person was always going to need.

Doing it on day one removes the request entirely, which is better than making the request faster.

The objection is that roles are messy, which is true and is a reason to start with the clearest ones rather than to abandon the approach.

The security conversation

Every reduction in approval steps meets a security objection, and some of those objections are right.

The productive framing is risk-proportionate: full review for sensitive systems, automatic grant for the ones everybody has.

Bring the elapsed-time figure to that conversation. Security teams respond to evidence that the current arrangement produces workarounds, which it does.

Expiry and re-request

Access that expires generates repeat requests and repeat waiting.

Where the expiry is a real control, keep it and automate the renewal path.

Where it is habit, extend it.

Repeated identical requests from the same person are a design signal, not a user problem.

What to check

Do you know elapsed time to working access, by system?

How much of it is waiting for approval versus waiting for action?

Is any access granted automatically by role?

And does every approver have a named deputy?

The point

Granting role-standard access at onboarding removes the request entirely, which is better than making the request faster..

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.