How to Auto-Generate New-Hire IT Setup Checklists with Claude

The short answer: Claude turns a role definition, an entitlement list and market-specific requirements into a complete new-hire IT checklist in seconds, and regenerates it whenever any of those change. What it cannot do is create accounts, approve access, or enrol the device — that is your identity system, an approval workflow, and Intune or Apple Business Manager. Use the checklist as the specification, not the automation.

Every company that has hired more than twenty people has a new-hire IT checklist somewhere, usually written by someone who left two years ago. It lists an email account, a laptop, a VPN client replaced last spring, and a line near the bottom saying "add to relevant groups". Nobody owns it, nobody versions it, and it is consulted for the first time in months on the Monday morning when somebody new is standing in reception.

The checklist is not really the problem. Most companies know roughly what a new hire needs. What they lack is a way to keep that knowledge current across a dozen roles, three countries and an app estate that changes every quarter — and to produce the right version of it, for the right person, on demand. That is a generation problem, which happens to be exactly what a language model is good at.

Why Onboarding Checklists Are Always Out of Date

They describe tools, not roles. A checklist saying "install the CRM" was written when there was one CRM and everyone used it. The moment sales, support and finance need different access to the same system, a tool-shaped list stops answering the question that matters: what this specific person should be able to do.

They are written once and never versioned. The SSO rollout, the new expense system, the endpoint agent that replaced the old one — each changed the correct answer, and none triggered an edit to the document. Nobody notices until a new hire spends day three without access to something obvious.

They assume one market. A checklist built around a Singapore office quietly breaks in Shanghai, where procurement lead times, network reachability and the applicable privacy regime all differ. Teams usually discover this the first time they onboard outside the home market, in the worst possible way.

They stop at the handover, and nobody owns them. Most checklists end when the laptop is delivered — nothing about the ninety-day access review, nothing about the reverse process. Onboarding sits between HR, IT and the hiring manager, which means it sits with whoever is least able to say no, and the document decays because maintaining it is on nobody's objectives.

Building a Role-Aware Checklist Generator

The shift is small but real: stop maintaining a checklist, and start maintaining the inputs it is derived from. The list itself becomes disposable output you regenerate whenever you need it.

Feeding Claude the Inputs That Matter

A useful generator needs six things, and output quality is almost entirely determined by how honestly you write them down.

The role, described by what it does. Not the job title — the systems it touches and the decisions it makes. "Handles customer payment data" tells the model something a title never will.

The entity and market. Which legal entity employs the person, which office they sit in, and which country's rules apply to their data and device. This field alone turns one generic list into genuinely different ones.

The device standard. What hardware this role gets, who supplies it, how long local procurement takes, and whether it is corporate-owned or a personal device brought under management. That last distinction changes almost every step that follows.

The entitlement map. Which groups, licences and application roles correspond to which job function. It usually exists only in someone's head or a spreadsheet — writing it down is the highest-value hour here.

The approval rules. What can be granted automatically, what needs a manager, what needs a data owner. The model marks these; it never resolves them.

The timeline. What must be true before day one, what happens on day one, and what happens at thirty and ninety days.

Keep these as a small set of reference documents rather than pasting them into every conversation. Claude's Projects feature is built for exactly this — a persistent context every conversation in that project can see — so the role matrix and entitlement map live in one place and get updated once. Check Anthropic's current documentation for what is available on your plan, since this differs between the consumer product, Team plans and the API.

An Output Format People Will Actually Follow

Ask for the checklist grouped by owner, not by system, so each group can be handed to a different person without editing, and order within each group by deadline rather than importance — the person doing the work needs to know what blocks day one.

Require four fields on every line: the owner, the system, the prerequisite that must already be done, and an observable done-condition. "Set up email" is not a checklist item. "Mailbox created in the SG tenant, licence assigned, test message received — IT, requires HR record complete" is one, because you can look at it and know whether it happened.

Fix a machine-readable format in the prompt and keep it stable — Markdown pastes cleanly into most wikis, CSV imports into a ticketing system — because stability is what lets you diff this month's output against last month's.

Finally, instruct the model to flag uncertainty rather than fill it in. An item it is unsure about should appear as an open question addressed to a named owner. A checklist that quietly invents an approval step is worse than one admitting it does not know.

A Worked Example — A Sales Hire in Singapore and an Engineer in Shanghai

Two people, same company, same start date, almost nothing in common past the first three lines.

The Singapore sales hire needs a corporate Windows laptop, in stock locally and shippable pre-registered so it configures itself at first sign-in. Identity is straightforward: a corporate tenant account, group membership granting the standard productivity suite, and a CRM role scoped to their territory rather than global read. Because they handle customer contact data, the checklist carries a Personal Data Protection Act briefing as a real item with a completion record, not a line in a welcome email. Day-one access works because nothing in that chain has a long lead time.

The Shanghai engineer's checklist diverges almost immediately. Device procurement is a local process with its own lead time, so the trigger date moves weeks earlier. Network access is a design question rather than a checkbox, because reachability of overseas collaboration services from a mainland office is genuinely variable and needs validating, not assuming. The applicable regime is the Personal Information Protection Law, which changes what training is required and what the company must be able to evidence. Internal communication may run on a different platform than the rest of the company — an additional account, and an additional offboarding step. And the engineer needs production access, the item on either list that should never be granted automatically.

The model does not know these differences on its own; it knows them because you wrote them into the entity and market inputs. The point is that once those inputs exist, producing the correct list for either person costs nothing, and both stay correct as the underlying facts change.

AI-Generated Checklists Versus a Static Template Versus Automated Provisioning

