The workflow was embarrassing for a team that called itself IT Operations.
Someone needs access to a tool. They DM me or a teammate. We tell them to fill out the IT request form. They fill it out. We read the form, decide the priority and category, assign it to someone, open a Jira ticket, and DM the requester a confirmation. If the request needs manager approval, we forward it and wait.
Each request touched at least four systems and required at least two humans. For a P4 "I need read access to this S3 bucket" request, that's comically over-engineered.
What I Built
Two Slack slash commands. That's it.
/itrequest — opens a modal. User fills in: what they need, urgency, any relevant context. Hit submit. Claude triages the request: assigns a category, priority (P1–P4), SLA, recommended owner, and a suggested first action. The structured result posts to #it-requests and a Jira ticket is created automatically.
/accessrequest — same modal pattern. Claude assesses the risk level of the request (Low / Medium / High) based on what's being requested and who's requesting it. Low-risk requests auto-approve with a DM confirmation. Medium and High route to #it-approvals with interactive Approve / Deny buttons that managers can click directly in Slack. When a decision is made, the requester gets a DM notification with the outcome.
Zero email. Zero form-forwarding. One Slack command, and the right people get notified immediately.
The Risk Assessment Prompt
Getting Claude to reliably assess access request risk took more iteration than I expected.
First version: "Assess whether this access request is low, medium, or high risk." Got inconsistent results. "Admin access to production database" and "read access to the company wiki" were sometimes both rated medium.
The fix was giving Claude a concrete risk rubric:
- Low: read access to internal tools, adding someone to a standard group they're eligible for based on their role, common software installs
- Medium: write access to production systems, admin access to non-critical tools, any access outside the requester's normal role scope
- High: admin access to production systems, access to systems containing PII or financial data, access that bypasses normal approval chains
With that rubric in the prompt, the triage accuracy jumped significantly. More importantly, it gave me a clear audit trail — every decision has the risk assessment attached, so when someone asks "why was this request auto-approved?" there's a structured answer.
Jira Integration
The Jira piece required more care than the Slack piece. Our Jira instance used custom fields for IT request type and priority that didn't map cleanly to the default Jira schema. The API calls had to use the custom field IDs (which are not human-readable — they're things like customfield_10023) and the allowed values for each field had to match Jira's configured list exactly.
I built a small config file that maps Claude's output schema (category, priority) to Jira's field IDs and allowed values. When the Claude response comes back, it gets translated before the Jira API call. When Jira's schema changes (and it does, every time someone updates the project config), I update the mapping file, not the bot logic.
Results
We deployed this for a 900-person org. Week one numbers:
- 68% of access requests were Low risk and auto-approved without any human involvement
- Average time to Jira ticket creation dropped from 47 minutes to under 30 seconds
- Zero P1/P2 requests slipped through without same-day handling (previously 2–3 per month would get buried)
The 3 hours per week I'm saving is real but undersells it. The bigger impact is reliability — things don't fall through the cracks anymore. The Slack bot logs every request, every decision, every action. When someone asks "what happened to my access request from Tuesday?" there's a complete audit trail in #it-requests and Jira.
What I'd Change
The modal design is functional but basic. The better version would be a dynamic modal that adapts based on the request type — access requests for production systems would prompt for business justification upfront, while software install requests wouldn't. That requires more complex Slack modal logic (block actions with dynamic updates) which I've scoped for the next version.
The Jira integration also assumes a specific project structure. Making it configurable — so other teams could deploy this without modifying the source — is the next engineering priority.
The code is on GitHub with setup instructions. You'll need a Slack app, Jira Cloud API credentials, and an Anthropic API key. Setup takes about an hour.