Access request management is fine until four people start on the same Monday. Then a process designed around one request at a time produces twelve, arriving within an hour, each needing a different approver, and the person handling them has no way to tell which are urgent.
TL;DR
- Individual requests are not the problem. Cohorts are, because they arrive together and compete.
- Role templates remove most of the volume, and most teams can write three of them in an afternoon.
- The approval step is usually the bottleneck, not the granting step.
- An access request with no record is an offboarding problem you have not had yet.
- Standing access beats a fast request process for anything predictable.
- Measure time to first productive hour, not tickets closed.
Why cohorts break a process that works
A single access request is a small, well understood piece of work. Somebody asks, somebody approves, somebody grants. Teams build a process around that shape and it serves them well for years.
A cohort breaks it in three ways at once. The volume arrives in a burst rather than a stream, so queueing behaviour appears that never existed before. The requests are correlated, so a single absent approver blocks four people instead of one. And the requesters are all new, so none of them knows what to ask for, which means a large share of the requests are wrong on arrival and generate a second round.
None of this is fixed by handling requests faster. It is fixed by having fewer of them.
Role templates do most of the work
The single highest return change in this area is writing down what each common role gets by default, and granting it without anybody asking.
Most teams resist this because it feels like over provisioning. In practice the opposite is true. When getting access is slow, people request more than they need, because a second request is expensive and they would rather ask once. Predictable standing access for a role reduces total permissions granted, because nobody is hedging.
What to do:
- Take your three most common roles and list what the last three hires in each actually ended up with.
- Remove anything granted and never used, which you can usually see in the tool itself.
- Publish the remainder as the default for that role.
- Grant it automatically at the same time the account is created.
- Keep the request process for everything outside the template.
The list of what people ended up with, rather than what they asked for on day one, is the important input. The first version is always wrong and the retrospective version is close to right.
The bottleneck is approval, not granting
When teams time their access process they usually find the administrator is not the slow part. Granting takes minutes. Waiting for an approver takes days, and the variance is enormous because it depends entirely on one person’s week.
Two things fix most of it. The first is a named deputy for every approver, published in advance rather than found during an escalation. The second is deciding which requests need approval at all, which is a question most organisations have never asked directly. A tool that everyone in a role gets anyway does not need an approval step, and keeping one there is ceremony that costs real days.
Reserve approval for things with a cost, a licence implication or a data sensitivity. Everything else is a template.
A team that measured the wrong thing for a year
A company of about ninety people reported strong numbers on access requests. Median time to close was under four hours and the service desk was comfortably within target.
New starters still spent their first two days unable to work. The reason was in the measurement: the clock started when the ticket was raised, and nobody raised a ticket until they discovered the access was missing. A starter spent the first morning assuming they had not been shown where something was, the afternoon asking a colleague, and raised the ticket on day two. The four hour figure was real and described the wrong interval entirely.
Changing the measure to hours between start time and first successful use of each core tool moved the number from four hours to eleven working hours, and made the problem visible enough to fix with templates.
The record you will need later
Every access granted informally is an offboarding problem that has not happened yet. A request handled by a message and a manual grant leaves no trace, and in two years nobody can tell what that person has.
The minimum record is what was granted, to whom, who approved it and when. It does not need a dedicated system; a spreadsheet beats nothing by a wide margin. What matters is that it is one place and that it is written at the moment of granting rather than reconstructed later, because reconstruction is how audits become weeks of work.
An answering layer is worth a word here for what it does not do. Matram is our own product, and it answers questions from your documentation, so it can tell a starter what their role normally gets, who approves a given tool and how to raise a request. It has no free tier, it is not an HRIS, and its actions reach HubSpot, Zendesk and webhooks only, so it can open a ticket in a connected service desk but it will not grant access or approve anything. WhatsApp is coming soon rather than available. Pricing is flat at $29, $69 and $199 a month with unlimited seats. The approval bottleneck is outside it.
Where effort pays off
| Problem | Common fix | Better fix |
|---|---|---|
| Too many requests | Faster handling | Role templates granted by default |
| Requests sit waiting | Chase the approver | Named deputy, published in advance |
| Wrong things requested | Better request form | Publish what the role gets |
| Nobody knows who has what | Annual audit | Record at the point of granting |
| Cohort week overload | Overtime | Provision from the start date, not the request |
The checklist worth keeping
Checklist:
- Three role templates written and published.
- Template access granted at account creation, not on request.
- Every approver has a named deputy.
- Approval reserved for cost, licence or sensitivity.
- Every grant recorded in one place at the time it happens.
- The measure is time to first productive use, not ticket closure.
Final Thoughts
Access request management gets treated as a throughput problem and it is mostly a prediction problem. The requests that arrive in a cohort week are overwhelmingly predictable, which means they did not need to be requests at all.
Write the templates, grant them automatically, keep approval for the things that genuinely warrant it, and record what you gave people. The queue stops being the problem because most of it stops existing.
Frequently asked questions
What is access request management?
It is the process by which somebody asks for access to a system, that request is approved, and the access is granted and recorded. In small teams it is usually a ticket queue and a person. The quality of it is judged by how quickly somebody can do their job, not by how fast tickets close, and those two measures can diverge a long way.
Is standing access by role a security risk?
Less than most people assume, and often less than the alternative. When access is slow to obtain, people request more than they need so they do not have to ask twice, which inflates total permissions. A published default built from what people in that role actually use tends to grant less overall, and it is reviewable in a way that ad hoc grants are not.
Which requests still need approval?
Anything with a per seat cost, a licence implication or access to sensitive data. Everything else is a reasonable candidate for a role template. Keeping an approval step on a tool that everybody in a role receives anyway adds days of waiting for a decision that was never genuinely in question.
How should we measure this?
Measure working hours between a starter beginning and their first successful use of each core tool. Ticket resolution time is misleading because the clock starts when somebody notices a gap and raises it, which can be a day or more after the gap mattered. The two numbers often differ by a factor of three.
Can an answering agent handle access requests?
It can explain what a role normally receives, name the approver and tell somebody how to raise a request, and some can open a ticket in a connected service desk. Granting and approving are separate capabilities that belong to identity management and to a human respectively, so an answering layer reduces the question load around requests rather than the requests themselves.
What record should we keep?
What was granted, to whom, who approved it and when, written at the moment of granting rather than reconstructed afterwards. A spreadsheet is enough to start. The value appears at offboarding and during audits, when the alternative is working backwards through chat history to guess what somebody still has access to.
