Reducing Software Request Friction Until Most Need No Human

Monday, 08:30, at Bellweather Logistics. Nadia runs a desk of four and has the last quarter's closed software requests in a spreadsheet. That is because the operations director asked on Friday why "getting a program" takes a week. There were 140. The median took four working days from request to the requester saying it worked. Ninety-six of the 140 were for one of nine programs. Sixty-one of those were for programs that were already on the standard image. That means sixty-one people waited for something they already had. Forty-four of the remaining were approved by a manager who has never once said no to any of them. Nadia looks at the four working days and sees, for the first time, that almost none of them were spent doing anything.

Friction, in a software request, is every step between a person needing a program and having it that adds a wait, a question or a person without changing the answer. Reducing it is not making the desk faster. It is removing the steps that were never deciding anything, so that the desk's time goes on the requests that need it. The target is a desk where most software requests need no decision from anyone outside the desk. At that desk, a good share need no technician at all. The rest are answered in hours because the queue is no longer full of the first two kinds. This article is part of our Software Installs & Licence Requests series. It is the last one because everything in it builds on the workflow, the approvals, the install discipline and the register that the earlier articles set up.

It starts with where the friction is and the catalogue as the answer to "can I have". Next come the pre-approved list that grows from the exceptions, role bundles installed before anyone asks, and the renewal calendar that removes the surprise. Then it covers measuring turnaround honestly and the share that needed no human. A short war story and the pre-approved list to copy finish the article.

Where the Friction Is

There are four frictions in a software request, and each one shows up in the tickets as a different kind of wait. The first is not knowing: the requester does not know what they may have, whether they already have it, or how to ask. The ticket arrives as "can I have" or does not arrive at all. The second is asking: the form, or the lack of one, costs a round of questions before anyone can act. The third is waiting on a decision: the ticket sits with an approver who was never going to say no. The fourth is waiting on the desk: the install is twenty minutes of work queued behind three days of other tickets. Nadia's four working days were mostly the third and the first, and neither of those is fixed by hiring.

Find your own four by reading a month of closed software requests with a column for each. Record how long before the desk first touched it and how long waiting on the requester. Also record how long waiting on an approver and how long waiting on the desk's install. The tickets' timestamps supply all four if the status was set honestly. That is the reason the workflow article in this series insists on a waiting status that says who the ticket is with. A desk that cannot tell where the wait was cannot remove it, and will remove the wrong one, usually by asking the technicians to install faster. The table below is the four frictions, the sign of each in the tickets, and the fix. The fixes are the rest of this article.

Fix them in that order, because each fix shrinks the next one's queue. A catalogue removes the requests for things people already have, which is a fifth to a third of the total at most desks I have seen. A form removes the round of questions from what remains. A pre-approved list removes the decision from most of what remains after that. Role bundles remove the request entirely for new starters. What is left is the genuine exception. A desk with only the genuine exceptions in its software queue answers them in hours. That is because there are nine of them a quarter rather than ninety.

The Catalogue Is the Answer to "Can I Have"

The catalogue is one page that lists every program the organisation provides, who may have it, whether it is already on their machine, and how to get it if not. Its whole job is to be read before a ticket is raised. The idea of a catalogue as the published list of what the desk does, in plain words, belongs to The Service Catalogue Idea. The software catalogue is the part of that list that happens to be programs. It is the part requesters consult most because "can I have" is the commonest question any desk is asked. A catalogue that answers it before the ticket has removed the ticket. A catalogue that lives in a folder the desk alone can see has removed nothing.

Each entry says five things and no more. It gives the program's name as a requester would recognise it and what it is for in one line. It says who may have it (everyone, a role, or by request) and whether it is on the standard image already. It also says how to get it (already installed, self-service, or the form with this entry picked). Conditions from the security look go on the entry too, in a line a requester can read. For example, the entry might say: "installed by the desk; the sharing feature is turned off". Price does not go on it, and nor does the supplier's licence jargon. The catalogue is for the person who wants to draw a diagram, not for the person who wants to know the seat type. The register holds the rest.

