Measuring Access Requests: Turnaround, Stalls and Repeat Asks

Friday, 15:30, at Carrow Print. Joel runs a desk of three and has a one-line e-mail from the managing director: "Sales tell me it takes weeks to get anyone access to anything. Is that true?" Joel's honest answer at half past three is that he does not know. He knows the desk is quick, because he sits in it. He knows the sales team's new starters have waited for the customer database more than once, because he remembers the phone calls. And he knows that neither of those is a number. He exports the quarter's access tickets, two hundred and twelve of them, and starts counting. After all, "it depends" is the one answer a managing director has already heard from everyone else.

Measuring access requests means tracking a handful of numbers each quarter. They say how long a request takes from asked to granted, and where the waiting happens and on whom. They show which requests keep recurring and should stop being requests, and what the whole loop costs the desk in hours. The numbers exist to make three decisions: which owner needs a deputy, which repeat request becomes a role bundle, and where the desk's time is going. This article is part of our Access & Permission Requests series, and it is the last in it. The five before it describe the loop. And this one is how to tell whether the loop is working.

It covers what the numbers are for and counting access requests properly. Next come turnaround, the median and the tail, then stalls and where the waiting happens. It covers repeat asks and the bundle candidates, then the desk's hours as a worked example. Next come per-technician numbers with the coaching rule, then reading the numbers together. It finishes with the quarterly report line, a short war story, and the access scorecard to copy, in that order. Every figure in it is from Carrow Print, which is fictional, and is a worked example rather than a target.

What the Numbers Are For

Each number answers a question that leads to an action. And a number that leads to no action is a number the desk should stop counting. Turnaround answers "how long does a requester wait?", and when it is long the action is to find out where. Stall time by owner answers "where?", and the action is a deputy, a timer or a conversation with one named person. Repeat asks answer "which requests should not be requests?", and the action is a bundle approved once. Hours answer "what does this cost the desk?", and the action is the case for the bundles. The review completion count, from the previous article, answers "is the loop closing?" And the action is a line in the report naming who did not close it. Five numbers, five actions. Anything else is decoration.

The numbers are not for ranking technicians. And the reason is structural rather than kind: access turnaround is dominated by approvers, who are not on the desk. And a technician whose requests take longest is usually the one who handles the sales team's requests. A fair per-technician cut exists, with a minimum sample, and a section below describes it. The headline numbers describe the loop, not the people turning it.

Counting Access Requests Properly

The first decision is which tickets count. It has to be written down once so that every quarter counts the same way. The general discipline of deciding the rules before the first count is in Counting Tickets Properly. This is that discipline applied to one ticket type. An access request is a ticket whose outcome is a change in what a person can reach. It counts whether it arrived on the access form, by e-mail, by chat or as a line in an onboarding. A ticket that arrived on the form and turned out to be a broken folder is not one. And a ticket that arrived as "I can't open the finance folder" and was resolved by adding the requester to a group is. The desk marks them at close, with a category, a tag or whatever the tool offers, and the mark is what the quarter's export filters on. Where the access form is a form of its own, most of the marking is already done. This is the case when a department has its own form in QuerySolv and in many tools. In that case, the desk only has to catch the ones that came in sideways.

The second decision is where the clock begins and ends. It begins when the request is complete, meaning the five answers from The Access Request, Done Properly are on the ticket. The time before that, while the desk asks what and for whom, is counted separately as "time to a complete request". That is a number about the form rather than about the loop. The turnaround clock ends when the requester is told the grant is made, not when the grant is made. A grant nobody has been told about is a grant the requester is still waiting for. In between, the clock is split into three. From complete request to the approver being asked is the desk's. From the approver being asked to the approval is the approver's. From approval to the requester being told is the desk's again. The three pieces are the whole of the diagnosis, and a desk that keeps only the total has a number it cannot act on.

Count in working days, with the desk's business hours and not the calendar. That way, a request made at five on Friday and granted at nine on Monday is a few minutes and not three days. Most tools time-stamp every state change and every reply. So the three pieces come from the ticket's history with a spreadsheet and some patience. Where the tool offers service-level targets on a business-hours schedule, as many do, the business-hours arithmetic is already done for the total and the pieces still need the export. Whether the tool's clock pauses while a ticket waits on an approver is a thing to check. Some tools pause it and many do not. The honest desk counts waiting time explicitly rather than trusting either behaviour.

Turnaround: The Median and the Tail

