AI for IT Teams: 4 Workflows That Actually Save Time (With Prompts)

AI only delivers value for IT teams when it maps to work that actually happens every week. That means a specific prompt applied to a specific repeatable workflow, turning what used to take an hour into something that takes five minutes. The IT teams getting the most out of AI right now are not doing anything exotic. They identified where their time goes, wrote a prompt for it, and made it a permanent part of how they work.

Michael Curatolo, IT Manager at Nutrafol, and Zaafir Kherani, a product leader at Rippling, walked through exactly that in a recent webinar on AI for IT (you can watch that session here). Together they covered four workflows, four prompts, and a clear before-and-after on each. What follows covers each one: the problem it solves, the actual prompt, what good output looks like, and how it runs inside Rippling AI.

Key Learnings

• A role-specific onboarding provisioning checklist built from a single AI prompt eliminates the tribal knowledge problem and reduces day-one provisioning failures caused by missed steps or incorrect sequencing.

• AI-generated documentation lowers the barrier to writing SOPs and knowledge base articles, but the bigger unlock is AI-powered retrieval — connecting employee natural language questions to the right article before a ticket is ever created.

• Roughly 30-40% of IT ticket volume is L1 work that does not require a human (a stat shared during a Rippling IT webinar). An AI triage prompt can resolve common issues end-to-end and, when escalation is needed, hand off a structured context note so the technician never starts from scratch.

• Weekly ticket summaries and incident notes written manually take 45 minutes to an hour. With AI, they take minutes and the quality is more consistent because nothing gets left out under time pressure.

• The teams getting the most from AI are the ones who start narrow, iterate on the prompt, and treat the first output as a draft rather than a final answer.

Use Case 1: Role-Based Onboarding Provisioning Checklist

The Problem

IT provisioning for a new hire is the highest-volume, highest-stakes workflow most IT teams run. It is also the one most likely to fail in ways that are invisible until day one.

The sequence is long: procure and allocate hardware, ship to the employee’s home address, guide them through MDM enrollment (zero-touch or manual), create email accounts, provision SSO-connected apps, and send individual invitations for everything that sits outside SSO. Each step has dependencies on the previous one, and each dependency is a failure point. A typo in the employee’s name from HR cascades. A shipping delay pushes enrollment. An app that was not flagged as role-specific gets missed entirely.

For a lean IT team running multiple new hires per week, the manual coordination cost compounds fast. The standard workaround — a checklist in a spreadsheet or, worse, in someone’s head — fails when that person is out, when the role is unusual, or when a new IT team member runs the process for the first time.

The Prompt

“I am onboarding a new [Job Title] in the [Department] department. Their start date is [Start Date]. Generate a complete IT provisioning checklist that covers hardware setup, software access, account creation, and security requirements based on their role. Flag anything that needs to be done more than 48 hours in advance.”

The three variables — job title, department, and start date — are what separate this from a generic checklist. Job title drives which apps get provisioned. The department determines group membership in your IdP and which policies apply. The start date triggers the 48-hour flag, which surfaces hardware procurement and MDM pre-enrollment tasks that break if started too late.

What Good Output Looks Like

A well-executed version of this prompt returns a sequenced checklist grouped by category: hardware, identity and access, SaaS provisioning, security configuration, and day-one readiness. Items that require lead time are flagged explicitly. Nothing is left as an implicit assumption. A new IT team member who has never run this onboarding before can execute it correctly without asking anyone for help.

In Rippling AI

The prompt above works in any AI tool. But Zaafir Kherani described why Rippling AI takes a different approach to the same problem: “The bigger unlock is that when the underlying data already lives in one place — the employee’s role, their department, their location, their manager, the device they’re supposed to get, the app policies — it’s all part of the same workflow. IT isn’t rebuilding the checklist from memory every time. The system has that context. And so AI can turn that context into the actual work that has to happen.”

In practice, that means Rippling AI does not need you to describe the role, the department, and the access requirements in the prompt. It already knows them from the employee record. The checklist it generates is grounded in your actual environment, not a generic approximation of it. For IT teams running Rippling IT, that is a meaningful difference on day-one provisioning failures — the most common source is a step that was missed because the context was wrong, not because the admin was careless.

Use Case 2: SOP, Knowledge Base Article, and Runbook Generation

The Problem

Documentation never gets written: resolving an issue while simultaneously documenting it in a structured format is genuinely hard, and under time pressure, the notes get rushed or skipped.

Documentation exists but nobody finds it: an employee who needs to reset their MFA on a new device will search “how do I get into Okta on my new phone” rather than “MFA device enrollment procedure.” If the knowledge base relies on keyword matching, that article might as well not exist.

Both problems have a real cost. Undocumented resolutions mean the next technician who encounters the same issue starts from zero. Unfindable documentation drives repeat tickets that IT has to handle manually, which is the opposite of what a knowledge base is supposed to do.

When documentation does exist but was written by multiple people over time, inconsistency in format and depth makes it harder to maintain. One article has numbered steps, another has walls of text. One covers three troubleshooting scenarios, another covers none. A strong AI system can help you control the chaos.