Publish it where people already look. At most organisations that is the knowledge base the desk's portal shows, with a link from the request form and from the desk's signature. If you run QuerySolv, the catalogue page is a knowledge base article visible to everyone rather than to agents only. In QuerySolv, the software department's own request form can link it at the top. That way, the list is the first thing a requester sees and the form is the second. In any tool, the test is whether a new starter in their first week can find the page without asking anyone where it is. If the answer is "it is in the shared drive under IT", the catalogue exists and does not work.

Give it an owner and a prune. The desk lead owns it, reviews it once a quarter against the register and the tickets, and removes entries nobody has requested in a year. That is because a catalogue of ninety programs is a catalogue nobody reads to the end. The prune is the same discipline the service catalogue article applies to the whole list of services. It has the same enemy, which is that entries are easy to add and feel rude to remove. Remove them. A short list people read beats a complete one they do not.

The Pre-Approved List Grows From the Exceptions

The pre-approved list is the part of the catalogue that needs no decision from anyone. It grows by one rule: an exception that is approved three times for the same kind of requester becomes an entry. The third approval is the organisation telling the desk that it has already decided. Asking the manager a fourth time is asking them to make a decision they have made three times without ever saying no. The desk lead reviews the quarter's approved exceptions, finds the ones approved more than twice, and adds them, with the conditions the security look set. The manager who approved them is told, usually with relief. The approval design that makes this safe, three questions with one owner each, is in Approvals Without a Committee. This article is about feeding it.

Review the declined exceptions in the same sitting. A program declined three times is a need the catalogue is not meeting. The right response is a proper look at a licensed equivalent, raised by the desk on behalf of the people who asked. The desk is the only place in the organisation that sees every request for the same thing. Three declines of the same diagramming tool from three departments is a request for a diagramming tool from the organisation. The catalogue should answer it with something, even if not with that one. The conversation about the unapproved asks themselves, and what the reply says in the meantime, is in Unapproved Software Asks and the Shadow IT Conversation.

Every entry on the list carries the seat position, because a pre-approved paid program is only pre-approved while there are seats spare. The entry says "owned: 25, spare: 4, from the register", and the desk checks the register before installing. When the spare count reaches zero the entry's route changes from "no decision" to "budget holder, for the next seat". It changes back when the next seat harvest or renewal makes room. The register, kept the way Licence Tracking Without a Tool keeps it, is what makes a pre-approved paid program honest. Without it the list is approving seats the organisation has not bought, which is friction removed in the direction of the audit letter.

Resist "unless". An entry that reads "pre-approved for everyone, unless they are a contractor, unless the machine is a shared one, unless the manager has said otherwise" is three decisions wearing one entry. Each unless is a question a technician has to ask. If an entry needs conditions, write them into who it is for and leave the rest off. The list is the approval. It cannot also be the exception.

Role Bundles: Install Before They Ask

A role bundle is the set of catalogue entries a given role gets on day one, installed from the onboarding ticket before the person has sat down. It is the single largest reduction in software requests a desk can make. The sixty-one requests at Bellweather for programs already on the image were from people who did not know. The forty-four approved by a manager who never said no were mostly from people in three roles asking, one by one, for the four programs everyone in that role uses. A bundle for each of the three roles, installed at onboarding, removes those forty-four before they are typed. The design of the role profile, what each role gets as kit, accounts and software, is the subject of Role Profiles and Standard Kits in the onboarding series. The software bundle is the software column of that profile. This article inherits it rather than redesigning it.

Build the bundles from the tickets, the same way the catalogue was built. Pull a year of software requests and group them by the requester's role. The programs that most people in a role asked for within their first three months are that role's bundle. The threshold is "most", not "all". A program two of nine analysts asked for stays on the catalogue by request. A program seven of nine asked for goes in the bundle. The bundle is installed as packages after the image. That is the method the installing article in this series recommends for programs some people get. Each install still gets its record, because the audit letter does not care that the install was automatic.

Review each bundle with the role's manager once a year, in the same sitting as the licence renewals. Ask two questions. What did new starters in this role ask for in their first quarter that the bundle did not have? What in the bundle did nobody open? The first question grows the bundle; the second shrinks it and returns seats to the pool. A bundle that is never reviewed grows the way the standard image grows, by accumulation, until every new analyst gets a program the role stopped using two reorganisations ago. (It is still being renewed. It always is.)

