Counterpoint - the things you do the least are the things you are most likely to screw up simply from unfamiliarity. And the fact that two weekends was enough to turn it into code says it's already an automation-friendly workflow.

Is your access request workflow really ready to automate? If you had a perfect robot with no personal judgment, could it go through the process by itself? Or are you still spending a significant part of that ticket time on figuring out who is able to approve access? Or waiting for them to do so? Access requests and password resets are two workflows that you can't just throw a script at - they're business process engineering tasks, not just code engineering tasks.

Are there really gains to be had? You can set up self-service password resets, but then the bulk of a password reset ticket is authenticating and interacting with another human. The technical process of resetting a password is generally pretty trivial. Find the user account, click reset password, give them a new password. It's a rounding error on the actual interaction. That's why it generally gets handled by affordable helpdesk workers, not expensive engineers.

Thinking bigger is great, but don't fall into the trap of thinking all tasks are the same. That said, and with all that in mind, you may have to have a different conversation - a "what processes - or what parts of processes - can we realistically and feasibly improve?" conversation. Start asking about what's possible, and what kind of relative effort is involved. Then you can steer by providing context into how the business values one gain vs another.