Do I have a licence for that is usually the second largest ticket type after account access. It arrives phrased as a question and it ends in an approval, which is why it sits awkwardly between a knowledge base and a request form, and why most desks handle it worse than its volume deserves.
TL;DR
- Access requests look like questions and finish as approvals. An answering agent handles the first half well and must not attempt the second.
- Four questions hide inside one ticket: does the tool exist here, am I eligible, is a seat free, and who approves it.
- Three of those four are answerable from a document you probably have not written. The fourth needs live data.
- Publishing an approved software list with eligibility and approver per entry removes most of this queue without any automation.
- The commonest wrong answer is a confident yes about a tool the company does not have, which is worse than no answer.
- Never let an agent imply approval. Explaining the approval route is service, predicting its outcome is a problem.
Four questions in one ticket
Somebody asks for access to a design tool. That single sentence contains four separate questions and the desk usually answers them in the wrong order.
Does the company have this at all. A surprising share of requests are for tools nobody has bought, and answering this first saves everything downstream. Am I eligible. Many tools are scoped to a function, a seniority or a contract type. Is there a free seat. Live data, which no document can hold. Who approves it, and how long does that take. Process, which is documentable and almost never documented.
Three of those four are static facts. Writing them down once removes most of the queue, and the reason it has not happened is that each answer lives with a different person and nobody owns the combined view.
The document that removes most of this
| Column | Why it earns its place |
| Tool name, plus the names people use for it | Half of all searches use the informal name |
| Do we have it | Answers the commonest request outright |
| Who is eligible | Stops a request that was never going to be approved |
| Approver, by role | The question nobody can currently answer |
| Typical turnaround | Removes the chase ticket three days later |
| What to use instead | Redirects requests for tools we do not have |
| Cost basis, where known | Makes the requester weigh it themselves |
The last two rows do disproportionate work. What to use instead converts a dead end into a resolution, because somebody asking for a tool you do not have usually has a job to do that something else covers. And a visible cost basis makes a meaningful share of requesters withdraw the request themselves, which no approval workflow achieves.
Keep it as one table, not a page per tool. It needs to be scannable by a person and retrievable as a unit, and a page per tool means fifty documents to maintain and a search that has to pick between them.
The seat count problem
Whether a licence is available is live data sitting in a vendor console, a procurement spreadsheet or nowhere at all. A document-trained agent cannot know it and will either decline, which is correct and unsatisfying, or describe the general position, which sounds like an answer and is not.
Resist the temptation to put a seat count in the document. It is wrong within a week, and a stale seat count is worse than no seat count because somebody will plan around it. State instead that availability is checked at approval, which is true, useful, and does not decay.
If seat availability genuinely drives a lot of tickets, that is an integration into whatever holds the licence data, and it is worth scoping only after the static document exists, because the document is cheaper and covers more of the volume.
Where an agent must stop
The hard boundary in this category is approval. An agent explaining that a request goes to a named role and typically takes two days is providing a service. An agent saying that a request of this kind is usually approved has made a prediction about somebody else’s decision, and that prediction will be quoted back when the answer turns out to be no.
What to do:
- Have the agent answer does-it-exist, eligibility and the approval route, and nothing beyond those three.
- Make it decline seat availability explicitly rather than inferring it, and say that availability is confirmed at approval.
- Forbid any wording that implies an outcome, including usually, should be fine and straightforward.
- End every access conversation by pointing at the request form rather than offering to raise it, unless something behind the agent can actually raise it.
- Where the tool does not exist, give the approved alternative in the same answer, which resolves the contact rather than deferring it.
The fourth item is the join that gets left unspecified. A conversation that correctly explains the process and then ends is a step shorter than the ticket it replaced only if the form is one click away and prefilled with what the person already said.
Disclosure: Matram is owned by the same people who publish PeopleOpsHQ. It is relevant here because it answers from a document like the approved software table above and declines what the document does not cover, and it is priced flat at $29, $69 and $199 a month with unlimited seats, which matters when the asking population is everybody. It has no free tier, it answers questions rather than actioning tickets, and it is not an ITSM platform, so the request form and the approval chain remain somebody else’s job. The options are compared in our IT support chatbot comparison.
Final thoughts
Access requests are mishandled because they are treated as one thing. Four questions arrive in one sentence, three of them are static facts nobody has written down, and the fourth needs live data that no document should try to hold.
Publish the approved software table with eligibility, approver and an alternative for everything you do not have. That single document removes more of this queue than any automation, and it is the thing an answering agent needs in order to be useful here at all. Then keep the agent on the question half and let the approval chain stay where accountability lives.
Frequently asked questions
Why are software access requests hard to automate?
Because one sentence contains four separate questions: whether the company has the tool at all, whether the requester is eligible, whether a seat is free, and who approves it. Three are static facts that can be documented, the fourth needs live data from a vendor console, and the ticket only looks simple because the desk answers whichever part it happens to know.
What should an approved software list contain?
Tool name including the informal names people actually use, whether you have it, who is eligible, the approver by role, typical turnaround, what to use instead if you do not have it, and the cost basis where known. The alternative column converts a dead end into a resolution, and a visible cost basis makes a real share of requesters withdraw before any approver is involved.
Should you publish seat counts?
No, because the number is wrong within a week and a stale seat count is worse than none, since somebody will plan around it. State that availability is confirmed at approval, which is true, useful and does not decay, and treat live licence data as an integration to scope later if seat availability turns out to drive genuinely significant volume.
Can an agent tell someone their request will be approved?
No, and this is the firm boundary in this category. Explaining that a request goes to a named role and usually takes two days is a service, while saying that requests of this kind are normally approved is a prediction about somebody else’s decision that will be quoted back when the answer is no. Forbid wording such as usually, should be fine and straightforward in the configuration explicitly.
What happens when somebody asks for a tool you do not have?
Give the approved alternative in the same answer, because the person has a job to do that something else almost certainly covers, and a bare no simply converts the ticket into a second conversation. A confident yes about a tool the company has never bought is the worst outcome in this category, and it happens when the corpus contains generic product documentation rather than your own list.
How should the handover to a request form work?
The form should be one click from the answer and prefilled with what the person has already said, otherwise the conversation has added a step rather than removed one. This join is the part most deployments leave unspecified, and it is where the time saving either materialises or quietly disappears into somebody retyping their own request into a second interface.
