Most requests that reach an IT department are repetitive: an account for a new employee, access to a share, a shared mailbox, a virtual machine with standard parameters. Each takes a few minutes of work and, on average, two days of waiting in a queue. The waiting time does not come from the difficulty of the task but from the fact that a person has to notice it, read it and click through it.
The pattern
Automated request handling consists of four elements that exist in most organisations but are not connected:
- A form in the ticketing system with structured fields: not “describe what you need”, but a department drop-down, a field for the share name, a read/write toggle.
- Approval in the same system, by a manager or the resource owner, according to existing rules.
- A call to the automation platform after approval: the ticketing system sends a request with the form content to the API of the platform that runs the playbook or script.
- The result written back into the ticket: what was created, with what parameters, or what error occurred. The ticket closes automatically or returns to the queue for a person.
A human appears in two places: at approval, if the rules require it, and on error.
Design rules
Validation on the automation side, not in the form. A form can be changed, bypassed, or the API called directly. The playbook checks every field: does the department exist, does the name follow the convention, is the requester allowed to ask for this resource. External data is untrusted regardless of its source.
Idempotence. Re-running the same request does not create a second account or grant access twice. If the resource exists, the automation reports that and finishes without an error.
A service account with minimal permissions. An automation that creates user accounts does not need domain administrator rights. It needs delegation to one organisational unit. Every permission beyond that is risk without benefit.
A trail. Every action of the automation is recorded with the ticket number: in the platform log, in the description of the created object, in a comment on the ticket. The question “who created this account and why” has an answer without a search.
Errors are visible. A failed run does not end with a silently closed ticket. The ticket returns to the queue with the full error message and a flag that it needs manual intervention.
A dry-run mode. The automation can be run with a parameter that only reports what it would do. The first weeks of a new automation happen in this mode, with results compared against manual fulfilment.
Where to start
Not with the most complicated request, but with the one that meets two conditions: the highest volume and the smallest consequences of a mistake. Usually that is access to a share or a distribution group. One request type taken to completion, with validation, a trail and error handling, becomes the template for all the others.
What to measure
Two numbers: the time from submitting a request to its fulfilment, and the share of requests of a given type completed without human involvement. The first shows the effect for users; the second shows where the automation still fails and why.
Summary
Automating requests does not require a new platform, only connecting the ticketing system to the tool that already runs playbooks, over an API and under a few rules: form data is untrusted, actions are idempotent, the service account has minimal permissions, every action leaves a trail, and errors go back to a person. Two days of waiting become two minutes, and the IT team deals with the requests that actually need a decision.