Report the median turnaround, which is the middle value when every request's time is sorted, and never the mean. The mean of two hundred quick requests and twelve stuck ones is a number that describes neither. Joel's two hundred and twelve requests had a median of a day and a half in working days. That is the number the managing director should hear first. It is also the number the sales team would not recognise, because the sales team's experience was the tail. The tail is the slowest tenth or so of requests listed by name. Joel's tail was nineteen requests over ten working days, of which twelve were for the customer database and all twelve had waited on one approver. That is the sentence that answers the e-mail, and it took the median and the tail together to write it.

Split the median by the three clocks and the shape of the loop appears. At Carrow the desk's first piece, from complete request to approver asked, had a median under half a working day. The approver's piece had a median of one working day across all owners. The desk's last piece, from approval to requester told, was under half a day again. For the customer database alone the approver's piece had a median of five working days, and the desk's two pieces were unchanged. That is how Joel could say to the managing director that the desk was not the delay without sounding like a man defending his desk. The pieces are what make the number a diagnosis rather than a grade.

Small counts need care, and access requests are a small count at most small organisations. A quarter with forty requests has a median that two slow tickets can move by a day. And the right report for that desk is the counts and the tail by name, not a median with decimals. Report a range, "between one and two working days", when the count is small. Report the tail always, because the tail is where the action is whatever the count.

Stalls: Where the Waiting Happens

A stall is time a request spends waiting on an approver past the timer the desk set. And the number that matters is not the total but the cut by owner. For each person who approves anything, count how many requests they were asked to approve. Record the median working days they took, and how many went past the timer. The cut is a short table, one row per owner, and at most organisations it has a dozen rows and one or two that explain the whole tail. Joel's table had fourteen rows. Thirteen of them had a median of a day or less. The fourteenth was the sales director, who owned the customer database and approved in a batch on Friday afternoons. She had thirty-one requests in the quarter with a median of five working days and twelve past the timer.

The action for the row is one of three, and it is not a complaint to the owner's manager. An owner with a long median and no deputy needs a deputy, which the approval article describes and which takes one conversation. An owner with a deputy and a long median anyway needs the chase actually run. That is a desk habit and not an owner's failing. An owner who approves everything in a batch once a week, as the sales director did, needs to be shown the row. In that case, ask whether the batch could be twice a week. When Joel asked, it could. The whole mechanism of owners, deputies and timers is in Approval Workflows That Do Not Stall. The stall table is how a desk knows which row of the matrix to go and fix. Nobody has ever been shown their own row and defended it. They ask for the deputy line.

Keep the unknown-owner stalls apart from the approver stalls, because they are a different problem with a different fix. A request that waited four days while the desk worked out who owned the supplier portal did not wait on an approver. It waited on the register, and the fix is a row on it. Count those separately, by resource, and the list of resources with no owner is the list the desk takes to the next access review. At Carrow there were six such requests in the quarter, all for two resources. Both had owners by the following Monday, which is the fastest any measurement in this article has ever turned into a fix.

Repeat Asks: The Bundle Candidates

A repeat ask is the same resource at the same level requested for people in the same role three or more times in a quarter. It is the clearest signal the numbers give, because the action is exactly one thing. Ask the owner to approve it for the role, once, in advance, and stop asking per person. The count is by resource and role together. "The job-costing application, read" requested by seven estimators is a bundle. The same resource requested by seven people from seven teams is seven ordinary requests. Sort the quarter's requests by resource and level, then by the requester's role, and read down the list for runs. Joel found four runs. The warehouse scanner role came up eleven times, all new operatives; job costing read came up seven, all estimators. The proofs folder, edit, came up five, all pre-press. The customer database, standard role, came up nine, all sales starters, which was also most of the tail.

Each run is a bundle, and the bundle is the access half of a role profile, which Role Profiles and Standard Kits describes and the approval article signs. Thirty-two of Joel's two hundred and twelve requests were in the four runs. Every one of them had been approved individually by an owner who was being asked the same question for the eleventh time. A bundle removes the approval step from those thirty-two, which removes the approver's median from their turnaround. For the nine sales starters, that meant the customer database on their first morning instead of their second week. The repeat-ask count is the number that turns the loop into a shorter loop. It is the one to look at first when the desk has time for only one.

Watch for the other repeat, which is the same person asking repeatedly. A requester with five access tickets in a quarter is either in a role whose bundle is missing half its contents or in a role the profile does not cover. Both are findings for the profile's owner rather than for the desk. Count requesters with three or more requests in the quarter and read the list. It is short, and each name on it is a role profile that needs a line added. The person has not been asking too much. The bundle has been giving too little.

