← All posts

Use cases

The HR guide to onboarding employees on your software stack (when you don't own any of the tools)

Shaul Gittelman · Founder, Guidely · August 2, 2026 · 4 min read

HR owns onboarding. HR does not own the tools.

That's the structural bind under most bad week-one experiences, and it's worth stating plainly because everyone involved experiences it as a series of small annoyances instead of as one problem. The new hire needs to submit a timesheet in the HRIS, file an expense, pick benefits in a portal that looks like it was built in 2011, request a laptop through the IT service desk, and also learn the CRM or the ticketing system or whatever their actual team runs on. Five-plus tools, owned by four different departments, each documented (or not) in that department's preferred corner of the wiki, at that department's level of freshness.

HR's job is to assemble a coherent first week out of that — with no admin rights to any of it. So the onboarding packet becomes a links page: here's the expense policy doc, here's IT's setup guide, here's a Loom someone in sales recorded in 2024. And by Thursday, the new hire is doing what every new hire does when the links page fails them: asking their manager, asking their buddy, or — because HR sent the packet — asking HR. Congratulations, you're the help desk for tools you can't even log into as an admin.

Two kinds of not-knowing

Getting out of the bind starts with splitting the problem. New hires get stuck on software in two distinct ways, and they need different fixes:

Universal tasks — the things every employee does in their first two weeks, in tools HR chose: enroll in benefits, set up direct deposit, submit the first expense, request equipment, log time off. This list is short (usually 8–12 tasks), nearly identical for every hire, and changes only when a vendor changes. It is, frankly, a solved problem that most companies haven't bothered to solve: build a first-week checklist of those tasks and attach a current, step-by-step guide to each one. Not the vendor's generic help center — yours, with your payroll provider's actual screens and your expense categories.

Role tasks — the CRM for sales, the helpdesk for support, the admin consoles for IT. HR should not write these guides and mostly can't. What HR can do is own the standard: every team maintains a "first ten tasks" list for its core tools (the exercise from the CRM playbook), and onboarding isn't "done" for a role until that list exists. HR as the orchestrator of the format, tool owners as the authors of the content. That division survives reorgs; "HR documents everything" does not.

The universal list is also where you should be ruthless about format. Benefits enrollment doesn't need a 20-minute all-hands session in week one — it's a click-path with a deadline, the purest case there is for a guide over a meeting. Save the humans for the things that need humans: culture, expectations, the people themselves.

The maintenance problem is the real problem

Here's what kills these programs, a year in: the payroll vendor redesigns its portal, and nobody tells HR. The screenshots in the enrollment guide now show a UI that doesn't exist. The new hire hits step 3, can't find the button, and concludes — correctly — that the guide can't be trusted. One stale guide taxes the credibility of every fresh one.

This is the quiet reason onboarding content decays into a links page: links to other people's docs can't go stale in a way that's your fault. It's also why I keep coming back to the same argument from different doors: static documentation of living software rots by default, and the only durable fixes are either paying the maintenance tax forever or moving to guidance that reads the tool as it is right now.

That second option is the product I sell, so, disclosure made: with an extension-based guide layer, "attach a guide to each checklist task" stops meaning "maintain 12 screenshot docs." The new hire asks "how do I set up direct deposit?" on the payroll portal and gets walked through the live page — today's build of it, whatever the vendor shipped this quarter. For HR specifically, this has a property nothing else in your stack has: it works identically across all the tools in the first-week checklist, including the four you don't administer, because it never needed admin access in the first place — it guides on whatever page the employee is on.

And it gives HR something it almost never gets: visibility. Completion data per task, per hire — who got through benefits enrollment, which step of the expense flow people abandon, what new hires actually ask in week one. That last one is the gold. The ask-log from your first ten hires is a ranked, verbatim list of everything your onboarding forgot to cover, in the hires' own words. No survey gets you that, because surveys ask in week four what people were confused by in week one, and by week four they've forgotten — the confusion got resolved by interrupting somebody.

Start smaller than feels serious

The full program — universal checklist, per-role task lists, guides attached, freshness owned — sounds like a quarter-long L&D initiative. Don't run it as one. Take your next new hire, write down every software question they ask in their first two weeks, and count the ones that were asked of a human because no self-serve answer was within reach. That number is your baseline, the list is your backlog, and the top three items are next month's guides. Onboarding programs built from real stuck-points beat onboarding programs built in planning offsites, every single time.

There's a dedicated page on Guidely for HR & L&D teams at /for/hr.