The Renewal Calendar Removes the Surprise

A renewal that lapses produces a burst of tickets that read "my program says the licence has expired", one per user, all on the same morning. The burst is the most avoidable friction there is. The renewal calendar from the licence tracking article provides a reminder two to three months before each renewal that opens a ticket for the budget holder. It exists to prevent exactly this. The friction it removes is not the renewal itself but the thirty tickets, the thirty replies, the thirty apologies and the day the thirty people lost. A desk that renews on time is invisible on renewal day. A desk that does not is the subject of an all-hands e-mail.

The calendar also removes a quieter friction, which is the renewal placed at last year's count because nobody had time to check. The renewal ticket asks the register how many seats are in use. A renewal placed at the right count is a renewal that leaves seats spare for the pre-approved route rather than paying for seats nobody opens. The two are the same mechanism: a date in the calendar, a ticket with four questions, a decision made with the register open, two months before the money moves.

Tell the users before the renewal if anything will change for them, which is rare, and tell nobody if nothing will, which is usual. A renewal that goes well is a non-event, and non-events do not need announcing. The one message worth sending is to the budget holder, a week after the renewal ticket closes: "renewed at twenty-two seats rather than twenty-five, from the register; the three released seats are back in the pool". It takes a minute and it is the sentence that gets the register's monthly hour defended at the next budget round.

Measuring Turnaround Honestly

Turnaround is the time from a software request arriving to the requester confirming the program works. It is measured per request from the ticket's timestamps. It is reported as a median with the two clocks beside it: time waiting on a decision, and time waiting on the desk. The median rather than the average, because one request that waited six weeks for a budget holder on leave turns an average of two days into an average of five. That average tells the director nothing true about either. The two clocks, because a turnaround of four days is a different problem when three of them were an approver's and when three of them were the desk's. Only the tickets can say which. The general discipline of counting from the tickets rather than from memory, and of cutting the count by the things that matter, is in Counting Tickets Properly. Here it is applied to one ticket type.

Report it by lane, because the lanes have different promises. A median of one working day for pre-approved requests and five for exceptions, with the exception clock split into decision and desk, is a report that shows where the time goes. A single median across both lanes is a number that gets better when the catalogue grows and worse when the exceptions get harder. The two effects cancel, and the director asks why nothing has changed. Nadia's first report after the catalogue showed the overall median falling from four days to two, and the exception median rising from five to six. That is because the easy exceptions had become catalogue entries and the hard ones were what remained. Both numbers were good news. Only the split showed it.

Do not cut turnaround by technician except for coaching, and not from fewer than forty or so requests of a comparable kind. That is because the install step is twenty minutes and the rest of the clock belongs to approvers and requesters that the technician does not control. A technician whose requests take longer is usually a technician who got the exceptions. The per-person figure is read with the person, for what it says about the lane they were handed, and never ranked.

The Share That Needed No Human

The number that shows friction falling is the share that needed no human, counted two ways. One is the share of software requests fulfilled with no decision from anyone outside the desk. The other is the share fulfilled with no technician at all. The first is the pre-approved lane's share of the total. It comes straight from the lane field on the form, or from the "pre-approved" mark on the install record where the form has no field. The second is the requests that were met by the image, a role bundle or self-service. Those are usually not tickets at all and have to be counted from the install records and the onboarding tickets. Both are reported as "N of M requests, about a share", in the way the metrics series reports every count. The two numbers are beside the fraction so that a small month is not mistaken for a trend.

Bellweather's first quarter, the one in Nadia's spreadsheet, was 140 requests, of which about thirty went down the pre-approved lane, roughly a fifth. None were met without a technician because there was no self-service and the bundles did not exist. Two quarters later, the catalogue was published, the list had grown by the three-times rule, and bundles were on the onboarding ticket. The count was about ninety requests, of which about sixty-five were pre-approved, close to three quarters. A further thirty or so installs happened through bundles with no request at all. The requests that needed a decision fell from over a hundred to about twenty-five. The desk did not get faster at anything. It stopped being asked things it had already answered.