The Prompt

Write a [SOP / KB article / Runbook] for [topic]. The audience is [IT helpdesk / end users / IT manager]. Cover the following: [brief outline of steps or scope]. Format it with a title, a one-sentence purpose statement, numbered step-by-step instructions, and a troubleshooting section for the three most common issues. Use plain language that a non-technical employee can follow without prior context.

The audience variable matters more than it looks. An SOP written for an IT helpdesk technician can use technical terminology, assume familiarity with your MDM and IdP, and skip explanations of basic concepts. The same article written for end users needs plain language, no jargon, and anticipation of the questions a non-technical employee will ask when something does not go as expected. Specifying the audience in the prompt produces meaningfully different output and prevents the common failure of writing documentation that only IT can understand, then being surprised when employees keep submitting tickets.

What Good Output Looks Like

A well-formed knowledge base article from this prompt includes:

• A clear title (not “MDM Enrollment” but “How to Enroll Your Mac in Company Device Management”)

• A one-sentence purpose statement that tells the reader exactly what they will be able to do after reading

• Numbered steps that are specific enough to follow without guessing

• A troubleshooting section that addresses the three issues employees actually encounter

The troubleshooting section is often what separates documentation that deflects tickets from documentation that does not.

In Rippling AI

Zaafir Kherani frames the documentation use case in two parts: “The obvious one is drafting. AI can turn a rough outline into an SOP or runbook in seconds, and that alone lowers the barrier to writing things down. But I think the even more important part is retrieval. Employees don’t search the way IT files things.”

What makes Rippling AI different for documentation is not just that it can generate a first draft faster — any AI tool should be able to do that. The differentiation is that the retrieval problem largely solves itself when the AI already has access to the employee record, device state, app assignments, and policy history that live in the same platform.

Rippling’s MCP (Model Context Protocol) server extends this further, allowing any compatible AI tool — Claude, Cursor, and others — to connect directly to your Rippling workspace and query that same live data. When an employee asks a natural language question, the AI can connect that question to the right answer using context it already has about who they are and what environment they are in, rather than searching across disconnected systems.

As Zaafir Kherani put it: “When AI understands the natural language question and can connect it to the right internal documentation, you prevent tickets before they happen. That’s a very different support model.”

Use Case 3: L1 Support Triage and Intelligent Escalation

The Problem

IT support teams consistently estimate that 30-40% of their ticket volume is L1 work:

• Password resets

• Access requests

• VPN issues

• App setup questions

• Misrouted tickets from other departments

These tickets do not require technical judgment. They require a consistent process, the right documentation, and someone — or something — to execute the steps.

The real cost is not just the time spent on L1 tickets. It is the context loss that happens when a ticket does need to escalate. An AI that handles the initial triage but cannot pass meaningful context to a human technician has just moved the work around rather than reduced it. The technician still has to ask the employee the same questions again, reconstruct what was already tried, and figure out why the ticket was escalated — a worse experience than if the employee had just submitted a ticket directly.

The Prompt

You are an IT support assistant. When a user reports an issue, ask clarifying questions one at a time to gather everything needed before escalating. Collect: the user’s name, device type, operating system, a description of the issue, when it started, any error messages they see, and what they have already tried. If the issue can be resolved with self-service, walk the user through the steps. If it needs a human, summarize the full context in a structured handoff note so the technician can start without asking the same questions again.

The phrase “one at a time” in the prompt is deliberate. Asking all clarifying questions in a single message overwhelms users and reduces response quality. Sequential, conversational questioning produces more complete and accurate information. The structured handoff note at the end is what makes escalation efficient: the technician receives a context package with everything already collected, categorized, and ready to act on.

What Good Output Looks Like

For self-service resolutions, the AI walks the employee through the steps in plain language, checks for success, and closes the interaction. For escalations, it produces a structured note — and nothing needs to be asked twice:

• User name

• Device type

• OS version

• Issue description

• Onset timing

• Error messages verbatim

• Steps already attempted

The real-world implementation typically involves integrating an AI platform with both Slack and your ticketing system. The AI serves as a virtual agent in the ticket queue and as a chatbot in Slack. Week one requires close monitoring to catch cases where the agent cannot resolve an issue but also cannot route it correctly. Finding and correcting those edge cases in the first two weeks is what determines whether adoption sticks.

In Rippling AI

Zaafir Kherani described the Rippling AI difference on support this way: “The AI isn’t just reading a help article. It can use the employee record and the role, team, device, apps, and policies and workflow history all in one place. The answer gets grounded in the actual environment, not a generic one. And any next action stays inside governed workflows, so things like permissions, approvals, and audit logs are all handled.”

He gave a concrete example: an employee asks for access to GitHub.

• In a generic AI tool, that request goes into the ticket queue.