• Setup effort — The static template wins for the first hire and loses forever after. Generation costs an afternoon of writing down the entitlement map. Automated provisioning is a project with a budget, measured in weeks.
• Accuracy six months later — Generation wins clearly. A template is accurate the day it is written and decays silently. A generator is only as stale as its inputs, which are small enough that someone will actually update them.
• Handling an unusual role — Generation wins outright. A contractor with restricted access, a rehire, a country manager in a one-employee market — exactly the cases a template cannot cover and a rules-based system needs a change request for.
• Speed on day one — Automated provisioning wins, and it is not close. A checklist tells a human what to do; zero-touch enrolment simply does it.
• Auditability — Automated provisioning wins, generation second. A provisioning system produces logs; a generated checklist produces a dated artefact; a wiki page edited by nine people produces an argument.

These are not competitors. The generated checklist is the specification; automated provisioning is the implementation. Companies that skip straight to automation without writing down the entitlement map usually end up automating access decisions nobody ever agreed to.

The Part AI Can't Do — Approval, Enrolment, and the Riskier Half

Approval is a control, not a step. If an item grants access to customer data, financial systems or production infrastructure, a named human must approve it and that approval must be recorded. The model can identify which items need approval and who should give it, but must never decide the answer — and no generated checklist should be wired into a system that grants access.

Enrolment is where the real automation lives. Windows Autopilot registers a device to your tenant so a user signing in for the first time receives their configuration, policies and applications without IT touching the machine. Apple Business Manager's automated device enrolment does the equivalent for Macs, iPhones and iPads, and Android Enterprise offers a zero-touch path for Android hardware. All three require the device to be registered — typically by the reseller or via its hardware identifier — before the box is opened, which is why procurement belongs in the checklist weeks before the start date. Requirements differ by platform and change; confirm them in the vendor documentation before designing around them.

Offboarding is the riskier half and gets a fraction of the attention. A missed onboarding item is an inconvenience on day one. A missed offboarding item is a live account belonging to someone who no longer works for you, and it can persist for years. Generate the leaver checklist from the same inputs, at the same time, and store it with the joiner one.

Getting This Right — Identity, Device Enrolment, and When to Bring in IT

There is a data question underneath this that is easy to miss because the content feels administrative. A prompt describing a role in the abstract is harmless. A prompt including a named individual, their start date, salary band or personal contact details is a processing activity involving personal data, under whichever regime applies — Hong Kong's PDPO, Singapore's PDPA, or the PRC's PIPL. The rule is simple: generate checklists from roles, not from people. If you need a named version, substitute the name into an already-generated template locally rather than sending the person's details to the model at all. On the API rather than the consumer product, review the data-handling terms that apply to your account, since they differ.

The other half is what the checklist points at. Zero-touch enrolment, group-based entitlements and a device-compliance baseline turn a generated list into an actual workflow, and getting them right is a configuration project rather than a prompt. Brocent's MDM and BYOD management practice covers that layer — enrolment profiles, compliance policies, and the difference between a corporate device and a personal one under management. Our AI+ support practice helps design the prompts, reference documents and review step so the output is trustworthy rather than merely fast, and managed IT support runs the joiner-mover-leaver process once defined. If the underlying process is not written down yet, our guide to auto-generating SOPs with ChatGPT and Notion is the right first step, because generating a checklist from an undocumented process just produces a confident-sounding guess. Brocent has run managed IT across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016.

Frequently Asked Questions

Does this actually create the accounts?

No, and it should not. The model produces a specification — what should exist, who owns each item, and what "done" looks like. Creating the account, assigning the licence and granting group membership happen in your identity system, ideally driven by role-based groups. Connecting a language model directly to an account-provisioning API is technically possible and a bad idea for exactly the reason it is appealing: it removes the human who would have caught the mistake.

How do we keep the entitlements right for each role?

By maintaining the entitlement map, the one artefact worth real effort. Write down which groups, licences and application roles belong to each job function, review it when a system is added or replaced, and treat it as the input the checklist is generated from. If your directory already grants access through role-based groups, the map mostly describes what your groups already do — which is also a good way to discover that some do more than anyone intended.

What about offboarding — isn't that the riskier half?

Yes, and it is usually the neglected one. Generate the leaver checklist alongside the joiner one, from the same role description, and keep them together. It should cover account disablement rather than deletion, session and token revocation, device return and wipe, mailbox delegation, and any market-specific system that exists in only one office. The failure mode to design against is not forgetting the main account — it is the third-party tool nobody remembered was connected.

Can it handle different markets' device and compliance requirements?

Only to the extent you tell it what they are. The model has general knowledge of the major regimes, but not your entities, your local procurement realities, or which systems are reachable from which office. Write those into the market input, keep them current, and require the output to cite which market rule produced each item, so a wrong assumption is visible rather than buried.

Do we need Intune specifically, or will any MDM do?

Any modern MDM supporting zero-touch enrolment for your device mix will do. Intune is the natural choice if you are already on Microsoft 365, because identity, device and application layers sit on one platform. What matters is the capability, not the product: devices registered before shipping, configuration applied at first sign-in, and a compliance baseline access policy can depend on.

Where to Start

Pick the role you hire most often and write down its six inputs — role, entity, device, entitlements, approvals, timeline. That is the whole investment. Generate the checklist, then compare it line by line against what actually happened for the last person you onboarded in that role, watching the gaps in both directions: what the model missed, and what your real process does that nobody wrote down. The second list is usually more interesting. Then generate the leaver checklist from the same description. If you would rather have the checklist, the enrolment and the access model designed together, get in touch.