The Desk's Hours: A Worked Example

The desk's own time on an access request is between twenty and forty minutes for most requests at Carrow. Joel measured this by having each of the three technicians note their minutes on thirty requests apiece and taking the range rather than the average. The time covered reading and completing the five answers, finding the owner on the matrix, and sending the approval request. It covered the chase where there was one, making the grant, writing the record, and telling the requester. Two hundred and twelve requests at twenty to forty minutes is somewhere between seventy and a hundred and forty hours in the quarter. Call it two to three working weeks of one technician, for a desk of three. That is a larger share of the desk than anyone had guessed, and the number the managing director wrote down.

The hours are what make the case for the bundles. The thirty-two bundled requests still have to be granted. But a bundled grant has no owner to find, no approval to send and no chase. And the technicians' notes put it at five to ten minutes rather than twenty to forty. That saves somewhere between eight and sixteen hours a quarter at Carrow's volume. That is not a large number, and it is honest. And it is also the number before the bundle shortens nine sales starters' wait from two weeks to a morning. The sales director was able to put her own figure on that. Hours are the desk's currency; the requester's wait is the organisation's, and the report carries both.

Do not count the approver's days as the desk's hours. Do not count the requester's wait as anyone's hours unless the requester's manager offers a figure, which they sometimes will. The desk's number is the minutes its own people spent. A desk that reports "a hundred hours lost to access requests" when it means "a hundred hours of waiting" has told a true thing in a way that will be found out.

Per-Technician Numbers: Coaching and a Minimum Sample

The only per-technician cut that is fair is the desk's own two pieces of the clock. Those run from complete request to approver asked and from approval to requester told. They are the pieces the technician controls. Turnaround as a whole is the approvers'. A technician's turnaround figure is mostly a statement about which owners their requests happened to land on. Cut the two desk pieces by technician, and read them for coaching and never for ranking. Do not read them at all for a technician with fewer than thirty or so comparable requests in the period. At Carrow's volume, that meant the quarter and not the month. A technician whose first piece has a long median usually has a habit. Examples include granting before the approval and tidying up after, or sitting on requests that need the owner found. And the number is a reason for a conversation about the habit and nothing more.

Say the coaching rule aloud before the first cut and every time after. A number by name on a page becomes a league table in the reader's head whatever the heading says. The per-technician cut goes to the desk lead and the technician, not into the report. And the report carries the desk's pieces as a whole. A desk that has been ranked on access turnaround will start granting before approval to improve its number, which is the one behaviour the whole loop exists to prevent. Nobody has ever been coached into a shorter median by seeing their name at the bottom of a list, and several desks have been coached out of their records that way.

Reading the Numbers Together

The access numbers lie when read alone, as any metric does, and the pairings that keep them honest are short. A falling median with a growing tail means the easy requests got easier and the hard ones did not, which is usually the bundles working and the owners not. A falling median with rising repeat asks means the desk has got quicker at approving the same thing eleven times, which is the wrong improvement. A falling stall count with a rising unknown-owner count means owners are answering and the register is not keeping up. And a turnaround that falls while the review's "lines with no traceable request" rises means the desk is granting faster than it is recording. That is the number to stop everything for. The general idea, that a metric travels with the one that would expose it, is in Reading Metrics Together. Here it is enough that the scorecard has all five on one page so that the pairs sit in sight of each other.

Read the numbers against the previous quarter and not against anyone else's desk. No two organisations have the same owners, resources or approvers. A benchmark for access turnaround would be a number about nobody. Carrow's second quarter had a median of one working day, a tail of six, no stall row over two days, and one repeat ask. That is a loop shortened where it could be and now waiting on the one owner who still approves on Fridays. That is a worked example and not a standard. Yours will have its own Fridays.

The Quarterly Report Line

The report line is one sentence and four numbers. And it goes in the desk's quarterly report beside the other lines rather than in a document of its own. It gives the count of requests, the median turnaround and the tail count. It gives the longest-stalling owner's row stated as a fix in progress rather than a complaint. It also gives the bundles created this quarter with the requests they removed. "Two hundred and twelve access requests; median a day and a half, nineteen over ten days, twelve of those on one approver, who now has a deputy; four bundles created, removing about thirty requests a quarter." The review's four numbers, from the previous article, sit on the next line. Which numbers go in the report and which stay on the desk's working sheet is the subject of The Numbers to Show and the Numbers to Keep. The stall table by owner is a number to keep. Show it to each owner privately and to leadership as "fixed" or "in progress", never as a list of names.