• In Rippling AI, the system already knows who the employee is, what department they are in, and what the access policy is for that department. If they qualify automatically, access gets provisioned. If approval is required, the right approver receives a structured request with all the context attached and can approve with a single click. The ticket never sits in the queue waiting for a human to perform a 30-second task.

This is what separates AI that reduces ticket volume from AI that merely categorizes it. Rippling is building natively into this with an upcoming Help Desk product that brings support directly into the same platform where employee records, device data, and access policies already live. Rather than connecting a third-party ticketing tool to Rippling and hoping the integration holds, IT teams will be able to manage tickets, automate L1 resolution, and escalate with full context inside a single system.

Use Case 4: Incident Summaries and Weekly Ticket Reports

The Problem

IT teams generate two types of written work after the actual work is done: ticket notes for individual issues, and summary reports for leadership. Both are important. Both get rushed or skipped when the queue is full.

Ticket notes are where institutional IT knowledge actually lives — what was reported, what was checked, and what fixed it. When notes are incomplete, the next technician who encounters the same issue has to rediscover the solution from scratch. When notes are consistent and detailed, the knowledge base gets richer over time and repeat issues get resolved faster.

Leadership summaries are different — and high visibility. Producing a weekly status report by hand can take 45 minutes to an hour. Multiply that across a year and it is a significant chunk of a senior IT person’s time spent on formatting and summarizing work that is already documented in tickets.

The Prompts

Prompt A — Weekly Ticket Summary for Leadership:

Summarize all IT support tickets closed this week into a brief status report for leadership. Group them by category: hardware, access, software, and other. Call out any issue that came up more than once this week and likely needs a permanent fix. Flag any tickets that exceeded our SLA and explain why. Keep the tone factual and clear.

Prompt B — Individual Ticket Notes:

Using the conversation history from this support ticket, write a complete set of internal notes summarizing: the issue reported, steps taken to diagnose it, the resolution, time to resolution, and any follow-up actions required. Write it so any IT team member can pick up where we left off without needing to ask the employee to repeat themselves.

Prompt A produces a leadership-ready status report grouped by category, with recurring issues surfaced automatically as candidates for a permanent fix rather than another round of manual resolution. Prompt B does something equally valuable on the individual ticket level, converting raw conversation history into a clean, consistent set of notes that any technician on the team can pick up and run with.

What Good Output Looks Like

A good weekly summary groups tickets cleanly, calls out patterns (if password reset requests spiked this week, that is worth noting), flags SLA breaches with brief context, and keeps the tone factual rather than defensive or vague. A good ticket note reads like it was written by a careful technician who had unlimited time — because AI does not rush.

In Rippling AI

Zaafir Kherani noted that ticket notes and leadership summaries tend to be underestimated as AI use cases: “Leadership summaries are visible, so teams naturally care about them. But ticket notes are where institutional IT knowledge actually lives. When those notes are rushed or missing, the next person has to rediscover the same thing. AI is very good at turning messy ticket history into a clean handoff. And when that AI has access to system context — what device, what access, what was changed — those notes get that much more useful because they’re grounded in what actually happened.”

The compounding effect here matters. Individually, a better ticket note saves the next technician ten minutes. At scale, across hundreds of tickets a month, that institutional knowledge accumulates into a knowledge base that is genuinely useful rather than one that everyone knows is incomplete and ignores.

Three Mistakes IT Teams Make When Starting With AI

• Starting too broad: A prompt like “help me with IT” produces output that is useless for operational work. The teams getting value are specific about the workflow, the audience, the format, and the constraints. Specificity is not optional — it is what makes AI behave like an operational system rather than a chatbot.

• Automating everything at once: Pick one workflow, run it for two weeks, fix the edge cases, and then add the next one. Trying to implement all four use cases simultaneously means none of them gets the iteration it needs to work reliably.

• Treating the first output as final: The first response is a draft. Review it, tighten the prompt based on what was off, keep what worked, and run it again. The goal is a prompt that produces consistent, reliable output every time — and that takes a few iterations to get right.

What Gets Done When the Repetitive Work Disappears

The honest answer to “what does your team do with the time AI saves?” is not a list of strategic initiatives. It is the work that has been on the backlog for six months. The complex escalation that deserves a real investigation instead of five rushed minutes. The runbook that never got written because there was never time to write it. Taking an actual lunch.

That is what makes IT AI adoption different from AI adoption in other functions. IT teams are not trying to do more. They are trying to do what they already have to do without it taking everything they have.

The four prompts covered in this article are a starting point. Pick the one that maps to your biggest time sink, run it this week, and see what the output looks like. The goal is not a perfect first draft. It is a repeatable pattern that works reliably enough that you stop thinking about that workflow and start thinking about the next one.

For more prompts and templates for IT workflows, explore Rippling’s AI Prompt Library. For a deeper look at IT onboarding specifically, the complete IT onboarding checklist covers the full provisioning sequence from pre-boarding through the first 90 days.

This article draws on a Rippling webinar featuring Michael Curatolo, IT Manager at Nutrafol, and Zaafir Kherani, Product at Rippling. The session was the first of three on AI for IT.