There is a third count, which is the requests that never arrived because the catalogue answered them. It is counted the way deflection is counted everywhere in this library. There is a baseline of requests for a program before the catalogue entry existed and the count afterwards. The difference is stated as a range with the caveats attached. The honest method, and the ways of fooling yourself with it, are in What Deflection Means. The only thing to add here is that the sixty-one requests for programs already on the image are the easiest deflection a desk will ever claim. That is because every one of them is a ticket that an entry reading "already on your machine" would have prevented. Nadia claimed them, in a range, with the method written down. The operations director, who had asked why a program takes a week, was told that for most programs it now takes no time at all, with the count beside the sentence. The report format that carries a line like that to leadership without losing the count is in The Monthly Report They Will Actually Read.

A Short War Story: The Start-of-Term Burst at Oakmoor College

Oakmoor College's desk of three received around three hundred software requests in the first two weeks of every academic year. Nearly all were from new and returning lecturers asking for one of the same six programs. Each one went to a head of department for approval, waited two to six days, and was then installed by hand. So the desk did nothing else for a month and the lecturers taught the first fortnight without the tools their courses were built on. The desk lead, Tomasz, costed the burst at a little over a hundred hours of desk time and did not try to cost the teaching. The following summer he built a lecturer bundle from the previous year's tickets. He had the six heads of department approve the bundle once, as a list, in July. He installed it on every teaching laptop from the start-of-year onboarding tickets before term began. The first two weeks of the next term brought about forty software requests, most of them genuine exceptions. The desk answered them in a median of a day. The lesson Tomasz wrote in the handover notes was that three hundred approvals of the same six things were not three hundred decisions. They were one decision the college had been making three hundred times.

The Pre-Approved List

The list below is the layout Nadia uses for the pre-approved section of the catalogue, as a requester sees it. It is followed by the rules the desk applies to keep it honest. The requester does not see those rules. Each entry is one line a person in a hurry can read, with the seat position for paid programs taken from the register at the monthly touch. Two example rows show the shape with fictional values. The rules underneath are the part most desks skip, and they are the reason the list is still trusted a year later.

PRE-APPROVED SOFTWARE — NO DECISION NEEDED; CHECK HERE BEFORE YOU ASK
Owned by: ______________   Last reviewed: ________   Next review: ________

Program (as requesters know it) | What it is for | Who may have it | Already on your machine? | How to get it | Conditions
Document reader | opening and signing forms | everyone | yes, on the image | nothing to do | none
Diagram tool | flow charts and floor plans | everyone | no | form, pick "Diagram tool"; installed within 1 working day | installed by the desk; sharing feature off
Drawing viewer (paid) | viewing drawings | drawing office, project managers | no | form; 25 seats owned, 4 spare | when no seats are spare, the next seat needs your budget holder

RULES THE DESK APPLIES (not shown to requesters)
  Adding an entry
    [ ] Approved as an exception three times for the same kind of requester in a year, or
    [ ] in a role bundle agreed with the role's manager
    [ ] Security look done; conditions copied onto the entry and the install record
    [ ] Paid: register row exists; seat position copied at each monthly touch
  Keeping an entry
    [ ] Requested, or installed from a bundle, at least once in the last year
    [ ] No "unless"; conditions are written into "who may have it" or the entry comes off
    [ ] Paid entry with zero spare seats: route changes to "budget holder for the next seat"
  Removing an entry
    [ ] Not requested in a year, or the program retired, or the licence not renewed
    [ ] Existing users told a month before, with the alternative named
    [ ] Register updated; seats released at the next renewal

QUARTERLY REVIEW (one sitting, with the register open)
  1. Approved exceptions this quarter, grouped by program: any at three or more? Add.
  2. Declined exceptions, grouped: any at three or more? Raise a proper look at an equivalent.
  3. Entries with no requests in a year: remove, with notice.
  4. Counts for the report: requests ____, pre-approved ____, no technician ____, exceptions ____.

Nadia sent the operations director the second quarter's two counts and the turnaround by lane, on one page, with the catalogue link at the bottom. He read it and asked whether the three-quarters figure could go higher. He was told that it could, slowly, as the exceptions turned into entries. He was also told that the remaining quarter was the part of the job that needed a person. He asked for nothing else, which on a Monday morning is as good as a software request gets.

Frequently Asked Questions