IT Helpdesk Automation Level-1 resolved from slack, the rest routed with the ticket written
Password resets, access requests and how-to questions are handled in chat within minutes; IT sees only what needs a person.
- Installed for you · one-time$249
- Run for you$297/month
- Custom build · this process$5,000–9,000 one-time
- Starts whenSlack / Teams bot message + help desk event
Covers up to 1,500 requests a month with one identity provider, one MDM and one help desk. ServiceNow integration, hardware provisioning workflows or custom approval matrices are a custom build. Custom builds start at $2,000 site-wide; this band is for this process and its integrations.
IT Helpdesk Automation is an automation Agentmelt installs in your own tools. The free template is a file you import yourself; the kit ($49) adds the setup guide and prompts. Installed for you costs $249 one-time and is live within two working days of access, with a recorded walkthrough and 30 days of fixes. Run for you costs $297/month, with setup and maintenance included. A custom build of this process is $5,000–9,000 one-time; custom builds start at $2,000 site-wide. No call is needed for any option. Written by Max Zeshut; last revised 2026-09-21.
Reference stack: Claude + n8n. Node names are on each step; the file is under the template.
Founder at Agentmelt
Reviews every build before it goes live; the workflow escalates to a person, never past one.
What is it helpdesk?
IT helpdesk automation handles level-1 requests where they arrive — a Slack or Teams bot, email, the portal — by answering from your IT knowledge base with a citation, executing the approved self-service actions through the identity provider and the device manager (a password reset, access to a shared drive, a licence for a tool) with the right approval attached, and creating a well-formed ticket for everything else, routed to the right queue with the context gathered. The access map per role is a written rule IT owns; the model classifies and drafts, it never grants. What used to be half of IT’s day becomes a queue of the requests that needed an engineer.
- IT spends half its day on password resets and access requests.
- A new hire waits three days for access someone could have granted in a minute.
- The same “how do I connect to the VPN” question is answered forty times a month.
- Tickets arrive as “it doesn’t work” and the first reply is always “what doesn’t?”.
- The knowledge base exists and nobody, including IT, reads it.
If two of these are yours, this is the process to look at first. Free audit — or read on.
What it looks like once it runs.
Level-1 IT is repetitive by definition: password resets, access to a shared drive, a licence for a tool, 'how do I connect to the VPN'. The workflow handles those through a Slack or Teams bot and the ticket system — answering from your IT knowledge base, executing approved self-service actions through the identity provider and MDM with the right approvals, and creating well-formed tickets for everything else. IT staff handle problems, not requests.
- 9:31 “I'm locked out.” The requester is verified through single sign-on; the request is classified.
- 9:31 A how-to is answered from the knowledge base. A reset or access request waits for the right approval, then runs in the identity system.
- 9:33 Every request becomes a ticket with what was done; anything unresolved goes to the right queue with the context.
- Friday Questions the bot could not answer become draft knowledge-base articles for IT to approve.
IT tickets are dominated by requests that have a known procedure but still need a person to execute them. Response time for a password reset is measured in hours, access requests bounce between manager and IT, and the same how-to question is answered fifty times a month.
Most L1 requests are resolved in the conversation where they were asked, in minutes, with the approval and the audit trail the security team requires. Tickets that reach IT are complete — category, device, user context, what was already tried — and the knowledge base improves from every unresolved question.
Trigger, then 8 steps.
Seven of the eight steps run without anyone. Step 04 waits for a person.
Slack / Teams bot message + help desk event
Receive the request
Message text, requester identity (verified through the chat platform's SSO), device and location from the MDM where available.
Classify the request
Password/MFA, access request, software/licence, hardware, how-to, outage report, other — with urgency. Outage reports skip to incident handling.
Answer from the knowledge base
How-to questions are answered from the IT knowledge base with the steps and a link; the agent asks a clarifying question when the request is ambiguous.
Self-service actions with approval
Password reset → identity-provider API after MFA verification. Access to a group or app → manager approval request in Slack, then the identity-provider call. Software → licence check, then MDM deployment or a purchase request. Hardware → ticket with the asset details.
Execute through the systems
Okta/Entra ID/Google Workspace for identity actions, Jamf/Intune for software deployment, the licence platform for seat assignment — each call logged with requester, approver and timestamp.
Create or update the ticket
Every request, resolved or not, becomes a ticket with the classification, the actions taken and the conversation, so metrics and audits are complete.
Route unresolved requests
Anything the bot cannot resolve is assigned to the right IT queue with the context and a summary; the requester is told who has it and the expected time.
Improve the knowledge base
Weekly: questions the agent could not answer, grouped by topic, become draft KB articles for IT to approve; resolved-by-bot rate and time-to-resolve reported per category.
Most L1 requests are resolved in the conversation where they were asked, in minutes, with the approval and the audit trail the security team requires
Most L1 requests are resolved in the conversation where they were asked, in minutes, with the approval and the audit trail the security team requires.
One decision, at step 04. Seven steps ran without you.
Each pattern page explains it in plain words and lists every automation that uses it.
The template is built on n8n (how the n8n AI Agent node works); the same steps run on Make, Zapier or plain code. The tool is chosen to fit your accounts, you own the result, and the template comes in all three formats.
A typical first month — a 600-person company with a four-person IT team, on Slack, Okta, Intune and Jira Service Management.
Not a client report
About 1,100 requests a month, most with a known procedure that still needs a person: password resets, access to a shared drive, 'how do I set up the VPN'. A reset takes hours because it waits in a queue, access requests bounce between the manager and IT, and the same how-to is answered fifty times. The knowledge base was last updated when someone left.
The first month- Day 1The IT bot sits in #it-help. It classifies each request and answers from the knowledge base with the article cited; anything it cannot answer becomes a complete ticket — category, device, user, what was already tried. No actions yet.
- Week 1IT reviews the bot's answers on about 250 requests. Identity comes from Slack's single sign-on, and the security lead signs off the self-service list: resets, standard app access, approved software installs. Privileged groups are excluded.
- Week 2Self-service switches on. A reset asks for a fresh MFA step and runs through Okta; a drive-access request goes to the owner for approval in Slack and is granted when they click, with requester, approver and time on the ticket.
- Week 3Every interaction, resolved or not, is a ticket in Jira Service Management with its outcome — the true request volume is visible for the first time. An outage report bypasses the bot and pages the on-call engineer, as designed.
- Week 4The weekly run groups the unanswered questions by topic and drafts an article for each from IT's own resolutions. IT approves five; the bot answers those the following week.
| Metric | Before | After a month |
|---|---|---|
| Time to a password reset | hours in a queue | minutes, with MFA, in the conversation |
| Requests resolved without a person | 0 | the bulk of level-1 volume: resets, standard access, installs |
| Access grants without a recorded approver | common | none — the approval is on the ticket |
| Knowledge-base articles | stale | growing weekly from unanswered questions; coverage typically doubles in a quarter |
Figures follow the blueprint's controls and its knowledge-base curve at 1,100 requests a month. The resolved-by-bot rate is on your help desk from week three, because every interaction becomes a ticket — read it there.
This is a worked example, not a client's results: the company is a composite of a stated size, and the figures are the ranges this blueprint's own metrics make typical at that size. A real engagement replaces it, with permission, once an install has run a month.
Data it touches
- Slack / Teams (identity-verified requests)
- IT knowledge base (Confluence, Notion, help centre)
- Identity provider (Okta, Entra ID, Google Workspace)
- MDM and licence platforms (Jamf, Intune, licence manager)
- Help desk (Jira SM, Freshservice, ServiceNow)
Guardrails
- Identity is taken from the chat platform's SSO, never from the message; sensitive actions require a fresh MFA step.
- Access grants always require manager (or app owner) approval recorded in the ticket; privileged groups are excluded from self-service.
- Every automated action is logged with requester, approver and timestamp for audit.
- Outage reports and security concerns bypass the bot and go straight to the on-call engineer.
Self-service that security will sign off
IT self-service fails when it is either too permissive or so locked down that it resolves nothing. The workflow's design has three controls security teams accept: identity comes from SSO and sensitive actions re-verify with MFA; access grants always go through the owner's approval, which is recorded; and privileged groups are simply excluded from the bot. Within those rules, resets, standard access and software installs can be fully automated, and those are the bulk of L1 volume.
Every request becomes a ticket, even the resolved ones
Chat-based resolution is convenient and invisible. The workflow writes every interaction to the help desk as a ticket with its outcome, so IT management sees the true request volume, the resolved-by-bot rate and the categories that still need people. That data is what justifies the automation and what points at the next process to fix.
The knowledge base writes itself, almost
Questions the agent could not answer are the KB's gaps. The weekly run groups them by topic and drafts an article for each from the resolutions IT staff provided in the tickets. IT approves or edits; the next week the bot answers those questions. Most teams find their KB coverage doubles in the first quarter without anyone sitting down to write documentation.
What it connects to.
| Tool | Role in this workflow |
|---|---|
| n8n | Bot logic, approvals, system calls, ticketing |
| Claude | Classification, KB answers, clarifying questions |
| Okta / Entra ID / Google Workspace | Identity actions |
| Jamf / Intune | Software deployment |
| Jira Service Management / Freshservice | Tickets and metrics |
Want this running without building it?
$297/month
We set it up in your tools, run it on our servershost it on our n8n cloud (or deploy it to your own n8n, Make or Zapier), watch it, and fix it when something changes. Setup included, cancel monthly; the automation stays yours if you leave.
$5,000–9,000 one-time
Your systems, your rules, your edge cases. A one-off build delivered into your accounts to keepon Claude and n8n, delivered into your accounts to keep, with documentation and a recorded walkthrough.
Covers up to 1,500 requests a month with one identity provider, one MDM and one help desk. ServiceNow integration, hardware provisioning workflows or custom approval matrices are a custom build.
Also sold one-time, installed in your own accounts, as part of the it administrators package and the cybersecurity analysts package — do it yourself $49 · installed for you $249 · done for you $490.
When this becomes a custom build.
The subscription covers the standard version — $297/month, setup and maintenance included. Three things move it to a custom build ($5,000–9,000 one-time), delivered into your accounts to keep. If one of them is you, say so on the audit and the plan prices both.
ServiceNow or another enterprise ITSM as the system of record.
Hardware provisioning — ordering, shipping and asset tracking — as part of the request flow.
Approval matrices by department, seniority and cost, rather than one approver per request type.
Running the standard version first is the usual path: the exceptions it logs in the first month are the scope of the custom build, with your own numbers. How custom builds work.
Frequently asked questions.
Can it reset passwords without IT involvement?
Yes, after MFA verification through the identity provider, and it is logged. Accounts in privileged groups are excluded and always go to a person.
Which help desks and identity providers are supported?
Jira Service Management, Freshservice, Zendesk and ServiceNow (custom); Okta, Microsoft Entra ID, Google Workspace and JumpCloud for identity; Jamf and Intune for devices.
What happens during an outage?
Outage reports are recognised and routed to the on-call engineer and the incident channel immediately, and the bot switches to a status-message mode so requesters get the current incident update instead of a KB answer.
Can an IT helpdesk agent reset passwords and grant access without IT?
Within the written map: a reset after identity verification through the chat platform’s single sign-on; access on the role map after the manager’s click; anything off the map to IT with the request and the reason. Every action is logged with who approved it. The model classifies and drafts; the identity provider executes; nobody is granted anything by a language model’s judgement.
Which help desks and identity providers does it work with?
Jira Service Management, Freshservice, Zendesk and — as a custom build — ServiceNow for tickets; Okta, Microsoft Entra ID and Google Workspace for identity; Jamf, Intune and Kandji for devices; Slack and Teams as the front door. Hardware provisioning and approval matrices by department are custom builds.
What happens during an outage?
The bot switches to the incident playbook: it answers “is X down?” from the status page or the incident channel, stops opening duplicate tickets, tells requesters where updates will appear, and collects the reports into one incident ticket for the engineer. The playbook is a rule you write; the workflow follows it.
What this blueprint is built on.
Vendor documentation the steps rely on, and the rules the guardrails are written against.
- Okta — API reference developer.okta.com/docs/reference/
- Microsoft Graph — overview learn.microsoft.com/en-us/graph/overview
- Jamf — developer portal developer.jamf.com/