The line's job is to answer the managing director's question before he asks it next quarter, and to make the next question a better one. "Is it true that access takes weeks?" became, at Carrow, "why does the customer database still take five days?" That is a question with an owner, a row and a fix. Numbers that lead to a better question are doing their job. Numbers that lead to the same question are not.

A Short War Story: The Bundle Nobody Built at Acme

At Acme, a distributor with a warehouse of about sixty operatives and a desk of two, every new operative needed the same four things. These were the scanner application's picker role, the shift rota folder, the warehouse mailbox and the time-recording system. Each was requested on a separate ticket by the shift supervisor and approved individually by the operations manager, a man called Grant. Grant approved everything he was sent and was sent the same four questions thirty-eight times in a year. Each set took a median of four working days, during which the new operative worked from a colleague's scanner. The audit of stock discrepancies later put that at about sixty hours of unattributable picking across the year. The desk's own time on the hundred and fifty-two tickets, at about half an hour each, came to roughly seventy-five hours. Grant's came to an afternoon a month he could not account for. A technician called Lucy, counting the year's requests by resource and role for the first time, found the run of thirty-eight in about ten minutes. The bundle took one conversation with Grant, who signed it in the same conversation. The following year's new operatives had all four on their first morning, and the desk's access tickets fell by a third. A repeat request is an approval the organisation keeps paying for, and nobody at Acme had counted the payments because each one was small.

The Access Scorecard

The scorecard below is the one Joel keeps, one page per quarter, filled from the quarter's export and the review's parent ticket. The first block is the counting rules, written once and copied forward unchanged so that the quarters compare. The second is turnaround with its three pieces and its tail. The third is the stall table by owner, kept on the desk and not in the report. The fourth is the repeat asks and the bundles they became; the fifth is the desk's hours in a range. The last is the report line, written out in the words that will go to leadership. Every number is beside last quarter's, because a number without the one before it is a fact and not a trend.

ACCESS REQUEST SCORECARD — ONE PAGE PER QUARTER
Desk: ______________   Quarter: ________   Prepared by: __________   Last quarter beside each figure

COUNTING RULES (same every quarter)
  An access request is: any ticket whose outcome changed what a person can reach, marked at close.
  Clock starts: the five answers are on the ticket.     Clock stops: the requester is told.
  Pieces:  desk (request -> approver asked)  |  approver (asked -> approved)  |  desk (approved -> told)
  Working days on the desk's business-hours schedule.  Waiting time is counted, never paused away.

TURNAROUND
  Requests this quarter: ____ (last: ____)    Time to a complete request, median: ____ (form quality)
  Median, request to told: ____ working days (last: ____)
    desk piece 1: ____    approver piece: ____    desk piece 2: ____
  Tail (over ____ working days): ____ requests (last: ____)   listed by ticket: ________________

STALLS BY OWNER (kept on the desk; shown to each owner privately)
  Owner / resource          Requests   Median approval days   Past the timer   Action
  _______________________   ____       ____                   ____             deputy / chase / batch
  _______________________   ____       ____                   ____             ______________________
  Unknown-owner stalls: ____ requests, resources: ______________   Register rows added: ____

REPEAT ASKS (same resource + level + role, three or more)
  Resource / level / role                      Count   Bundle created?   Requests it removes
  __________________________________________   ____    [ ] yes  [ ] no   ____ per quarter
  __________________________________________   ____    [ ] yes  [ ] no   ____ per quarter
  Requesters with three or more requests: ____   profiles to amend: ______________

DESK HOURS (minutes per request, measured on a sample, as a range)
  Ordinary request: ____ to ____ min   Bundled request: ____ to ____ min
  Quarter's desk hours: ____ to ____   (last: ____ to ____)

REVIEW (from the quarter's parent ticket)
  Managers asked: ____   Completed: ____   Lines reviewed: ____   Removed: ____   No traceable request: ____

REPORT LINE (as it will appear)
  "____ access requests; median ____ working days, ____ over ____ days, ____ of those on one approver,
   now ______________; ____ bundles created, removing about ____ requests a quarter.
   Review: ____ of ____ managers completed; ____ lines removed."

Joel answered the managing director on the Monday with the line and the stall row for the customer database described as "in hand". He also requested ten minutes with the sales director, which he got. That produced a deputy and a Tuesday batch to go with the Friday one. The sales team's next starter had the customer database by lunchtime on her first day. The managing director's next e-mail, a quarter later, asked a different question. It was a better one, and it had a number in it, which Joel took as the review he had been hoping for.

Frequently Asked Questions